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 el software. o requisitos del 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 ser documentados, procesables, mensurables, comprobables, [4] rastreables, [4] relacionados con 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 necesaria ]
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. [ cita necesaria ] La calidad de los requisitos se puede mejorar mediante estos y otros métodos:
Consulte Análisis de partes interesadas para obtener un análisis de las personas u organizaciones (entidades legales como empresas y 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:
Los requisitos a menudo tienen implicaciones interfuncionales que son desconocidas para las partes interesadas individuales 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 haber un escriba dedicado presente para documentar la discusión, liberando 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.
Una forma tradicional de documentar los requisitos han sido las listas de requisitos tipo contrato. 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 [ cita requerida ] ; pero todavía se ven hasta el día de hoy.
Como alternativa a las listas de requisitos, Agile Software Development utiliza historias de usuarios para sugerir requisitos en el lenguaje cotidiano.
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 terminado la mitad.
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. [ cita necesaria ]
Los prototipos pueden ser diagramas planos (a menudo denominados wireframes ) 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 un diseño gráfico . Esto ayuda a evitar confusiones sobre si el prototipo representa la apariencia visual final de la aplicación. [ cita necesaria ]
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 empresarial 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 cómo 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.
La especificación de requisitos es la síntesis de los hallazgos del descubrimiento con respecto a 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.
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 funciones detalladas. Suelen ser capacidades de alto nivel (software y/o hardware) que se necesitan para lograr un resultado empresarial.
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: [1]
Los requisitos arquitectónicos explican lo que se debe hacer identificando la arquitectura de sistemas necesaria de un sistema .
Los requisitos estructurales explican lo que se debe hacer identificando la estructura necesaria de un sistema.
Los requisitos de comportamiento explican lo que se debe hacer 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 realizar. El análisis de requisitos funcionales se utilizará como funciones 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.
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. [1]
Los requisitos de "construir hasta", "codificar hasta" y "comprar hasta" para productos y los requisitos de "cómo ejecutar" para procesos se expresan en paquetes de datos técnicos y manuales técnicos. [1]
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. [1]
Un requisito 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. [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 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 producto.
Los posibles problemas causados por ingenieros y desarrolladores durante el análisis de requisitos son:
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 "prueben en el mercado" antes de que se produzca cualquier código. Lo mejor de estas herramientas ofrece:
Es ampliamente reconocido dentro de la industria del software que los proyectos de ingeniería de software son críticamente vulnerables cuando estas actividades se realizan mal.
[1]
