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
Identificar qué esperan los distintos tipos de usuario y otros implicados del producto.
Comprender objetivos de usuario y los objetivos de negocio.
Aprender acerca del entorno en el que se va a utilizar el nuevo producto.
Trabajar con individuos que representen cada tipo de usuario para comprender sus necesidades y sus espectativas de calidad.
Análisis
Analizar la información recibida por los usuarios para distinguir sus objetivos de los requisitos funcionales, espectativas de calidad, reglas de negocio, soluciones propuestas y otra información.
Descomponer requisitos de alto nivel en el nivel apropiado de detalle.
Deducir requisitos funcionales a partir de otros requisitos.
Comprender la importancia relativa de los atributos de calidad.
Asignación de requisitos a los componentes de software definidos en la arquitectura del sistema.
Negociar prioridades de implementación.
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 espectativas 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
Antecedentes
Oportunidades de negocio
Objetivos de negocio
Métricas de éxito
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 eldevelopper 3000es 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.
Riesgos de negocio
Asunciones y dependencias
Alcance y limitaciones
Características principales
Alcance de la versión inicial
Alcance de las siguientes versiones
Limitaciones y exclusiones
Contexto de negocio
Perfiles de interesados
Prioridades del proyecto
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
Propósito
Convenciones utilizadas en el documento
Alcance del proyecto
Referencias
Descripción general
Perspectiva del producto Incluir modelos visuales, como un diagrama de contexto o un mapa de ecosistema.
Tipos de usuario y características
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.
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.
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
Característica 1
Descripción Pequeña descripción, indicando si es de prioridad baja, media o alta.
Requisitos funcionales
Característica 2
...
Requisitos de datos
Modelo lógico de datos Incluir una representación visual, como un diagrama entidad-relación o un diagrama de clases UML.
Diccionario de datos Es mejor almacenar el diccionario de datos de forma externa.
Informes
Adquisición, integridad, retención y disponibilidad de los datos
Requisitos de interfaces externas
Interfaces de usuario
Interfaces software
Interfaces hardware
Interfaces de comunicación
Atributos de calidad
Usabilidad
Rendimiento
Seguridad
Otros
Requisitos de internacionalización y localización
Otros requisitos
Apéndice A: Glosario
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.
