Requerimientos.

Presentación del tema: "Requerimientos."— Transcripción de la presentación:

1 Requerimientos

2 Agenda Definiciones Iniciales: Requerimientos
Problemas con los Requerimientos Procesos de Requerimientos Especificación de Requerimientos

3 Requerimiento Restricción sobre el espacio de soluciones de software.
Condición que debe ser cumplida por el software para que pueda ser recibido por el cliente. Se negocia/determina de mutuo acuerdo con el cliente. No todas las necesidades y expectativas de los clientes son requerimientos.

4 Unas definiciones iniciales
Calidad Existe muchas definiciones y teorías de calidad. Algunas de las teorías actuales sobre sistemas, calidad y procesos fueron desarrolladas en la década de 1940, por investigadores americanos en el Japón (Deming). Administración Total de Calidad El ciclo de Hacer-Planear-Verificar-Actuar Mejoramiento continuo de procesos

5 Unas definiciones iniciales
Calidad Podríamos definir calidad como la satisfacción de las necesidades y expectativas de los usuarios. La clave esta en lograr convertir las necesidades y expectativas de los usuarios en requerimientos. Los requerimientos no son (de por sí) las necesidades y las expectativas de los usuarios.

6 Unas definiciones iniciales
Requerimiento Característica requerida para recibir, aceptar o adquirir un producto. Restricción sobre el espacio de soluciones. Si No

7 Unas definiciones iniciales
El conjunto de requerimientos define el espacio de soluciones aceptables. Soluciones Aceptables

8 Unas definiciones iniciales
Ejemplo... Comprar una videocasetera Debe ser Sony Debe manejar VHS Debe costar menos de $ oo Debe poderse pagar con tarjeta de crédito

9 Unas definiciones iniciales
Ejemplo... Comprar una videocasetera ¿Compraría una grabadora de audio, Sony, de menos de $ ?. ¿Compraría una videocasetera Panasonic, de menos de $ ? ¿Compraría una videocasetera Sony de $ ?

10 Unas definiciones iniciales
Los requerimientos deben negociarse con los clientes Las necesidades y expectativas de los clientes son requerimientos potenciales. La negociación permite determinar los requerimientos del sistema/software. Los requerimientos deben ser parte integral de los contratos.

11 Unas definiciones iniciales
Requerimientos Potenciales Necesidades, Deseos, Expectativas del cliente Requerimientos Acuerdos entre Desarrolladores y Clientes Entrevistas Especificación Negociación

12 Unas definiciones iniciales
Calidad... Cumplir con los requerimientos. Cumplir con lo acordado con los clientes. Cumplir a cabalidad el contrato. Los contratos deben elaborarse adecuadamente. Los contratos deben contener a los requerimientos.

13 Unas definiciones iniciales
La Ingeniería de Software y los procesos de desarrollo de software suponen que los requerimientos de software ya existen (ya están definidos, por lo menos informalmente). El punto de partida de todo proceso de ingeniería son los requerimientos.

14 Problemas con los Requerimientos
El proceso de requerimientos no es fácil. No es simplemente “tomar nota” de las necesidades del cliente. Es un proceso de comunicación. Es necesario entender que es lo que quiere el cliente. Es un proceso de negociación. Es necesario determinar que cosas podemos comprometernos a hacer.

15 Problemas con los Requerimientos
No hay acuerdos en los Requerimientos No se hizo ningún tipo de negociación y no hay acuerdos reales entre los usuarios y desarrolladores. No se ha realizado ningún tipo de verificación que posibilite determinar si los desarrolladores han comprendido las exigencias de los usuarios. Los Requerimientos no se han priorizado No se ha hecho ningún estudio costo-beneficio, ni de ningún otro tipo que posibilite la definición de prioridades y/o cronogramas basados en los requerimientos.

16 Problemas con los Requerimientos
Requerimientos incompletos El listado de los requerimientos no incluye cosas que son necesarias para que el software funcione. Requerimientos contradictorios Unos requerimientos parecen contradecir a otros requerimientos. Si el software cumple a cabalidad con algunos requerimientos, ni puede cumplir con los otros.

17 Problemas con los Requerimientos
Requerimientos ambigüos Existen múltiples interpretaciones para el requerimiento. Cada usuario y/o desarrollador puede entender algo distinto. (Puede no existir ningún acuerdo). Requerimientos de Desarrollador. El desarrollador introduce requerimientos que no fueron solicitados por el cliente, y que hacen díficil satisfacer los requerimientos reales. (Presunciones de Diseño).

18 Problemas con los Requerimientos
¿Cómo solucionar el problema? Un proceso disciplinado que busque determinar y solucionar los diferentes problemas de los requerimientos. Un sistema de especificaciones que posibilite comunicar y negociar los requerimientos eficientemente con los usuarios.

19 Procesos de Requerimientos
En la actualidad, a diferencia de los métodos tradicionales, existe una separación marcada entre los procesos de requerimientos y de análisis de requerimientos. Existen varias opciones en torno a los procesos de Requerimientos Ingeniería de Requerimientos

20 Procesos de Requerimientos
Aplicando UML y Patrones, Larman Casos de Uso Reales Declaración de Trabajo Listado de Casos de Uso Casos de Uso Esenciales Prototipos

21 Procesos de Requerimientos
Use Case in Context, Kulak Listado de Casos de Uso Casos de Uso Terminados Declaración de Trabajo Casos de Uso Fachada Casos de Uso Completos Casos de Uso Enfocados Listado de Actores Prototipos

22 Procesos de Requerimientos
RUP Casos de Uso Prototipos Especificación con Casos de Uso Visión de Producto Glosario de Términos

23 Procesos de Requerimientos
Iconix Declaración de Trabajo Prototipos Casos de Uso

24 Proceso de Requerimientos
El prototipo es el mecanismo para “revisar” las especificaciones de requerimientos. La Especificación es el mecanismo para “formalizar” los acuerdos entre desarrolladores y usuarios.

25 Proceso de Requerimientos
Algunos métodos y autores sugieren comenzar con la definición de los prototipos ¿Será conveniente? ¿Qué pasa si el usuario no sabe “a ciencia cierta” que es lo que quiere? La realización de los prototipos puede ser un “arma de doble filo”.

26 Especificación de Requerimientos
La Especificación es: El documento final que detalla, de manera completa y no ambigüa, los requerimientos del software a desarrollar. El proceso de construcción de ese documento.

27 Especificación de Requerimientos
La Especificación puede realizarse de acuerdo a estándares internacionales reconocidos o a formatos de métodos formales de Ingeniería de Software ANSI/IEEE NSA NASA RUP Otros.

28 Agenda Levantamiento Analisis Especificación Validación

29 Requerimientos “El desarrollo de requerimientos puede ser subdividido en : Levantamiento, Analisis, Especificación y Verificación” Thayer and Dorfman 1977. Cada etapa deberá contar con tecnicas claras, estandares, metodos y herramientas que permitan madurar los pasos del proyecto.

30 Requerimientos Metas y Objetivos
Escribir una buena especificación de requerimientos. Validaciones y acuerdos con los usuarios Validación del entendimiento del problema.

31 Requerimientos Desarrollo de requerimientos EXCELENTES REQUERIMIENTOS
VALIDACION METODOS DE ESPECIFICACION DE RQTS TECNICAS DE IDENTIFICACION DE REQTS METODOS DE DOCUMENTACION HERRAMIENTAS Y ESTANDARES

32 Requerimientos Conceptos
Los requerimientos son: “Una especificación de lo que deberia ser implementado. Ellos son descripciones de cómo el sistema deberia comportarse o son tambien un atributo o propiedad del sistema. Ellos pueden ser una restricción o condición en el proceso de desarrollo del sistema” (Sommerville and Sawyer 1977). Es indispensable que todos y cada uno de los requerimientos esten, excelentemente definidos, claros y validados.

33 Requerimientos Calidad
Como saber si una especificaión de requerimientos es buena o tiene problemas ?

34 Requerimientos Necesarios No ambiguos Verificables Completos Correctos
Características de excelentes requerimientos Necesarios No ambiguos Verificables Completos Correctos Viables Priorizables Consistentes

35 Requerimientos Necesarios
Deberá documentar algo que el usuario realmente necesita. Cuando forma parte de un contrato firmado. Es requerido por un estandar o por variables externas indispensables.

36 Requerimientos No ambiguos
Un requerimiento es NO AMBIGUO si todos los lectores pueden llegar a la misma interpretación “Escribalo en lenguaje natural, evitando terminos tecnicos, de ser necesario haga un glosario.”

37 Requerimientos Verificables
Aplique metodos formales, para realizar pruebas que confirmen que el requerimiento esta correctamente especificado. Utilice la documentación escrita sobre el tema para verificar el requerimiento

38 Requerimientos Completos
Requerimientos mal especificados podrian esconder información que no es facil de detectar. Enfoquese en conocer las tareas del usuario, y no en sesgarse en las funciones que deberia tener el sistema. Si Ud. Sabe que tiene información incompleta utilice marcas o banderas que le anuncien “TAREAS PENDIENTES”.

39 Requerimientos Viables
Es mas facil implementar requerimientos cuando se conocen las limitaciones tecnicas, la capacidad, y las condiciones que rodean el ambiente del proyecto. Para detectar requerimientos “NO VIABLES” es importante incluir dentro del equipo de analisis un miembro de la parte tecnica o de ingenieria, asi como un miembro del dominio del problema.

40 Requerimientos Viables
Cada requerimiento indica una funcionalidad o condición que debe contener el software. No podemos contar con interpretaciones incorrectas sobre funcionalidades. Un usuario representativo puede determinar si un requerimiento es correcto o no.

41 Requerimientos Priorizables
Si todos los requerimientos tienen el mismo nivel de prioridad, esto es un sintoma de mala especificación. Cada requerimiento o conjunto de ellos debe poderse distribuir en las diferentes releases o versiones del producto. Si todos los requerimientos son de “alta prioridad”, problemas para incluir nuevos.

42 Requerimientos Consistentes
Los requerimientos deben estar acordes con las reglas del negocio y con las variables externas que afectan el dominio del problema. Si un requerimiento tiene conflicto con otro requerimiento  problema de especificación.

43 Requerimientos Problemas ?  Estrategias
Si no llega a un acuerdo con el usuario y sigue considerandolo NECESARIO, ESCALE EN NIVEL ORGANIZACIONAL O EN DOMINIO DEL PROBLEMA. Presente modelos similares y resultados obtenidos del mismo dominio u otros dominios Si continua considerando que aun es AMBIGUO, valide con otros miembros del dominio diferentes a la fuente. Arme un grupo hectereogeneo de discusión de ambiguedades.

44 Requerimientos Problemas ?  Estrategias
Si no lo considera lo suficientemente VERIFICABLE, apoyese en bibliografia y teorias. Busque expertos externos en el dominio. Busque una formula que lo lleve al resultado esperado. Si considera que aun no es CORRECTO, diseñe una encuesta con formato cerrado de respuesta.

45 Requerimientos Problemas ?  Estrategias
Si considera que aun no es VIABLE, busque opinion de terceros que tengan un buen nivel de credibilidad. Justifique en terminos economicos ($). Si no lo ha podido PRIORIZAR, elabore una tabla para que el usuario asigne una priorida unica a cada requerimiento. Escale con la tabla. Si considera que aun no es CONSISTENTE, reuna las fuentes y plantee la problematica

46 Requerimientos Identificación de requerimientos
Analice los documentos “fuentes” (resultados de las reuniones con los usuarios). Extraiga las sentencias que contienen las palabras : DEBERÁ , DEBE. Identifique sentencias que impliquen requerimientos. Identifique sentencias de tipo VERBOS, ACCIONES Y UN RESULTADO. Haga una lista de FUNCIONALES Y NO FUNCIONALES.

47 Requerimientos Vital para el entendimiento.
Redacción de requerimientos - IMPORTANCIA Vital para el entendimiento. Buena redaccion facilita buena interpretacion. Redaccion estandar facilita comprension. Buena redaccion, facil validacion. TODOS LOS REQUERIMIENTOS DEBEN TENER EL MISMO ESTILO DE REDACCION

48 Requerimientos Modelo de redacción de requerimientos NUEVOS “El sistema en el modulo de ventas debe ofrecer una opción mediante la cual el usuario pueda ver una comparacion de lo presupuestado versus la venta real en un rango de fechas”

49 Requerimientos Modelo de redacción de requerimientos NUEVOS Lugar tiempo evento objeto A quien Sujeto Debe, deberá, no debe, no deberá Acción verbo sentencia “Cuando el tiempo de conexión exceda el valor predeterminado como maximo, el sistema debe cancelar la selección informandole a el usuario que el tiempo se agoto y por lo tanto sera desconectado”

50 Requerimientos Modelo de redacción de requerimientos ERRORES –MODIFICACIONES - MEJORAS Lugar tiempo evento objeto A quien Sujeto Debe, deberá, no debe, no deberá Acción verbo sentencia “En el reporte de mercados objetivos, al aplicarle filtros por asesor y zona, muestra la informacion en desorden, se debe corregir de tal forma que salga ordenado por numero de cedula del asesor y agrupado por zona”

51 Requerimientos Mantenga sentencias y parrofos cortos.
Al escribir requerimientos TENGA EN CUENTA Mantenga sentencias y parrofos cortos. Apropiada gramatica, ortografia y puntuación. Haga un glosario. Utilice terminos consistentes definidos en el glosario. El sistema debe, deberá.. Seguidas de una acción. Para evitar ambiguedades no use : amigable, facil. Simple, rapido, fuerte, superior, aceptable, robusto. Si encuentra “y” , “o”, “etc”, esto puede representar varios requerimientos.

52 Requerimientos Ejemplo para párrafos narrativos.
Requerimos que en el momento de realizar una factura a credito, que el sistema automaticamente despliegue la pantalla de recaudo, donde el vendedor deberá digitar el valor del recaudo para esa factura. Ese valor de recaudo deberá ser igual al valor de la factura que acabo de crear, y ademas las opciones de pago que deberan aparecer deben ser solo las de cheque postfechado o credito firmado. De igual forma el sistema valida si el vendedor tiene autorizacion para recibirle cheque a ese cliente y si no la tiene debe esconder la opción de cheque postfechado. Cuando acabe de grabar ese recaudo, el valor no deberá afectar su cartera, y si se recibio cheque, esa informacion del cheque deberá ser guardada para que sea impresa en la factura que se va a grabar.

53 Administracion de Requerimientos
Contar con una herramienta que permita la administración adecuada de los requerimientos. RTM (Trace Matrix Requeriments). Ejemplo Asist Web ?? Existen herramientas comerciales para la ADM de requerimientos. Cuales ??

54 Clasificarlos Especificarlos Priorizarlos Requerimientos
Análisis de requerimientos Clasificarlos Especificarlos Priorizarlos

55 Requerimientos Clasificación de requerimientos
La clasificación ayuda a determinar que requerimientos se desarrollan o no. Es una propuesta que permite ACOTAR el desarrollo de los requerimientos. Nos ayuda a tomar en cuenta todos los requerimientos pero a enfocarnos en los FUNCIONALES. Para clasificarlos se deben tomar en cuenta los diferentes tipos de requerimientos.

56 Requerimientos SW (Software Requeriment) SWC (Software Constraint)
Clasificación de requerimientos SW (Software Requeriment) SWC (Software Constraint) DR (Deriverd Requeriment) D# (Duplicated Requeriment) HW (Hardware Requeriment) NTH (Nice To Have) P (Performance Requeriment)

57 Requerimientos Clasificación de requerimientos SW (Software Requeriment). Aquellos que representan una funcionalidad en el software. Son los que se construyen en el producto

58 Requerimientos Clasificación de requerimientos SWC (Software Constraint). Ayudan al analista a incluir condicionamientos, que pueden generar dificultades a la hora de contruir el software.

59 Requerimientos Clasificación de requerimientos DR (Deriverd Requeriment). Un requerimiento que se deriva de otro que ya existe. Se deriva por DETALLE o por CONSECUENCIA.

60 Requerimientos Clasificación de requerimientos D# (Duplicate Requeriment). Esta caracteristica o tipificación permite que este requerimiento no se DESARROLLE.

61 Requerimientos Clasificación de requerimientos HW (Hardware Requeriment). Esta caracteristica representa que este requerimiento no necesariamente tendra opciones de CÓDIGO. O que este requerimiento implica funcionalidad en un HARDWARE “es parte del proyecto”

62 Requerimientos Clasificación de requerimientos NTH (Nice To Have). Esta tipificación sirve para identificar aquellos requerimientos que estan por fuera del alcance del proyecto. Se podran tener en cuenta en futuras versiones “NO SE DESARROLLA”

63 Requerimientos Clasificación de requerimientos P (Performance Requeriment). Esta caracteristica ayuda al analista a generar PRECONDICIONES o cualidades especificas en el diseño, para cumplir con un requerimiento de rendimiento.

64 Requerimientos Priorización de Requerimientos
La mayoria de los equipos de desarrollo son conscientes de que los requerimientos deben ser priorizados.