Redaccin correcta de requisitos

Ejemplos prcticos

Ejemplo 1.- La informacin sobre los metadatos de los usuarios debera almacenarse en memoria dentro de una tabla hash, o bien en una tabla de base de datos, con una clave ajena a la tabla de Usuarios. Observaciones: Se debe evitar el uso del tiempo condicional debera preferiblemente se debe utilizar el imperativo, deber . Los requisitos funcionales no deben incluir requisitos no funcionales o del sistema, memoria , tabla hash, tabla de base de datos

Corregido: La informacin sobre los metadatos de los usuarios deber almacenarse en el sistema.

Ejemplo 2. !l administrador deber ser capaz de insertar, borrar, mostrar " actualizar la informacin sobre los usuarios. #pcionalmente, deber tambi$n ser capaz de %enerar un informe " enviarlo por e-mail al cliente. Observaciones: La opcionalidad debe e&presarse como un atributo, " nunca como te&to dentro de un requisito. 'eber usar un requisito individual para cada necesidad. (uchos verbos concentrados en un requisito pueden implicar la mezcla de diferentes necesidades. Corregido: !l )dministrador !l )dministrador !l )dministrador !l )dministrador !l )dministrador al cliente deber deber deber deber podr ser capaz de a*adir usuarios ser capaz de borrar usuarios ser capaz de mostrar usuarios ser capaz de actualizar usuarios %enerar un informe para enviarlo por e-mail

Ejemplo 3 !l sistema debe ser capaz de importar archivos de tipo )+,. !l proceso debe ser ami%able " r pido para el usuario. Observaciones: -$rminos como .ami%able/ " .r pido/ son difciles de medir ", por lo tanto, imposible de probar de forma correcta. Corregido: !l sistema debe ser capaz de importar archivos )+,. !l proceso debe presentar una interfaz que sea acorde a las especificaciones t$cnicas definidas para este tipo de requerimientos, adem s el tiempo de respuesta debe no e&ceder los 0 se%.

Ejemplo 4 !l administrador deber ser capaz de crear facturas asociadas con las diferentes compa*as que est$n in%resadas en el sistema " $ste tambi$n deber estar al tanto de facturas impa%as para que puedan %enerar un mail " envi rselos a ellos. !l uso apropiado de si%nos de puntuacin har los requisitos m s f ciles de leer. !l n1mero de slabas por palabra " palabras por frase es tambi$n un buen indicador de la le%ibilidad del requisito. !l e&ceso de pronombres puede hacer un requisito difcil de entender, en el ejmeplo 2ellos 2, 3se refiere al administrador o al cliente4 La redaccin de los requisitos no debe ser mu" e&tensa. Corregido: !l administrador deber ser capaz de crear facturas asociadas con las diferentes compa*as que est$n in%resaads en el sistema. 5ste tambi$n deber estar al tanto de facturas impa%as para que puedan %enerar un mail " enviarse a los clientes.

Ejemplo 5 Los clientes podr n remitir rdenes por 6nternet. !stas rdenes deben incluir fecha de envo " cantidad de artculos. Una vez que se recibe la orden, el equipo de empaquetado debe reco%er todos los artculos " enviar un mail al cliente. 'eben soportarse los protocolos http " https, as como los nave%adores !&plorer " 7irefo&. La resolucin mnima ser de 89:;&<=>. Observaciones: Un e&ceso de t$rminos diferentes en el mismo requisito puede indicar? @ue se est n mezclando diferentes necesidades en un 1nico requisito @ue se est proporcionando demasiado detalle, que puede ser parte del dise*o 6%ualmente, muchos verbos pueden involucrar diferentes necesidades mezcladas en un 1nico requisito Corregido: Los clientes podr n remitir rdenes por 6nternet, estas deben incluir fecha de envo " cantidad de artculos.

Ejemplo 6 !n mi opinin, nin%1n cliente debera poder nunca enviar rdenes al equipo de empaquetado. Aa lo hicimos as en un pro"ecto hace tres a*os " el resultado fue nefasto Observaciones Bo ha%a e&plcita su opinin, C!n mi opininDlimtese a escribir lo que el sistema debe hacer. Bo mezcle demasiados t$rminos ne%ativos, "a que a veces puede dificultar la lectura del requisitoErestriccin. Bo diva%ue al redactar el requisito. Limtese a indicar qu$ es lo que debe hacer el sistema.

Corregido: Un cliente no podr enviar rdenes directamente al equipo de empaquetado

Ejemplo 7 Feneralmente, el sistema debe ser capaz de terminar el proceso de rastreo sin sobrecar%ar e&cesivamente el servidor. Observaciones !vite e&presiones va%as como? .%eneralmente/, .com1nmente/ Gerifique si cada asercin puede ser medida de forma sencilla Csobrecar%ar e&cesivamente D Corregido !l sistema debe ser capaz de terminar el proceso de rastreo en un tiempo inferior a : se%undos " sin que el proceso sobrepase los :09 (+ de memoria.

El modelo de casos de uso

 Un caso de uso es una descripcin %r fica " te&tual de un sistema en t$rminos de una secuencia de acciones. Son una forma %r fica de especificar los requisitos de un sistema. Los casos de uso un m$todo diferente para or%anizar los requerimientos funcionales, ellos a1n son requerimientos . De inici!n Un caso de uso es una especificacin %r fica " te&tual de una serie de acciones realizadas por un sistema, el cual produce un resultado observable que es, tpicamente, de valor para uno o m s actores u otros %rupos de inter$s dentro del sistema.

Carac"er#s"icas
'escribe la interaccin entre un actor e&terno al sistema " el sistema con te&to en len%uaje natural " representacin. Representa los requisitos funcionales desde el punto de vista del usuario " por lo tanto produce un resultado observable por $l. !s iniciado por un 1nico actor. Realiza una funcionalidad concreta. 'escribe cmo un actor usa un sistema para conse%uir un obje"ivo, " lo que el sistema hace para a"udarle. !l modelo de casos de uso sirve para definir " e&presar %r ficamente el sis"ema " su en"orno. !l modelo de casos de uso se e&presa %r ficamente mediante uno o varios diagramas de casos de uso.

 ) pesar de que cada ,asos de Uso soporta un proceso, $stos se centran en la meta, no en el proceso. (c"uali%aci!n de Cuen"a 'e"iro de E ec"ivo

Un caso de uso B# dice c!mo trabaja el sistema, sino lo $ue debe ser capa% de &acer. Los ,asos de Uso describen solo aquellas caractersticas que son visibles " si%nificativas para los actores que usar n el sistema. !sto evita el hacer una descomposicin funcional. Hor ejemplo, si un sistema debe %uardar datos en una base de datos, solo se debe ilustrar el mensaje que indica que los datos se %uardaron, no cmo se %uardan.

Obje"ivos de los casos de uso ?

,omprender la funcionalidad del sistema. 'iscutir con el usuario nuestra visin de esa funcionalidad. 6dentificar conceptos del sistema, clases, atributos " operaciones. Galidar el an lisis " el modelo del dise*o. Hroporcionar informacin para las pruebas del sistema " de aceptacin

Elemen"os diagrama de Casos de )so

Caso de Uso Sistema

Dependencia

(c"or

Asociacin

Generalizacin

(c"ore s
!l actor puede ser tanto una persona como otro sistema que jue%a un rol en la interaccin con el mismo. Un mismo rol puede ser desempe*ado por varias personas *Ej. +ecre"ar#a, docen"e, es"udian"e, vendedor-. Un usuario no es un actor, sino que asume un rol cuando interact1a con el sistema " por lo tanto funciona como un tipo de actor. Un actor no forma parte del sistema -odo actor tiene un nombre. Un actor puede intervenir en varios casos de uso -ipos de actores .ersonas o cosas Cotro sistema, un sensor, a%ua, fue%o, tiempo...D. .rimarios o secundarios Crealizan tareas administrativas o de mantenimientoD.

C!mo /den"i icar ac"ores -eniendo en cuenta lo que es un actor, ha" que encontrar la si%uiente informacin? 8. 6dentificar los usuarios del sistema. Hara ello tener en cuenta para quien se est dise*ando o con que personas va a interactuar de un modo directo Cactores principalesD " quienes va a tener un papel de supervisin o mantenimiento del sistema Cactores secundariosD. :. 6dentificar los roles que jue%an esos usuarios desde el punto de vista del sistema. Ia" varios tipos, %estores de alto nivel, %ente que introduce datos, etc. J. 6dentificar o"ros sis"emas con los cuales e&ista comunicacin. !stos sistemas tambi$n se consideran como actores dado que son al%o e&terno a nuestro sistema.

Casos de uso
Un caso de uso Representa una tarea, o unidad co&eren"e de uncionalidad, que el sistema est obli%ado a proporcionar a los actores en beneficio de los interesados. !n un caso de uso pueden participar varios ac"ores distintos, " adem s? Las acciones de un actor pueden ser beneficiosas para otros actores. Huede haber interesados CstakeholdersD que no sean actores en absoluto.

'elaciones
Asociacin Es el tipo de relacin ms bsica que indica la invocacin de un actor o caso de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha simple. Dependencia o Instanciacin Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relacin se denota con una flecha punteada. Generalizacin Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su estereotipo, que puede ser de Uso ( uses!!) o de Herencia ( e"tends!!). Este tipo de relacin esta orientado e"clusivamente para casos de uso (y no para actores).

extends# $e recomienda utilizar cuando un caso de uso es similar a otro (caracter%sticas). uses# $e recomienda utilizar cuando se tiene un con&unto de caracter%sticas que son similares en ms de un caso de uso y no se desea mantener copiada la descripcin de la caracter%stica. De lo anterior cabe mencionar que tiene el mismo paradi'ma en dise(o y modelamiento de clases, en donde esta la duda clsica de usar o heredar.

EJEMP !

Lue%o, tenemos que un ,liente puede 'epositar 6temes " un #perador puede cambiar la informacin de un 6tem o bien puede 6mprimir un informe?

)dem s podemos notar que un item puede ser una +otella, un -arro o una Kaba.

#tro aspecto es la impresin de comprobantes, que puede ser realizada despu$s de depositar al%1n item por un cliente o bien puede ser realizada a peticin de un operador.

!ntonces, el dise*o completo del dia%rama Use ,ase es?

Ejemplo

,onsideraremos el proceso de afiliacin de una persona a la or%anizacin.

6dentificar al )ctor mas representativo, en este caso .'O0O1O' e identificar toda la funcionalidad del sistema desde su punto de vista. !n otras palabras, se le debe pre%untar al promotor todo lo que $l necesita del sistema, " su respuesta probablemente sera?

afiliar a una persona entre%ar la documentacin de afiliaciones para su procesamiento consultar de vez en cuando el estado de la afiliacin de sus clientes dD visitar a sus clientes para corre%ir al%1n dato que pudiera haber quedado pendiente a fin de dar curso definitivo a la afiliacin.

Casos de )so?

Lue%o de describir todos los casos de uso, ha" que tratar de detectar las e&cepciones o caminos alternativos que requieran una atencin especial por el sistema. -ambi$n se debe tomar en cuenta la funcionalidad necesaria para el tratamiento de los errores. Hor ejemplo, en el paso BL 8, si el Hromotor considera que es necesaria la participacin de )uditora ($dica en la revisin de la solicitud, debe indicarlo en el formulario de afiliacin. Hor este motivo, el dia%rama de casos de uso quedara indicando que el caso de uso M)filiar a una personaN debera e&tender su funcionalidad con la comprendida en el caso de uso MSolicitar participacin de )uditora ($dicaN.

Es"ereo"ipos
Los estereotipos se usan en U(L en los ,asos de Uso, clases " paquetes. 2o"aci!n 33include44: ,uando un ,aso de Uso necesita a"uda de otro ,aso de Uso, la dependencia se dibuja con una flecha punteada hacia el caso que ser MusadoN. !s una subrutina o llamada a funcin. 2o"aci!n 33e5"end44 indica que un ,aso de Uso puede necesitar a"uda de otro ,aso de Uso, contrario al include donde siempre la necesita.

!jercicio : 7loristera vir"ual

!n este ejemplo se pretende desarrollar una tienda de flores virtual. Hara ello una empresa decide montar una franquicia de reparto de flores " crear una p %ina Oeb que colocar en 6nternetP las floristeras se har n miembros de la franquicia " ser n las encar%adas del reparto de las flores solicitadas por 6nternet. Los usuarios se conectar n a la m quina Oeb " realizar n pedidos, Cencar%ar n ramos de floresD que ser n enviados a otra tercera persona. Una vez que el usuario ha realizado el pedido, la aplicacin se encar%ar de buscar la floristera m s cercana al domicilio del destinatario, que se encuentre re%istrada en el sistema " la notificar que debe realizar una entre%a. ,uando esta floristera ha"a realizado la entre%a entrar en el sistema " re%istra la fecha " hora en que realizo la entre%a. La aplicacin debe de llevar un re%istro de fechas tales como fecha en la que se realiza el pedido, fecha en la que de debe entre%ar, la fecha de real de la entre%a, etc. ,uando un cliente hace un pedido, se le proporciona un identificador 1nico para poder se%uir el estado de su pedido. !l usuario puede entrar

(c"ores?

(c"ores de la 6loris"er#a vir"ual ser7n: Las Personas de desean enviar flores. Clien"e Las empresas o personas encar%adas de enviar fsicamente las flores a las personas destino del pedido. 1ienda !l Administrador que ser el encar%ado de dar de alta las -iendas en el sistema. !l asignador, entendi$ndose como un proceso encar%ado de asi%nar los pedidos realizados por los clientes a la tienda que deber hacer la entre%a. Los destinatarios de los pedidos.

Hersonas que desean enviar flores

!mpresas o personas encar%adas de enviar fsicamente las flores a las personas destino del pedido

Hersona encar%ada en dar de alta las -iendas en el sistema

Hroceso encar%ado de leer los nuevos pedidos " asi%n rselos a la tienda que realizar la entre%a

Los des"ina"arios no se inclu"en en el dia%rama por que no interact1an directamente con el sistema.

Casos de )so?

(antenimiento tienda
Q

Realizar pedido
Q

Q Q
Iacer Se%uimiento de pedidoQ

)si%nar tienda
Q

0isi!n 8 prop!si"o uncional de un caso de uso

Q (antenimiento tienda
Q

Q Realizar pedido
Q

Q )si%nar tienda
Q

Q
Iacer Se%uimiento de pedidoQ

Ejercicio 3 Lavado de recipientes de vidrio

Una empresa ofrece servicio de lavado de recipientes de vidrio Cbotellas, jarras " vasosD utilizando una m quina lavadora autom tica. !l proceso de lavado es distinto se%1n el item. !n base a las especificaciones que se muestran a continuacin, establecer el dia%rama de casis de uso. !l ,liente deposita uno de los items " recibe un ticRet impreso con el n1mero de orden de su trabajo. !l tipo de item " la cantidad de unidades depositadas. !l operador indica en la m quina el tipo de item " pulsa el botn de inicio del proceso de lavado. 'urante el proceso de lavado, el operador tiene la posibilidad de %enerar una alarma en caso se presente una eventualidad que altere el proceso normal de lavado. La alarma tambi$n se dispara cuando un elemento que est siendo lavado se atora en la m quina lavadora, o cuando a la impresora le falta papel. )l finalizar el da, se necesita saber cu ntas unidades de cada item se han lavado. !sta informacin la necesita el operador para presentar su

(C1O'E+

Hersona deposita los items para que sean lavados

Operador

Hersona que opera el sistema " la m quina lavadora

/den"i icaci!n de Casos de )so?

8. Un clien"e deposita un item *Deposi"ar /"em:. Un clien"e recibe un -icRet impreso C/mprimir 1ic9e"D, con la orden de su trabajo. J. Un Operador establece el tipo de item a lavar Ces"ablecer 1ipo de /"emD, e inicia el proceso de lavado del item *:avar /"em-. ;. Un Operador puede %enerar una alarma C;enerar alarmaD cuando se presenta una emer%encia. 0. La alarma C;enerar alarmaDtambi$n se dispara cuando se presenta. un atoro o cuando la impresora no tiene papel. =. Un Operador %enera un reporte diario C/mprimir repor"e diarioD.

Diagrama de Caso de )so por ac"or

Q 'epositar 6tem Q Q 6mprimir -icRet Q Q !stablecer tipo 6tem Q Q
!perador

Lavar 6tem QQ Fenerar alarma Q Q 6mprimir reporte diario

'elaciones de ;enerali%aci!n

Se%1n las especificaciones, Sel proceso de lavado es distinto se%1n se ten%a que lavar botellas, jarras, o vasosTP por lo tanto, el caso de uso :avar /"em tiene tres especializaciones Ccasos de uso hijosD? :avar <o"ellas, :avar =arras, 8 :avar >asos.

Q Lavar 6tem Q Q Lavar +otellas Q Q Lavar GasosQ

!perador

Q Lavar KarrasQ

'elaciones de /nclusi!n Los casos de uso /mprimir 1ic9e" e /mprimir 'epor"e Diario tiene una parte de su funcionalidad en com1n. )mbos inclu"en el caso de uso /mprimir.
Q SincludeT Q 6mprimir -icRet Q 6mprimirQ SincludeT Q 6mprimir reporte diario Q

!perador

'elaciones de E5"ensi!n !l caso de uso ;enerar (larma puede ser invocado e&cepcionalmente cuando un item que est siendo lavado C :avar /"emD, se atora en la m quina lavadora, o cuando a la impresora le falta papel C6mprimirD
Q )include* Q 6mprimir -icRet Q Q 6mprimir -icRet Q )e"tend $in papel* 6mprimirQ )include* Q 6mprimir reporte diario Q Q Fenerar )larma )e"tend atoro* Q Q Lavar 6temQ Q Lavar +otellas Q Q Lavar KarrasQ Q Lavar GasosQ !stablecer tipo 6tem
!perador

C(+O : 6eria de subas"as

Se desea modelar un sistema inform tico para %estionar las transacciones en un recinto ferial de subastas. ,ualquier persona que ha"a lo%rado acceso al recinto de la feria puede conectarse al sistema a trav$s de al%uno de los muchos terminales disponibles, " participar en las subastas que ten%an lu%ar, en al%una de las modalidades ofrecidas por el sistema, es decir, como comprador, como vendedor, o como simple observador. Hara subastar al%1n artculo es necesario darse de alta como vendedor. !l vendedor puede re%istrar artculos en la subasta, rellenando una ficha por cada artculo, que sale as inmediatamente a subasta. )n lo%amente, para participar en una subasta es necesario darse de alta como comprador. !l comprador puede pujar por cualquiera de los artculos subastados en la feria. ,uando no se produce nin%una nueva puja, el artculo queda definitivamente adjudicado al comprador. Si un artculo no ha recibido nin%una puja, el vendedor puede modificar al%uno de sus datos. ,ualquier persona puede participar como observador en una subasta, es decir, puede consultar la lista de artculos subastados " seleccionar uno

Ejericicio Un sistema autom tico de cambio de %rupos para asi%naturas funciona de la si%uiente manera? !l profesor da de alta una asi%natura " proporciona al sistema un listado con los alumnos matriculados en dicha asi%natura. Un alumno que quiera cambiar de %rupo en una asi%natura puede consultar las peticiones de cambio. Si encuentra al%una que le interese, el alumno solicita el cambio " el sistema lo almacena. Si no, el alumno puede dejar el cambio que desea por si a otro alumno le interesara. Los alumnos slo pueden consultar " publicitar cambios de las asi%naturas en las que est n matriculados.