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 ]
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:
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:
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.
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.
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]
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:
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 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:
En la industria del software se reconoce ampliamente que los proyectos de ingeniería de software son extremadamente vulnerables cuando estas actividades se realizan de manera deficiente.
[1]
