Análisis de requerimientos

En ingeniería de sistemas e ingeniería de software, el análisis de requisitos se centra en las tareas que determinan las necesidades o condiciones para satisfacer el producto o proyecto nuevo o modificado, teniendo en cuenta los requisitos posiblemente conflictivos de las distintas partes interesadas., analizar, documentar, validar y gestionar requisitos de software o sistema.

El análisis de requisitos es fundamental para el éxito o el fracaso de un proyecto de software o sistemas. Los requisitos deben estar documentados, ser factibles, mensurables, comprobables, rastreables, relacionados con las necesidades u oportunidades comerciales identificadas y definidos con un nivel de detalle suficiente para el diseño del sistema.

Descripción general

Conceptualmente, el análisis de requisitos incluye tres tipos de actividades:

• Recursos necesarios: (por ejemplo, la carta o definición del proyecto), la documentación del proceso empresarial y las entrevistas con los interesados. Esto se llama a veces también la recolección de requisitos o descubrimiento de requisitos.
• Requisitos de grabación: Los requisitos pueden documentarse en diversas formas, por lo general incluyendo una lista resumida y pueden incluir documentos de lenguaje natural, casos de uso, historias de usuario, especificaciones de procesos y una variedad de modelos, incluyendo modelos de datos.
• Analizar los requisitos: determinar si los requisitos establecidos son claros, completos, no duplicados, concisos, válidos, coherentes e inequívocos, y resolver cualquier conflicto aparente. El análisis también puede incluir requisitos de tamaño.

El análisis de requisitos puede ser un proceso largo y agotador durante el cual están involucradas muchas habilidades psicológicas delicadas. Los nuevos sistemas cambian el entorno y las relaciones entre las personas, por lo que es importante identificar a todas las partes interesadas, tener en cuenta todas sus necesidades y asegurarse de que comprendan las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Estos pueden incluir el desarrollo de escenarios (representados como historias de usuarios en métodos ágiles), la identificación de casos de uso, el uso de observación o etnografía en el lugar de trabajo, la realización de entrevistas o grupos focales (más acertadamente denominados en este contexto como talleres de requisitos o talleres de requisitos). sesiones de revisión) y creación de listas de requisitos. Se pueden utilizar prototipos para desarrollar un sistema de ejemplo que se pueda demostrar a las partes interesadas. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las partes interesadas, de modo que se produzca un sistema que satisfaga las necesidades del negocio. La calidad de los requisitos se puede mejorar mediante estos y otros métodos.

• Visualización. Usando herramientas que promuevan una mejor comprensión del producto final deseado, como visualización y simulación.
• Uso consistente de plantillas. Producir un conjunto consistente de modelos y plantillas para documentar los requisitos.
• Documentando dependencias. Documentar dependencias e interrelaciones entre los requisitos, así como cualquier hipótesis y congregaciones.

Temas de análisis de requisitos

Identificación de partes interesadas

Consulte Análisis de partes interesadas para obtener información sobre personas u organizaciones (entidades legales como empresas, organismos de normalización) que tienen un interés válido en el sistema. Pueden verse afectados por él directa o indirectamente. Un nuevo énfasis importante en la década de 1990 fue centrarse en la identificación de las partes interesadas. Cada vez se reconoce más que las partes interesadas no se limitan a la organización que emplea al analista. Otras partes interesadas incluirán:

• cualquiera que opera el sistema (operadores normales y de mantenimiento)
• cualquiera que se beneficie del sistema (beneficios funcionales, políticos, financieros y sociales)
• cualquiera involucrado en la compra o adquisición del sistema. En una organización de productos de mercado masivo, la gestión de productos, la comercialización y a veces las ventas actúan como consumidores sustitutos (clientes de mercado masivo) para guiar el desarrollo del producto.
• organizaciones que regulan aspectos del sistema (financiera, de seguridad y otros reguladores)
• personas u organizaciones que se oponen al sistema (las partes interesadas negativas; véase también el caso Misuse)
• organizaciones responsables de sistemas que interconectan con el sistema bajo diseño.
• aquellas organizaciones que se integran horizontalmente con la organización para la cual el analista está diseñando el sistema.

Sesiones de desarrollo conjunto de requisitos (JRD)

Los requisitos a menudo tienen implicaciones interfuncionales que las partes interesadas desconocen y que a menudo se pasan por alto o no se definen completamente durante las entrevistas con las partes interesadas. Estas implicaciones multifuncionales se pueden obtener realizando sesiones de JRD en un entorno controlado, facilitadas por un facilitador capacitado (analista de negocios), donde las partes interesadas participan en discusiones para obtener requisitos, analizar sus detalles y descubrir implicaciones multifuncionales. Debe estar presente un escriba dedicado para documentar la discusión, lo que libera al analista de negocios para dirigir la discusión en una dirección que genere requisitos apropiados que cumplan con el objetivo de la sesión.

Las sesiones JRD son análogas a las sesiones conjuntas de diseño de aplicaciones. En las primeras, las sesiones provocan requisitos que guían el diseño, mientras que en las segundas se obtienen las características de diseño específicas que se implementarán para satisfacer los requisitos suscitados.

Listas de requisitos de estilo contrato

Una forma tradicional de documentar los requisitos han sido las listas de requisitos de estilo contractual. En un sistema complejo, estas listas de requisitos pueden tener cientos de páginas.

Una metáfora apropiada sería una lista de compras extremadamente larga. Estas listas están muy en desuso en el análisis moderno; ya que han demostrado ser espectacularmente infructuosos en el logro de sus objetivos; pero todavía se ven hasta el día de hoy.

Fortalezas

• Proporciona una lista de requisitos.
• Proveer un contrato entre los patrocinadores del proyecto y los desarrolladores.
• Para un sistema grande puede proporcionar una descripción de alto nivel de la cual se pueden derivar requisitos de menor nivel.

Debilidades

• Tales listas pueden correr a cientos de páginas. No están destinados a servir como una descripción fácil de leer de la aplicación deseada.
• Tales requisitos enumeran resumen todos los requisitos y por lo tanto hay poco contexto. El Analista de Negocios puede incluir contexto para requisitos en la documentación de diseño adjunta.
  • Esta abstracción no pretende describir cómo encajan los requisitos o trabajan juntos.
  • La lista no puede reflejar las relaciones y dependencias entre los requisitos. Si bien una lista hace que sea fácil priorizar cada artículo individual, eliminar un artículo fuera de contexto puede hacer que un caso de uso completo o requisito de negocio sea inútil.
  • La lista no suplanta la necesidad de revisar los requerimientos cuidadosamente con los interesados para obtener una mejor comprensión compartida de las implicaciones para el diseño del sistema / aplicación deseado.
• Simplemente crear una lista no garantiza su integridad. El Analista de Negocios debe hacer un esfuerzo de buena fe para descubrir y recoger una lista sustancialmente completa, y depender de los interesados para señalar los requisitos de falta.
• Estas listas pueden crear un falso sentido de comprensión mutua entre las partes interesadas y los desarrolladores; Los analistas de negocios son críticos para el proceso de traducción.
• Es casi imposible descubrir todos los requisitos funcionales antes de que comience el proceso de desarrollo y pruebas. Si estas listas son tratadas como contrato inmutable, los requisitos que emergen en el proceso de desarrollo pueden generar una solicitud de cambio polémica.

Alternativa a las listas de requisitos

Como alternativa a las listas de requisitos, Agile Software Development utiliza historias de usuarios para sugerir requisitos en el lenguaje cotidiano.

Metas medibles

Las mejores prácticas toman la lista compuesta de requisitos simplemente como pistas y preguntan repetidamente "¿por qué?" hasta que se descubran los propósitos comerciales reales. Luego, las partes interesadas y los desarrolladores pueden diseñar pruebas para medir qué nivel de cada objetivo se ha logrado hasta el momento. Estos objetivos cambian más lentamente que la larga lista de requisitos específicos pero no medidos. Una vez que se ha establecido un pequeño conjunto de objetivos críticos y medidos, la creación rápida de prototipos y fases cortas de desarrollo iterativo pueden proceder a entregar valor real a las partes interesadas mucho antes de que el proyecto haya finalizado la mitad.

Prototipos

Un prototipo es un programa informático que exhibe una parte de las propiedades de otro programa informático, permitiendo a los usuarios visualizar una aplicación que aún no ha sido construida. Una forma popular de prototipo es una maqueta, que ayuda a los futuros usuarios y otras partes interesadas a tener una idea de cómo será el sistema. Los prototipos facilitan la toma de decisiones de diseño, porque se pueden ver y compartir aspectos de la aplicación antes de crearla. A menudo se observaron mejoras importantes en la comunicación entre usuarios y desarrolladores con la introducción de prototipos. Las primeras vistas de las aplicaciones dieron lugar a menos cambios posteriores y, por tanto, redujeron considerablemente los costes generales.

Los prototipos pueden ser diagramas planos (a menudo denominados estructuras alámbricas) o aplicaciones de trabajo que utilizan funcionalidad sintetizada. Los wireframes se crean en una variedad de documentos de diseño gráfico y, a menudo, eliminan todo el color del diseño (es decir, utilizan una paleta de colores en escala de grises) en los casos en los que se espera que al software final se le aplique el diseño gráfico. Esto ayuda a evitar confusiones sobre si el prototipo representa la apariencia visual final de la aplicación.

Casos de uso

Un caso de uso es una estructura para documentar los requisitos funcionales de un sistema, que generalmente involucra software, ya sea nuevo o en proceso de modificación. Cada caso de uso proporciona un conjunto de escenarios que transmiten cómo el sistema debe interactuar con un usuario humano u otro sistema para lograr un objetivo comercial específico. Los casos de uso normalmente evitan la jerga técnica y prefieren el lenguaje del usuario final o del experto en el dominio. Los casos de uso suelen ser coautores de ingenieros de requisitos y partes interesadas.

Los casos de uso son herramientas engañosamente simples para describir el comportamiento de software o sistemas. Un caso de uso contiene una descripción textual de las formas en que se pretende que los usuarios trabajen con el software o sistema. Los casos de uso no deben describir el funcionamiento interno del sistema ni explicar cómo se implementará ese sistema. En cambio, muestran los pasos necesarios para realizar una tarea sin suposiciones secuenciales.

Especificación de requisitos

La especificación de requisitos es la síntesis de los hallazgos de descubrimiento relacionados con las necesidades comerciales del estado actual y la evaluación de estas necesidades para determinar y especificar qué se requiere para satisfacer las necesidades dentro del alcance de la solución en cuestión. El descubrimiento, el análisis y la especificación mueven la comprensión desde un estado actual como está a un estado futuro. La especificación de requisitos puede cubrir toda la amplitud y profundidad del estado futuro que se va a lograr, o podría apuntar a vacíos específicos que llenar, como errores prioritarios del sistema de software que corregir y mejoras que realizar. Dado que cualquier proceso de negocio grande casi siempre emplea software y sistemas y tecnología de datos, la especificación de requisitos a menudo se asocia con la construcción de sistemas de software, compras, estrategias de computación en la nube, software integrado en productos o dispositivos, u otras tecnologías. La definición más amplia de especificación de requisitos incluye o se centra en cualquier estrategia o componente de la solución, como capacitación, guías de documentación, personal, estrategias de marketing, equipos, suministros, etc.

Tipos de requisitos

Los requisitos se clasifican de varias maneras. Las siguientes son categorizaciones comunes de requisitos relacionados con la gestión técnica:

Requisitos comerciales

Declaraciones de objetivos a nivel empresarial, sin referencia a funciones detalladas. Suelen ser capacidades de alto nivel (software y/o hardware) que se necesitan para lograr un resultado empresarial.

Requisitos del cliente

Declaraciones de hechos y suposiciones que definen las expectativas del sistema en términos de objetivos de la misión, entorno, limitaciones y medidas de eficacia e idoneidad (MOE/MOS). Los clientes son aquellos que realizan las ocho funciones principales de la ingeniería de sistemas, con especial énfasis en el operador como cliente clave. Los requisitos operativos definirán la necesidad básica y, como mínimo, responderán las preguntas planteadas en el siguiente listado:

• Distribución o despliegue operacionales: ¿Dónde se utilizará el sistema?
• Perfil de la Misión o escenario: ¿Cómo logrará el sistema su objetivo de misión?
• Rendimiento y parámetros conexos: ¿Cuáles son los parámetros críticos del sistema para cumplir la misión?
• Medios de utilización: ¿Cómo se utilizan los distintos componentes del sistema?
• Necesidades de eficacia: ¿Qué tan eficaz o eficiente debe ser el sistema en el desempeño de su misión?
• Ciclo de vida operacional: ¿Cuánto tiempo utilizará el sistema el usuario?
• para el Medio Ambiente: ¿Qué entornos se espera que el sistema funcione de manera eficaz?

Requisitos arquitectónicos

Los requisitos arquitectónicos explican lo que se debe hacer identificando la arquitectura de sistemas necesaria de un sistema.

Requisitos estructurales

Los requisitos estructurales explican lo que se debe hacer identificando la estructura necesaria de un sistema.

Requisitos de comportamiento

Los requisitos de comportamiento explican lo que se debe hacer identificando el comportamiento necesario de un sistema.

Requisitos funcionales

Los requisitos funcionales explican lo que se debe hacer identificando la tarea, acción o actividad necesaria que se debe realizar. El análisis de requisitos funcionales se utilizará como funciones de nivel superior para el análisis funcional.

Requisitos no funcionales

Los requisitos no funcionales son requisitos que especifican criterios que se pueden utilizar para juzgar el funcionamiento de un sistema, en lugar de comportamientos específicos.

Requisitos de rendimiento

La medida en que se debe ejecutar una misión o función; generalmente se mide en términos de cantidad, calidad, cobertura, puntualidad o preparación. Durante el análisis de requisitos, los requisitos de rendimiento (qué tan bien se debe hacer) se desarrollarán de forma interactiva en todas las funciones identificadas en función de los factores del ciclo de vida del sistema; y caracterizados en términos del grado de certeza en su estimación, el grado de criticidad para el éxito del sistema y su relación con otros requisitos.

Requisitos de diseño

Las funciones "construir para", "codificar para" y "comprar para" requisitos para productos y "cómo ejecutar" requisitos para procesos expresados en paquetes de datos técnicos y manuales técnicos.

Requisitos derivados

Requisitos que están implícitos o transformados a partir de requisitos de nivel superior. Por ejemplo, un requisito de largo alcance o alta velocidad puede dar lugar a un requisito de diseño de bajo peso.

Requisitos asignados

Un requisito que se establece dividiendo o asignando de otro modo un requisito de alto nivel en múltiples requisitos de nivel inferior. Ejemplo: un artículo de 100 libras que consta de dos subsistemas podría generar requisitos de peso de 70 libras y 30 libras para los dos artículos de nivel inferior.

Los modelos de categorización de requisitos más conocidos incluyen FURPS y FURPS+, desarrollados en Hewlett-Packard.

Problemas de análisis de requisitos

Cuestiones de las partes interesadas

Steve McConnell, en su libro Rapid Development, detalla varias formas en que los usuarios pueden inhibir la recopilación de requisitos:

• Los usuarios no entienden lo que quieren o los usuarios no tienen una idea clara de sus requisitos
• Los usuarios no se comprometen a un conjunto de requisitos escritos
• Los usuarios insisten en nuevos requisitos después de que el costo y el calendario han sido fijos
• La comunicación con los usuarios es lenta
• Los usuarios a menudo no participan en opiniones o son incapaces de hacerlo
• Los usuarios son técnicamente no sofisticados
• Los usuarios no entienden el proceso de desarrollo
• Los usuarios no conocen la tecnología actual

Esto puede llevar a una situación en la que los requisitos del usuario sigan cambiando incluso cuando se haya iniciado el desarrollo del sistema o del producto.

Problemas de ingeniera / desarrollador

Los posibles problemas causados por ingenieros y desarrolladores durante el análisis de requisitos son:

• Una inclinación natural hacia el código de escritura puede llevar a la implementación comenzando antes de que el análisis de requisitos sea completo, lo que podría dar lugar a cambios de código para satisfacer los requisitos reales una vez que se conocen.
• El personal técnico y los usuarios finales pueden tener diferentes vocabularios. En consecuencia, pueden creer erróneamente que están en perfecto acuerdo hasta que el producto terminado sea suministrado.
• Los ingenieros y desarrolladores pueden intentar ajustar los requisitos a un sistema o modelo existente, en lugar de desarrollar un sistema específico para las necesidades del cliente.

Soluciones intentadas

Un intento de solución a los problemas de comunicaciones ha sido emplear especialistas en análisis de sistemas o negocios.

Las técnicas introducidas en la década de 1990, como la creación de prototipos, el lenguaje de modelado unificado (UML), los casos de uso y el desarrollo ágil de software, también pretenden ser soluciones a los problemas encontrados con los métodos anteriores.

Además, ha entrado en el mercado una nueva clase de herramientas de simulación o definición de aplicaciones. Estas herramientas están diseñadas para cerrar la brecha de comunicación entre los usuarios empresariales y la organización de TI, y también para permitir que las aplicaciones se 'comercialicen de prueba' antes de que se produzca cualquier código. Lo mejor de estas herramientas ofrece:

• pizarras electrónicas para dibujar flujos de aplicación y probar alternativas
• capacidad para captar lógica empresarial y necesidades de datos
• capacidad para generar prototipos de alta fidelidad que imitan de cerca la aplicación final
• interactividad
• capacidad para añadir requisitos contextuales y otros comentarios
• capacidad para usuarios remotos y distribuidos para funcionar e interactuar con la simulación