EST.

Victor Mamani Hualpa

COD: 2011 119041
CAPITULO 5: COMPRENSION
DE LOS REQUERIMIENTOS
UNIVESID!D N!CION!" #O$E %!S!DE $OHM!NN UNIVESID!D N!CION!" #O$E %!S!DE $OHM!NN
&!CU"T!D DE IN$ENIE'! &!CU"T!D DE IN$ENIE'!
E.!.(. IN$. EN IN&OM)TIC! * SISTEM!S E.!.(. IN$. EN IN&OM)TIC! * SISTEM!S
INTRODUCCIN

Entender los requerimientos de un problema es una tarea

difcil.
El usuario final y los clientes a veces no saben lo que
necesitan.

Existe a veces una falta de comprensin de las caractersticas

y funciones que le beneficiarn.
I. INGENIERA DE
REQUERIMIENTOS

Es un espectro amplio de tareas y tcnicas que llevan a entender los

requerimientos.

Comienza durante la actividad de comunicacin y continua en la de

modelado.
Debe adaptarse a las necesidades del:
roceso
royecto
roducto
ersonas que !acen el traba"o

Establece una base solida para el dise#o y la construccin. $in esta% el

soft&are resultante tiene alta probabilidad de no satisfacer las
necesidades del cliente.
roporciona el mecanismo apropiado para entender lo que desea el
cliente% analizar las necesidades% evaluar la factibilidad% ne'ociar una
solucin razonable% especificar la solucin sin ambi'(edades% validar la
especificacin y administrar los requerimientos a medida que se
transforman en un sistema funcional.
A. TAREAS DE LA INGENIERA DE
REQUERIMIENTOS
). C*+CEC,-+
$e establece el entendimiento bsico del problema% las
personas que quieren una solucin% la naturaleza de la
solucin que se desea% as como la eficacia de la
comunicacin y colaboracin preliminares entre el equipo de
soft&are y los otros participantes.
.. ,+D/0/C,-+
Consiste en pre'untar al cliente% a los otros usuarios y a
otras personas cuales son los ob"etivos para el sistema o
producto% que es lo que va a lo'rarse% como se a"usta a las
necesidades de la or'anizacin y como va a usarse el
sistema en las operaciones cotidianas.
). C*+CEC,-+
.. ,+D/0/C,-+
1. E2/3*4/C,-+
5. +E0*C,/C,-+
6. E$EC,7,C/C,-
+
8. 9/2,D/C,-+
:. /D;,+,$<4/C,-
+
,. ,+0E+,E4=/ DE 4E>?E4,;,E+<*$
2. INDAGACIN
roblemas cuando ocurre la inda'acin:
roblemas de alcance
7rontera de los sistemas mal definido.
Especificacin de detalles tcnicos innecesarios.
roblemas de entendimiento
2os usuarios no estn se'uros de lo que necesitan.
Capacidades y limitaciones computacionales no entendidas.
roblemas de comunicacin con el ,n'. de sistemas.
*misin de informacin por creer que esta sobrentendida.
$olicitud de requerimientos ambi'uos.
roblemas de volatilidad
2os requerimientos cambian con el tiempo.
$olucin: obtencin de requerimientos de forma or'anizada.
). C*+CEC,-+
.. ,+D/0/C,-+
1. E2/3*4/C,-+
5. +E0*C,/C,-+
6. E$EC,7,C/C,-
+
8. 9/2,D/C,-+
:. /D;,+,$<4/C,-
+
,. ,+0E+,E4=/ DE 4E>?E4,;,E+<*$ /. </4E/$ DE 2/ ,+0E+,E4=/ DE
4E>?E4,;,E+<*$
1. E2/3*4/C,-+
En esta etapa se expande y refina la informacin obtenida
en la concepcin y la inda'acin.
$e centra en desarrollar un modelo refinado de los
requerimientos@ motivado por la creacin y me"ora de
escenarios de usuarios que describan como interactuar
usuario final y sistema.
5. +E0*C,/C,-+
2os clientes piden mas de los que puede lo'rarse dado lo
limitado de los recursos.
2os participantes deben de ordenar sus requerimientos
se'An su prioridad y lue'o analizar los conflictos.
Con un enfoque iterativo los requerimientos se evalAan%
eliminan% combinen o modifican de modo que cada parte
lo're cierto 'rado de satisfaccin.
). C*+CEC,-+
.. ,+D/0/C,-+
1. E2/3*4/C,-+
5. +E0*C,/C,-+
6. E$EC,7,C/C,-
+
8. 9/2,D/C,-+
:. /D;,+,$<4/C,-
+
,. ,+0E+,E4=/ DE 4E>?E4,;,E+<*$ /. </4E/$ DE 2/ ,+0E+,E4=/ DE
4E>?E4,;,E+<*$
6. E$EC,7,C/C,-+
?na especificacin puede ser un documento escrito% un
con"unto de modelos 'rficos% un modelo matemtico
formal% un con"unto de escenarios de uso% un prototipo o
cualquier combinacin de stos.
2a formalidad y el formato de una especificacin varan con
el tama#o y comple"idad del soft&are que se va a construir.
8. 9/2,D/C,-+
2a validacin de los requerimientos analiza la especificacin
a fin de 'arantizar que todos ellos !an sido enunciados sin
ambi'(edades@ que se detectaron y corri'ieron las
inconsistencias% las omisiones y los errores% y que los
productos del traba"o se presentan conforme a los
estndares establecidos para el proceso% el proyecto y el
producto.
). C*+CEC,-+
.. ,+D/0/C,-+
1. E2/3*4/C,-+
5. +E0*C,/C,-+
6. E$EC,7,C/C,-
+
8. 9/2,D/C,-+
:. /D;,+,$<4/C,-
+
,. ,+0E+,E4=/ DE 4E>?E4,;,E+<*$ /. </4E/$ DE 2/ ,+0E+,E4=/ DE
4E>?E4,;,E+<*$
:. /D;,+,$<4/C,-+ DE 2*$ 4E>?E4,;,E+<*$
Es el con"unto de actividades que ayudan al equipo del
proyecto a identificar% controlar y dar se'uimiento a los
requerimientos y a sus cambios en cualquier momento del
desarrollo del proyecto.
). C*+CEC,-+
.. ,+D/0/C,-+
1. E2/3*4/C,-+
5. +E0*C,/C,-+
6. E$EC,7,C/C,-
+
8. 9/2,D/C,-+
:. /D;,+,$<4/C,-
+
,,. E$</32ECE4 2/$ 3/$E$
En el caso ideal% los participantes e in'enieros de soft&are traba"an "untos en el
mismo equipo.
/. Etapas requeridas para establecer las bases que permiten entender los
requerimientos de soft&are.
). ,dentificacin de los participantes
?n participante es cualquier persona que ten'a inters directo o que se
beneficie del sistema que se va a desarrollar.
,. ,+0E+,E4=/ DE 4E>?E4,;,E+<*$ /. </4E/$ DE 2/ ,+0E+,E4=/ DE 4E>?E4,;,E+<*$ ,,.
E$</32ECE4 2/$ 3/$E$
.. 4econocer los mAltiples puntos de vista
Cada participante busca sus intereses.
Clasificar la informacin para una decisin en base a requerimientos
co!erentes.
1. <raba"ar !acia la colaboracin
3uscar reas de inters comAn requerimientos de comAn acuerdo y
conflictivos.
,nte'racin de requerimientos ele'ido por un experto.
5. Bacer las primeras pre'untas
C>uin est detrs de la solicitud de este traba"oD
C>u problemas resolvera esta solucinD
CEs usted la persona indicada para responder estas pre'untasD C$us
respuestas son EoficialesFD
,,. E$</32ECE4 2/$ 3/$E$ /. E<//$ /4/
E$</32ECE4 2/$ 3/$E$
III. INDAGACIN DE LOS
REQUERIMIENTOS

<ambin llamada recabacin de los requerimientos combina

elementos de la solucin de problemas% elaboracin% ne'ociacin y
especificacin.
/. 4ecabacin de los requerimientos en forma colaborativa
,n'. de $oft&are como otros participantes diri'en o intervienen las reuniones.
$e establecen re'las para la preparacin y participacin.
$e su'iere una a'enda para cubrir punto importantes.
?n facilitador controla la reunin.
$e utiliza un mecanismo de definicinG!o"as de traba"o% postHits entre otrosI.
2a meta es identificar el problema% proponer elementos de la solucin% ne'ociar
distintos enfoques y especificar un con"unto preliminar de requerimientos de la
solucin en una atmsfera que favorezca el lo'ro de la meta.
2ista de ob"etos% servicios% restricciones y desempe#o del sistema que se va a
construir.
3. Desplie'ue de la funcin de calidad GD7CI
Es una tcnica de administracin de la calidad que traduce las
necesidades del cliente en requerimientos tcnicos para el soft&are.
El D7C define los requerimientos de forma que maximicen la
satisfaccin del cliente.
,dentifica tres tipos de requerimientos
Requerimientos normaes
*b"etivos y metas que se establecen para un producto o sistema durante las reuniones con
el cliente.
E"emplo: 'rficos pedidos para aparecer en la pantalla% funciones especficas del sistema y
niveles de rendimiento definidos.
Requerimientos es!era"os
Estn implcitos en el producto o sistema y quiz sean tan importantes que el cliente no los
mencione de manera explcita.
E"emplo: 7cil interaccin !umanoJmquina% operacin 'eneral correcta y confiable% y
facilidad para instalar el soft&are.
Requerimientos emo#ionantes
Estas caractersticas van ms all de las expectativas del cliente y son muy satisfactorias si
estn presentes.
E"emplo: pantalla sensible al tacto% correo de voz visual% etc.
,,,. ,+D/0/C,-+ DE 2*$
4E>?E4,;,E+<*$
C. Escenarios de uso
2os escenarios% que a menudo se llaman casos de uso% proporcionan la
descripcin de la manera en la que se utilizar el sistema.
D. ,nda'acin de los productos del traba"o
2os productos del traba"o incluyen:
?n enunciado de la necesidad y su factibilidad.
?n enunciado acotado del alcance del sistema o producto.
?na lista de clientes% usuarios y otros participantes que intervienen en la inda'acin
de los requerimientos.
?na descripcin del ambiente tcnico del sistema.
?na lista de requerimientos Gde preferencia or'anizados por funcinI y las
restricciones del dominio que se aplican a cada uno.
?n con"unto de escenarios de uso que dan perspectiva al uso del sistema o producto
en diferentes condiciones de operacin.
Cualesquiera prototipos desarrollados para definir requerimientos.
,,,. ,+D/0/C,*+ DE 2*$
4E>?E4,;,E+<*$
I$. DESARROLLO DE CASOS DE
USO

?n caso de uso narra una !istoria estilizada sobre cmo interactAa un

usuario final Gque tiene cierto nAmero de roles posiblesI con el sistema
en circunstancias especficas.
?n caso de uso ilustra el soft&are o sistema desde el punto de vista
del usuario final.

2os casos de uso se definen desde el punto de vista de un actor. ?n

actor es un papel que desempe#an las personas GusuariosI o los
dispositivos cuando interactAan con el soft&are.

ara escribir un caso de uso:

Definir un con"unto de actores
un actor es cualquier cosa que se comunique con
el sistema o producto y que sea externo a ste.
ersonas o dispositivos que usan el sistema.
4epresentan los papeles que desempe#an.
$e su'iere que los casos de uso deben responder las
si'uientes pre'untas:
C>uin es el actor principal y quinGesI elGlosI secundarioGsID
CCules son los ob"etivos de los actoresD
C>u precondiciones deben existir antes de comenzar la
!istoriaD
C>u tareas o funciones principales son realizadas por el actorD
C>u excepciones deben considerarse al describir la !istoriaD
CCules variaciones son posibles en la interaccin del actorD
C>u informacin del sistema adquiere% produce o cambia el
actorD
C<endr que informar el actor al sistema acerca de cambios en
el ambiente externoD
C>u informacin desea obtener el actor del sistemaD
C>uiere el actor ser informado sobre cambios inesperadosD
,9. DE$/44*22* DE C/$*$ DE
?$*
Fig. 01 CASO DE USO N1
Fuente: Poleth Alanoca
Fig. 02 CASO DE USO N2
Fuente: Poleth Alanoca
$. ELA%ORACIN DEL MODELO DE
REQUERIMIENTOS
El ob"etivo del modelo del anlisis es describir los dominios de
informacin% funcin y comportamiento que se requieren para un
sistema basado en computadora.

El modelo cambia en forma dinmica a medida que se aprende ms

sobre el sistema por construir% y otros participantes comprenden ms
lo que en realidad requieren.
or esa razn% el modelo del anlisis es una foto'rafa de los
requerimientos en cualquier momento dado.
/. E2E;E+<*$ DE2 ;*DE2* DE 4E>?E4,;,E+<*

Existen varias formas de concebir los requerimientos se puede

seleccionar un modo de representacin Gpor e"emplo% el caso de usoI y
aplicarlo !asta excluir a todos los dems.
2os modos diferentes de representacin fuerzan a considerar los
requerimientos desde distintos puntos de vista% enfoque que tiene una
probabilidad mayor de detectar omisiones% inconsistencia y
ambi'(edades.
). Elementos basados en el escenario
El sistema se describe desde el punto de vista del usuario con el empleo de un
enfoque basado en el escenario.
Casos de uso con sus dia'ramas.Grevisar ?;2I . Dia'rama de actividades ?;2.
Con frecuencia son la primera parte del modelo en desarrollo. Como tales%
sirven como entrada para la creacin de otros elementos de modelado.
.. Elementos basados en clases
Cada escenario de uso implica un con"unto de ob"etos que se manipulan cuando
un actor interactAa con el sistema. Estos ob"etos se clasifican en clases: con"unto
de ob"etos que tienen atributos similares y comportamientos comunes.
ara ilustrarlo se pueden usar dia'ramas de clase ?;2.
1. Elementos de comportamiento
<iene un efecto profundo en el dise#o que se eli"a y en el enfoque de
implementacin que se aplique.
El diagrama de estado es un mtodo de representacin del comportamiento de un
sistema que ilustra sus estados y los eventos que ocasionan que el sistema
cambie de estado.
?n estado es un modo de comportamiento observable desde el exterior. 2os
estmulos externos ocasionan transiciones entre los estados.
ara ilustrarlo se puede usar un dia'rama de estado ?;2

9. E2/3*4/C,-+ DE2 ;*DE2* DE 4E>?E4,;,E+<*$ /. E2E;E+<*$ DE2 ;*DE2* DE
4E>?E4,;,E+<*

5. Elementos orientados al flu"o
2a informacin fluye en un sistema basado en computadora.
Es posible crear un modelo del flu"o de la informacin para cualquier sistema
basado en computadora.
3. /<4*+E$ DE /+/2,$,$

Estos patrones de anlisis su'ieren soluciones Gpor e"emplo% una

clase% funcin o comportamientoI dentro del dominio de la aplicacin
que pueden volverse a utilizar cuando se modelen muc!as
aplicaciones.

los patrones de anlisis aceleran el desarrollo de los modelos de

anlisis abstracto que capturan los principales requerimientos del
problema concreto% debido a que proveen modelos de anlisis
reutilizables con e"emplos% as como una descripcin de sus venta"as y
limitaciones.
los patrones de anlisis facilitan la transformacin del modelo de
anlisis en un modelo del dise#o% su'iriendo patrones de dise#o y
soluciones confiables para problemas comunes.

,9. E2/3*4/C,-+ DE2 ;*DE2* DE 4E>?E4,;,E+<*$ /. E2E;E+<*$ DE2 ;*DE2*
DE 4E>?E4,;,E+<*

$I. REQUERIMIENTOS DE LAS
NEGOCIACIONES

El ob"etivo de esta ne'ociacin es desarrollar un plan del

proyecto que satisfa'a las necesidades del participante y que al
mismo tiempo refle"e las restricciones del mundo real Gpor
e"emplo% tiempo% personas% presupuesto% etc.I que se !ayan
establecido al equipo del soft&are.
2as me"ores ne'ociaciones buscan un resultado E'anarH'anarF.

con"unto de actividades de ne'ociacin al principio de cada

iteracin del proceso de soft&are.
,dentificacin de los participantes clave del sistema o subsistema.
Determinacin de las Econdiciones para 'anarF de los participantes.
+e'ociacin de las condiciones para 'anar de los participantes a fin de
reconciliarlas en un con"unto de condiciones 'anarH'anar para todos los
que intervienen Gincluso el equipo de soft&areI.
$II. $ALIDACION DE LOS
REQUERIMIENTOS
/l'unas pre'untas deben plantearse y responderse para 'arantizar que
el modelo de requerimientos es una reflexin correcta sobre las
necesidades del participante y que provee un fundamento slido para el
dise#o.
CEs co!erente cada requerimiento con los ob"etivos 'enerales del sistema o
productoD
C$e !an especificado todos los requerimientos en el nivel apropiado de
abstraccinD Es decir% Cal'unos de ellos tienen un nivel de detalle tcnico que
resulta inapropiado en esta etapaD
El requerimiento% Ces realmente necesario o representa una caracterstica
a're'ada que tal vez no sea esencial para el ob"etivo del sistemaD
CCada requerimiento est acotado y no es ambi'uoD
C<iene atribucin cada requerimientoD Es decir% C!ay una fuente Gpor lo 'eneral
una individual y especficaI clara para cada requerimientoD
$II. $ALIDACION DE LOS
REQUERIMIENTOS CBay requerimientos en conflicto con otrosD
CCada requerimiento es asequible en el ambiente tcnico que alber'ar el sistema
o productoD
?na vez implementado cada requerimiento% Cpuede someterse a pruebaD
El modelo de requerimientos% Crefle"a de manera apropiada la informacin% la
funcin y el comportamiento del sistema que se va a construirD
C$e !a EparticionadoF el modelo de requerimientos en forma que expon'a
informacin cada vez ms detallada sobre el sistemaD
C$e !a usado el patrn de requerimientos para simplificar el modelo de stosD C$e
!an validado todos los patrones de manera apropiadaD
C$on consistentes todos los patrones con los requerimientos del clienteD
MUCH!S $!CI!S (O SU !TENCI+N
CAPITULO 5: COMPRENSION
DE LOS REQUERIMIENTOS
UNIVESID!D N!CION!" #O$E %!S!DE $OHM!NN UNIVESID!D N!CION!" #O$E %!S!DE $OHM!NN
&!CU"T!D DE IN$ENIE'! &!CU"T!D DE IN$ENIE'!
E.!.(. IN$. EN IN&OM)TIC! * SISTEM!S E.!.(. IN$. EN IN&OM)TIC! * SISTEM!S