Toma de Requisitos

Introducción

Los requisitos son una especificación de lo que debe implementarse. Son descripciones de cómo debe comportarse el sistema, o de una propiedad o atributo del sistema. Pueden ser una restricción en el proceso de desarrollo del sistema.

Tipos de requisito

• Requisito de negocio
  Objetivo de negocio de alto nivel de la organización que construye un producto o de un cliente que lo adquiere.
• Regla de negocio
  Política, directriz, estándar o regulación que define o restringe algún aspecto del negocio. No es un requisito de software en sí mismo, sino el origen de varios tipos de requisitos de software.
• Restricción
  Limitación impuesta a las opciones disponibles para el desarrollador en el diseño y construcción del producto.
• Requisito de interfaz externa
  Descripción de una conexión entre un sistema y un usuario, otro sistema o un dispositivo.
• Característica
  Una o más capacidades del sistema lógicamente relacionadas que proveen valor a un usuario y están descritas mediante un conjunto de requisitos funcionales.
• Requisito funcional
  Descripción de un comportamiento que un sistema presentará bajo determinadas condiciones.
• Requisito no funcional
  Descripción de una propiedad o característica qeu un sistema presentará o una restricción que debe respetar.
• Atributo de calidad
  Tipo de requisito no funcional que describe un servicio o característica de rendimiento de un producto.
• Requisito de sistema
  Requisito de alto nivel de un producto que contiene múltiples subsistemas, que pueden ser todos software o software y hardware.
• Requisito de usuario
  Objetivo o tarea que específicos tipos de usuario debe conseguir con un sistema, o un atributo de producto deseado.
  Los requisitos de usuario se pueden representar mediante casos de uso, historias de usuario y tablas evento-respuesta. Idealmente los propios usuarios deberían proporcionar esta información.

Niveles de requisito

• Requisitos de negocio
• Requisitos de usuario
• Requisitos funcionales
• Requisitos no funcionales

Desarrollo de requisitos

1. Obtención
   1. Identificar qué esperan los distintos tipos de usuario y otros implicados del producto.
   2. Comprender objetivos de usuario y los objetivos de negocio.
   3. Aprender acerca del entorno en el que se va a utilizar el nuevo producto.
   4. Trabajar con individuos que representen cada tipo de usuario para comprender sus necesidades y sus expectativas de calidad.
2. Análisis
   1. Analizar la información recibida por los usuarios para distinguir sus objetivos de los requisitos funcionales, expectativas de calidad, reglas de negocio, soluciones propuestas y otra información.
   2. Descomponer requisitos de alto nivel en el nivel apropiado de detalle.
   3. Deducir requisitos funcionales a partir de otros requisitos.
   4. Comprender la importancia relativa de los atributos de calidad.
   5. Asignación de requisitos a los componentes de software definidos en la arquitectura del sistema.
   6. Negociar prioridades de implementación.
   7. Identificar lagunas en los requisitos o requisitos innecesarios según el alcance definido.
3. Especificación
   • Traducir las necesidades de usuario en requisitos escritos y diagramas adecuados para su comprensión, revisión y uso por parte de su público objetivo.
4. Validación
   • Revisar los requisitos documentados para corregir cualquier problema antes de que el grupo de desarrollo los dé por buenos.
   • Desarrollar test de aceptación y criterios para confirmar que un producto basado en los requisitos cumpliría las necesidades del cliente y alcanzaría los objetivos de negocio.

Este desarrollo se realiza de forma iterativa:

Gestión de requisitos

• Definir la línea base de los requisitos, una instantánea en el tiempo que representa un conjunto de requisitos funcionales y no funcionales acordado, revisado y aprobado, a menudo para una versión específica del producto o una iteración de desarrollo.
• Evaluar el impacto de los cambios de requisitos propuestos e incorporar los cambios aprobados en el proyecto de forma controlada.
• Mantener el plan del proyecto actualizado con los requisitos según evolucionan.
• Negociar nuevos compromisos basados en el impacto estimado de los cambios de requisitos.
• Definir las relaciones y dependencias que existen entre los requisitos.
• Tracear los requisitos individualmente con su correspondientes diseño, código fuente y tests.
• Rastrear el estado de los requisitos y cambiar la actividad en todo el proyecto.

El objeto de la gestión de requisitos es anticipar y acomodarse a los nuevos cambios, además de minimizar su impacto en el proyecto.

A menudo es imposible –o innecesario– especificar completamente los requisitos funcionales antes de comenzar el diseño y la implementación. En esos casos se utilizará un enfoque iterativo, implementando una parte de los requisitos cada vez y obteniendo feedback del cliente antes de pasar al siguiente ciclo. Esta es la esencia del desarrollo ágil.

Requisitos desde el punto de vista del usuario

La brecha de expectativa

Implicados y clientes

Un implicado (stakeholder) es una persona, grupo u organización que está activamente involucrado en el proyecto, se ve afectado por su proceso o resultado o puede influir en los mismos.

A continuación se muestran los posibles implicados, en negrita están los clientes.

• Fuera del organismo de desarrollo
  • Usuario directo
  • Usuario indirecto
  • Comprador
  • Personal de compras
  • Personal jurídico
  • Contratista
  • Subcontratista
  • Gestor de empresa
  • Jefe de contratación
  • Agencia de gobierno
  • Experto en la materia
  • Gestor del programa
  • Beta tester
  • Público general
  • Consultor
  • Auditor
  • Certificador
  • Organismo regulador
  • Proveedor de software
  • Proveedor de material
  • Capitalista de riesgo
• En el organismo de desarrollo
  • Jefe de desarrollo
  • Marketing
  • Personal de operación
  • Personal jurídico
  • Arquitecto software
  • Dueño de la compañía
  • Personal de ventas
  • Instalador
  • Mantenedor
  • Director de Proyecto
  • Experto en usabilidad
  • Experto en la materia
  • Patrocinador ejecutivo
  • Oficina de gestión de proyectos
  • Fabricación
  • Personal de formación
  • Arquitecto de cartera
  • Personal de infraestructura
• En el equipo del proyecto
  • Jefe de proyecto
  • Analista
  • Architecto de la aplicación
  • Diseñador
  • Desarrollador
  • Product Owner
  • Analista de datos
  • Analista de procesos
  • Probador
  • Gestor de producto
  • Personal de calidad
  • Escritor documentación
  • Administrador de base de datos
  • Ingeniero hardware
  • Analista de infraestructuras
  • Arquitecto de solución de negocio

Los clientes son un subconjunto de los implicados. Un cliente es un individuo u organización que obtiene un beneficio directo o indirecto de un producto. Los clientes de software pueden solicitar, pagar, seleccionar, especificar, usar o recibir la salida generada por un producto de software.

Los requisitos de usuario deben venir de personas que realmente usen el producto, bien de forma directa o indirecta. Estos usuarios (denominados usuarios finales) son un subconjunto de los clientes.

Los requisitos del usuario deben provenir de personas que presionarán las teclas, tocarán la pantalla o recibirán las salidas

Relación cliente-desarrollo

Carta de derechos y responsabilidades de los clientes

• Tienes derecho a:
  • Esperar que el analista hable tu lenguaje
  • Esperar que el analista conozca tu negocio y tus objetivos
  • Esperar que el analista registre los requisitos de forma apropiada
  • Recibir explicación sobre las prácticas y los entregables en la toma de requisitos
  • Cambiar tus requisitos
  • Esperar un entorno de mutuo respeto
  • Escuchar ideas y alternativas para tus requisitos y sus soluciones
  • Describir características que harán el producto fácil de usar
  • Escuchar formas de ajustar los requisitos para acelerar el desarrollo mediante la reutilización
  • Recibir un sistema que satisfaga tus necesidades funcionales y expectativas de calidad
• Tienes la responsabilidad de:
  • Enseñar a los analistas y desarrolladores tu negocio
  • Dedicar el tiempo necesario para proporcionar y aclarar los requisitos
  • Ser específico y preciso al proporcionar información sobre los requisitos
  • Tomar decisiones oportunas sobre los requisitos cuando se te solicite
  • Respetar la evaluación del desarrollador sobre el coste y la viabilidad de los requisitos
  • Dar a los requisitos prioridades realistas en colaboración con los desarrolladores
  • Revisar los requisitos y evaluar los prototipos
  • Establecer criterios de aceptación
  • Comunicar inmediatamente cambios de los requisitos
  • Respetar el proceso de desarrollo de los requisitos

Llegar a acuerdos sobre los requisitos

• Los clientes están de acuerdo en que los requisitos cumplen sus necesidades
• Los desarrolladores aceptan que entienden los requisitos y que son factibles
• Los probadores acuerdan que los requisitos son verificables
• La gerencia acepta que los requisitos lograrán sus objetivos comerciales.

La línea base de los requisitos

Una línea base (baseline) de requisitos es un conjunto de requisitos que han sido revisados y acordados y que sirven de base para el desarrollo principal.

Una vez que se ha decidido la línea base, el analista debería poner los requisitos bajo control de versiones. Esto permite al equipo modificar el alcance cuando sea necesario de una forma controlada, analizando el impacto de cada cambio propuesto.

Buenas prácticas para la ingeniería de requisitos

A continuación se muestra un proceso en la ingeniería de requisitos que puede servir para la mayoría de los proyectos. Los pasos se siguen de forma aproximadamente secuencial, pero el proceso no es estrictamente secuencial. Los primeros siete pasos normalmente se realizan al principio del proyecto (aunque se revisiten de forma periódica), los demás pasos se realizan para cada iteración o revisión.

Se realiza al principio del proyecto:

1. Definir los requisitos de negocio.
2. Identificar los tipos de usuario.
3. Identificar usuarios representativos.
4. Identificar quiénes toman las decisiones sobre los requisitos.
5. Plan de obtención de requisitos.
6. Identificar los requisitos de usuario.
7. Priorizar los requisitos de usuario.

Se repite en cada iteración:

8. Desarrollar los requisitos de usuario.
9. Derivar los requisitos funcionales.
10. Modelar los requisitos.
11. Especificar los requisitos no funcionales.
12. Revisar los requisitos.
13. Desarrollar prototipos.
14. Desarrollar o evolucionar la arquitectura.
15. Asignar requisitos a componentes.
16. Desarrollar pruebas a partir de los requisitos.
17. Validar requisitos de usuario, requisitos funcionales, requisitos no funcionales, modelos de análisis y prototipos.

Obtención de Requisitos

• Definir la visión del producto y el alcance del proyecto
  El documento de visión y alcance contiene los requisitos de negocio del producto. La visión da a todos los implicados una comprensión común del resultado del producto. El alcance define el límite entre lo que entra y lo queda fuera en una iteración o versión específica. La visión debería permanecer relativamente estable a lo largo del proyecto, pero cada versión planificada o iteración necesita su propia declaración de alcance.
• Identificar los tipos de usuario y sus características
  Para evitar pasar por alto las necesidades de algún tipo de usuario, es necesario identificar todos los posibles grupos de usuarios. Se pueden diferenciar en frecuencia de uso, características utilizadas, niveles de privilegios, o experiencia. Describir aspectos de sus tareas laborales, aptitudes, localización o características personales que podrían influir en el diseño del producto. Crear "personas" (descripciones de gente imaginaria que puede representar cada tipo particular de usuario).
• Elegir un jefe por cada tipo de usuario
  Identificar un individuo que pueda servir apropiadamente como la voz literal del cliente para cada tipo de usuario. El jefe (product champion) presenta las necesidades de su tipo de usuario y toma decisiones en su nombre.
• Realizar grupos de enfoque con usuarios tipo
  Elegir grupos de usuarios representativos de otros productos anteriores o similares.
• Trabajar con usuarios representativos para identificar los requisitos de usuario
  Los requisitos de usuario se pueden expresar en forma de casos de uso, historias de usuario o escenarios.
• Identificar eventos de sistema y respuestas
  Listar los eventos externos que es el sistema puede experimentar y la respuesta esperada para cada evento.
• Llevar a cabo entrevistas de obtención de requisitos
  Se pueden hacer entrevistas uno-a-uno o con pequeños grupos de interesados.
• Llevar a cabo talleres de obtención de requisitos
• Observar a los usuarios realizando sus trabajos
  Se pueden utilizar diagramas de flujo para plasmar los pasos y decisiones que hacen en su trabajo y su relación con otros grupos.
• Distribuir cuestionarios
• Analizar la documentación existente
• Examinar informes de problemas con los sistemas actuales
• Reutilizar requisitos existentes

Análisis de Requisitos

• Modelar el entorno de la aplicación
  El diagrama de contexto es un sencillo modelo de análisis que muestra cómo el nuevo sistema encaja en su entorno. Define las fronteras e interfaces entre el sistema a desarrollar y las entidades externas como usuarios, dispositivos y otros sistemas.
• Crear interfaz de usuario y prototipos técnicos
  Cuando los desarrolladores o los usuarios no están seguros de los requisitos, es conveniente construir un prototipo para hacer los conceptos y las posibilidades más tangibles.
• Analizar la viabilidad de los requisitos
  El analista debe trabajar con los desarrolladores para evaluar la viabilidad de implementar cada requisito a un coste y rendimiento aceptables en el entorno previsto. Esto permite a los implicados comprender los riesgos asociados con implementar cada requisito, incluyendo conflictos y dependencias con otros requisitos, factores externos y obstáculos técnicos.
• Priorizar los requisitos
  Es importante priorizar los requisitos para asegurar que el equipo implementa la funcionalidad más valiosa o más oportuna primero.
• Crear un diccionario de datos
  Permite que todos los que trabajan en el proyecto usen definiciones consistentes.
• Modelar los requisitos
  Un modelo de análisis es un diagrama que representa los requisitos de forma visual. Se pueden utilizar diagramas de flujo, diagramas entidad-relación, diagramas de transición de estados, tablas de estados, mapas de diálogo, árboles de decisión y otros.
• Analizar las interfaces entre nuestro sistema y el mundo exterior
• Asignar requisitos a los subsistemas

Especificación de Requisitos

• Utilizar plantillas de documento de requisitos
  Las plantillas aportan una estructura consistente.
• Identificar el origen de los requisitos
  El origen de cada requisito debe ser traceable.
• Etiquetar de forma única cada requisito
• Registrar las reglas de negocio
  Las reglas de negocio incluyen políticas de la empresa, leyes, estándares y algoritmos. Documentar las reglas de negocio aparte de los requisitos del proyecto.
• Especificar requisitos no funcionales

Validación de Requisitos

• Revisar los requisitos
• Comprobar los requisitos
  Los tests constituyen una vista alternativa de los requisitos. Los proyectos ágiles a menudo crean tests de aceptación en lugar de requisitos funcionales detallados.
• Definir criterios de aceptación
• Simular los requisitos

Gestión de Requisitos

• Establecer un proceso de control del cambio de los requisitos
  El proceso debe definir cómo los cambios de requisitos son propuestos, analizados y resueltos.
• Realizar análisis de impacto de los cambios de requisitos
• Establecer líneas base y control de versiones de los conjuntos de requisitos
• Mantener un histórico de los cambios de requisitos
• Controlar el estado de cada requisito
• Controlar los problemas con los requisitos
• Mantener una matriz de trazabilidad de requisitos
• Usar una herramienta de gestión de requisitos

Conocimiento

• Formar a los analistas
• Educar a los implicados sobre requisitos
• Educar a los desarrolladores sobre el dominio de la aplicación
• Definir un proceso de ingeniería de requisitos
• Crear un glosario

Gestión de Proyectos

• Elegir ciclo de vida de desarrollo de software apropiado
• Planificar cómo abordar la toma de requisitos
• Estimar el esfuerzo de los requisitos
• Basar el plan del proyecto en los requisitos
• Identificar quiénes hacen decisiones sobre los requisitos
• Renegociar los acuerdos del proyecto cuando cambian los requisitos
• Analizar, documentar y gestionar los riesgos relativos a los requisitos
• Registrar el esfuerzo gastado en los requisitos
• Revisar las lecciones aprendidas en los requisitos de otros proyectos

Comenzar con nuevas prácticas

La siguiente tabla relaciona todas las prácticas anteriores con el valor que aportan al proyecto y su dificultad.

	Dificultad Alta	Dificultad Media	Dificultad Baja
Valor Alto	Definir un proceso de ingeniería de requisitos	Entrenar a los analistas	Educar a los desarrolladores sobre el dominio de la aplicación
	Basar los planes en los requisitos	Planificar cómo abordar los requisitos	Utilizar plantillas de documentos de requisitos
	Renegociar los acuerdos	Identificar los jefes	Identificar los tipos de usuario
		Identificar requisitos de usuario	Modelar el entorno de la aplicación
		Entrevistas de obtención de requisitos	Identificar los orígenes de los requisitos
		Especificar requisitos no funcionales	Establecer líneas base y versiones de control de los conjuntos de requisitos
		Priorizar requisitos	Identificar quiénes hacen decisiones sobre los requisitos
		Definir visión y alcance
		Establecer un proceso de control del cambio
		Revisar los requisitos
		Asignar requisitos a los subsistemas
		Utilizar una herramienta de gestión de requisitos
		Registrar reglas de negocio
Valor Medio	Mantener una matriz de trazabilidad de requisitos	Educar a los implicados sobre los requisitos	Crear un diccionario de datos
	Hacer talleres para facilitar la obtención de requisitos	Dirigir grupos de enfoque	Observar a los usuarios realizando su trabajo
	Estimar el esfuerzo de los requisitos	Crear prototipos	Comprobar los requisitos
	Reutilizar requisitos existentes	Analizar la viabilidad	Registrar el estado de los requisitos
		Definir los criterios de aceptación	Llevar a cabo un análisis de la documentación
		Modelar los requisitos	Registrar problemas con los requisitos
		Analizar las interfaces	Etiquetar de forma única cada requisito
		Analizar el impacto del cambio	Crear un glosario
		Elegir un ciclo de vida apropiado
		Identificar eventos y respuestas del sistema
		Gestionar los riesgos de los requisitos
		Revisar las lecciones aprendidas
		Registrar el esfuerzo de los requisitos
Valor Bajo		Distribuir cuestionarios	Examinar informes de problemas
		Mantener un histórico de cambios
		Simular los requisitos

No hay que intentar aplicar todas las técnicas en nuestro próximo proyecto, sino ir sumándolas poco a poco a nuestro conjunto de herramientas.

El Analista de Negocio (BA – Business Analyst)

El rol de analista

El analista tiene como responsabilidad principal obtener, analizar documentar y validar las necesidades de los implicados en el proyecto.

Tareas del analista

• Definir requisitos de negocio
• Planificar cómo abordar la toma de requisitos
• Identificar los implicados del proyecto y los tipos de usuario
• Obtener requisitos
• Analizar requisitos
• Documentar requisitos
• Comunicar requisitos
• Dirigir la validación de requisitos
• Facilitar la priorización de requisitos
• Gestionar requisitos

Habilidades esenciales del analista

• Saber escuchar
• Habilidad para hacer entrevistas y cuestionarios
• Pensar de forma clara en situaciones de estrés
• Capacidad de análisis
  Ser capaz tanto de descender desde alto nivel a los detalles, como de generalizar
• Habilidad de pensar en todo el sistema de forma global
• Capacidad de aprendizaje
• Ser buen facilitador
• Liderazgo
• Observación
• Comunicación
• Organización
• Modelado
• Habilidades interpersonales
• Creatividad

Requisitos de negocio

Los requisitos de negocio deberían estar claros antes de especificar los requisitos funcionales y no funcionales. Los requisitos de negocio dan un marco de referencia para tomar decisiones sobre la asunción o la modificación de los requisitos propuestos.

Documento de visión y alcance

El documento de visión y alcance recoge todos los requisitos de negocio en un único entregable. Una plantilla de dicho documento es la siguiente:

1. Requisitos de negocio

   1. Antecedentes
   2. Oportunidades de negocio
   3. Objetivos de negocio
   4. Métricas de éxito
   5. Visión en una frase
      Para (cliente objetivo) que (declaración de la necesidad u oportunidad) el (nombre del producto) es (categoría del producto) que (características principales, beneficios, razones para comprar o usar) a diferencia de (alternativas, sistema actual) nuestro producto (diferencias y ventajas).

   Ejemplo: Para los programadores que necesitan una herramienta de desarrollo ágil el developper 3000 es un sistema de desarrollo rápido que permite programar directamente según se piensa. A diferencia de otros sistemas de desarrollo rápido nuestro producto no necesita de teclado ni ratón, sólo la mente.

   6. Riesgos de negocio
   7. Asunciones y dependencias

2. Alcance y limitaciones

   1. Características principales
   2. Alcance de la versión inicial
   3. Alcance de las siguientes versiones
   4. Limitaciones y exclusiones

3. Contexto de negocio

   1. Perfiles de interesados
   2. Prioridades del proyecto
   3. Consideraciones de desarrollo

Técnicas de representación del alcance

Diagrama de contexto

El diagrama de contexto ilustra visualmente la frontera y las conexiones entre el sistema a desarrollar y el resto. Corresponde con el nivel 0 de los diagramas de flujo.

El sistema a desarrollar se representa con un círculo, las entidades externas se representan con rectángulos y las flechas se utilizan para representar el flujo de datos o artículos físicos entre el sistema y las entidades externas.

Mapa de ecosistema

El mapa de ecosistema muestra todos los sistemas relacionados con el sistema a desarrollar y cómo interaccionan entre sí. La diferencia con el diagrama de contexto es que muestra sistemas que no están directamente relacionados con el sistema a desarrollar.

Todos los sistemas se representan mediante cajas, con el sistema principal con el borde en negrita.

Árbol de características

El árbol de características es una representación visual de las características del producto organizadas en grupos lógicos, que subdivide cada característica jerárquicamente en mayor nivel de detalle.

Una rama principal en el medido del árbol indica el producto a implementar. Cada característica tiene su propia rama que sale de la principal.

Lista de eventos

Una lista de eventos identifica eventos externos que podrían desencadenar un comportamiento en el sistema.

La lista de eventos complementa el diagrama de contexto y el mapa de ecosistema.

Usuarios

Para obtener toda la información necesaria del usuario hay que seguir estos pasos:

• Identificar los tipos de usuario.
• Elegir y trabajar con individuos que representen cada tipo de usuario y otros grupos de interesados.
• Acordar quién es el responsable de la toma de decisiones.

Tipos de usuario

Clasificando usuarios

Los tipos de usuario se muestran a continuación:

Un individuo puede pertenecer a más de un tipo de usuario. Se pueden agrupar los usuarios en distintos tipos según los siguientes diferencias:

• Privilegio de acceso o nivel de seguridad (por ejemplo usuario corriente, invitado, administrador)
• Tareas que realiza durante su trabajo
• Características que utiliza
• Frecuencia con la que usa el producto
• Experiencia con la aplicación y conocimientos informáticos
• Plataforma en la que lo utiliza
• Lenguaje nativo
• Si interactúa con el sistema directa o indirectamente

Los tipos de usuario no tienen porqué referirse exclusivamente a personas, pueden ser software que utiliza nuestro producto, como bots.

Los tipos de usuarios se pueden modelar mediante un diagrama de contexto o un organigrama.

Los tipos de usuario, características, responsabilidades y localización física se deben documentar en el documento de requisitos (Software Requeriments Specification, SRS).

Personas

Se puede crear una persona para cada tipo de usuario. Una persona es una descripción de un miembro hipotético que es representativo de su grupo de usuarios.

Es más fácil pensar en una persona para obtener los requisitos que pensar en un usuario abstracto.

Cómo resolver conflictos con los requisitos

• Usuarios individuales
  Decide el representante (product champion) elegido de cada tipo de usuario o el product owner
• Tipos de usuario
  Los tipos de usuario más importantes tienen preferencia
• Segmentos de mercado
  Los segmentos con más impacto en el negocio tienen preferencia
• Clientes corporativos
  Los objetivos de negocio dictan la dirección
• Usuarios y jefes
  Decide el representante (product champion) elegido de cada tipo de usuario o el product owner
• Desarrollo y clientes
  Los clientes tienen preferencia, pero en línea con los objetivos de negocio
• Desarrollo y ventas
  Ventas tiene preferencia

Obtención de requisitos

El ciclo de obtención de requisitos es el siguiente:

Técnicas de obtención de requisitos

Obtención de requisitos con los interesados

• Entrevistas
  Tanto individuales como grupales
• Talleres
  Son reuniones con interesados y expertos seleccionados. Existe un facilitador, que suele ser el analista
• Grupos de enfoque
  Consiste en un grupo representativo de usuarios con la intención de recoger requisitos funcionales y de calidad
• Observar el trabajo de los usuarios
• Cuestionarios

Obtención de requisitos de forma independiente

Las siguientes técnicas las puede utilizar el analista para obtener requisitos por sí mismo:

• Análisis de interfaces del sistema
• Análisis de interfaces de usuario
• Análisis de documentación

Qué técnicas emplear según el tipo de proyecto

• Software para un mercado de masas
  • Entrevistas
  • Grupos de enfoque
  • Cuestionarios
• Software interno
  • Entrevistas
  • Talleres
  • Grupos de enfoque
  • Observación
  • Análisis de interfaces del sistema
  • Análisis de documentación
• Reemplazar un sistema existente
  • Entrevistas
  • Talleres
  • Observación
  • Análisis de interfaces del sistema
  • Análisis de interfaces de usuario
  • Análisis de documentación
• Mejorar un sistema existente
  • Entrevistas
  • Talleres
  • Análisis de interfaces del sistema
  • Análisis de interfaces de usuario
  • Análisis de documentación
• Nueva aplicación
  • Entrevistas
  • Talleres
  • Análisis de interfaces del sistema
• Implementación de un paquete de software
  • Entrevistas
  • Talleres
  • Observación
  • Análisis de interfaces del sistema
  • Análisis de documentación
• Sistemas embebidos
  • Entrevistas
  • Talleres
  • Análisis de interfaces del sistema
  • Análisis de documentación
• Implicados distribuidos geográficamente
  • Entrevistas
  • Talleres
  • Cuestionarios

Planificando la obtención de requisitos

• Objetivos
• Técnicas
  Elegir qué técnicas utilizar con cada grupo de implicados
• Estimar la agenda y los recursos
• Documentos y sistemas necesarios para la obtención de requisitos independiente
• Productos a obtener
• Riesgos

Requisitos de usuario. Casos de uso

Casos de uso e historias de usuario

Un caso de uso describe una secuencia de interacciones entre un sistema y un actor externo con el resultado de que permite al actor conseguir algún resultado de valor. El nombre de los casos de uso siempre es un verbo seguido de un objeto.

Una historia de usuario es una descripción corta y simple de una característica tomada desde la perspectiva de la persona que desea la nueva funcionalidad, normalmente un usuario o cliente del sistema. Las historias de usuario se escriben según el siguiente esquema:

Como un <tipo de usuario> quiero <algún objetivo> para <alguna razón>

A partir de los casos de uso se pueden obtener los requisitos funcionales y las pruebas. A partir de las historias de usuario se obtienen las pruebas de aceptación:

Casos de uso

Para identificar a los actores podemos hacer a los usuarios las siguientes preguntas:

• ¿Quién (o qué) es notificado cuando algo ocurre en el sistema?
• ¿Quién (o qué) provee información o servicios al sistema?
• ¿Quién (o qué) ayuda al sistema a responder y completar una tarea?

Los diagramas de casos de uso son representación visual de alto nivel de los requisitos de usuario.

Ejemplo de Diagrama de Casos de Uso

Escenarios

Un caso de uso es una colección de escenarios de uso, y un escenario es una instancia específica de un caso de uso. Cuando se buscan requisitos se puede empezar desde un caso de uso general y desarrollarlo hasta escenarios más específicos, o se puede generalizar desde un escenario específico hasta el caso de uso más amplio.

El escenario que sigue el flujo normal del caso de uso se denomina escenario principal. Los demás escenarios se denominan escenarios alternativos.

Plantilla para casos de uso

La siguiente plantilla es una estructura donde recoger la información que encontramos al analizar un caso de uso, organizada de una forma consistente.

Ejemplo de Especificación de un Caso de Uso

Los elementos esenciales en un caso de uso son los siguientes:

• Un identificador único y un nombre breve que establece el objetivo del usuario
• Una breve descripción del propósito del caso de uso
• Un desencadenante que inicia la ejecución del caso de uso
• Precondiciones que se deben cumplir antes de que inicie el caso de uso
• Postcondiciones que describen en estado del sistema después de que el caso de uso se complete satisfactoriamente
• Enumeración de pasos que muestran la secuencia de interacciones entre el actor y el sistema -un diálogo- yendo desde las precondiciones hasta las postcondiciones
• Excepciones que impiden que el caso de uso tenga éxito. Describen condiciones de error que pueden ocurrir durante la ejecución del caso de uso y cómo se deben tratar

En casos de uso complejos se pueden utilizar diagramas de flujo o diagramas de actividad para representar de forma visual el escenario principal, los alternativos, así como las excepciones.

Relaciones Extend e Include

En el diagrama de casos de uso existen dos tipos de relaciones: extend ("extiende") e include ("usa").

Extend se utiliza cuando se quiere mostrar un comportamiento opcional del caso de uso (un escenario alternativo). Include cuando se quiere reflejar un comportamiento común en varios casos de uso.

Cómo identificar los casos de uso

Se pueden identificar casos de uso de las siguientes maneras:

• Identificar los actores primero, luego diseñar los procesos de negocio soportados por el sistema y definir los casos de uso para las actividades donde actores y sistemas interactúan.
• Crear escenarios específicos para ilustrar cada proceso de negocio, después generalizar los escenarios a casos de uso e identificar los actores involucrados en cada uno.
• Utilizando la descripción de un proceso de negocio, preguntar "¿Qué tareas debe realizar el sistema para completar este proceso o convertir las entradas en salidas?" Esas tareas pueden ser casos de uso.
• Identificar los eventos externos a los que debe responder el sistema, entonces relacionar esos eventos con actores participantes y casos de uso específicos.
• Utilizar un análisis CRUD para identificar las entidades que requieren los casos de uso para crear, leer, actualizar o borrar,
• Examinar el diagrama de contexto y preguntar "¿Qué objetivos de cada una de las entidades externas se quiere conseguir con la ayuda del sistema?"

Productos en la obtención de casos de uso

Casos de uso y requisitos funcionales

Los casos de uso describen la perspectiva de usuario. No contienen toda la información que un desarrollador necesita para escribir el software. Un analista desde especificar explícitamente los requisitos funcionales necesarios para implementar cada caso de uso.

La funcionalidad asociada a los casos de uso se puede documentar de varias maneras:

• Solo casos de uso
  Se incluyen los requisitos funcionales en cada especificación de los casos de uso. Aparte hay que documentar los requisitos no funcionales y cualquier funcionalidad que no esté asociada con un caso de uso. Para no repetir la funcionalidad que necesiten varios casos de uso, se puede señalar con relaciones. Los casos de uso se pueden recoger en documento de requisitos de usuario.
• Casos de uso y requisitos funcionales
  Se pueden escribir de forma sencilla los casos de uso y los requisitos funcionales derivados de cada uno en un SRS o en un repositorio de requisitos. Se establece la trazabilidad entre cada caso de uso y sus requisitos funcionales asociados; la mejor forma de gestionar la trazabilidad es con una herramienta de gestión de requisitos.
• Solo requisitos funcionales
  Otra opción es organizar los requisitos funcionales por caso de uso o por característica, e incluir ambos en el SRS o en el repositorio de requisitos. Los casos de uso se escriben de forma muy escueta y los detalles se incluyen en los requisitos funcionales.
• Casos de uso y pruebas
  Otra estrategia es escribir de forma detallada la especificación de los casos de uso, con pruebas de aceptación. Esto evita la duplicidad que se tiene al detallar casos de uso y requisitos.

Errores a evitar

• Demasiados casos de uso
  No escribir un caso de uso separado por cada escenario posible. Lo normal es tener más casos de uso que requisitos de negocio y características, pero muchos más requisitos funcionales que casos de uso.
• Casos de uso demasiado complejos
• Incluir diseño en los casos de uso
  Los casos de uso se deben enfocar en lo que los usuarios necesitan, no en la apariencia de las pantallas.
• Incluir definiciones de datos en los casos de uso
  Las definiciones de datos se deben guardar en un diccionario de datos y en un modelo de datos.
• Casos de uso que no entienden los usuarios
  Los casos de uso deben estar escritos desde la perspectiva del usuario, no del sistema.

Reglas de negocio

Tipos de reglas de negocio

• Hechos
• Restricciones
• Posibilitadores
• Inferencias
• Cálculos

Descubriendo las reglas de negocio

• Conocimiento común de la organización
• Sistemas antiguos
• Modelos de proceso de negocio
• Análisis de documentación existente
• Análisis de datos
• Departamentos de normativa

Reglas de negocio y requisitos

El analista debe decidir qué reglas de negocio pertenecen a su aplicación, cuáles se tienen que hacer cumplir en el software, y de qué manera.

Documentando los requisitos

Los requisitos se documentan en el SRS (Software Requirements Specification). El SRS se puede almacenar en un documento de texto, una hoja de cálculo, un wiki, una base de datos o una herramienta de gestión de requisitos (RM).

Los requisitos se pueden representar de múltiples formas:

• Lenguaje natural
• Modelos visuales
• Especificaciones formales

La mayoría de los proyectos de software se pueden documentar correctamente con lenguaje natural junto con modelos visuales.

Especificación de requisitos de software (SRS)

El SRS establece las funciones y capacidades que un sistema de software debe proporcionar, sus características y las restricciones que debe respetar. Debería describir de forma tan completa como sea necesaria los comportamientos del sistema en diversas condiciones, así como las cualidades deseadas del sistema, como el rendimiento, la seguridad y la facilidad de uso. El SRS es la base para la planificación, el diseño y la codificación del proyecto posterior, así como la base para las pruebas del sistema y la documentación del usuario. Sin embargo, no debe contener detalles de diseño, construcción, pruebas o gestión de proyectos distintos a las limitaciones conocidas de diseño e implementación.

Plantilla de SRS

1. Introducción
   1. Propósito
   2. Convenciones utilizadas en el documento
   3. Alcance del proyecto
   4. Referencias
2. Descripción general
   1. Perspectiva del producto
      Incluir modelos visuales, como un diagrama de contexto o un mapa de ecosistema.
   2. Tipos de usuario y características
   3. Entorno de operación
      Plataformas hardware, sistemas operativos y versiones; localización geográfica de los usuarios, servidores y bases de datos. Listar cualquier otro software o aplicaciones con el que tenga que coexistir el sistema.
   4. Restricciones de diseño e implementación
      Por ejemplo: determinado lenguaje de programación que hay que utilizar. Describir cualquier factor que restrinja las opciones disponibles de los desarrolladores.
   5. Asunciones y dependencias
      Se incluyen las asunciones relativas a la funcionalidad del sistema; las asunciones relativas al negocio aparecen en el documento de visión y alcance.
3. Características del sistema
   1. Característica 1
      1. Descripción
         Pequeña descripción, indicando si es de prioridad baja, media o alta.
      2. Requisitos funcionales
   2. Característica 2
   3. …
4. Requisitos de datos
   1. Modelo lógico de datos
      Incluir una representación visual, como un diagrama entidad-relación o un diagrama de clases UML.
   2. Diccionario de datos
      Es mejor almacenar el diccionario de datos de forma externa.
   3. Informes
   4. Adquisición, integridad, retención y disponibilidad de los datos
5. Requisitos de interfaces externas
   1. Interfaces de usuario
   2. Interfaces software
   3. Interfaces hardware
   4. Interfaces de comunicación
6. Atributos de calidad
   1. Usabilidad
   2. Rendimiento
   3. Seguridad
   4. Otros
7. Requisitos de internacionalización y localización
8. Otros requisitos
9. Apéndice A: Glosario
10. Apéndice B: Modelos de Análisis

Evitar información duplicada en varias secciones, en su lugar utilizar referencias cruzadas y enlaces. Utilizar control de versiones e incluir un histórico de versiones.

Escribiendo buenos requisitos

Características de los buenos requisitos

• Completo
• Correcto
• Flexible
• Necesario
• Priorizado
• No ambiguo
• Verificable

Características de las colecciones de requisitos

Estas con las características que deben cumplir los requisitos que se agrupan para una revisión o iteración específica.

• Completa
• Consistente
• Modificable
• Trazable

Cómo escribir requisitos

Un modelo para escribir un requisito desde la perspectiva del sistema es

[precondición (opcional)] [desencadenante (opcional)] el sistema deberá [respuesta esperada]

Para hacerlo desde el punto de vista del usuario se puede utilizar

[Tipo de usuario o nombre del actor] debe ser capaz de [hacer algo] [con algún objeto] [condiciones, tiempo de respuesta o calidad]

Nivel de detalle

Se debe escribir con más detalle cuando:

• El trabajo se realiza para un cliente externo.
• El desarrollo o las pruebas se van a externalizar.
• Los miembros del equipo están dispersos geográficamente.
• Las pruebas del sistema se basarán en los requisitos.
• Se necesitan estimaciones precisas.
• Se necesita trazabilidad de requisitos.

Se puede escribir con menos detalle cuando:

• El trabajo se hace para la propia empresa.
• Los usuarios están involucrados.
• Los desarrolladores tienen experiencia.
• Se reemplaza una aplicación anterior.
• Se utilizará un paquete de software como solución.

Estableciendo prioridades a los requisitos

Escala a tres niveles (según importancia y urgencia)

MoSCoW

• Must
  El requisito debe ser satisfecho.
• Should
  El requisito es importante y debería ser incluido si fuera posible.
• Could
  Es deseable, pero prescindible. Solo se debe implementar si hay tiempo y recursos disponibles.
• Won’t
  No se debería incluir ahora mismo, pero sí en una revisión posterior.

Validando requisitos

La validación de requisitos asegura que:

• Los requisitos del software describen con precisión las capacidades y propiedades del sistema que satisfarán las necesidades de los distintos interesados.
• Los requisitos de software se derivan correctamente de los requisitos comerciales, los requisitos del sistema, las reglas comerciales y otras fuentes.
• Los requisitos son completos, factibles y verificables.
• Todos los requisitos son necesarios y todo el conjunto es suficiente para cumplir con los objetivos comerciales.
• Todas las representaciones de los requisitos son coherentes entre sí.
• Los requisitos proporcionan una base adecuada para proceder con el diseño y la construcción.

Gestionando requisitos

Gestión del cambio

Plantilla para controlar el cambio de requisitos

1. Propósito y alcance
2. Roles y responsabilidades
3. Estado cambio solicitado
4. Criterios de entrada
5. Tareas
   1. Evaluar petición cambio
   2. Decidir si realizar el cambio
   3. Implementar el cambio
   4. Solicitar el cambio
6. Criterios de salida
7. Informe de estado del control del cambio