Análisis de requerimientos - Requirements analysis

Una perspectiva de ingeniería de sistemas sobre el análisis de requisitos.

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 cumplir con el producto o proyecto nuevo o alterado, teniendo en cuenta los requisitos posiblemente conflictivos de los distintos interesados , analizando, documentando, validando y gestionando software o Requisitos del 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, procesables, medibles, 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:

Obtención de requisitos : (por ejemplo, el estatuto o la definición del proyecto), documentación del proceso comercial y entrevistas con las partes interesadas. A veces, esto también se denomina recopilación de requisitos o descubrimiento de requisitos.
Requisitos de registro: los requisitos se pueden documentar en varias formas, que generalmente incluyen una lista resumida y pueden incluir documentos en lenguaje natural, casos de uso , historias de usuarios , especificaciones de procesos y una variedad de modelos, incluidos 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 los conflictos aparentes. 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 la creación de listas de requisitos. La creación de prototipos se puede utilizar 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 comerciales. La calidad de los requisitos se puede mejorar a través de estos y otros métodos.

Visualización. Usar herramientas que promuevan una mejor comprensión del producto final deseado, como la visualización y la simulación.
Uso constante de plantillas. Producir un conjunto coherente de modelos y plantillas para documentar los requisitos.
Documentar dependencias . Documentar las dependencias e interrelaciones entre los requisitos, así como las suposiciones y las congregaciones.

Temas de análisis de requisitos

Identificación de las partes interesadas

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

cualquiera que opere el sistema (operadores normales y de mantenimiento)
cualquier persona que se beneficie del sistema (beneficiarios funcionales, políticos, financieros y sociales)
cualquier persona involucrada en la compra o adquisición del sistema. En una organización de productos de mercado masivo, la gestión de productos, el marketing 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 (reguladores financieros, de seguridad y otros).
personas u organizaciones que se oponen al sistema (partes interesadas negativas; ver también caso de uso indebido )
organizaciones responsables de los sistemas que interactúan con el sistema en diseño.
aquellas organizaciones que se integran horizontalmente con la organización para la que el analista está diseñando el sistema.

Sesiones de desarrollo de requisitos conjuntos (JRD)

Los requisitos a menudo tienen implicaciones multifuncionales que son desconocidas para los interesados individuales y, a menudo, se pasan por alto o se definen de forma incompleta durante las entrevistas con los interesados. Estas implicaciones multifuncionales se pueden obtener mediante la realización de sesiones de JRD en un entorno controlado, facilitado por un facilitador capacitado (analista de negocios), en el que 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, liberando al Analista de Negocios para que dirija la discusión en una dirección que genere los requisitos apropiados que cumplan con el objetivo de la sesión.

Las sesiones de JRD son análogas a las sesiones de diseño de aplicaciones conjuntas . En el primero, las sesiones provocan requisitos que guían el diseño, mientras que en el segundo se obtienen las características específicas del diseño que deben implementarse para satisfacer los requisitos planteados.

Listas de requisitos de estilo de contrato

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

Una metáfora apropiada sería una lista de compras extremadamente larga. Tales listas están muy desfavorecidas en el análisis moderno; ya que han resultado espectacularmente fracasados en la consecución de sus objetivos; pero todavía se ven hasta el día de hoy.

Fortalezas

Proporciona una lista de verificación de requisitos.
Proporcione un contrato entre los patrocinadores del proyecto y los desarrolladores.
Para un sistema grande, puede proporcionar una descripción de alto nivel a partir de la cual se pueden derivar requisitos de nivel inferior.

Debilidades

Estas listas pueden ocupar cientos de páginas. No pretenden servir como una descripción fácil de leer de la aplicación deseada.
Estas listas de requisitos resumen todos los requisitos y, por lo tanto, hay poco contexto. El analista de negocios puede incluir el contexto de los requisitos en la documentación de diseño adjunta.
- Esta abstracción no pretende describir cómo los requisitos encajan o funcionan juntos.
- Es posible que la lista no refleje las relaciones y dependencias entre los requisitos. Si bien una lista facilita la priorización de cada elemento individual, eliminar un elemento fuera de contexto puede inutilizar un caso de uso completo o un requisito comercial.
- La lista no reemplaza la necesidad de revisar los requisitos cuidadosamente con las partes interesadas para obtener una mejor comprensión compartida de las implicaciones para el diseño del sistema / aplicación deseado.
La simple creación de una lista no garantiza que esté completa. El analista de negocios debe hacer un esfuerzo de buena fe para descubrir y recopilar una lista sustancialmente completa y confiar en las partes interesadas para señalar los requisitos que faltan.
Estas listas pueden crear un falso sentido de entendimiento mutuo entre las partes interesadas y los desarrolladores; Los analistas comerciales son fundamentales para el proceso de traducción.
Es casi imposible descubrir todos los requisitos funcionales antes de que comience el proceso de desarrollo y prueba. Si estas listas se tratan como un contrato inmutable, los requisitos que surgen en el proceso de Desarrollo pueden generar una solicitud de cambio controvertida.

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 objetivos comerciales reales. Las partes interesadas y los desarrolladores pueden entonces 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 medidos y críticos, la creación rápida de prototipos y las fases breves de desarrollo iterativo pueden proceder para ofrecer valor real a las partes interesadas mucho antes de que el proyecto haya terminado a la mitad.

Prototipos

Un prototipo es un programa de computadora que exhibe una parte de las propiedades de otro programa de computadora, lo que permite a los usuarios visualizar una aplicación que aún no se ha construido. 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 se verá el sistema. Los prototipos facilitan la toma de decisiones de diseño, porque los aspectos de la aplicación se pueden ver y compartir antes de que se compile. Con la introducción de prototipos, se observaron a menudo mejoras importantes en la comunicación entre usuarios y desarrolladores. Las primeras vistas de las aplicaciones provocaron menos cambios posteriores y, por lo tanto, redujeron considerablemente los costos generales.

Los prototipos pueden ser diagramas planos (a menudo denominados wireframes ) o aplicaciones de trabajo que utilizan funciones sintetizadas. Los wireframes se crean en una variedad de documentos de diseño gráfico y, a menudo, eliminan todos los colores del diseño (es decir, utilizan una paleta de colores en escala de grises) en los casos en que se espera que el software final tenga un diseño gráfico aplicado. Esto ayuda a evitar confusiones sobre si el prototipo representa el aspecto 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 implican software, ya sea nuevo o modificado. 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 generalmente evitan la jerga técnica, prefiriendo en su lugar el idioma del usuario final o experto en el dominio . Los casos de uso a menudo son coautores de los ingenieros de requisitos y las 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 los usuarios deben trabajar con el software o el sistema. Los casos de uso no deben describir el funcionamiento interno del sistema, ni deben 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 con respecto a las necesidades comerciales del estado actual y la evaluación de estas necesidades para determinar y especificar lo que se requiere para satisfacer las necesidades dentro del alcance de la solución en foco. El descubrimiento, el análisis y la especificación mueven la comprensión de un estado actual tal cual a un estado futuro futuro. La especificación de requisitos puede cubrir toda la amplitud y profundidad del estado futuro que se realizará, o podría apuntar a brechas específicas para llenar, como errores de sistema de software prioritarios para corregir y mejoras para realizar. Dado que cualquier proceso empresarial grande casi siempre emplea software y sistemas de datos y tecnología, la especificación de requisitos a menudo se asocia con compilaciones 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 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 formas. Las siguientes son categorizaciones comunes de requisitos que se relacionan con la gestión técnica:

Requerimientos del cliente

Declaraciones de hechos y supuestos que definen las expectativas del sistema en términos de los objetivos de la misión, el entorno, las limitaciones y las 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 implementación operativa : ¿Dónde se utilizará el sistema?
Perfil o escenario de la misión : ¿Cómo logrará el sistema su objetivo de misión?
Rendimiento y parámetros relacionados : ¿Cuáles son los parámetros críticos del sistema para cumplir la misión?
Entornos de utilización : ¿Cómo se utilizarán los distintos componentes del sistema?
Requisitos de eficacia : ¿Cuán eficaz o eficiente debe ser el sistema en el desempeño de su misión?
Ciclo de vida operativo : ¿Cuánto tiempo estará en uso el sistema por parte del usuario?
Entorno : ¿Qué entornos se espera que opere el sistema de manera eficaz?

Requisitos arquitectónicos: Los requisitos arquitectónicos explican lo que se debe hacer al identificar la arquitectura de sistemas necesaria de un sistema .
Requisitos estructurales: Los requisitos estructurales explican lo que se debe hacer al identificar la estructura necesaria de un sistema.
Requisitos de comportamiento: Los requisitos de comportamiento explican lo que se debe hacer al identificar el comportamiento necesario de un sistema.
Requerimientos funcionales: Los requisitos funcionales explican lo que se debe hacer mediante la identificación de 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.
requerimientos 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 desempeño: La medida en que debe ejecutarse una misión o función; generalmente medido en términos de cantidad, calidad, cobertura, oportunidad o disponibilidad. Durante el análisis de requisitos, los requisitos de rendimiento (qué tan bien debe realizarse) 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.
Requerimientos de diseño: Los requisitos de "construir para", "codificar para" y "comprar para" para productos y los requisitos de "cómo ejecutar" para procesos expresados en paquetes de datos técnicos y manuales técnicos.
Requisitos derivados: Requisitos implícitos o transformados a partir de un requisito de nivel superior. Por ejemplo, un requisito de largo alcance o alta velocidad puede resultar en un requisito de diseño de bajo peso.
Requisitos asignados: Un requisito que se establece dividiendo o asignando un requisito de alto nivel en varios requisitos de nivel inferior. Ejemplo: Un artículo de 100 libras que consta de dos subsistemas puede resultar en requisitos de peso de 70 libras y 30 libras para los dos artículos de nivel inferior.

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

Problemas de análisis de requisitos

Problemas 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 comprometerán con un conjunto de requisitos escritos
Los usuarios insisten en nuevos requisitos después de que se hayan fijado el costo y el calendario
La comunicación con los usuarios es lenta
Los usuarios a menudo no participan en las reseñas o no pueden hacerlo.
Los usuarios son técnicamente poco sofisticados
Los usuarios no comprenden 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 ha iniciado el desarrollo del sistema o del producto.

Problemas de ingeniero / desarrollador

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

Una inclinación natural hacia la escritura de código puede llevar a que la implementación comience antes de que se complete el análisis de requisitos, lo que puede resultar en cambios de código para cumplir con los requisitos reales una vez que se conocen.
El personal técnico y los usuarios finales pueden tener vocabularios diferentes. En consecuencia, pueden creer erróneamente que están en perfecto acuerdo hasta que se suministre el producto terminado.
Los ingenieros y desarrolladores pueden intentar hacer que los requisitos se ajusten 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 están pensados como soluciones a los problemas encontrados con métodos anteriores.

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

pizarrones electrónicos para esbozar flujos de aplicaciones y probar alternativas
capacidad para capturar la lógica empresarial y las necesidades de datos
capacidad para generar prototipos de alta fidelidad que imitan de cerca la aplicación final
interactividad
capacidad para agregar requisitos contextuales y otros comentarios
capacidad para que los usuarios remotos y distribuidos ejecuten e interactúen con la simulación

Ver también

Referencias

Bibliografía

Brian Berenbach; Daniel Paulish; Juergen Katzmeier; Arnold Rudorfer (2009). Ingeniería de requisitos de software y sistemas: en la práctica . Nueva York: McGraw-Hill Professional. ISBN 978-0-07-160547-2.
Hay, David C. (2003). Análisis de requisitos: de la visión empresarial a la arquitectura (1ª ed.). Upper Saddle River, Nueva Jersey: Prentice Hall. ISBN 0-13-028228-6.
Laplante, Phil (2009). Ingeniería de Requisitos para Software y Sistemas (1ª ed.). Redmond, WA: CRC Press. ISBN 978-1-4200-6467-4.
McConnell, Steve (1996). Desarrollo rápido: Taming Wild Software Schedules (1ª ed.). Redmond, WA: Microsoft Press. ISBN 1-55615-900-5.
Nuseibeh, B .; Easterbrook, S. (2000). Ingeniería de requisitos: una hoja de ruta (PDF) . ICSE '00. Actas de la conferencia sobre el futuro de la ingeniería de software . págs. 35–46. CiteSeerX 10.1.1.131.3116 . doi : 10.1145 / 336512.336523 . ISBN 1-58113-253-0.
Andrew Stellman y Jennifer Greene (2005). Gestión de proyectos de software aplicado . Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8.
Karl Wiegers y Joy Beatty (2013). Requisitos de software (3ª ed.). Redmond, WA: Microsoft Press. ISBN 978-0-7356-7966-5.

enlaces externos

Entrada de enciclopedia revisada por pares sobre ingeniería y análisis de requisitos
Proceso de definición de los requisitos de las partes interesadas de la Universidad de Adquisición de Defensa --- Proceso de definición de los requisitos de las partes interesadas en la Wayback Machine (archivado el 23 de diciembre de 2015)
Guía del documento de requisitos del sistema MIL-HDBK 520

Languages

In other projects