7/23/2019 IdSW - U1 - Ingeniera de Requerimientos

1/8

INGENIERA DE SOFTWARUnidad 2 - Modelo de Requerimient

arlos Ale!andro asta"os #$%

2'(' Tareas de la In)enier*a de Requisitos2'2' T+,ni,as de la In)enier*a de Requisitos2'' Modelado de requisitos

2'.' /erramientas ASE %ara la In)enier*a de requisitos'

7/23/2019 IdSW - U1 - Ingeniera de Requerimientos

2/8

INDICE

Introduccin.'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Tareas de la Ingeniera de Requisitos.''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' .

Tcnicas de la Ingeniera de Requerimientos.'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' .

Modelado de requisitos.'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 0

Herramientas Case.'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 0

Conclusin'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 1

Referencias'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

2

7/23/2019 IdSW - U1 - Ingeniera de Requerimientos

3/8

Modelo de Requerimientos.

Introduccin.

En la ingeniera de sistemasy laingeniera de software, la Ingeniera de

requisitoso Ingeniera de requerimientoscomrende todas las tareas relacionadas con la

determinacin de las necesidades o de las condiciones a satisfacer ara un software nue!o o

modificado, tomando en cuenta los di!ersos requisitos de lasartes interesadas, que ueden

entrar en conflicto entre ellos.

Muc"as !eces se "a#la de requerimientos en !e$ de requisitos% esto se de#e a una mala

traduccin del ingls. &a ala#ra requirementde#e ser traducida como requisito, mientras que

requerimiento se traduce al ingls como request.

El rosito de la ingeniera de requisitos es "acer que los mismos alcancen un estado

timo antes de alcan$ar la fase de dise'o en el royecto. &os #uenos requisitosde#en ser

medi#les, comro#a#les, sin am#ig(edades o contradicciones, etc.

https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_sistemashttps://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_softwarehttps://es.wikipedia.org/wiki/Stakeholderhttps://es.wikipedia.org/wiki/Requisito_(sistemas)https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_sistemashttps://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_softwarehttps://es.wikipedia.org/wiki/Stakeholderhttps://es.wikipedia.org/wiki/Requisito_(sistemas)

7/23/2019 IdSW - U1 - Ingeniera de Requerimientos

4/8

Tareas de la Ingeniera de Requisitos.

)esde un unto de !ista concetual, las acti!idades son de cinco clases.

*#tener requisitos+ a tra!s de entre!istas o comunicacin con clientes o futuros usuarios,

ara sa#er cules son sus e-ectati!as.

nali$ar requisitos+ detectar y corregir las carencias o falencias comunicati!as,

transformando los requisitos o#tenidos de entre!istas y requisitos, en condiciones aroiadas araser tratados en el dise'o.

)ocumentar requisitos+ igual que todas las etaas, los requisitos de#en estar de#idamente

documentados.

/erificar los requisitos+ consiste en comro#ar la imlementacin de los requerimientos.

/alidar los requisitos+ comro#ar que los requisitos imlementados sean funcionales ara lo

que inicialmente se construy el roducto.

Tcnicas de la Ingeniera de Requerimientos.

&a ingeniera de requisitos uede ser un roceso largo y arduo ara el que se requiere de

"a#ilidades sicolgicas. &os nue!os sistemas cam#ian el entorno y las relaciones entre la gente,

as que es imortante identificar a todos los actores in!olucrados, considerar sus necesidades y

asegurar que entienden las imlicaciones de los nue!os sistemas. &os analistas ueden emlear

!arias tcnicas ara o#tener los requisitos del cliente. Histricamente, esto "a incluido tcnicas

tales como las entre!istas, o talleres con gruos ara crear listas de requisitos. Tcnicas ms

modernas incluyen los rototios, y utili$an casos de uso. Cuando sea necesario, el analista

emlear una com#inacin de estos mtodos ara esta#lecer los requisitos e-actos de las

ersonas imlicadas, ara roducir un sistema que resuel!a las necesidades del negocio.

Entrevistas.

&as entre!istas son un mtodo com0n. 1or lo general no se entre!ista a toda la gente que se

relacionar con el sistema, sino a una seleccin de ersonas que reresente a todos los sectores

crticos de la organi$acin, con el nfasis uesto en los sectores ms afectados o que "arn un uso

ms frecuente del nue!o sistema.

Talleres.

&os requisitos tienen a menudo imlicaciones cru$adas desconocidas ara las ersonas

imlicadas indi!iduales y que a menudo no se descu#ren en las entre!istas o quedan

incomletamente definidas durante la misma. Estas imlicaciones cru$adas ueden descu#rirse

reali$ando en un am#iente controlado, talleres facilitados or un analista del negocio, en donde las

ersonas imlicadas artician en discusiones ara descu#rir requisitos, anali$an sus detalles y las

imlicaciones cru$adas. menudo es 0til la seleccin de un secretario dedicado a la

documentacin de la discusin, li#erando al analista del negocio ara centrarse en el roceso de la

definicin de los requisitos y ara dirigir la discusin.

E-isten dos tcnicas de este tio que son las ms utili$adas+ 2rainstorming 3&lu!ia de ideas4

y 5) 35oint lication )e!eloment, )ise'o de licacin Con6unta4. &a diferencia que e-iste

entre am#as tcnicas es que durante la tormenta de ideas se tiene como o#6eti!o generar una gran

cantidad de ideas, es desestructurada y la informacin que se o#tiene uede ser !isual, te-tual

.

7/23/2019 IdSW - U1 - Ingeniera de Requerimientos

5/8

coloquial% mientras que en el 5) el taller es ordenado, la informacin que se o#tiene es !isual y su

o#6eti!o es generar requisitos y la interfa$ del sistema.

)urante una sesin de &lu!ia de ideas, todos los articiantes ueden aortar distintas ideas

en un am#iente li#re de re6uicios. 7ing0n articiante de#e 6u$gar negati!amente la rouesta de

otros, sino que se anotan todas las ideas en una i$arra y sern e!aluadas al final de la sesin. El

rinciio #sico es no descartar de manera aresurada ning0n lanteo, de modo que e-iste la

osi#ilidad de que sur6an otras ideas deri!adas de la idea original y se generan !arios untos de

!ista del ro#lema.

En el 5oint alication de!eloment se tra#a6a directamente so#re los documentos a generar,las temticas que se tratan durante las reuniones siguen un esquema y se #usca que la misma sea

ordenada y racional. 8e define una agenda con los untos rinciales a tratar durante la 6ornada.

Este tio de taller tiene el incon!eniente de que es muy difcil oder reunir a todas los articiantes,

es costoso y generalmente es necesaria ms de una reunin ara esta#lecer los requisitos del

sistema.

Forma de contrato.

En lugar de una entre!ista, se ueden llenar formularios o contratos indicando los requisitos.

En sistemas muy comle6os stos ueden tener centenares de ginas.

Objetivos medibles.

&os requisitos formulados or los usuarios se toman como o#6eti!os generales, a largo la$o,

y en cam#io se los de#e anali$ar una y otra !e$ desde el unto de !ista del sistema "asta

determinar los o#6eti!os crticos del funcionamiento interno que luego darn forma a los

comortamientos arecia#les or el usuario. &uego, se esta#lecen formas de medir el rogreso en

la construccin, ara e!aluar en cualquier momento qu tan a!an$ado se encuentra el royecto.

Prototipos y Casos de uso.

9n rototio es una eque'a muestra, de funcionalidad limitada, de cmo sera el roducto

final una !e$ terminado. yudan a conocer la oinin de los usuarios y rectificar algunos asectos

antes de llegar al roducto terminado.

9n caso de uso es una tcnica ara documentar osi#les requisitos, graficando la relacin

del sistema con los usuarios u otros sistemas. )ado que el roio sistema aarece como una ca6a

negra, y slo se reresenta su interaccin con entidades e-ternas, ermite omitir dic"os asectos y

determinar los que realmente corresonden a las entidades e-ternas. El o#6eti!o de esta rctica

es me6orar la comunicacin entre los usuarios y los desarrolladores, mediante la rue#a temrana

de rototios ara minimi$ar cam#ios "acia el final del royecto y reducir los costes finales. Esta

tcnica se enfrenta a los siguientes eligros otenciales.

los directi!os, una !e$ que !en un rototio, les cuesta comrender que queda muc"o

tra#a6o or "acer ara comletar el dise'o final.&os dise'adores tienden a reutili$ar el cdigo de los

rototios or temor a :erder el tiemo; al comen$ar otra !e$.&os rototios ayudan

rincialmente a las decisiones del dise'o y de la interfa$ de usuario. 8in em#argo, no

roorcionan e-lcitamente cules son los requisitos.&os dise'adores y los usuarios finalesueden centrarse demasiado en el dise'o de la interfa$ de usuario y demasiado oco en roducir

un sistema que sir!a el roceso del negocio.

&os rototios ueden ser+ diagramas, alicaciones oerati!as con funcionalidades

sinteti$adas. &os diagramas, en los casos donde se esera que el software final tenga dise'o

grfico, se reali$an en una !ariedad de documentos de dise'o grficos y a menudo elimina todo el

color del dise'o del software 3es decir utili$ar una gama de grises4. Esto ayuda a re!enir la

confusin so#re la aariencia final de la alicacin.

3

7/23/2019 IdSW - U1 - Ingeniera de Requerimientos

6/8

Modelado de requisitos.

Descripcin del problema.

Es un resumen reliminar de las necesidades que sir!e como unto de artida ara

comrender los requisitos del sistema.

Modelado de casos de uso.

)escri#e un sistema en trminos de sus distintas formas de utili$acin, cada una de las

cuales se conoce como casos de uso los cuales se comonen de una secuencia de e!entos

iniciada or el usuario, lo cual indica que ara comrender los casos de uso de un sistema rimero

es necesario sa#er quines son sus usuarios ues de "ec"o los usuarios tam#in son diferentes.

1ara ellos se define con el conceto de actor al tio de usuario que est in!olucrado en la

utili$acin de un sistema y que adems es una entidad e-terna al roio sistema siendo entonces

el actor y el caso de uso las entidades #sicas del modelo de casos de uso.

&os casos de uso con las ideas simles y rcticas que no requieren de muc"as "a#ilidades

tecnolgicas arar ser utili$adas.

&os ctores or otro lado son las entidades distintas a los usuarios, en el sentido que estos

son las ersonas reales que utili$arn el sistema, mientras que los actores reresentan cierta

funcin que una ersona real reali$a.

Herramientas Case.

&as "erramientas C8E 3Comuter ided 8oftware Engineering, Ingeniera de 8oftware

sistida or Comutadora4 son di!ersas alicaciones informticas o rogramas informticos

destinadas a aumentar la roducti!idad en el desarrollo de software reduciendo el costo de las

mismas en trminos de tiemo y de dinero.

Estas "erramientas ueden ayudar en todos los asectos del ciclo de !ida de desarrollo del

software en tareas como el roceso de reali$ar un dise'o del royecto, clculo de costos,

imlementacin de arte del cdigo automticamente con el dise'o dado, comilacin automtica,

documentacin o deteccin de errores entre otras.

7/23/2019 IdSW - U1 - Ingeniera de Requerimientos

7/8

Me6orar la roducti!idad del software.

umentar la calidad del software.

Reducir el tiemo y costo de desarrollo y mantenimiento de los sistemas informticos.

Me6orar la lanificacin de un royecto.

umentar la #i#lioteca de conocimiento informtico de una emresa ayudando a la

#0squeda de soluciones ara los requisitos.

utomati$ar el desarrollo del software, la documentacin, la generacin de cdigo, las

rue#as de errores y la gestin del royecto.yuda a la reutili$acin del software, orta#ilidad y estandari$acin de la documentacin.

Destin glo#al en todas las fases de desarrollo de software con una misma "erramienta.

acilitar el uso de las distintas metodologas roias de la ingeniera del software.

#a clasi$icacin de las herramientas C!E es"

&as lataformas que soortan.

&as fases del ciclo de !ida del desarrollo de sistemas que cu#ren.

&a arquitectura de las alicaciones que roducen.

8u funcionalidad.

Conclusin

Esta es la etaa de rearacin indisensa#le ara la correcta creacin de un

software a medida.

Cada una de las etaas y asa de cada una de ellas se de#en reali$ar de manera

secuencial y ordenada con el rosito de no omitir ning0n detalle ara que as el

resultado final sea el deseado.

)e manera imerati!a la recoilacin de informacin es la #ase ara que esta etaa

y las su#secuentes uedan reali$ase sin contra tiemos y del mismo modo la

identificacin de los ctores y usuarios as como la estructuracin e identificacin de

Casos de uso garanti$an una #ase slida ara el desarrollo del sistema.

1

7/23/2019 IdSW - U1 - Ingeniera de Requerimientos

8/8

Referencias

Ingeniera de 8oftware orientada a o#6etos con 9M&, 5/ e Internet. lfredo Fit$enfeld.

Ingeniera de 8oftware. 8omer!ille.

www.wiGiedia.com

www.monografas.com

www.google.com

4