Toma de Requisitos – rhernando.net

Índice

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

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.
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.
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.
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:

Definir los requisitos de negocio.
Identificar los tipos de usuario.
Identificar usuarios representativos.
Identificar quiénes toman las decisiones sobre los requisitos.
Plan de obtención de requisitos.
Identificar los requisitos de usuario.
Priorizar los requisitos de usuario.

Se repite en cada iteración:

Desarrollar los requisitos de usuario.
Derivar los requisitos funcionales.
Modelar los requisitos.
Especificar los requisitos no funcionales.
Revisar los requisitos.
Desarrollar prototipos.
Desarrollar o evolucionar la arquitectura.
Asignar requisitos a componentes.
Desarrollar pruebas a partir de los requisitos.
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:

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.
1. Riesgos de negocio
2. Asunciones y dependencias
Alcance y limitaciones
1. Características principales
2. Alcance de la versión inicial
3. Alcance de las siguientes versiones
4. Limitaciones y exclusiones
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

Introducción
1. Propósito
2. Convenciones utilizadas en el documento
3. Alcance del proyecto
4. Referencias
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.
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