Análisis de requisitos

Este artículo tiene varios problemas. Ayúdenos a mejorarlo o a discutir estos problemas en la página de discusión . ( Aprenda cómo y cuándo eliminar estos mensajes ) Este artículo necesita citas adicionales para su verificación .Por favor, ayude a mejorar este artículo añadiendo citas de fuentes confiables . El material sin fuentes puede ser cuestionado y eliminado. Buscar fuentes:  «Análisis de requisitos» – noticias  · periódicos  · libros  · académico  · JSTOR ( Diciembre 2011 )( Aprenda cómo y cuándo eliminar este mensaje ) Este artículo está en formato de lista pero puede leerse mejor como prosa .Si es necesario, puedes ayudar a convertir este artículo. Hay ayuda para editarlo . ( Julio de 2022 ) ( Aprenda cómo y cuándo eliminar este mensaje )

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 , analizando, documentando, validando y gestionando los requisitos del software o sistema . ^[2]

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

Conceptualmente, el análisis de requisitos incluye tres tipos de actividades: ^{[ cita requerida ]}

• Recopilación de requisitos (por ejemplo, el acta de constitución o la definición del proyecto), documentación de procesos de negocio y entrevistas con las partes interesadas. A esto también se lo denomina a veces 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.
• Análisis de 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 el dimensionamiento de los requisitos.

El análisis de requisitos puede ser un proceso largo y agotador durante el cual se involucran 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 comprenden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Estas pueden incluir el desarrollo de escenarios (representados como historias de usuario en métodos ágiles ), la identificación de casos de uso , el uso de la observación del lugar de trabajo o la etnografía , la realización de entrevistas o grupos de discusión (más acertadamente denominados en este contexto como talleres de requisitos o sesiones de revisión de requisitos) 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. ^{[5] [6]} La calidad de los requisitos se puede mejorar a través de estos y otros métodos:

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

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (October 2009) (Learn how and when to remove this message)

Consulte el análisis de las partes interesadas para conocer las personas u organizaciones (entidades jurídicas como empresas y organismos de normalización) que tienen un interés válido en el sistema y que pueden verse afectadas por él de forma directa o indirecta.

En la década de 1990, un nuevo enfoque importante fue 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 incluyen:

• Cualquier persona 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 para el mercado masivo, la gestión de productos, el marketing y, a veces, el departamento de ventas actúan como consumidores sustitutos (clientes del mercado masivo) para guiar el desarrollo del producto.
• Organizaciones que regulan aspectos del sistema (reguladores financieros, de seguridad y otros)
• personas u organizaciones opuestas al sistema (partes interesadas negativas; véase 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 cual el analista está diseñando el sistema.

Los requisitos suelen tener implicaciones interfuncionales que son desconocidas para las partes interesadas individuales y que a menudo se pasan por alto o se definen de forma incompleta durante las entrevistas con las partes interesadas. Estas implicaciones interfuncionales 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 debates para obtener requisitos, analizar sus detalles y descubrir implicaciones interfuncionales. Debe estar presente un escriba dedicado a documentar el debate, lo que libera al analista de negocios para dirigir el debate en una dirección que genere requisitos adecuados 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 las primeras, las sesiones plantean requisitos que guían el diseño, mientras que en las segundas se plantean las características de diseño específicas que se implementarán para satisfacer los requisitos planteados.

Una forma tradicional de documentar los requisitos ha sido mediante listas de requisitos de tipo contractual. En un sistema complejo, dichas listas pueden tener cientos de páginas.

Una metáfora adecuada sería la de una lista de compras extremadamente larga. Este tipo de listas están muy en desuso en el análisis moderno, ya que han demostrado ser espectacularmente ineficaces para lograr sus objetivos ^{[ cita requerida ]} , pero todavía se las ve hoy en día.

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

• Estas listas pueden ocupar cientos de páginas y no tienen como objetivo servir como descripción fácil de leer de la aplicación deseada.
• Estas listas de requisitos abstraen 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 que acompaña al documento.
  • 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, eliminar un elemento fuera de contexto puede hacer que todo un caso de uso o requisito comercial resulte inútil.
  • La lista no reemplaza la necesidad de revisar cuidadosamente los requisitos con las partes interesadas para lograr 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 que las partes interesadas señalen los requisitos que faltan.
• Estas listas pueden crear una falsa sensación de entendimiento mutuo entre las partes interesadas y los desarrolladores; los analistas de negocios son fundamentales en 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 surjan en el proceso de desarrollo pueden generar una solicitud de cambio controvertida.

Como alternativa a las listas de requisitos, el desarrollo de software ágil utiliza historias de usuario para sugerir requisitos en lenguaje cotidiano.

Las mejores prácticas toman la lista de requisitos compuesta simplemente como pistas y preguntan repetidamente "¿por qué?" hasta que se descubren los propósitos comerciales reales. Las partes interesadas y los desarrolladores pueden entonces idear 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 mensurables, se pueden realizar fases rápidas de creación de prototipos y desarrollo iterativo breve para ofrecer valor real a las partes interesadas mucho antes de que el proyecto haya terminado la mitad.

Un prototipo es un programa informático que muestra una parte de las propiedades de otro programa informático, 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 construya la aplicación. Con la introducción de prototipos, se observaron a menudo importantes mejoras en la comunicación entre usuarios y desarrolladores. Las primeras visualizaciones de las aplicaciones dieron lugar a menos cambios posteriores y, por lo tanto, redujeron considerablemente los costos generales. ^{[ cita requerida ]}

Los prototipos pueden ser diagramas planos (a menudo denominados wireframes ) o aplicaciones funcionales que utilizan funcionalidades sintetizadas. Los wireframes se realizan 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 que se espera que se aplique un diseño gráfico al software final . Esto ayuda a evitar confusiones sobre si el prototipo representa el aspecto visual final de la aplicación. ^{[ cita requerida ]}

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

Los casos de uso son herramientas engañosamente simples para describir el comportamiento del software o los sistemas. Un caso de uso contiene una descripción textual de cómo se supone que los usuarios deben trabajar con el software o el 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.

This section needs expansion. You can help by adding to it. (February 2018)

La especificación de requisitos es la síntesis de los hallazgos de descubrimiento sobre las necesidades actuales del negocio 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 cuestión. El descubrimiento, el análisis y la especificación trasladan la comprensión de un estado actual tal como está a un estado futuro que se desea alcanzar. La especificación de requisitos puede cubrir toda la amplitud y profundidad del estado futuro que se desea alcanzar, o puede apuntar a brechas específicas que se deben llenar, como errores prioritarios del sistema de software que se deben corregir y mejoras que se deben realizar. Dado que cualquier proceso empresarial de gran tamaño casi siempre emplea sistemas y tecnología de software y datos, la especificación de requisitos a menudo se asocia con la creació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.

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

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

Enunciados de hechos y supuestos que definen las expectativas del sistema en términos de objetivos de misión, entorno, restricciones y medidas de eficacia e idoneidad (MOE/MOS). Los clientes son aquellos que realizan las ocho funciones primarias 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 a las preguntas planteadas en el siguiente listado: ^[1]

• Distribución o despliegue operativo : ¿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 : ¿Qué tan efectivo o eficiente debe ser el sistema en el desempeño de su misión?
• Ciclo de vida operativo : ¿Durante cuánto tiempo el usuario utilizará el sistema?
• Entorno : ¿En qué entornos se espera que el sistema funcione de manera eficaz?

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

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

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

Los requisitos funcionales explican lo que se debe hacer identificando la tarea, acción o actividad necesaria que se debe llevar a cabo. El análisis de requisitos funcionales se utilizará como función de nivel superior para el análisis funcional. ^[1]

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

El grado en que se debe ejecutar una misión o función se mide generalmente en términos de cantidad, calidad, cobertura, puntualidad o preparación. Durante el análisis de requisitos, los requisitos de desempeño (qué tan bien se debe realizar) se desarrollarán de manera interactiva en todas las funciones identificadas en función de los factores del ciclo de vida del sistema; y se caracterizarán 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. ^[1]

Los requisitos de "construcción", "codificación" y "compra" para los productos y los requisitos de "cómo ejecutar" para los procesos se expresan en paquetes de datos técnicos y manuales técnicos. ^[1]

Requisitos que se deducen o se transforman 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. ^[1]

Un requisito se establece dividiendo o asignando de otro modo un requisito de alto nivel en varios requisitos de nivel inferior. Ejemplo: un artículo de 100 libras que consta de dos subsistemas puede dar como resultado requisitos de peso de 70 libras y 30 libras para los dos artículos de nivel inferior. ^[1]

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

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

• Los usuarios no entienden lo que quieren o 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 cronograma
• La comunicación con los usuarios es lenta
• Los usuarios a menudo no participan en las revisiones o son incapaces de hacerlo.
• Los usuarios son técnicamente poco 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.

Los posibles problemas que pueden causar los 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 potencialmente puede resultar en cambios en el 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 y, en consecuencia, pueden creer equivocadamente que están en perfecto acuerdo hasta que se les entrega 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.

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

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 de software ágil , también están pensadas como soluciones a los problemas surgidos 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 salvar 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 a modo de prueba" antes de producir cualquier código. Las mejores de estas herramientas ofrecen:

• Pizarras electrónicas para esbozar flujos de aplicaciones y probar alternativas
• Capacidad de capturar la lógica empresarial y las necesidades de datos
• Capacidad de generar prototipos de alta fidelidad que imiten fielmente la aplicación final
• interactividad
• Capacidad de agregar requisitos contextuales y otros comentarios
• Capacidad para que usuarios remotos y distribuidos ejecuten e interactúen con la simulación

^[1]

Wikimedia Commons tiene medios relacionados con Análisis de requisitos .

• Entrada de enciclopedia revisada por pares sobre ingeniería y análisis de requisitos
• Proceso de definición de requisitos de las partes interesadas de la Universidad de Adquisiciones de Defensa ^{[ enlace roto ]} --- Proceso de definición de requisitos de las partes interesadas en Wayback Machine (archivado el 23 de diciembre de 2015)
• Guía de documentos sobre requisitos de sistemas MIL-HDBK 520