Ingeniera de requerimientos

Ingeniera de Sistemas e Informtica

Propsito de la sesin Verifica si los requerimientos

cumplen con las caractersticas de los buenos requerimientos.

Contenido de la sesin Enfoque prctico de la ingeniera

de requerimientos.

Propsito y contenido de la sesin

Recapitulando

4Control de acceso

5Quienes son los stakeholders?

Identifique los requerimientos

Redacta los requerimientos

Cuestionario

Ingeniera de requerimientos

Enfoque prctico en la Ingeniera de Requerimientos

7Enfoque prctico en la Ingeniera de Requerimientos

El proceso de especificar los requerimientos a travs del estudio de las necesidades de los involucrados (stakeholders)

Analizar sistemticamente y refinar dichas especificaciones

8Requerimiento

Un requerimiento se define como: una condicin o capacidad que el sistema

debe desempear. Este puede ser cualquiera de los siguientes: Una capacidad necesaria para un cliente o usuario

que le permita resolver un problema o alcanzar un objetivo.

Una capacidad que debe ser atendida o poseda por un sistema para satisfacer un contrato, estndar, especificacin, regulacin, u otro documento formalmente impuesto.

Una restriccin impuesta por un stakeholder.

9Stakeholder

El stakeholder se define como alguien afectado por el sistema que est siendo desarrollado.

Los dos tipos de stakeholders son los usuarios y clientes. Los usuarios son las personas que usan el sistema. Los clientes son la gente que requieren el

sistema y son responsables de aprobarlos. Usualmente los clientes pagan por el desarrollo

del sistema.

10

Stakeholder

Algunas veces los requerimientos provistos por ambos grupos entran en conflicto. En la mayora de estos tipos de conflictos, los

requerimientos de los clientes tienen precedencia sobre los requerimientos de los usuarios.

Los otros tipos de stakeholders no deben descuidarse. Llamaremos stakeholder a cualquiera involucrado en el

sistema (ya sea durante el desarrollo o despus de que este se complete) y cualquiera quien tenga cualquier requerimiento para el sistema.

Pirmide de requerimientos

ModeradorNotas de la presentacinDependiendo del formato, origen, y caractersticas comunes, los requerimientos pueden dividirse en diferentes tipos de requerimientos.

En la siguiente diapositiva se muestran algunos tipos que se usan frecuentemente en los proyectos.

Necesidad de stakeholder Un requerimiento de un stakeholder.

Caracterstica Un servicio provisto por el sistema, usualmente formulado por un analista

de negocio; el propsito de una caracterstica es realizar una necesidad de un stakeholder.

Caso de uso Una descripcin del comportamiento de un sistema en trminos de

secuencias de acciones. Requerimiento suplementario

Otro requerimiento (usualmente no funcional) que no puede ser capturado en los casos de uso.

Caso de prueba Una especificacin de las entradas, condiciones de ejecucin y resultados

esperados para las pruebas. Escenario

Una secuencia especifica de acciones, un camino especifico a travs de un caso de uso

Pirmide de requerimientos

ModeradorNotas de la presentacinA diferentes niveles de estos requerimientos se capturan diferentes detalles.

En el nivel ms bajo, se detalla ms el requerimiento.

13

Mejores prcticas de administracin de requerimientos

Tener al menos dos niveles diferentes de abstraccin de requerimientos. Por ejemplo, la Visin contiene requerimientos de alto

nivel (caractersticas), y en los niveles ms bajos de la pirmide se expresan los requerimientos a un nivel detallado. Los stakeholders Senior (como un vicepresidente) no

tienen tiempo para leer 200 pginas de requerimientos detallados, pero s podran leer un documento de Visin de 20 pginas.

Depende del analista de negocio decidir la granularidad de los requerimientos a cada nivel.

14

Mejores prcticas de administracin de requerimientos

Las necesidades provienen del stakeholders, y las caractersticas son formuladas por los analistas de negocios.

El rol de los casos de prueba es revisar si los casos de uso y requerimientos suplementarios son correctamente implementados.

Los escenarios ayudan a derivar casos de uso desde los casos de prueba y facilitan el diseo e implementacin de caminos especficos a travs de los casos de uso.

15

Trazabilidad entre requerimientos

La trazabilidad es una tcnica que provee una relacin entre los diferentes niveles de requerimientos en el sistema.

Esta tcnica ayuda a determinar el origen de cualquier requerimiento en el sistema.

Cada necesidad usualmente se mapea a alguna caracterstica.

Generalmente, es una relacin de muchos a muchos porque una necesidad se puede trazar a muchas caractersticas, y una caracterstica puede derivarse de muchas necesidades.

ModeradorNotas de la presentacinUna necesidad que se mapea a una caracterstica es tambin un caso comn.

Las caractersticas se mapean a los casos de usos con una relacin de muchos a muchos.

Las caractersticas tambin se mapean a los requisitos suplementarios en una relacin de muchos a muchos.

Cada caso de uso se mapea a uno o ms escenarios, as una relacin de uno a muchos existen entre casos de usos y escenarios.Los escenarios se mapean a los casos de prueba en una relacin de muchos a muchos.

16

Importancia de la trazabilidad

Verificar que una implementacin realiza todos los requerimientos. Todo lo que el cliente requiere fue implementado.

Verificar que la aplicacin hace solamente lo que se requiere. No implementa algo que el cliente nunca pidi.

Anlisis de impacto: Qu elementos sern afectados cuando se considere agregar un nuevo requerimiento o cambiar uno existente?

Ayuda en la administracin de cambios: Cuando algn requerimiento cambia, queremos saber cules casos de prueba deberan rehacerse para probar este cambio.

17

Caractersticas de los buenos requerimientos

Inequvoco Comprobable (Verificable) Claro (conciso, breve, simple, preciso) Correcto Comprensible Factible (realista, posible) Independiente Atmico Necesario Libre implementacin (abstracto)

18

Caractersticas de los buenos requerimientos

Adems de estos criterios para requerimientos individuales, tres criterios se aplican para definir los requerimientos: Consistente Completo No redundante

Proyecto para una agencia de viajes

20

Inequvoco

Debera haber una sola forma de interpretar el requerimiento. Algunas veces la ambigedad se produce por acrnimos indefinidos.

21

Inequvoco

REQ1 El sistema ser implementado usando ASP ASP significa Active Server Pages o Application

Service Provider? Para corregir esto, podemos mencionar un nombre

complete y proporcionar un acrnimo en parntesis. REQ1 El sistema ser implementado usando

Active Server Pages (ASP).

22

Inequvoco

Aqu tenemos otro ejemplo: REQ1 El sistema no aceptarn contraseas mayores a 15

caracteres. No est claro lo que el sistema se supone har:

El sistema no dejar que el usuario ingrese ms de 15 caracteres.

El sistema truncar la cadena ingresada a 15 caracteres. El sistema mostrar un mensaje de error si el usuario

ingresa ms de 15 caracteres. El requerimiento corregido refleja la clarificacin:

REQ1 El sistema no aceptar contraseas con ms de 15 caracteres. Si el usuario ingresa ms de 15 caracteres cuando elija la contrasea, un mensaje de error le pedir que los corrija.

23

Inequvoco

Cierta ambigedad se introduce cuando se colocan ciertas palabras: REQ1 En la pantalla Vuelo almacenado, el usuario

solamente puede ver un registro. Esto significa que el usuario puede solo ver, no

borrar o actualizar? o significa que el usuario puede ver solo un registro, no dos o tres?

Una forma de arreglar el problema es reescribir el requerimiento desde el punto de vista del sistema: REQ1 En la pantalla de Vuelo almacenado, el sistema

mostrar solamente un vuelo.

24

Comprobable (Verificable)

Los verificadores deben ser capaces de comprobar si el requerimiento est implementado correctamente. La prueba se debera pasar o fallar.

Para ser comprobable, los requerimientos deben ser claros, precisos, e inequvocos.

Algunas palabras pueden hacer a un requerimiento no comprobable: Algunos adjetivos como: robusto, seguro, exacto, efectivo,

eficiente, expandible, flexible, factible al mantenimiento, confiable, amigable al usuario, adecuado.

Algunos verbos o frases adverbiales: rpidamente, seguramente, de manera oportuna

Palabras o acrnimos no especficos: etc., y/o, TBD

25

Comprobable (Verificable)

Tales requerimientos se pueden ver as: REQ1 La herramienta de bsqueda debera permitir al

usuario encontrar una reservacin basado en el Apellido, Fecha, etc. En este requerimiento, todos los criterios de

bsqueda deben ser explcitamente listados. El diseador y desarrollador no deben suponen lo que el usuario quiere decir por etc..

Otros problemas pueden originarse por palabras o frases ambiguas: Frases modificadoras: como sea apropiado, como se

requiera, si es necesario, ser considerado Palabras vagas: administrar, manejar

26

Comprobable (Verificable)

Voces pasivas: el sujeto de la sentencia recibe la accin del verbo en vez de ejecutarla. REQ1 El cdigo del aeropuerto ser ingresado por el

usuario. REQ2 El cdigo del aeropuerto ser ingresado.

El primer ejemplo muestra el clsico uso de voz pasiva. En voz activa se leera El usuario ingresar el

cdigo del aeropuerto. El segundo ejemplo muestra otro resultado del uso de

la voz pasiva en el cual el agente que desempea la accin algunas veces se omite, quin debera ingresar el cdigo, el sistema o el usuario?

27

Comprobable (Verificable)

Pronombres indefinidos: poco, varios, ms, muchos, varios, cualquiera, alguien, algo, unos, alguno, etc. REQ1 El sistema resistir el uso concurrente de

muchos usuarios. Qu nmero se debera considerar muchos 10,

100, 1000?

28

Claro (conciso, breve, simple, preciso)

Los requerimientos no debern contener verborrea o informacin innecesaria. Estos deberan ser indicados claramente y simplemente.

29

Claro (conciso, breve, simple, preciso)

Ejemplo: REQ1 Alguna veces el usuario ingresara el

cdigo del aeropuerto, el cual el sistema comprender, pero algunas veces la ciudad ms cercana la reemplazar, as el usuario no necesita conocer el cdigo del aeropuerto y esto ser entendido por el sistema.

Esta sentencia puede ser reemplazada por uno ms simple: REQ1 El sistema identificar al aeropuerto

basado en el cdigo del aeropuerto o ciudad.

30

Correcto

Si un requerimiento contiene hechos estos deben ser verdaderos REQ1 Los precios de renta de carro muestran

todos los impuestos aplicables (incluyendo el 6% de impuesto del estado) El impuesto depende del estado, as el 6% provisto

es incorrecto.

31

Comprensible

Los requerimientos sern gramticamente correctos y escritos en un estilo consistente.

Deberan usarse las convenciones estndar. La palabra deber se usar en lugar de debera, podra o puede.

32

Factible (Realista, Posible)

El proyecto debera ser factible dentro de las restricciones existentes tales como tiempo, dinero, y recursos disponibles: REQ1 El sistema tendr una interfaz con

lenguaje natural que entender comandos en el idioma Espaol. Este requerimiento no es posible dentro de un tramo

corto del tiempo de desarrollo.

ModeradorNotas de la presentacinAmbigedad:La palabra gato se puede entender como un animal o una herramienta.

En la oracin Juan come arroz con palillos no es claro si Juan come los palillos junto con arroz o los usa para comer el arroz, comprese con la oracin Juan come arroz con leche.

En la oracin Juan tom la torta de la mesa y la comi no es claro qu comi Juan, la torta o la mesa (comprese con la oracin Juan tom la torta de la mesa y la limpi con un trapo).

33

Independiente

Para comprender el requerimiento, no debe ser necesario conocer otro requerimiento: REQ1 La lista de vuelos disponibles deber

incluir nmero, hora y fecha de partida, hora y fecha de arribo para cada tramo de un vuelo.

REQ2 Este deber ser ordenado por precio. La palabra "Este" en la segunda sentencia se

refiere al requerimiento previo. Sin embargo, si el orden de los requerimientos cambia este requerimiento no ser comprensible.

34

Atmico

El requerimiento deber contener un solo elemento trazable: REQ1 el sistema proveer la posibilidad de reservar un

vuelo, comprar un pasaje, reservar un cuarto de hotel, reservar un auto, y dar informacin acerca de las atracciones.

Este requerimiento combina cinco requerimientos atmicos, que hacen una trazabilidad muy dificultosa. Las sentencias que incluan las palabras "y" o "pero" deberan ser revisadas para ver si se pueden separar en requerimientos atmicos.

35

Necesario

Un requerimiento es innecesario si: Ninguno de los stakeholders necesita el requerimiento, o Remover el requerimiento no afectar al sistema

Un ejemplo de un requerimiento que no es necesario para el stakeholder es un requerimiento que es aadido por los desarrolladores y diseadores porque asumen que los usuarios o clientes los quieren.

Por ejemplo, el hecho que un desarrollador piense que al usuario le gustara que el sistema muestre un mapa del aeropuerto y l sabe cmo implementarlo no es una razn vlida para aadir este requerimiento.

36

Necesario

Un ejemplo de un requerimiento que puede ser removido porque no provee ninguna nueva informacin puede ser similar al siguiente: REQ1 Todos los requerimientos especificados

en el documento de visin sern implementados y probados.

37

Libre implementacin (abstracto)

Los requerimientos no deberan contener informacin de diseo e implementacin innecesaria: REQ1 La informacin contenida ser

almacenada de un archivo de texto. Cmo se almacenan informacin debe ser

transparente el usuario y deberan ser los diseadores o arquitectos los que tomen la decisin.

38

Consistente No debera existir ningn conflicto entre los requerimientos. Los conflictos pueden ser

directos o indirectos. Los conflictos directos ocurren cuando, en la misma situacin, se espera un

comportamiento diferente. REQ1 La fecha ser mostrada en el formato mm/dd/yyyy. REQ2 La fecha ser mostrada en el formato dd/mm/yyyy.

Algunas veces es posible resolver el conflicto al analizar las condiciones bajo las cuales el requerimiento toma lugar.

Por ejemplo, si REQ1 fue hecho por un usuario americano y REQ2 por un usuario peruano, los requerimientos anteriores pueden ser descritos como sigue: REQ1 Para los usuarios en los Estados Unidos, las fechas sern mostradas en el

formato mm/dd/yyyy REQ2 Para los usuarios en Per, las fechas sern mostradas en el formato

dd/mm/yyyy Esto eventualmente llevara al siguiente requerimiento:

REQ3 las fechas sern mostradas basadas en el formato definidas por navegador web del usuario.

39

Consistente

Otro ejemplo de un conflicto directo puede ser visto en estos dos requerimientos: REQ1 Pago por PayPal estar disponible. REQ2 Solamente pagos con tarjeta de crdito

sern aceptados. En este caso el conflicto no puede ser

resuelto al aadir condiciones, as uno de los requerimientos deber cambiarse o quitarse.

40

Consistente

Los conflictos indirectos ocurren cuando los requerimientos no describen la misma funcionalidad, pero no es posible cumplir con ambos requerimientos a la vez. REQ1 El sistema debera tener una interfaz de lenguaje natural. REQ2 El sistema ser desarrollado en tres meses.

Algunos requerimientos no tienen conflicto, pero estos usan una terminologa inconsistente: REQ1 Para los vuelos de entrada y de salida, el usuario ser capaz

de comparar los precios de otros vuelos, de aeropuertos cercanos. REQ2 Los vuelos de salida y de retorno estarn ordenados por el

nmero menor de paradas. Para describir el mismo concepto en el primer requerimiento se usa el

trmino "vuelo de entrada", y en el segundo requerimiento se usa el trmino "vuelos de retorno". La utilizacin debera ser consistente.

Cada requerimiento debera expresarse solamente una vez y no debera superponerse con otro requerimiento. REQ1 Un calendario estar disponible para

ayudar a ingresar la fecha de vuelo. REQ2 El sistema mostrar un calendario pop-up

cuando se ingrese cualquier fecha El primer requerimiento (relacionados slo a

la fecha de vuelo) es un subconjunto de la segunda (relacionada a cualquier fecha ingresada por el usuario).

No redundante

Un requerimiento debera especificarse para todas las condiciones en las que pueda ocurrir. REQ1 El pas de destino no necesita ser

mostrado para los vuelos dentro de los Estados Unidos.

REQ2 Para los vuelos sobre el mar, el sistema mostrar un pas de destino.

Qu acerca de los vuelos a Canad y Mxico? stos no estn dentro de los Estados Unidos ni sobre el mar.

Completo

43

Completo

Un requerimiento aplicable debera ser especfico. Esta es la condicin ms difcil de revisar. Realmente no existe forma de estar seguro que todos los

requerimientos son capturados y que una semana despus de la fecha de produccin uno de los stakeholders diga, "olvid mencionar que necesito una caracterstica ms en aplicacin".

Un buen requerimiento debera tener ms criterios. Sin embargo, stos pueden ser expresados como una combinacin

de los criterios que acabamos de discutir: Modificable: si ste es atmico y no redundante, es usualmente

modificable. Trazable: si ste es atmico y tiene una identificacin nica, es

usualmente trazable.

44

Un vistazo al proceso de administracin de requerimientos

Establecer un plan de administracin de requerimientos Obtencin de requerimientos Desarrollo del documento de visin Creacin de casos de uso Especificaciones suplementarias Creacin de casos de prueba en base a los casos de uso Creacin de casos de prueba en base a las

especificaciones suplementarias Diseo del sistema

El primer paso (plan de administracin de requerimientos) define la pirmide de requerimientos.

Requerimientos y documentos creados en cada fase

ModeradorNotas de la presentacinLa descripcin es simplificada porque slo los pasos principales son descritos.

Por ejemplo, algunas actividades definidas por el Proceso Unificado de Rational (RUP) son ms granulares.

(Por ejemplo, nuestro paso de crear casos de uso contiene las siguientes actividades RUP: encontrar casos de uso y actores, estructura del modelo de casos de uso, priorizar los casos de usos, y detallar los casos de uso).

46

Administracin de requerimientos

Es un proceso interactivo. En una iteracin tpica, se hace una pasada completa a travs de la

pirmide. An en la misma iteracin, podemos ir hacia atrs unos pocos pasos y

repetir la actividad. Por ejemplo, durante la creacin de un caso de uso, podemos

descubrir que alguna informacin est faltando, y necesitamos ms entradas del stakeholder, y as ir hacia atrs al paso de obtencin de requerimientos.

Para mantener la integridad del modelo, es importante actualizar todos los requerimientos afectados.

En las interacciones iniciales el nfasis se pone en los primeros pasos (arriba en la pirmide), y en iteracin las posteriores se pasa ms tiempo en la parte inferior de la pirmide.

47

Actividades

Elabore una lista de por lo menos 5 requerimientos a partir del video control de acceso.

Verifique que cumpla con las caractersticas de los buenos

requerimientos.

Verificacin del pleno.

Preguntas

Qu hemos aprendido?

Reflexionemos

Ingeniera de requerimientosPropsito y contenido de la sesinRecapitulando Control de accesoCuestionarioEnfoque prctico en la Ingeniera de RequerimientosEnfoque prctico en la Ingeniera de RequerimientosRequerimientoStakeholderStakeholderPirmide de requerimientosPirmide de requerimientosMejores prcticas de administracin de requerimientosMejores prcticas de administracin de requerimientosTrazabilidad entre requerimientosImportancia de la trazabilidadCaractersticas de los buenos requerimientosCaractersticas de los buenos requerimientosProyecto para una agencia de viajesInequvocoInequvocoInequvocoInequvocoComprobable (Verificable)Comprobable (Verificable)Comprobable (Verificable)Comprobable (Verificable)Claro (conciso, breve, simple, preciso)Claro (conciso, breve, simple, preciso)CorrectoComprensibleFactible (Realista, Posible)IndependienteAtmicoNecesarioNecesarioLibre implementacin (abstracto)ConsistenteConsistenteConsistenteNo redundanteCompletoCompletoUn vistazo al proceso de administracin de requerimientosRequerimientos y documentos creados en cada faseAdministracin de requerimientosActividadesPreguntasQu hemos aprendido?ReflexionemosNmero de diapositiva 51