02 desarrollo de requisitos

904 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
904
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

02 desarrollo de requisitos

  1. 1. 1 Ingeniería de Requisitos Tema 2: Desarrollo de Requisitos (Dr. Ricardo Quintero)
  2. 2. 2 Temas  La Visión del Producto y el Alcance del Proyecto  Clasificación de los Usuarios  Levantamiento de Requisitos  Entendiendo los Requisitos de Usuario  Las Reglas del Negocio  Documentando los Requisitos  Modelos y Diagramas para diversos Requisitos  Requisitos No Funcionales  Validación de Requisitos
  3. 3. La Visión del Producto y el Alcance del Proyecto  Historia verdadera: “Cuando mi colega Karen introdujo en su compañía la inspección del documento de requisitos, observó que muchos de los aspectos que los inspectores detectaron pertenecía al alcance del proyecto. Los inspectores frecuentemente tenían un entendimiento diferente sobre el alcance y objetivos del proyecto. En consecuencia, tuvieron dificultad para determinar que RF pertenecían al DERS” 3
  4. 4. Introducción  Los RN representan el nivel de abstracción más alto en la cadena de requisitos.  Definen la Visión y el Alcance para el sistema software.  Los RU y los RF deben alinearse al contexto y objetivos que los RN establecen. 4
  5. 5. Introducción  Proyectos que no tienen bien definida y comunicada la dirección invitan al desastre: los stakeholders nunca se ponen de acuerdo en los requisitos si carecen de un entendimiento común de los RN para el producto. 5
  6. 6. Introducción  Un síntoma común de que los RN no están suficientemente definidos se refleja en la inclusión, borrado y agregado continuo de características.  La Visión y el Alcance se deben resolver antes que se detallen los RF.  Esta Visión y Alcance ofrece el marco de referencia adecuado para la toma de decisiones sobre cambios y extensiones en requisitos. 6
  7. 7. La Visión del Producto  Def.- Describe lo que es el producto actual y lo que eventualmente llegará a ser.  La VP alinea a todos los stakeholders en una dirección común. 7
  8. 8. El Alcance del Proyecto  Def.- Identifica que porción de la visión a largo plazo del producto manejará el proyecto actual.  El AP pone límites a lo que estará dentro o fuera. Define los límites del proyecto.  Los detalles del AP se representan mediante la línea base de requisitos que el equipo define para el proyecto. 8
  9. 9. Visión del Producto y Alcance del Proyecto  La Visión aplica al Producto como un todo. Cambiará lentamente ante la evolución de los objetivos del negocio.  El Alcance pertenece a un proyecto específico o iteración que implementará el siguiente incremento de la funcionalidad del producto. Más dinámico que la visión, el líder de proyecto la ajusta en función de tiempo, presupuesto, recursos, calidad. 9
  10. 10. Visión del Producto y Alcance del Proyecto-Gráficamente 10
  11. 11. El documento de Visión y Alcance  El documento de Visión y Alcance recolecta los RN en un solo documento que pone la base para el trabajo subsecuente.  El propietario de este documento es el patrocinador ejecutivo del proyecto (o alguien similar).  El analista puede trabajar con el propietario para escribir el documento. 11
  12. 12. El documento de Visión y Alcance  La entrada a los RN debe provenir de los individuos que tienen un claro sentido del porqué del proyecto. 12
  13. 13. Plantilla básica para el documento de visión Puede basarse en esta plantilla 13
  14. 14. Ejemplos…  Oportunidad de Negocio: “Explotar el registro pobre de seguridad de un producto de la competencia”.  Objetivo de Negocio: “Capturar el 80% del mercado por ser reconocido como el producto más seguro en el mercado a través de revisiones de revistas y encuestas de consumidores”.  Necesidad del cliente: “Un producto más seguro”.  Característica: “Un motor de seguridad nuevo, robusto”. 14
  15. 15. El Diagrama de Contexto  La descripción del Alcance establece los límites y conexiones entre el sistema y el resto del universo.  El Diagrama de Contexto ilustra gráficamente estos límites.  Incluye:  Terminadores: que interactúan con el sistema.  Datos y control.  Flujo 15
  16. 16. El Diagrama de Contexto  Se puede incluir en el documento de Visión y Alcance o como un apéndice del DERS. 16
  17. 17. Ejemplo de Diagrama de Contexto 17
  18. 18. 18 Temas  La Visión del Producto y el Alcance del Proyecto  Clasificación de los Usuarios  Levantamiento de Requisitos  Entendiendo los Requisitos de Usuario  Las Reglas del Negocio  Documentando los Requisitos  Modelos y Diagramas para diversos Requisitos  Requisitos No Funcionales  Validación de Requisitos
  19. 19. Clasificación de los Usuarios  La participación del cliente es un factor crítico para el éxito de los proyectos.  El éxito en los requisitos software, y por tanto en el desarrollo de software, depende en obtener la voz del cliente cerca del oído del desarrollador.  Es importante identificar representantes de clientes al proyecto. 19
  20. 20. Pasos para buscar la voz del cliente 1. Identificar las diferentes clases de usuarios para el producto. 2. Identificar las fuentes de RU. 3. Seleccionar y trabajar con individuos que representen cada clase de usuario y otros grupos de stakeholders. 4. Acordar quienes serán los tomadores de decisiones de requisitos de tus proyectos. 20
  21. 21. Fuentes de Requisitos  Los orígenes de los Requisitos Software dependerán de la naturaleza del producto y tu ambiente de desarrollo. 21
  22. 22. Típicas Fuentes de Requisitos  Entrevistas y discusiones con usuarios potenciales.  Documentos que describen el producto actual o de la competencia.  Problemas reportados y solicitudes de extensión al sistema actual.  Encuestas de mercado y cuestionarios de usuarios.  Observando usuarios en su trabajo.  Análisis de escenarios (CU).  Eventos y respuestas (sistemas de tiempo real). 22
  23. 23. Clases de Usuarios  Los usuarios difieren en los siguientes aspectos:  Su experiencia en el dominio y su expertise en computación.  Las características que ellos usan.  Las tareas que realizan en soporte a sus procesos de negocio.  Sus privilegios de acceso o niveles de seguridad. 23
  24. 24. Clases de Usuarios  Basados en los aspectos anteriores se pueden agrupar los usuarios en diferentes clases de usuarios. 24
  25. 25. Clases de Usuarios  Usuarios favorecidos: reciben trato preferencial cuando se toman decisiones de prioridad o se resuelven conflictos entre requisitos.  Usuarios desfavorecidos: aquellos que se espera que no usen el producto (por razones legales, seguridad) 25
  26. 26. Clases de Usuarios  Usuarios ignorados y otras clases de usuarios: otros usuarios que no se consideran como parte de la clasificación. 26
  27. 27. Importancia de la clasificación de usuarios  Cada clase de usuario tendrá sus propios requisitos para las tareas que desempeñan  Tendrán diferentes requisitos no funcionales (usabilidad) que conducirá las decisiones de diseño de la IU.  Muy importante: cada tipo de usuario será la fuente básica de levantamiento de requisitos.  Considere, además, un catálogo de usuarios para todos los sistemas. Podrá reutilizarlo sistema a sistema. 27
  28. 28. Clases de Usuarios y el DERS  Documenta las clases de usuarios y sus características, responsabilidades y localizaciones físicas en el DERS.  Incluye toda la información pertinente de cada clase de usuario, su tamaño relativo o absoluto y cuales clases son favorecidas, esto ayudará a priorizar las peticiones de cambios y conducir la evaluación de impacto posteriormente. 28
  29. 29. Ejemplo de Clases de Usuarios Químicos (Favorecidos) Aproximadamente 1000 químicos localizados en 6 edificios utilizarán el sistema para solicitar químicos de vendedores y del almacén. Cada químico utilizará el sistema varias veces al día, necesitan buscar en catálogos de vendedores. Compradores Conocen poco de química y necesitan ayudas de consulta para los catálogos de vendedores. Utilizarán el sistema unas 20 veces al día 29
  30. 30. Un usuario ejemplo  Es posible crear 1 usuario representativo de cada clase, como sigue: “Alfredo, de 41 años, ha sido químico en Contoso Farmaceutica desde que se graduó hace 14 años. No tiene mucha paciencia con las computadoras. Trabaja en 2 proyectos a la vez …”  Conforme exploras los requisitos del químico, piensa en Alfredo como el Arquetipo de esta clase de usuario y pregúntate: ¿Qué necesitará hacer Alfredo? 30
  31. 31. Buscando Representativos de Usuarios  Todo tipo de proyecto necesita usuarios representativos que provean la voz del cliente.  Estos usuarios representativos deberían estar involucrados a través de todo el ciclo de vida, no sólo en la fase aislada de requisitos al inicio.  Una estrategia útil también es crear grupos enfocados de usuarios que incluyan expertos y novatos. 31
  32. 32. Rutas de comunicación entre Usuarios y Desarrolladores 32
  33. 33. El Campeón del Producto (Product Champion)  Cada Campeón de Producto es la interfase principal entre miembros de una clase de usuario y el analista de proyectos.  Los Campeones deben ser usuarios actuales, no representantes de patrocinadores, gerentes o desarrolladores de software que pretenden ser usuarios. 33
  34. 34. El Campeón del Producto (Product Champion)  Los mejores Campeones de Producto tienen una clara visión del nuevo sistema y son entusiastas acerca de él porque ven el próximo beneficio para él y sus compañeros.  Deben ser comunicadores efectivos, respetados por sus colegas.  Deben tener entendimiento pleno del dominio del problema.  Debe estar completamente empoderado para tomar decisiones sobre sus representados. 34
  35. 35. Expectativas de los Campeones de Productos 35 Categoría Actividades Planeación •Refinar el alcance y limitaciones del producto. •Definir las interfases a otros sistemas. •Evaluar el impacto de nuevos sistemas sobre operaciones del negocio. •Definir la ruta de transición a partir de las aplicaciones actuales Requisitos •Recolectar requisitos de otros usuarios •Desarrollar los escenarios en los CU •Resolver conflictos entre requisitos propuestos
  36. 36. Expectativas de los Campeones de Productos 36 Categoría Actividades Validación& Verificación •Inspeccionar los documentos de requisitos •Definir el criterio de aceptación •Desarrollar los casos de prueba a partir de los escenarios de los CU •Proveer los conjuntos de datos de pruebas •Realizar las pruebas beta Ayuda a usuarios •Escribir porciones de manuales de usuarios y ayuda •Preparar material para entrenamiento •Presentar demostraciones de productos a compañeros Gestión de Cambios •Evalúa y prioriza las correcciones de defectos •Evalúa y prioriza peticiones de extensión •Evalúa el impacto de cambios propuestos de requisitos en usuarios y procesos de negocio •Participa en las decisiones de cambios
  37. 37. “Vendiendo” la idea del Campeón de Producto  Espera oposición a la propuesta del Campeón del Producto: “Los usuarios están muy ocupados”, “La gerencia quiere tomar las decisiones”, “Nos va a demorar”, “Es muy caro”, “No se lo que voy a hacer como Campeón de Producto”.  Recuerda la importancia del involucramiento del usuario. 37
  38. 38. 38 Temas  La Visión del Producto y el Alcance del Proyecto  Clasificación de los Usuarios  Levantamiento de Requisitos  Entendiendo los Requisitos de Usuario  Las Reglas del Negocio  Documentando los Requisitos  Modelos y Diagramas para diversos Requisitos  Requisitos No Funcionales  Validación de Requisitos
  39. 39. Introducción  Lea la siguiente Historia.  ¿Le ha sucedido algo similar al levantar requisitos? Comente. 39
  40. 40. Introducción  El corazón de la IR es la Elicitación de Requisitos (o levantamiento de requisitos).  La ER es el proceso de identificar las necesidades y restricciones de los diferentes stakeholders del sistema software. 40
  41. 41. Introducción  La ER se centra en los RU: las tareas que los usuarios deben realizar con el sistema y las expectativas de rendimiento, usabilidad y otros atributos de calidad del usuario.  El analista debe cambiar la pregunta : ¿Qué deseas? por ¿Qué necesitas hacer? 41
  42. 42. Introducción  El resultado de la ER es un acuerdo general de las necesidades.  Una vez que se encuentran estas necesidades, los desarrolladores pueden explorar soluciones alternativas para atender las necesidades.  Los participantes de la ER deben resistir la tentación de diseñar el sistema hasta que entiendan el problema, de otra forma se arriesgan a hacer considerable tarea de rediseño posteriormente. 42
  43. 43. Introducción  El énfasis principal es en las tareas en lugar de la IU y en enfocarse en las necesidades básicas más que en deseos. Esto mantiene al equipo enfocado y evita el desvío prematuro hacia detalles de diseño. 43
  44. 44. Planeación de la Elicitación de Requisitos  Empieza por planear las actividades de la Elicitación de Requisitos.  Aún un plan simple de acciones incrementa la posibilidad de éxito y ofrece expectativas reales a los stakeholders. 44
  45. 45. Elementos a incluir en la planeación de la ER  Objetivos (explorar CU, desarrollar los RF, etc.)  Estrategias y procesos (encuestas, talleres, visitas al cliente, entrevistas individuales o a grupos)  Productos (lista de CU, el DERS, análisis de encuestas o especificaciones de atributos de calidad)  Estimación de tiempos y recursos (identificando clientes y analistas en las actividades, estimaciones de esfuerzo y tiempo)  Riesgos (factores que pueden impedir la ER, severidad de cada riesgo y como mitigar o controlar el riesgo) 45
  46. 46. Elicitación de Requisitos  La ER tiene éxito cuando se establece una relación colaborativa entre clientes y los desarrolladores de requisitos.  La comunicación se facilita cuando se usa el vocabulario del dominio y se evita la “jerga” computacional. Use glosarios.  Cuando la discusión se empieza a tornar hacia el “espacio de la solución” la pregunta ¿Porqué? puede devolverla al “espacio del problema” 46
  47. 47. Elicitación de Requisitos  En lugar de sólo transcribir lo que los usuarios dicen, un analista creativo sugiere ideas y alternativas a los usuarios durante la elicitación.  Cuando los usuarios no pueden expresar lo que ellos necesitan, quizá puedas observar su trabajo (o incluso hacerlo) y sugerir formas de automatizar el mismo.  Después de cada entrevista, documenta los aspectos discutidos y pide a los entrevistados que revisen la lista y hagan correcciones. 47
  48. 48. Talleres de Elicitación  Los talleres de requisitos son una técnica altamente efectiva para vincular usuarios y desarrolladores (de requisitos).  El facilitador debe planear el taller, seleccionar los participantes y guiar a los participantes a un resultado exitoso. 48
  49. 49. Tips para conducir sesiones exitosas en talleres de requisitos  Establecer reglas claras:  Iniciar y finalizar a tiempo.  Regresar rápido de los “breaks”.  Sólo uno comenta a la vez.  Todos deben contribuir.  Enfocar comentarios en aspectos, no en individuos. 49
  50. 50. Tips para conducir sesiones exitosas en talleres de requisitos  Mantenerse en el alcance:  Usar el documento de visión y alcance para confirmar si los RU propuestos caen dentro del alcance del proyecto.  Enfocarse en las tareas del usuario y no en detalles de diseño de IU (que vendrá después). 50
  51. 51. Tips para conducir sesiones exitosas en talleres de requisitos  Usar “parking lots” para registrar elementos para posterior consideración:  Múltiple información surgirá en el taller (atributos de calidad, reglas de negocio, ideas de IU, restricciones, etc.). Usar hojas de rotafolio como “Parking lots” para no perderlas, mostrar respeto a quien las brinda y usarlas después. 51
  52. 52. Tips para conducir sesiones exitosas en talleres de requisitos  Discusiones “Timebox”:  Asignar una periodo fijo de tiempo para discutir cada tópico (ej. 30 min. Por cada CU). Evitar invertir más tiempo que el necesario para evitar enfrentar otros tópicos. 52
  53. 53. Tips para conducir sesiones exitosas en talleres de requisitos  Mantener el equipo pequeño e incluir los participantes correctos.  Grupos mayores a 5 o 6 participantes avanzarán más lento.  Incluya al Campeón del Producto y otros representantes de usuarios, un analista de requisitos y un desarrollador. Considere “experiencia”, “conocimiento” y “autoridad para tomar decisiones” como calificadores para participar en el taller.  Mantenga a todos participando en el taller. 53
  54. 54. Clasificando la entrada de los clientes  El analista debe clasificar la entrada de los clientes: 54
  55. 55. Requisitos del Negocio  Cualquiera que describa los beneficios económicos, de mercado o del negocio que los clientes o la organización desea ganar a partir del producto.  “Incremento del mercado en un X%”  “Ahorro de $Y por año en electricidad gastado ahora por unidades ineficientes”  “Ahorro de $Z en costos de mantenimiento consumidos por el sistema legado W” 55
  56. 56. Casos de Uso o Escenarios  Oraciones sobre objetivos de usuario o tareas del negocio que el usuario necesita realizar.  “Necesito imprimir una etiqueta para cada paquete”  “Necesito gestionar una cola de muestras químicas esperando ser analizadas”  “Necesito calibrar el controlador de la bomba” 56
  57. 57. Reglas de Negocio (RN)  Cuando el cliente dice que sólo ciertas clases de usuarios pueden realizar una actividad bajo condiciones específicas.  Se pueden derivar RF para forzar las reglas.  Las RN no son RF.  “Debemos cumplir con cierta ley o política corporativa”  “Se debe conformar algún a un cierto estándar”  “Si alguna condición es verdad, entonces algo sucede”  “Debe ser calculado de acuerdo a cierta fórmula” 57
  58. 58. Requisitos Funcionales (RF)  Describen comportamientos observables que el sistema exhibirá bajo ciertas condiciones y las acciones que permitirá a los usuarios tomar.  Se derivan de los RU, RN y el DERS.  “Si la presión excede 40 psi, la luz de precaución se encederá”  “El usuario será capaz de ordenar la lista del proyecto en orden alfabético ascendente y descendente”  “El Sistema enviará un e-mail al Coordinador de Ideas cuando alguien genere una nueva idea” 58
  59. 59. Atributos de Calidad  Oraciones que indican que tan bien el sistema desempeñará algún comportamiento o permitirá a los usuarios tomar alguna acción.  Rápido, fácil, intuitivo, amigable con el usuario, robusto, confiable, seguro, eficiente. (Todos éstos se deben definir de forma precisa con el usuario). 59
  60. 60. Requisitos de Interfases Externas  Describen conexiones entre tu sistema y el resto del universo.  El DERS debe incluir secciones para interfases con usuarios, hardware y otros sistemas software.  “Debe leer señales de un dispositivo”  “Debe enviar mensajes a otro sistema”  “Debe ser capaz de leer (o escribir) archivos en algún formato”  “Debe controlar una pieza de hardware”  “Los elementos de la IU deben conformarse a un estilo estándar de IU” 60
  61. 61. Restricciones  Restricciones de diseño e implementación que acotan legítimamente las opciones disponibles al desarrollador.  “Los archivos enviados electrónicamente no deben exceder 10 MB de tamaño”  “Debe ser escrito en Java”  “No debe requerir más de 1 Gb de RAM”  “Debe operar idénticamente a otro sistema”  “Debe usar un control de IU específico” 61
  62. 62. Definiciones de Datos  Cuando el usuario describe el formato, tipo de dato, valores permitidos o valores por default para un elemento de datos o la composición de una estructura de datos compleja.  “El código postal consiste de cinco dígitos, seguido por un guión opcional, el valor por default es 0000”  Recolecte estos en un diccionario de datos, una referencia maestra que el equipo puede utilizar a lo largo de todo el desarrollo del producto y su mantenimiento. 62
  63. 63. Ideas solución  Mucho de lo que los usuarios presentan como requisitos caen en la categoría de ideas solución.  Alguien que describe una forma específica de interactuar con el sistema para realizar cierta acción está presentando una solución sugerida.  El analista debe “sumergirse” debajo de la Idea Solución para obtener el verdadero requisito.  La clave: preguntar ¿Porqué? 63
  64. 64. ¿Cómo saber cuando terminar?  Si el usuario no puede pensar en más CU, quizá terminaste.  Si el usuario propone nuevos CU, cuyos RF ya fueron derivados, quizá terminaste.  Si los usuarios repiten aspectos cubiertos en previas discusiones, quizá terminaste. 64
  65. 65. ¿Cómo saber cuando terminar?  Si sugiere nuevas características, RU o RF fuera de alcance.  Si los requisitos propuestos son de baja prioridad.  Si los usuarios están proponiendo capacidades que serán incluidas “algún día en la vida del producto” en lugar de “ahora”. 65
  66. 66. 66 Temas  La Visión del Producto y el Alcance del Proyecto  Clasificación de los Usuarios  Levantamiento de Requisitos  Entendiendo los Requisitos de Usuario  Las Reglas del Negocio  Documentando los Requisitos  Modelos y Diagramas para diversos Requisitos  Requisitos No Funcionales  Validación de Requisitos
  67. 67. Introducción  Lea la siguiente Historia.  ¿Cómo conduce usted los talleres de requisitos para obtener los CU? 67
  68. 68. Introducción  Las personas utilizan los sistemas software para alcanzar objetivos y la industria del software busca crear software útil.  Un prerrequisito necesario para diseñar software útil es conocer lo que los usuarios intentarán hacer con él. 68
  69. 69. Introducción  Por muchos años, los analistas han utilizado escenarios para obtener los requisitos de usuarios.  Un escenario es una descripción de una sola instancia de uso del sistema.  Ivar Jacobson, Larry Constantine y Lucy Locwood, así como Alistair Cockburn han formalizado esto en los Casos de Uso. 69
  70. 70. El enfoque de Casos de Uso  Un Caso de Uso describe una secuencia de interacciones entre el sistema y un actor externo.  Aunque nacen en el mundo OO, pueden utilizarse para cualquier paradigma de desarrollo.  Los CU cambian la perspectiva de desarrollo de requisitos para discutir lo que los usuarios necesitan lograr en contraste al enfoque tradicional de preguntar a los usuarios lo que desean que el sistema haga. 70
  71. 71. Diagramas de CU  Proveen una representación visual de alto nivel de los RU. 71
  72. 72. Casos de Uso y Escenarios  Un CU es una actividad única que un actor realiza para lograr algo de valor.  Un CU es una colección de escenarios relacionados.  Los escenarios pueden ser normales o alternativos. 72
  73. 73. Elementos esenciales de la descripción de un CU  Un identificador único  Un nombre que de forma breve establezca la tarea del usuario “verbo+objeto”  Una descripción textual escrita en lenguaje natural  Una lista de precondiciones  Una lista de poscondiciones  Una lista numerada de pasos que muestren los pasos de la secuencia de diálogo entre actor y sistema 73
  74. 74. Cursos Normal y Alternativos en un CU 74
  75. 75. CU que comparten un conjunto común de pasos-<<include>> 75
  76. 76. CU con granuralidad mayor 76
  77. 77. Identificando Casos de Uso  Se pueden identificar en varias formas:  Identifica los actores primero y después los procesos de negocio en los cuales participan.  Identifica los eventos externos a los cuales el sistema debe responder y después relaciona estos eventos a actores participantes y CU especificos. 77
  78. 78. Identificando Casos de Uso  Se pueden identificar en varias formas:  Expresar procesos de negocio en términos de escenarios específicos, generalizar los escenarios a CU e identificar los actores involucrados en cada CU.  Derivar los CU a partir de RF. Si algunos requisitos no trazan a CU alguno, considere si realmente se necesitan. 78
  79. 79. Documentando los CU  En esta etapa de exploración, los participantes deben pensar en CU esenciales: simplificados, generalizados, abstractos, libres de tecnología e independientes de implementación.  El foco debe ser el objetivo que el usuario trata de alcanzar y las responsabilidades del sistema. 79
  80. 80. Documentando los CU  Los CU esenciales están a un nivel de abstracción más alto que los CU concretos.  Estilo concreto: capturar el número ID del químico.  Estilo esencial: especificar el químico deseado. 80
  81. 81. Ejemplo de CU  Este es un ejemplo de CU 81
  82. 82. CU y Casos de Prueba  Así como los CU esenciales también se pueden crear Casos de Prueba conceptuales (independientes de teconología).  Estos Casos de Prueba ayudan al equipo a tener un claro entendimiento de cómo el sistema se comportará en escenarios específicos. 82
  83. 83. CU y RF  Los desarrolladores software no implementan RN o CU, ellos implementan RF: “bits” específicos de comportamiento de sistema que permiten a los usuarios ejecutar los CU y lograr sus objetivos.  Es necesario que el analista traduzca la visión de requisitos del usuario (expresada en el CU) a la visión del desarrollador. 83
  84. 84. Formas de documentar los RF obtenidos a partir de los CU  Sólo CU: incluir los RF directo en la descripción del CU.  CU y DERS: escribir descripciones simples directas del CU y documentar los RF derivados en el DERS. Se debe establecer la trazabilidad entre ambos. 84
  85. 85. Formas de documentar los RF obtenidos a partir de los CU  Sólo DERS: organizar el DERS por CU o por característica e incluir ambos, CU y RF, en el DERS. 85
  86. 86. Errores a evitar  Muchos CU: quizá porque no se estén escribiendo al nivel de abstracción adecuado. Típicamente se deben tener más CU que RN y características, pero menos que los RF. 86
  87. 87. Errores a evitar  Incluir diseño de IU en los CU: los CU se deberían enfocar en lo que los usuarios necesitan lograr con la ayuda del sistema, no en como se deberían ver las pantallas. Enfatiza las interacciones conceptuales entre actores y sistema y difiere la IU específica a la etapa de diseño. 87
  88. 88. Errores a evitar  Incluir definiciones de datos en los CU. Manejarlo en un diccionario de datos separado.  CU que los usuarios no entienden. Si los usuarios no pueden relacionar la descripción del CU a sus procesos de negocio o tareas, hay problemas con el CU.  Uso excesivo de relaciones include y extends. 88
  89. 89. 89 Temas  La Visión del Producto y el Alcance del Proyecto  Clasificación de los Usuarios  Levantamiento de Requisitos  Entendiendo los Requisitos de Usuario  Las Reglas del Negocio  Documentando los Requisitos  Modelos y Diagramas para diversos Requisitos  Requisitos No Funcionales  Validación de Requisitos
  90. 90. Introducción  Toda organización opera de acuerdo a un conjunto extenso de políticas corporativas, leyes y estándares industriales.  Tales principios controladores se les conoce colectivamente como Reglas de Negocio. 90
  91. 91. Introducción  Las Aplicaciones Software frecuentemente forzan las RN, en otros casos son controladas humanamente mediante políticas y procedimientos.  Muchas RN se originan fuera del contexto de toda aplicación software, aunque suelen ser la fuente mayor de RF porque dictan capacidades que el sistema debe poseer para conformar con las reglas.  Aún Requisitos del Negocio de alto nivel podrían conducirse a partir de RN (cumplir con alguna regulación gubernamental). 91
  92. 92. Introducción  Las RN se deben tratar como un Activo Importante.  Si no se documentan o manejan apropiadamente existirán sólo en la “mente” de los individuos: se entenderán de forma distinta, se manejarán inconsistentemente.  Si se conoce donde y como cada aplicación implementa sus RN, será mucho más fácil cambiar las aplicaciones cuando la regla cambie.  Tener un Repositorio Maestro de RN facilitará a todas las aplicaciones afectadas su implementación consistente. 92
  93. 93. Taxonomía de las RN  Se han propuesta diferentes taxonomías (clasificaciones) para organizar las RN.  Veremos una taxonomía simple que incluye cinco tipos de RN que trabajan para muchas situaciones. 93
  94. 94. Taxonomía de las RN 94 Una sexta categoría podría incluir términos, palabras definidas, frases y abreviaciones que son importantes para el negocio. (Un Glosario es un lugar conveniente para definir términos)
  95. 95. Hechos (Facts)  Los Hechos son estatutos simples que son verdad a lo largo de todo el negocio. Son llamados invariantes (verdades inmutables de entidades y atributos).  Describen asociaciones o relaciones entre términos importantes del negocio.  Otras RN podrían referenciar ciertos Hechos, pero los Hechos en sí mismos generalmente no se traducen en RF software. 95
  96. 96. Ejemplos de Hechos (Facts)  “Cada contenedor químico tiene un identificador único en código de barras”  “Cada orden deberán tener un cargo de embarque”  “Cada línea de producto en una orden representa una combinación específica de químico, grado, tamaño de contenedor y número de contenedores”  “Boletos no reembolsables generan un cargo cuando el comprador cambia el itinerario”  “El impuesto de ventas no se calcula sobre cargos de embarque” 96
  97. 97. Restricciones (Constraints)  Los Constraints acotan las acciones que el Sistema o sus usuarios pueden realizar.  Algunas palabras y frases que sugieren una RN “Restricción”: debe, no debe, podría, solamente. 97
  98. 98. Ejemplos de Restricciones (Constraints)  “Un solicitante menor de 18 años debe tener un padre o tutor como aval del préstamo.”  “Un usuario puede solicitar un químico en nivel 1 solamente si tiene entrenamiento en químicos de uso rudo en los pasados 12 meses.”  “La correspondencia podría no desplegar más de 4 dígitos del número del IMSS.”  “La tripulación de una línea aerea debe recibir al menos 8 Hrs. De descanso continuo en cada periodo de 24 Hrs.” 98
  99. 99. Hay muchas restricciones  Pueden existir restricciones a nivel de proyecto o diseño o implementación.  Muchas RN imponen restricciones sobre la forma en la que el negocio opera: donde se reflejen en los RF software, la restricción es la justificación del RF.  En el acceso al sistema también hay restricciones (manejo de Passwords). 99
  100. 100. Habilitadores de Acción (Action Enablers)  Una regla que dispara alguna actividad bajo condiciones específicas es un Habilitador de Acción.  La condición podría ser una combinación compleja de valores falso y verdaderos para múltiples condiciones individuales. 100
  101. 101. Habilitadores de Acción (Action Enablers)  Forma general: “Si <alguna condición es verdadera o sucede algún evento> entonces <algo sucede>”  Se pueden documentar como Tablas de decisión (se verán después). 101
  102. 102. Habilitadores de Acción (Action Enablers) Ejemplos  “Si el almacén de químicos tiene contenedores de un cierto químico, entonces ofrece contenedores al solicitante”  “El último día del cuatrimestre, genera el reporte EP sobre manejo de químicos”  “Si el cliente ordenó un libro para autor que ha escrito múltiples libros, entonces ofrece los otros libros del autor antes de aceptar la orden” 102
  103. 103. Inferencias (Inferences)  Es una regla que establece nuevo conocimiento basado en la veracidad de ciertas condiciones.  También se le conoce como conocimiento inferido.  La inferencia crea un nuevo hecho a partir de otros hechos o a partir de computaciones. 103
  104. 104. Inferencias (Inferences)  También utilizan la forma “Si/Entonces”, pero la clausula “Entonces” implica un Hecho o Pieza de Información, no una acción a realizar. 104
  105. 105. Inferencias (Inferences) Ejemplos  “Si un pago no se recibe dentro de 30 días de calendario o la fecha está vencida, entonces la cuenta es reportada”  “Si el vendedor no puede embarcar un producto de la orden dentro de cinco días a partir de la recepción de la orden, entonces el producto es devuelto”  “Químicos con toxicidad LD50 menor a 5 mg/Kg son consideradores peligrosos” 105
  106. 106. Computaciones (Computations)  Cálculos realizados usando fórmulas matemáticas específicas o algoritmos.  Muchas computaciones siguen reglas que son externas a la compañía (como el cálculo de impuestos). 106
  107. 107. Computaciones (Computations)  “El precio unitario se reduce un 10% para ordenes de 6 a 10 unidades, 20% para órdenes de 11 a 20 unidades y 35% para órdenes mayores a 20 unidades”  “El cargo por envío terrestre para una orden que pesa más de 2 Kg. Es $4.75 más $0.12 por fracción”  “El precio total de una orden se calcula como la suma del precio de los productos, menos los descuentos, más lo impuestos, más el cargo de embarque y seguro” 107
  108. 108. Documentando las RN  Dado que las RN pueden influir múltiples aplicaciones, la organización debería manejarlas como un activo a nivel empresarial (no a nivel de proyecto).  En principio un catálogo simple es suficiente, en casos mayores se podría manejar una base de datos (con todo, busque siempre la simplicidad).  Trate de definir una plantilla para la documentación. 108
  109. 109. Ejemplo de plantilla para documentar las RN 109 ID Definición de la Regla Tipo de Regla Estática/ Dinámica Fuente ORDER-15 Un usuario puede solicitar un químico a nivel 1 solamente si tiene entrenamiento en los 12 meses anteriores Restricción Estática Política corporativa DISC-13 El descuento a la orden se calcula basado en el tamaño de la orden actual Computación Dinámica Política corporativa
  110. 110. Reglas del Negocio y Requisitos  Simplemente preguntar al usuario: “¿Cuáles son tus RN?” Suele no ayudar para su descubrimiento.  Dependiendo de la aplicación, algunas veces tendrás que inventar la RN conforme avances en el análisis y otras las descubrirás durante las discusiones de requisitos. 110
  111. 111. Reglas del Negocio y Requisitos  Durante el taller de Elicitación de Requisitos el analista tendrá que hacer preguntas sobre las razones de ciertos requisitos y restricciones que los usuarios presenten.  Estos discusiones provocan el surgimiento de RN como justificaciones. 111
  112. 112. Fuentes de RN y preguntas posibles que las obtienen 112
  113. 113. RN descubiertas y su implementación  Después de identificar y documentar la RN, determine cuales se deben implementar en el software.  Algunas RN conducirán a CU (y por tanto a Requisitos Funcionales que forzarán la regla). 113
  114. 114. RN descubiertas y su implementación-Ejemplo  Regla #1 (Habilitador de Acción) “Si la fecha de expiración para el contenedor químico se ha alcanzado, entonces notifique a la persona que posee actualmente el contenedor”  Regla #2 (Inferencia) “Un contenedor de un químico que puede formar un producto explosivo se considera expirado 1 año después de su fecha de manufactura”  Regla #3 (Hecho) “El Éter puede formar espontáneamente peróxidos explosivos” 114
  115. 115. RN descubiertas y su implementación-Ejemplo  Estas reglas dieron origen al CU “Notificar el propietario químico de expiración”  Un RF para este CU es “El sistema enviará una notificación por e-mail al propietario del contenedor químico en la fecha en la que el contenedor expire” 115
  116. 116. Trazabilidad entre RF y sus Reglas de Negocio padre  Use un atributo en el requisito llamado “Origen” e indique la regla que originó el RF  Defina enlaces de trazabilidad entre el RF y la(s) RN(s) pertinentes en la Matriz de Trazabilidad. 116
  117. 117. Recomendación Final  Para prevenir redundancia, no dupliques reglas del catálogo de RN en el DERS.  En su lugar, el DERS debería referenciar hacia reglas específicas como fuente, digamos, de algoritmos. 117
  118. 118. Siguientes pasos…  Lista todas las RN que pienses pertenecen al proyecto en el que estás trabajando. Empieza poblando un catálogo de RN. Clasifícalas de acuerdo a la taxonomía propuesta y discute el origen de cada regla.  Identifica la justificación detrás de tus requisitos funcionales para descubrir otras RN. 118
  119. 119. Siguientes pasos…  Construye una matriz de trazabilidad para indicar cuales RF o elementos de la base de datos implementan cada RN que has identificado. 119
  120. 120. 120 Temas  La Visión del Producto y el Alcance del Proyecto  Clasificación de los Usuarios  Levantamiento de Requisitos  Entendiendo los Requisitos de Usuario  Las Reglas del Negocio  Documentando los Requisitos  Modelos y Diagramas para diversos Requisitos  Requisitos No Funcionales  Validación de Requisitos
  121. 121. Introducción  El resultado del Desarrollo de Requisitos es un acuerdo entre clientes y desarrolladores sobre el producto a construir.  El documento de Visión y Alcance contiene los RN.  Los Requisitos de Usuario se capturan en los CU.  Los RF y RNF detallados residen en el Documento de la Especificación de Requisitos Software (DERS). 121
  122. 122. Introducción  A menos que todos los requisitos se escriban en un formato legible y los stakeholders clave los revisen, la gente no tendrá seguridad de lo que se está acordando. 122
  123. 123. Introducción  Los requisitos software se pueden representar de diversas formas:  Documentos que usan lenguaje natural estructurado y bien escrito.  Modelos gráficos ilustrando procesos, estados del sistema y sus cambios, relaciones de datos, etc.  Especificaciones formales matemáticas.  La forma más práctica: documentos textuales+modelos gráficos. 123
  124. 124. La Especificación de Requisitos Software  La ERS establece de forma precisa las Funciones y Capacidades que el sistema software debe proveer y las Restricciones que debe respetar.  Es la base para la posterior planeación, diseño y codificación (las cuales no deberían incluirse ahí). 124
  125. 125. ERS: completa y correcta  La ERS es el repositorio último para los requisitos del producto, por lo que se espera que sea completa.  Ni desarrolladores, ni clientes deberían hacer supuestos: si una cierta capacidad o calidad no aparece ahí, no se debe esperar que aparezca en el producto. 125
  126. 126. ERS: evolutiva e iterativa  No se debería esperar escribir el DERS completo desde el inicio.  Pero si se necesita capturar en él los requisitos de cada incremento, antes de construir tal incremento.  Antes de iniciar cada iteración se deberían fijar (obtener su línea base).  La línea base es el resultado de la revisión y aprobación de la ERS. 126
  127. 127. Organizando la ERS: Etiqueta los Requisitos  Para satisfacer el criterio de trazabilidad y modificabilidad cada RF se debe etiquetar.  Numéralos secuencialmente: RF- 39, RNF-40.  En caso de duda en algún requisito, señálalo de alguna manera: TBD (To be determined). 127
  128. 128. ERS e Interfases de Usuario  Imágenes de pantallas o arquitecturas de IU describen soluciones (diseños), no requisitos.  El diseño de pantallas podría retardar el establecimiento de la línea base de los requisitos.  Incluir diseño de IU en requisitos puede resultar en un diseño visual conduciendo los requisitos, lo cual puede llevar a vacíos funcionales. 128
  129. 129. ERS e Interfases de Usuario  Un balance adecuado podría ser incluir imágenes conceptuales (esquemas) de pantallas seleccionadas en la ERS sin demandar la implementación precisa siguiendo esos modelos.  Esto podría mejorar la comunicación sin motivar a los desarrolladores con restricciones innecesarias.  Debería ilustrar la intención subyacente, nada más. 129
  130. 130. Plantilla para la ERS (basada en el estándar IEEE 830)  No hay necesidad de inventar un nuevo documento de ERS.  Puede utilizar esta plantilla, basada en el estándar IEEE 830.  Un Ejemplo. 130
  131. 131. 131 Temas  La Visión del Producto y el Alcance del Proyecto  Clasificación de los Usuarios  Levantamiento de Requisitos  Entendiendo los Requisitos de Usuario  Las Reglas del Negocio  Documentando los Requisitos  Modelos y Diagramas para diversos Requisitos  Requisitos No Funcionales  Validación de Requisitos
  132. 132. Introducción  Lea esta Historia  Con relación a su experiencia, ¿Cuáles son los Diagramas que utiliza para la especificación de requisitos?. 132
  133. 133. Introducción  De acuerdo a Alan Davis (1995) no existe una sola vista de los requisitos que provea un entendimiento completo.  Se necesita una combinación de representaciones textuales y visuales para dibujar la imagen completa del sistema. 133
  134. 134. Introducción  Las vistas incluyen:  Listas y tablas de RF.  Modelos gráficos de análisis  Prototipos de IU  Casos de uso  Casos de prueba  Árboles de decisión  Tablas de decisión, etc. 134
  135. 135. Introducción  Los analistas podrían escribir los RF y dibujar algunos modelos.  Los diseñadores de IU construyen prototipos.  Los “testers” conducen la escritura de los casos de prueba. 135
  136. 136. Introducción  Comparando las diversas representaciones creadas a través de diversas personas, con diversos procesos de pensamiento revelará inconsistencias, ambigüedades, supuestos y omisiones difíciles de detectar a partir de una única vista. 136
  137. 137. De la Voz del Cliente a Modelos de Análisis  Escuchando cuidadosamente como presentan los clientes sus requisitos, el analista puede seleccionar palabras que se correspondan con elementos de modelado. 137
  138. 138. De la Voz del Cliente a Modelos de Análisis-Ejemplo 138 Tipo de Palabra Ejemplos Componentes de Modelos de Análisis Sustantivo Personas, organizaciones, sistemas software, datos u objetos que existan Terminadores o datos (DFD) Actores (CU) Entidades o sus atributos (DER) Clases o sus atributos (DC) Verbo Acciones, cosas que el usuario puede hacer, eventos que pueden suceder Procesos (DFD) CU Relaciones (DER) Transiciones (DTE) Actividades (DA)
  139. 139. Diagrama de Flujo de Datos (DFD)  Identifica los procesos transformacionales del sistema, las colecciones (almacenes) de datos o materiales que el sistema manipula y los flujos de datos o materiales entre procesos, almacenes y el mundo exterior.  Se puede elaborar el Diagrama de Contexto en el nivel 0 del DFD dividiendo el sistema en sus procesos mayores. 139
  140. 140. Diagrama de Flujo de Datos (DFD)-Ejemplo 140
  141. 141. Diagrama Entidad-Relación  Muestra las relaciones entre los datos del sistema.  Si el Diagrama ER se utiliza desde la perspectiva del analista entonces mostrará grupos lógicos de información del dominio del problema. 141
  142. 142. Diagrama Entidad-Relación- Ejemplo 142
  143. 143. Máquinas de Estado que modelan IU: el Mapa de Diálogo  El comportamiento de una IU se puede modelar mediante una Máquina de Estado.  En un momento en el tiempo un solo elemento de diálogo (menú, workspace, caja de diálogo, prompt, etc.) está disponible para entrada del usuario.  El usuario navega a un cierto elemento de diálogo basado en acciones que realiza desde el mismo.  Esta Máquina de estados se le llama Mapa de Diálogo (Wasserman y Wiegers) 143
  144. 144. Máquinas de Estado que modelan IU: el Mapa de Diálogo  El Mapa de Diálogo representa la IU a un nivel de abstracción alto.  Muestra los elementos de diálogo en el sistema y los enlaces de navegación entre los mismos, sin mostrar detalles de diseño de pantallas.  El Mapa de Diálogo permite que puedas explorar conceptos de la IU basado en el entendimiento que se tiene de los requisitos (puede complementar los CU).  Usuarios y desarrolladores pueden estudiar el Mapa de Diálogo para consensar una visión común de cómo el usuario interactuaría con el sistema para realizar una cierta tarea. 144
  145. 145. Máquinas de Estado que modelan IU: el Mapa de Diálogo  Los usuarios pueden recorrer el Mapa de Diálogo para buscar transiciones innecesarias, incorrectas, perdidas y por tanto requisitos perdidos, incorrectos o innecesarios.  Importante: el Mapa de Diálogo conceptual que se formula como parte del análisis sirve como guía durante el diseñado detallado de la IU. 145
  146. 146. Del Mapa de Diálogo a la Máquina de Estados  Cada Elemento de Diálogo se corresponde con un estado de una Máquina de Estados.  Cada opción de Navegación se corresponde con una transición (flecha) entre estados.  El evento que dispara una navegación de IU se muestra sobre la flecha de transición. 146
  147. 147. Del Mapa de Diálogo a la Máquina de Estados  Eventos:  Acción de usuario: presionar una tecla de función, clic sobre un hyperlink o presionar un botón.  Valor de datos: entrada de usuario inválida que dispara un mensaje de error.  Condición de sistema: detectar que una impresora no tiene papel.  Alguna combinación de las anteriores: teclear una opción de menú y presionar la tecla Enter. 147
  148. 148. Ejemplo de Mapa de Diálogo 148 Elemento de diálogo Acción stm Solicitud de químico-IU DTE Lista de Solicitudes Actuales Captura químico de solicitud Despliega Mensaje de Error Lista de Vendedores para el químico Lista de contenedores almacén Confirmar que la solicitud se acepta Histórico del Contenedor Pide colocar una solicitud Cancela la solicitud borrar químico de la lista solicitar otro químico cancelar la adición de nuevo químico quimico invalido OK solicitar químico desde almacen solicitar un químico diferente solicitar un químico de un vendedor solicitar un químico diferente cancelar la adicion de un nuevo químico seleccionar vendedor y agregarlo a la lista introducir solicitud para un número > 0 de químicos solicitar químico de un vendedor solicitar ver el Histórico del Contenedor Return OK; salir de función de solicitud seleccionar contenedor y agregarlo a la lista cancelar la adición de nuevos químicos
  149. 149. Diagramas de Clases  Un Diagrama de Clases en el cual las clases se corresponden a entidades del dominio o negocio y donde además se muestran las relaciones entre las clases. 149
  150. 150. Diagrama de Clases-Ejemplo 150
  151. 151. Tablas de Decisión y Árboles de Decisión  Son 2 técnicas alternativas para representar lo que el sistema debe hacer cuando entran en juego decisiones de lógica compleja.  La Tabla de Decisión lista los diferentes valores para todos los factores que influyen un cierto comportamiento e indica la acción esperada del sistema en respuesta a una combinación de factores. 151
  152. 152. Tabla de decisión-Ejemplo 152 Número de Requisito Condición 1 2 3 4 5 Usuario autorizado F V V V V Químico disponible - F V V V Químico peligroso - - F V V Solicitante entrenado - - - F V Aceptar solicitud X X Rechazar solicitud X X X
  153. 153. Árbol de decisión  Es una forma alternativa de representar gráficamente lógica compleja y acciones del sistema.  Selecciona sólo 1 representación: tabla de decisión o árbol de decisión 153
  154. 154. Árbol de decisión-Ejemplo 154
  155. 155. Recomendaciones finales …  Cada técnica de modelado vista tiene sus ventajas y limitaciones.  Algunas se sobreponen a otras (D. E-R, D. de clases, por ej.) por lo que no trates de crear todos los modelos para tu proyecto.  Toma en cuenta que los modelos de análisis se crean para ofrecer entendimiento y comunicación que vaya más allá de la especificación textual o de una única vista que un requisito pueda proveer.  Usa lo que realmente necesitas para explicar mejor tus requisitos. 155
  156. 156. 156 Temas  La Visión del Producto y el Alcance del Proyecto  Clasificación de los Usuarios  Levantamiento de Requisitos  Entendiendo los Requisitos de Usuario  Las Reglas del Negocio  Documentando los Requisitos  Modelos y Diagramas para diversos Requisitos  Requisitos No Funcionales  Validación de Requisitos
  157. 157. Introducción  Lea la siguiente Historia.  Discuta la relación que existe entre el éxito de un proyecto software y sus Requisitos No Funcionales. 157
  158. 158. Introducción  El éxito de un sistema software dependen no sólo de que ofrezca la funcionalidad esperada.  Depende, también, de que logre las expectativas de que tan bien trabajará.  Es decir:  ¿Qué tan fácil de utilizar será?  ¿Qué tan rápido correrá?  ¿Qué tan frecuente fallará?  ¿Cómo manejará situaciones inesperadas? 158
  159. 159. Introducción  Los Atributos de Calidad distinguen a un producto que solamente hace lo que se supone debe hacer de otro que “deleita” a sus clientes.  Un producto software excelente refleja un óptimo balance de las características de calidad competentes. 159
  160. 160. Introducción  Si no exploras las expectativas de calidad durante el levantamiento de requisitos, serás afortunado si el producto los satisface.  Desde el punto de vista técnico, los Atributos de Calidad conducen las decisiones arquitectónicas y de diseño (dividir las funciones del sistema en varias computadoras para alcanzar objetivos de desempeño o integridad) 160
  161. 161. Introducción  Generalmente los clientes no presentan sus expectativas de calidad explícitamente, sólo a través de su información podemos encontrar pistas al respecto.  La calidad, en sus muchas dimensiones, debe definirse tanto por clientes como por aquellos que construirán, probarán y mantendrán el software. 161
  162. 162. Atributos de Calidad  Existen varias clasificaciones para los Atributos de Calidad.  Si los desarrolladores conocen cuales son más cruciales para el éxito de su proyecto, podrán seleccionar el mejor enfoque para la arquitectura, diseño y programación que logre alcanzar los objetivos de calidad.  Se muestra una posible clasificación. 162
  163. 163. Clasificación-Atributos de Calidad 163 Importantes para los Usuarios Importantes para los Desarrolladores Disponibilidad Capacidad de Mantenimiento (Maintainability) Eficiencia Portabilidad Flexibilidad Reusabilidad Integridad Capacidad de Pruebas (Testability) Interoperabilidad Confiabilidad Robustez Usabilidad
  164. 164. El Mundo Ideal …  En un Mundo Ideal todo sistema debería exhibir el máximo valor posible para todos sus atributos: estar disponible todo el tiempo, nunca fallar, ofrecer resultados instantáneos y correctos y ser intuitivo de utilizar.  Como esto no siempre es posible, tu debes aprender cuales atributos son los más importantes para el éxito de tu proyecto.  Después definir los objetivos del usuario y desarrollador en términos de los atributos esenciales de tal forma que los diseñadores tomen las decisiones apropiadas. 164
  165. 165. Definiendo los Atributos de Calidad  Se deben definir preguntas apropiadas para obtener del usuario los Atributos de Calidad del Sistema.  El analista debe trabajar con los usuarios para crear requisitos específicos, medibles y verificables.  Considera, además, preguntar a los usuarios lo que sería un desempeño, usabilidad, integridad o confiabilidad inaceptable (requisitos inversos). 165
  166. 166. Atributos importantes para los usuarios-Disponibilidad  La medida planeada de tiempo en la que el sistema estará disponible para su uso completamente operacional.  Disponibilidad= Tiempo Medio entre Fallas del Sistema/Tiempo promedio de reparación entre fallas  Pregunta al usuario que porcentaje real de tiempo requieren disponibilidad y si hay momento para los cuales es imperativo para lograr objetivos del negocio o seguridad. 166
  167. 167. Atributos importantes para los usuarios-Disponibilidad  Ejemplo:  DI-1 El sistema debería estar disponible al menos 99.5% en miércoles entre 6:00 am y media noche, y al menos 99.95% en miércoles entre 4:00 pm y 6:00 pm hora local.  Ten cuidado con especificar 100% en los atributos de calidad porqué será imposible y costoso de alcanzar. 167
  168. 168. Atributos importantes para los usuarios-Eficiencia  La medida de que tan bien el sistema utiliza la capacidad del CPU, espacio en disco, memoria o ancho de banda.  La Eficiencia está relacionada con el desempeño: si el sistema consume muchos de los recursos disponibles, los usuarios encontrarán baja en el desempeño.  Considera configuraciones mínimas de hardware cuando defines objetivos de eficiencia, capacidad y desempeño. 168
  169. 169. Atributos importantes para los usuarios-Eficiencia  Ejemplo:  EF-1: Al menos 25% de la capacidad del CPU y RAM disponible a la aplicación deberían estar sin usar en las condiciones planeadas de carga pico. 169
  170. 170. Atributos importantes para los usuarios-Flexibilidad  Mide que tan fácil es el sistema para agregarle capacidades.  Se le conoce también como: extensibilidad, aumentabilidad, expandibilidad.  Si los desarrolladores anticipan muchas extensiones, deberían seleccionar enfoques de diseño que maximicen la flexibilidad del software. 170
  171. 171. Atributos importantes para los usuarios-Flexibilidad  Ejemplo:  FL-1: Un programador con al menos 6 meses de experiencia soportando este producto debería ser capaz integrarle una nueva capacidad de impresión al producto, incluyendo modificaciones al código y pruebas, en no más de 1 hr. de trabajo. 171
  172. 172. Atributos importantes para los usuarios-Integridad  El cual abarca seguridad, tiene que ver con el bloqueo de acceso no autorizado a las funciones del sistema, prevenir pérdida de información, asegurar que el software está protegido contra virus y proteger la privacidad y seguridad de los datos introducidos al sistema. 172
  173. 173. Atributos importantes para los usuarios-Integridad  Establece los requisitos de integridad en término no ambiguos: verificación de identidad de usuario, niveles de privilegio de usuarios, restricciones de acceso o datos precisos que se deben proteger. 173
  174. 174. Atributos importantes para los usuarios-Integridad  Ejemplo:  IN-1: Sólo los usuarios que tengan privilegios de Auditor estarán autorizados para ver el histórico de movimientos del cliente.  Muchos de los requisitos de Integridad son también Reglas de Negocio. Esto sugiere establecer trazabilidad entre los mismos. 174
  175. 175. Atributos importantes para los usuarios-Interoperabilidad  Qué tan fácil puede intercambiar datos o servicios el sistema con otros sistemas.  Para evaluar interoperabilidad, necesitas conocer con cuales otras aplicaciones se integrarán los datos y servicios de la aplicación actual.  Está relacionada con los requisitos de interfases externas. 175
  176. 176. Atributos importantes para los usuarios-Interoperabilidad  Ejemplo:  IO-1. El Sistema deberá ser capaz de importar cualquier estructura química del sistema ChemiDraw (versión 2.3 o anterior) y Chem-Struct (versión 5 o anterior). 176
  177. 177. Atributos importantes para los usuarios-Confiabilidad  La probabilidad de que el software se ejecute sin fallas por un periodo específico de tiempo.  La Robustez es también considerado un aspecto de confiabilidad.  Medida: porcentaje de las operaciones que se completan correctamente y tiempo promedio en el que el sistema corre antes de fallar. 177
  178. 178. Atributos importantes para los usuarios-Confiabilidad  Ejemplo:  CO-1. No más de 5 experimentos de 1000 se deberían perder por fallas en el software. 178
  179. 179. Atributos importantes para los usuarios-Robustez  O Tolerancia a Fallas: grado al cual un sistema continua funcionando apropiadamente cuando se enfrenta a entradas inválidas, defectos en componentes software y hardware o condiciones no esperadas de operación.  Pregunte al usuario sobre condiciones de error que el sistema podría encontrar y la forma en la que debería reaccionar. 179
  180. 180. Atributos importantes para los usuarios-Robustez  Ejemplo:  RO-1. Si el editor falla antes de que el usuario guarde el archivo, el editor debería ser capaz de recuperar todos los cambios hechos en el archivo que está siendo editado, hasta antes de 1 minuto antes de la falla. Esto estará disponible la próxima vez que el usuario inicie el programa. 180
  181. 181. Atributos importantes para los usuarios-Usabilidad  Incluye los factores que hace que los usuarios perciban al sistema amigable con el usuario.  También se le conoce como facilidad de uso, ingeniería humano-computadora.  Discusiones sobre usabilidad pueden incluir preguntas tipo: ¿Qué tan importante es que seas capaz de solicitar químicos de forma rápida y simple?¿Que tanto tiempo debería tomar completar una solicitud de un químico? 181
  182. 182. Atributos importantes para los usuarios-Usabilidad  Ejemplos:  US-1. Un usuario entrenado debería ser capaz de introducir una solicitud completa en un promedio de cuatro a máximo seis minutos.  US-2. Todas las funciones del menú Archivo deberán contar con teclas “shortcut” (Ctrl-X). Los comandos del Menú deberán ser semejantes a Microsoft Word.  US-3. Un usuario que nunca hubiera utilizado el sistema deberá ser capaz de hacer una solicitud con no más de 30 minutos de orientación. 182
  183. 183. Atributos importantes para los Desarrolladores-Mantenibilidad  Indica que tan fácil es corregir un defecto o modificar el software.  Depende de que tan fácil es de entender, cambiar y probar el software. Está relacionado con la flexibilidad y capacidad de prueba.  Se mide en términos del tiempo promedio para arreglar un problema y el porcentaje de reparaciones correctas. 183
  184. 184. Atributos importantes para los Desarrolladores-Mantenibilidad  Ejemplo:  MA-1. Un programador de mantenimiento deberá ser capaz de modificar los reportes existentes con 20 horas de trabajo o menos de esfuerzo de desarrollo.  MA-2. Las llamadas a funciones no deberán anidarse en más de 2 niveles de profundidad. 184
  185. 185. Atributos importantes para los Desarrolladores-Portabilidad  El esfuerzo requerido para migrar una pieza de software de un ambiente operativo a otro.  Algunos incluyen también la habilidad de internacionalizar y localizar un producto.  Los desarrolladores seleccionar aproximaciones de diseño y codificación que facilitarán la portabilidad del producto apropiadamente. 185
  186. 186. Atributos importantes para los Desarrolladores- Reusabilidad  El esfuerzo relativo para convertir un componente software y utilizarlo en otra aplicación.  Desarrollar un componente reutilizable tiene un costo mayor que uno que sólo se utilizará en 1 sola aplicación.  Un software reutilizable debe ser:  Modular  Bien documentado  Independiente de aplicación específica y ambiente operativo  Genérico en capacidad. 186
  187. 187. Atributos importantes para los Desarrolladores- Reusabilidad  Ejemplo:  RU-1: Las funciones de entrada se diseñarán para ser reutilizables a nivel de código objeto en otras aplicaciones que utilizan representaciones internacionales de estructuras químicas. 187
  188. 188. Atributos importantes para los Desarrolladores- “Testability”  Conocida también como verificabilidad. Se refiere a la facilidad con la cual los componentes software o el producto integrado se pueden probar para la búsqueda de defectos.  El diseño para verificabilidad es crítico si:  El producto tiene algoritmos y lógica compleja.  Contiene interrelaciones complejas de funcionalidad.  Será modificado frecuentemente (y tendrán que requerirse múltiples pruebas de regresión). 188
  189. 189. Atributos importantes para los Desarrolladores- “Testability”  Ejemplo:  TE-1: La complejidad ciclomática (McCabe 1982) máxima de un módulo no deberá exceder a 20.  Complejidad ciclomática: medida del número de ramificaciones lógicas en el código fuente: entre más ramificaciones y ciclos tenga tenderá a ser más difícil de probar, entender y mantener. 189
  190. 190. Atributos importantes para los Desarrolladores- Desempeño  Que tan bien o que tan rápido debe desempeñar funciones específicas el sistema.  Incluye: velocidad, througput (transacciones por segundo), capacidad (carga concurrente) y tiempo (alta demanda en tiempo real).  Los requisitos de desempeño restringen seriamente las estrategias de diseño, por lo que es importante establecer claramente sus objetivos. 190
  191. 191. Atributos importantes para los Desarrolladores- Desempeño  Ejemplo:  DE-1. El intérprete debe realizar el análisis sintáctico a velocidad de 500 estatutos por minuto.  DE-2. Cada página Web se descargará en 15 segs O menos sobre una conexión por modem de 50 Kbps  DE-3. La autorización de un retiro en el cajero automático no deberá tomar más de 10 seg. 191
  192. 192. Definiendo RNF usando Planguage  Algunos de los RNF se han definido de forma incompleta o no precisa.  No se puede evaluar un producto si no se definen los RNF de forma precisa.  Para abordar el problema de la ambigüedad e incompletitud de RNF Tom Gilb ha desarrollado Planguage. 192
  193. 193. Definiendo RNF usando Planguage  Ejemplo - Definir el RNF en Planguage: “95% de las consultas a la base de datos del catálogo deben completarse dentro de 3 segs. con un usuario que utiliza una PC Intel Pentium 4 de 1.1 Ghz corriendo Windows XP con al menos 60% de los recursos del sistema libres” 193
  194. 194. Definiendo RNF usando Planguage  TAG Desempeño. ConsultaTiempoDeRespuesta (Etiqueta)  AMBITION Tiempo de respuesta rápido para consultas de base de datos sobre la plataforma del usuario (propósito del RNF)  ESCALA Segundos de tiempo entre presionar la tecla Enter (o clic Ok) para introducir la consulta y empezar el despliegue de resultados (unidad de medida) 194
  195. 195. Definiendo RNF usando Planguage  MÉTRICA Pruebas Stopwatch realizadas sobre 250 consultas de prueba que representan un perfil de uso operacional (forma precisa de hacer las mediciones)  DEBE No más de 10 segs. Para el 98% de las consultas (nivel mínimo aceptable)  PLAN No más de 3 segs. por cada categoría de consulta, 8 seg. Para todas las consultas (objetivo nominal) 195
  196. 196. Definiendo RNF usando Planguage  DESEO No más de 2 segundos para todas las consultas. (resultado ideal)  DEFINICIÓN de plataforma base Procesador Intel Pentium 1.1 Ghz, 128 Mb RAM, Windows XP, corriendo QueryGen 3.3 con al menos 60% de recursos libres. Ninguna otra aplicación corriendo.  Más detalles: http://www.gilb.com 196
  197. 197. Compensación de atributos (Trade-off)  Ciertas combinaciones de atributos presentan compensaciones mutuas.  Usuarios y desarrolladores deben decidir cuales atributos son más importantes que otros y respetar estas decisiones consistentemente al tomar decisiones. 197
  198. 198. Tabla de Compensación de atributos (Trade-off)  La siguiente tabla muestra las compensación entre atributos. Utiliza los siguientes convencionalismos para su interpretación:  Un sigo “+/-” en el renglón indica que incrementar el atributo del renglón tiene un efecto positivo/negativo en el atributo de la columna.  Una celda en blanco indica poco/ningún efecto en el atributo de la columna. 198
  199. 199. Tabla de Compensación de atributos (Trade-off) 199
  200. 200. Implementando los RNF  Aunque los Atributos de Calidad son RNF, ellos pueden conducir a RF, líneas guía de diseño u otra información técnica que producirán los atributos de calidad deseados. 200
  201. 201. De los Atributos de Calidad (RNF) a Especificaciones Técnicas 201 Tipo de Atributo de Calidad Probable Categoría de Información Técnica Integridad, Interoperabilidad, Robustez, Usabilidad, Seguridad Requisitos Funcionales Disponibilidad, Flexibilidad, Eficiencia, Desempeño, Confiabilidad Arquitectura del Sistema Interoperabilidad, Usabilidad Restricciones de Diseño Flexibilidad, mantenibilidad, portabilidad, confiabilidad, reusabilidad, verificabilidad, usabilidad Línea guía de diseño Portabilidad Restricción de Implementación
  202. 202. 202 Temas  La Visión del Producto y el Alcance del Proyecto  Clasificación de los Usuarios  Levantamiento de Requisitos  Entendiendo los Requisitos de Usuario  Las Reglas del Negocio  Documentando los Requisitos  Modelos y Diagramas para diversos Requisitos  Requisitos No Funcionales  Validación de Requisitos
  203. 203. Introducción  Lea la siguiente Historia.  ¿Ha tenido alguna experiencia de “ambigüedad” en la especificación de sus requisitos? Comente 203
  204. 204. Introducción  Si un desarrollador software tiene que implementar un requisito ambiguo o incompleto tendrá que hacer sus propias interpretaciones, las cuales no siempre son correctas.  Se requiere un esfuerzo substancial para arreglar errores de requisitos después de que se ha completado el trabajo basado en estos requisitos. 204
  205. 205. Introducción  Estudios han demostrado que puede costar aproximadamente 100 veces más corregir un defecto en un requisito que corregir un error encontrado durante el desarrollo de requisitos.  Cualquier medida que se pueda tomar para detectar errores en las especificaciones de requisitos ahorrará tiempo y dinero substancial. 205
  206. 206. Las Pruebas y el Desarrollo de Requisitos  Si se inicia la planeación de las pruebas y el desarrollo de Casos de Prueba pronto, detectarás muchos errores antes de que se introduzcan.  Esto previene daños futuros y reduce los tiempos de mantenimiento y costos. 206
  207. 207. Modelo V de Desarrollo de Software con diseño/planeación de Pruebas 207
  208. 208. Modelo V de Desarrollo de Software con diseño/planeación de Pruebas  Planea las actividades de pruebas e inicia el desarrollo de Casos de Prueba preliminar durante la fase correspondiente de desarrollo.  Aunque aún no se ejecuten las pruebas (no hay código todavía) los Casos de Prueba conceptuales revelarán errores, ambigüedades y omisiones en la ERS y en los modelos de análisis antes de que el equipo escriba el software. 208
  209. 209. Validación de Requisitos  La VR es el cuarto componente (junto con elicitación, análisis y especificación del desarrollo de requisitos). 209
  210. 210. Validación de Requisitos  La VR intenta asegurar que:  La ERS describe correctamente las capacidades y características del sistema que satisfacerán las necesidades de los stakeholders.  Los requisitos software se derivaron correctamente de los requisitos del sistema, reglas del negocio u otras fuentes.  Los requisitos son completos y de alta calidad. 210
  211. 211. Validación de Requisitos  La VR intenta asegurar que:  Todas las representaciones de requisitos son consistentes unas con otras.  Los requisitos proveen una base adecuada para proceder con el diseño y construcción.  Sólo se pueden validar requisitos que han sido documentados no los que están en la mente de alguien.  La VR debe ser un proceso iterativo, no un paso final antes de fijar los requisitos en la línea base. 211
  212. 212. Validación & Verificación  Algunos llaman a esta etapa Verificación. La Verificación determina si un producto satisface los requisitos establecidos por el (do the thing right).  Validación evalúa si el producto satisface las necesidades del cliente (do the right thing). 212
  213. 213. Revisión Formal de Requisitos  Una Revisión por Parejas es aquella en la que alguien externo al autor del producto examina problemas en el mismo.  Ésta es una técnica importante para identificar requisitos ambiguos o no verificables, que no fueron definidos claramente para diseño y otros problemas.  La RxP es un proceso formal, bien definido (en contraste con “Revisiones Informales”). 213
  214. 214. Revisión Formal de Requisitos  El mejor tipo de Revisión Formal es llamada Inspección.  La Inspección de documentos de Requisitos es la técnica de mayor calidad software.  Si se desea maximizar la calidad del software, el equipo inspeccionará cada documento de requisitos que crea.  Inicia la inspección cuando tengas un 10% de la ERS: es la mejor técnica para prevenir –no sólo encontrar- defectos. 214
  215. 215. El proceso de Inspección  Michael Fagan desarrolló el proceso de inspección en IBM a la mitad de los 70s y otros lo han extendido o modificado con sus métodos.  Cualquier artefacto puede ser inspeccionado (requisitos, diseño, código fuente, pruebas, planes de proyectos, etc.) 215
  216. 216. El proceso de Inspección  La Inspección es un proceso multietapas bien definido.  Involucra un pequeño equipo de participantes entrenados que cuidadosamente inspeccionan un producto de trabajo buscando defectos y oportunidades de mejora. 216
  217. 217. Participantes en un proceso de Inspección  Deben representar 4 perspectivas: 1. El autor del producto de trabajo y quizá compañeros del autor. El analista provee esta perspectiva. 2. El autor de cualquier producto de trabajo o especificación predecesora para el producto inspeccionado. Un arquitecto de sistemas (o cliente) que asegure que la ERS detalla apropiadamente la especificación del sistema. 217
  218. 218. Participantes en un proceso de Inspección  Deben representar 4 perspectivas: 3. Gente que hará el trabajo basado en el producto siendo inspeccionado. Desarrollador, tester, líder de proyecto y escritor de la documentación del usuario. 4. Gente responsable del trabajo del producto que interactuará con el producto inspeccionado. Buscarán problemas con los requisitos de interfases externas. 218
  219. 219. Participantes en un proceso de Inspección  Limita el equipo a 6 o menos inspectores.  Esto significa que algunas perspectivas no serán representadas en cada inspección. 219
  220. 220. Roles de la inspección-Autor  Autor: es el analista que obtuvo los requisitos de usuario y escribió la especificación. Toma un papel pasivo en la inspección. No puede asumir ningún otro papel. Escucha los comentarios de otros inspectores, responde (no debate) a sus preguntas y piensa. Puede detectar errores que los otros inspectores no ven. 220
  221. 221. Roles de la inspección-Moderador  Moderador: o líder de inspección; planea la inspección con el autor, coordina actividades y facilita las reuniones de inspección. Distribuye los materiales a ser inspeccionados por los participantes, varios días antes de la reunión de inspección. Inicia la reunión a tiempo, motiva la participación y mantiene enfocada la reunión a encontrar defectos más que resolver problemas. Da seguimiento, junto con el autor, a la correcta corrección de defectos. 221
  222. 222. Roles de la inspección-Lector  Lector: parafrasea la ERS un requisito a la vez. Los otros participantes señalan defectos potenciales. Estableciendo los requisitos en sus propias palabras, el lector provee una interpretación que puede diferir de la de otros inspectores. Esto es una buena forma de revelar una ambigüedad, un posible defecto o un supuesto. 222
  223. 223. Roles de la inspección-Escritor  Escritor: usa formatos estándar para documentar lo que surja y los defectos encontrados durante la reunión de inspección. Debe enunciar en voz alta lo que escribió para confirmar exactitud. Los otros inspectores deben ayudar al escritor a capturar la esencia de lo que surge en una forma que claramente comunica al autor la localización y naturaleza de lo surgido. 223
  224. 224. Criterios de Inicio de la Inspección  Los prerrequisitos que se deben satisfacer antes de inspeccionar el documento de requisitos son:  El documento está conforme la plantilla estándar.  Se ha revisado la ortografía del documento.  El autor ha revisado visualmente el documento por errores de diseño.  Están disponibles los documentos de referencia que los inspectores requerirán para examinar el documento.  Los temas abiertos están señalados como TBD.  El moderador no encontró más de 3 defectos en una examen de 10 minutos de una muestra representativa del documento. 224
  225. 225. Etapas de Inspección 225
  226. 226. Etapas de la Inspección- Planeación (Planning)  El Autor y el Moderador planean juntos la inspección.  Determinan:  Quien participará  Que materiales recibirán los inspectores antes de iniciar.  Cuantas reuniones de inspección se necesitarán para cubrir el material.  La Tasa de Inspección (número de páginas por hora). 226
  227. 227. Etapas de la Inspección-Planeación (Planning)-La Tasa de Inspección y el No. de Defectos encontrados 227
  228. 228. Etapas de la Inspección- Introducción (Overview meeting)  Durante la Introducción, el Autor describe los antecedentes del material que el equipo está inspeccionando, sus supuestos y los objetivos específicos de la inspección.  Si todos son familiares con el documento, se puede omitir esta etapa. 228
  229. 229. Etapas de la Inspección- Preparación (Preparation)  Cada inspector examina el producto para identificar posibles defectos, usando checklist de típicos defectos. Hasta 75% de los defectos encontrados se descubren en esta etapa. No omitas este paso.  Considera pedir a cada desarrollador que revisará la ERS calificar cada requisito en términos de que tan bien lo entienden (1=no se entiende; 5=claro, completo y no ambiguo) 229
  230. 230. Etapas de la Inspección-Reunión de Inspección (Inspection Meeting)  El Lector lee a los otros inspectores a través del DERS, describiendo 1 requisito a la vez en sus propias palabras.  Conforme los inspectores encuentran posibles defectos (u otros aspectos), el Escritor los captura en una forma que viene a ser la lista de acciones para el autor de los requisitos.  Las reuniones de inspección no deberían tomar más de 2 hrs. Si se necesita más tiempo, reprograma otra reunión. 230
  231. 231. Etapas de la Inspección-Reunión de Inspección (Inspection Meeting)  Al final de la reunión el equipo decide aceptar el DERS tal como está, aceptar con revisiones menores o indicar si se requiere mayor revisión (esto indica problemas con el proceso de desarrollo de requisitos).  Considera una retrospectiva para explorar como se pueden mejorar los procesos antes de la siguiente actividad de especificación. 231
  232. 232. Etapas de la Inspección- Retrabajo (Rework)  El Autor debe planear invertir algo de tiempo re-trabajando los requisitos que siguen a la reunión de inspección.  Es el momento de resolver ambigüedades, eliminar puntos no claros y establecer la base para el desarrollo exitoso del proyecto. 232
  233. 233. Etapas de la Inspección- Seguimiento (Follow-up)  Paso final de la inspección. El Moderador o un individuo designado trabaja con el Autor para asegurarse que todos los aspectos abiertos fueron resueltos y que los errores fueron corregidos apropiadamente.  Esta etapa brinda el cierre de la inspección y habilita al moderador para determinar si el criterio de terminación se ha satisfecho. 233
  234. 234. Criterios de Cierre de la Inspección  Las Postcondiciones que se deben satisfacer antes de que el moderador declare la inspección completa son:  Todos los aspectos encontrados han sido atendidos.  Cualquier cambio hecho al documento y productos de trabajo relacionados fueron hechos correctamente.  Se ha revisado la ortografía del documento.  Todos los TBD se han resuelto.  El documento se ha incluido en el Sistema de Configuración del Sistema. 234
  235. 235. Checklists de defectos  Para ayudar a los inspectores a localizar típicos errores en los productos que inspeccionan es bueno desarrollar un checklist para cada tipo de documento de requisitos crea la organización. 235
  236. 236. Ejemplo Checklist de defectos-CU  ¿El CU es un Proceso elemental de negocio?  ¿Es claro el objetivo del CU?  ¿Está escrito el CU a nivel esencial, libre de detalles de diseño e implementación?  ¿Están documentados todos los cursos alternativos?  ¿Hay secuencias de acción comunes que se pueden factorizar en CU separados?  ¿Las precondiciones y postcondiciones enmarcan apropiadamente el CU? 236
  237. 237. Checklist para DERS  También se puede hacer un checklist para inspeccionar el DERS. 237
  238. 238. Probando los Requisitos-Casos de Prueba conceptuales  Se puede iniciar derivando los Casos de Prueba conceptuales muy temprano en el proceso de desarrollo.  Se pueden utilizar los Casos de Prueba para evaluar requisitos textuales, modelos de análisis y prototipos.  Los Casos de Prueba son independientes de implementación. 238
  239. 239. Probando los Requisitos-Casos de Prueba conceptuales 239
  240. 240. Definiendo el Criterio de Aceptación  No es suficiente la correcta implementación de los requisitos, se requiere también que la acepte el usuario final.  Los cliente deben definir el Criterio de Aceptación que determina si el sistema realmente satisface sus necesidades. 240
  241. 241. Definiendo el Criterio de Aceptación  La pregunta clave a responder por el usuario es: ¿Cómo juzgaría si el sistema satisface sus necesidades?  Si el cliente no puede expresar como evaluaría la satisfacción del sistema de un requisito particular, tal requisito no se ha establecido de forma suficientemente clara. 241
  242. 242. Definiendo el Criterio de Aceptación  No es suficiente escribir los requisitos. Se necesita asegurar que son los correctos y que son suficientemente buenos para servir de base al diseño, construcción, pruebas y gestión del proyecto. 242

×