Análisis de requisitos

Consulte el análisis de las partes interesadas para obtener información sobre las personas u organizaciones (entidades jurídicas como empresas y organismos de normalización) que tienen un interés legítimo en el sistema. Estas pueden verse afectadas por él, ya sea directa o indirectamente.

Un nuevo enfoque importante en la década de 1990 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 de consumo masivo, la gestión de producto, el marketing y, a veces, las ventas actúan como consumidores sustitutos (clientes del mercado masivo) para orientar 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; véase también Caso de mal uso )
• organizaciones responsables de los sistemas que interactúan con el sistema en fase de 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 desconocidas para las partes interesadas y, a menudo, se pasan por alto o se definen de forma incompleta durante las entrevistas. Estas implicaciones interfuncionales pueden identificarse mediante sesiones de JRD (Requerimientos de Requisitos Conjuntos) en un entorno controlado, facilitadas por un facilitador capacitado (analista de negocios). En estas sesiones, las partes interesadas participan en debates para obtener los requisitos, analizar sus detalles y descubrir las implicaciones interfuncionales. Un secretario se encargará de documentar la discusión, lo que permitirá al analista de negocios dirigirla hacia la generación de requisitos adecuados que cumplan con el objetivo de la sesión.

Las sesiones JRD son análogas a las sesiones de diseño conjunto de aplicaciones . En las primeras, las sesiones recogen los requisitos que guían el diseño, mientras que en las segundas se recogen las características de diseño específicas que deben implementarse para satisfacer los requisitos recogidos.

Una forma tradicional de documentar los requisitos ha sido mediante listas de requisitos con formato de contrato. En un sistema complejo, dichas listas de requisitos pueden ocupar cientos de páginas.

Una metáfora apropiada sería una lista de la compra larguísima. Este tipo de listas están muy mal vistas en el análisis moderno, ya que han demostrado ser un rotundo fracaso en el cumplimiento de sus objetivos ; sin embargo, todavía se ven hoy en día.

Las mejores prácticas consideran la lista de requisitos como meras pistas y se preguntan repetidamente "¿por qué?" hasta descubrir los objetivos reales del negocio. Los interesados ​​y los desarrolladores pueden entonces diseñar pruebas para medir el grado de avance de cada objetivo. Estos objetivos cambian más lentamente que la larga lista de requisitos específicos pero no cuantificados. Una vez establecido un pequeño conjunto de objetivos críticos y cuantificables, se pueden llevar a cabo prototipados rápidos y fases de desarrollo iterativas cortas para generar valor real para los interesados ​​mucho antes de que el proyecto haya llegado a su mitad.

Un prototipo es un programa informático que muestra parte de las propiedades de otro programa, permitiendo a los usuarios visualizar una aplicación que aún no se ha desarrollado. Un ejemplo común de prototipo es la maqueta , que ayuda a los futuros usuarios y otras partes interesadas a hacerse una idea de cómo será el sistema. Los prototipos facilitan la toma de decisiones de diseño, ya que permiten visualizar y compartir aspectos de la aplicación antes de su desarrollo. La introducción de prototipos suele conllevar mejoras significativas en la comunicación entre usuarios y desarrolladores. Las primeras versiones de las aplicaciones reducen la necesidad de realizar cambios posteriores y, por lo tanto, disminuyen considerablemente los costes generales.

Los prototipos pueden ser diagramas planos (a menudo denominados wireframes ) o aplicaciones funcionales con funcionalidades sintetizadas. Los wireframes se crean en diversos documentos de diseño gráfico y, con frecuencia, se elimina todo el color del diseño (es decir, se utiliza una paleta de grises) cuando se espera que el software final tenga un diseño gráfico . Esto ayuda a evitar confusiones sobre si el prototipo representa la apariencia visual final de la aplicación.

Un caso de uso es una estructura para documentar los requisitos funcionales de un sistema, generalmente de software, ya sea nuevo o en proceso de modificación. Cada caso de uso proporciona un conjunto de escenarios que describen cómo el sistema debe interactuar con un usuario humano u otro sistema para lograr un objetivo empresarial específico. Los casos de uso suelen evitar la jerga técnica, prefiriendo el lenguaje del usuario final o del experto en el dominio . Con frecuencia, los ingenieros de requisitos y las partes interesadas colaboran en la elaboración de los casos de uso.

Los casos de uso son herramientas aparentemente sencillas para describir el comportamiento de software o sistemas. Un caso de uso contiene una descripción textual de cómo se espera que los usuarios interactúen con el software o sistema. Los casos de uso no deben describir el funcionamiento interno del sistema ni explicar cómo se implementará. En cambio, muestran los pasos necesarios para realizar una tarea sin presuposiciones secuenciales.

La especificación de requisitos es la síntesis de los hallazgos del descubrimiento sobre las necesidades empresariales actuales y la evaluación de estas necesidades para determinar y especificar lo que se requiere para satisfacerlas dentro del alcance de la solución en cuestión. El descubrimiento, el análisis y la especificación permiten pasar de la comprensión del estado actual a un estado futuro deseado. La especificación de requisitos puede abarcar la amplitud y profundidad del estado futuro que se pretende alcanzar, o bien centrarse en deficiencias específicas que deben subsanarse, como errores prioritarios del sistema de software que deben corregirse y mejoras que deben implementarse. Dado que cualquier proceso empresarial de gran envergadura casi siempre emplea sistemas y tecnologías de software y datos, la especificación de requisitos suele asociarse con la creación de sistemas de software, las compras, las estrategias de computación en la nube, el 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 la formación, las guías de documentación, el personal, las estrategias de marketing, el equipo, los suministros, etc.

Declaraciones de objetivos a nivel empresarial, sin referencia a funcionalidades detalladas. Se trata generalmente de capacidades de alto nivel (software y/o hardware) necesarias para lograr un resultado empresarial.

Declaraciones de hechos y supuestos que definen las expectativas del sistema en términos de objetivos de la 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 la siguiente lista: ^{[ 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 deben utilizar los distintos componentes del sistema?
• Requisitos de eficacia : ¿Qué tan eficaz o eficiente debe ser el sistema para cumplir su misión?
• Ciclo de vida operativo : ¿Cuánto tiempo utilizará el sistema el usuario?
• Entorno : ¿En qué entornos se espera que el sistema funcione de manera eficaz?

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

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

Los requisitos funcionales explican qué se debe hacer al identificar la tarea, acción o actividad necesaria que debe realizarse. El análisis de requisitos funcionales se utilizará como las funciones de nivel superior para el análisis funcional. ^{[ 1 ]}

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

El grado de ejecución de una misión o función se mide generalmente en términos de cantidad, calidad, cobertura, puntualidad 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, basándose en los factores del ciclo de vida del sistema, y ​​se caracterizarán en términos del grado de certeza de 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, así como 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 resultar en 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 podría resultar en requisitos de peso de 70 libras y 30 libras para los dos artículos de nivel inferior. ^{[ 1 ]}

Entre los modelos de categorización de requisitos más conocidos se encuentran FURPS y FURPS+, desarrollados en Hewlett-Packard .

Steve McConnell, en su libro Desarrollo rápido , detalla varias maneras en que los usuarios pueden obstaculizar 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 a un conjunto de requisitos escritos.
• Los usuarios insisten en nuevos requisitos una vez que se han fijado el costo y el cronograma.
• La comunicación con los usuarios es lenta.
• Los usuarios a menudo no participan en las reseñas o son incapaces de hacerlo.
• Los usuarios carecen de conocimientos técnicos avanzados.
• Los usuarios no entienden el proceso de desarrollo.
• Los usuarios desconocen la tecnología actual.

Esto puede dar lugar a que los requisitos del usuario cambien continuamente incluso cuando ya se haya iniciado el desarrollo del sistema o del producto.

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

• La inclinación natural a escribir código puede llevar a que la implementación comience antes de que se complete el análisis de requisitos, lo que podría resultar en cambios en el código para cumplir con los requisitos reales una vez que se conozcan.
• El personal técnico y los usuarios finales pueden tener vocabularios diferentes. Por consiguiente, pueden creer erróneamente que están completamente de acuerdo hasta que se les entrega el producto terminado.
• Es posible que los ingenieros y desarrolladores intenten adaptar los requisitos a un sistema o modelo existente, en lugar de desarrollar un sistema específico para las necesidades del cliente.

Una de las soluciones que se han intentado para solucionar los problemas de comunicación ha sido contratar 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 Unificado de Modelado (UML), los casos de uso y el desarrollo ágil de software, también pretenden ser soluciones a los problemas que se presentaban con los métodos anteriores.

Además, ha surgido en el mercado una nueva clase de herramientas de simulación o definición de aplicaciones. Estas herramientas están diseñadas para superar la brecha de comunicación entre los usuarios de negocio y el departamento de TI, y también para permitir que las aplicaciones se sometan a pruebas de mercado antes de que se genere cualquier código. Las mejores de estas herramientas ofrecen:

• Pizarras electrónicas para esbozar flujos de aplicación 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 para añadir requisitos contextuales y otros comentarios.
• capacidad para que los usuarios remotos y distribuidos ejecuten e interactúen con la simulación