Este Tutorial Explica Qué es el Análisis de Requisitos, Los Pasos de Análisis de Requisitos, Los Ejemplos y los Objetivos de la Recopilación de Requisitos en SDLC:
El desarrollo de software es una tarea gigantesca que crea un producto de software que funciona.
El producto de software está construido según los requisitos del cliente. En su mayoría, este producto de software cumple con lo que el cliente/usuario final había esperado, mientras que a veces este producto no cumple completamente con lo que el cliente/usuario final había esperado.
¿Qué Es el Análisis de Requisitos?
Entendamos el Análisis de requisitos con la ayuda de un ejemplo.
Expectativas del cliente/usuario final:
Recepción del cliente/usuario final:
Ya que puede analizar a partir de las imágenes anteriores que hay un desajuste en el producto final con las expectativas del cliente. Esto podría deberse a innumerables razones, a saber. implementación incorrecta de los requisitos del cliente, diseño defectuoso, comprensión errónea de los requisitos del cliente por parte de los programadores y el equipo de calidad, etc.
Sin embargo, como puede ver, ya sea por cualquier motivo de entrega incorrecta del producto, la razón principal es el requisito. Por lo tanto, si se hubieran realizado la comprensión, captura, implementación y prueba correctas de los requisitos, habría ayudado a mitigar la entrega errónea e incompleta del producto al cliente/usuario final.
Una buena entrega de productos requiere la recopilación correcta de requisitos, el examen eficiente de los requisitos que se recopilan y, finalmente, una documentación clara de los requisitos, como condición previa. Todo este proceso también se denomina Análisis de Requisitos en el Ciclo de Vida de Desarrollo de Software (SDLC)
Etapas/Pasos de Análisis de requisitos
Como puede ver, el análisis de requisitos es la primera actividad en SDLC seguida de la Especificación Funcional, etc. El análisis de requisitos es un paso vital en SDLC, ya que resuena con las pruebas de aceptación que son críticas para la aceptación del producto por parte de los clientes.
En este tutorial, explicaremos cómo se realiza el análisis de requisitos en SDLC. También veremos los diversos pasos involucrados, los resultados, los desafíos y las medidas correctivas en el análisis de requisitos.
El análisis de requisitos comienza con:
- Recolección de requisitos, que también se llama como elicitación.
- A continuación se analizan los requisitos recopilados para comprender la exactitud y viabilidad de convertir estos requisitos en un posible producto.
- Y, por último, documentar los requisitos recogidos.
#1) Recopilación de requisitos
Para asegurarse de que todos los pasos mencionados anteriormente se ejecutan adecuadamente, se deben recopilar requisitos claros, concisos y correctos del cliente. El cliente debe ser capaz de definir sus requisitos correctamente y el analista de negocio debe ser capaz de recoger de la misma manera que el cliente quiere transmitir.
Muchas veces no es posible que los analistas de negocios del cliente realicen la recopilación de requisitos de manera eficiente. Esto podría deberse a la dependencia de muchas personas relacionadas con el producto final esperado, las herramientas, el entorno, etc. Por lo tanto, siempre es una buena idea involucrar a todas las partes interesadas que podrían influir o ser influenciadas por el producto final.
El posible grupo de partes interesadas podría ser ingenieros de Calidad de Software (tanto de control de calidad como de control de calidad), cualquier proveedor externo que pueda proporcionar soporte en el proyecto, usuario final al que está destinado el producto, programadores de software, otro equipo dentro de la organización que pueda proporcionar un módulo o plataforma de software, bibliotecas de software, etc. para el desarrollo de productos.
Ejemplo: En una organización, desarrollan un producto ADAS (sistema de cámara de visión envolvente para un OEM de prestigio) que necesita una pila de autosares y binarios de cargador de arranque que se reciben de otro proveedor.
Involucrar a varias partes interesadas en la etapa de recopilación de requisitos ayuda a comprender varias dependencias entre sí y se podría evitar cualquier posible conflicto futuro.
A veces, es una buena idea crear un modelo prototipo del producto previsto y mostrarlo al cliente. Esta es una excelente manera de transmitir a los clientes qué producto esperan y cómo se verá más adelante. Esto ayuda al cliente a visualizar el producto que espera y le ayuda a llegar a requisitos claros.
La creación de este prototipo depende de dos tipos de producto:
- Un producto similar que los clientes pretendían, existe dentro de la organización.
- Nuevo producto a desarrollar.
(i) En el primer caso, es más fácil mostrar al cliente cómo se vería el producto final y cómo se desarrollaría. En ADAS automotriz, es posible mostrar a los clientes otro producto que ya está en el mercado y se desarrolló dentro de la organización.
Por ejemplo, un sistema de cámara de visión envolvente desarrollado para un OEM (GM, Volkswagen, BMW, etc.).) y se puede mostrar a otro OEM.
Tenga en cuenta que no es aconsejable mostrar el producto/proto producto al cliente que está en desarrollo, ya que puede violar el Acuerdo de Confidencialidad firmado con otro cliente para el que se está desarrollando ese producto. También puede resultar en una pelea legal innecesaria.
Otro ejemplo podría ser el del sistema de infoentretenimiento, que está siendo desarrollado por la organización y que ya está en el mercado. Los analistas de negocios y otras partes interesadas dentro de una organización pueden planificar una demostración de taller para el cliente, mostrando sistemas de infoentretenimiento con HMI tangible, puertos de conector de dispositivo, caja de arena, etc.
Esto ayudará al cliente a comprender cómo se vería el producto final y proporcionar sus requisitos mucho más claramente.
(ii) El segundo caso se puede lograr creando un modelo de trabajo básico haciendo codificación y ensamblaje simples (la mayoría de las características aquí están codificadas en programas de software), o creando un diagrama de flujo o diagrama que podría convencer al cliente de cómo se vería el producto.
En cualquier caso, sería un respiro para el proceso de recopilación de requisitos, ya que el cliente ahora sabe lo que quiere.
El analista de negocios ahora puede organizar reuniones formales de obtención de requisitos, donde se podría invitar a todas las partes interesadas y, por lo tanto, puede anotar los diversos requisitos proporcionados por el cliente (en algunos casos, si las partes interesadas son más numerosas, se podría designar un escriba separado para anotar los requisitos del cliente o las historias de los usuarios para que el analista de negocios se concentre en moderar la reunión).
Los requisitos recopilados pueden ser en forma de historias de usuario (en desarrollo ágil), casos de uso, documentos de lenguaje natural del cliente, diagramas, diagramas de flujo, etc. Las historias de usuario se están volviendo populares en el ciclo de vida del desarrollo de software de hoy en día. Las historias de usuario son básicamente un conjunto de entradas de clientes en su lenguaje natural.
Ejemplo de recopilación de requisitos: En el sistema de cámara de visión envolvente ADAS, una posible historia de usuario podría ser:»Como usuario, debería ser capaz de ver lo que hay en el retrovisor de mi automóvil».
Podría haber muchas preguntas de» por qué » en cada historia de usuario, que ayudarán al cliente a proporcionar información más detallada sobre el requisito.
En la historia de usuario anterior, si un cliente dice» Como usuario, debería ser capaz de ver lo que hay en el retrovisor de mi automóvil», haciendo una pregunta» por qué «podría dar»Como usuario, debería ser capaz de ver lo que hay en el retrovisor de mi automóvil, para que pueda estacionar mi automóvil de manera segura».
Hacer la pregunta «por qué» también ayuda a crear requisitos objetivos y atómicos a partir de declaraciones de lenguaje natural gigantescas dadas por el cliente. Esto se puede implementar fácilmente más adelante en el código.
Otra forma de reunir el requisito es en forma de casos de uso. Un caso de uso es un enfoque paso a paso para lograr un determinado resultado. Esto no dice cómo funcionará el software en la entrada del usuario, sino que dice lo que se espera de las entradas del usuario.
Ejemplo:
#2) Análisis de los requisitos recopilados
Recopilación de requisitos posteriores, comienza el análisis de los requisitos. En esta etapa, varias partes interesadas se sientan y hacen una sesión de lluvia de ideas. Analizan los requisitos reunidos y buscan la viabilidad de implementarlos. Discuten entre sí y se resuelve cualquier ambigüedad.
Este paso es importante en el proceso de análisis de requisitos debido a las siguientes razones principales:
(i) El cliente puede proporcionar algunos requisitos que podrían ser imposibles de implementar debido a varias dependencias.
Ejemplo: Los clientes pueden solicitar la visualización envolvente del sistema de cámaras con una función de cámara de visión trasera que les ayudará a aparcar el coche. El cliente también puede solicitar la función de enganche de remolque que también utiliza la cámara trasera para funcionar.
Si el cliente indica que la cámara de visión trasera para asistencia en el estacionamiento debe funcionar en todo momento sin excepción, la función del remolque nunca funcionaría y viceversa.
(ii) Un analista de negocios podría haber entendido el requisito del cliente de manera diferente a como lo habría interpretado un programador.
Dado que los programadores piensan como expertos técnicos, siempre es posible que los requisitos del cliente se conviertan incorrectamente en especificaciones funcionales que luego se convertirán incorrectamente en documentos de arquitectura y diseño y posteriormente en código. El impacto es exponencial y, por lo tanto, debe comprobarse.
Una posible medida correctiva podría ser seguir un método ágil de desarrollo de software, seguir los casos de uso que proporciona el cliente, etc.
#3) Documentar los Requisitos analizados
Una vez que se realiza el análisis de los requisitos, comienza la documentación de los requisitos. Del análisis de los requisitos surgen varios tipos de requisitos.
Algunos de estos son:
(i) Especificación de requisitos del cliente.
(ii) Requisito de arquitectura de software.
Ejemplo:
(iii) Requisito de diseño de software.
Ejemplo:
(iv) Especificación de requisitos funcionales (derivada directamente de las especificaciones del cliente.)
Ejemplo: «Cuando el usuario toca el icono Bluetooth en la HMI de Infotainment, se debe mostrar la pantalla Bluetooth»
(v) Especificación de requisitos no funcionales (viz. rendimiento, estrés, carga, etc.).
Ejemplo: «Debería ser posible emparejar 15 dispositivos Bluetooth con el sistema de infoentretenimiento sin degradar el rendimiento del sistema».
(vi) Requisitos de interfaz de usuario.
Ejemplo: «En la pantalla del sintonizador FM, se debe proporcionar un botón para seleccionar diferentes estaciones»
Los requisitos anteriores se registran y documentan en herramientas de gestión de requisitos, como IBM DOORS, HP QC. A veces, las organizaciones tienen sus herramientas de gestión de requisitos personalizadas para reducir los costos.
Veamos ahora el proceso de convertir los requisitos de Negocio en Requisitos de Software (funcionales y no funcionales).
Convertir Requisitos de negocio en Requisitos de Software
Requisitos de negocio, como se mencionó anteriormente, son requisitos de alto nivel que hablan de lo que el usuario final quiere de una acción definida en el sistema de software. No es posible desarrollar todo el sistema de software basado en estos requisitos, ya que no se menciona una descripción detallada de cómo se implementará el sistema o componente de software.
Por lo tanto, los requisitos comerciales deben desglosarse en requisitos de software más detallados, que se detallarán más en los requisitos funcionales y no funcionales.
Para hacer esto, se pueden seguir los siguientes pasos:
- Divida los requisitos empresariales de alto nivel en historias de usuario detalladas.
- Derivar un diagrama de flujo para definir el flujo de actividades.
- Proporcionar la condición que justifica las historias de usuario derivadas.
- Diagramas de estructura metálica para explicar el flujo de trabajo de los objetos.
- Definir requisitos no funcionales fuera de los requisitos comerciales.
Comencemos por tomar un ejemplo de sistema de Infoentretenimiento automotriz.
El requisito comercial dice: «El usuario final debe poder acceder a la caja de widgets de navegación desde la HMI del sistema de infoentretenimiento y debe poder establecer la dirección de destino».
Por lo tanto, los pasos mencionados anteriormente se pueden implementar como:
#1) Divida los requisitos empresariales de alto nivel en historias de usuario detalladas.
Convirtamos este requisito de negocio en una historia de usuario de alto nivel, «Como usuario, debería poder acceder al cuadro de widget de navegación para poder ingresar la dirección de destino». Esta historia de usuario cuenta lo que necesita el usuario final. Trataremos de definir cómo implementar este requisito.
Comencemos por hacer posibles preguntas a esta visualización de historia de usuario.
- ¿Quiénes son los usuarios?
- ¿Cómo puedo acceder a la navegación, a bordo (desde la tarjeta SD) o desde el teléfono inteligente?
- ¿Qué tipo de entradas de destino puedo introducir?
- ¿Se me debe permitir ingresar el destino incluso cuando el automóvil está estacionado?
Estas son historias de usuarios de nivel más detallado derivadas de historias de usuarios de alto nivel y nos ayudarían a obtener más información sobre nuestros requisitos comerciales.
En este punto, podemos tomar una de las sub-historias de usuario y comenzar a cuestionar. Tomemos (no. 3):
- Puedo introducir entradas de destino como Coordenadas Geográficas, Dirección Postal, a través del Reconocimiento de Voz, etc.?
- ¿Necesito GPS para ingresar las coordenadas geográficas?
- ¿Puedo introducir la dirección de destino actual buscando en el historial de direcciones?
#2) Derivar un diagrama de flujo para definir el flujo de actividades.
Ahora podemos ver que el requisito de negocio se desglosa en casos de uso muy detallados que se pueden marcar en el diagrama de flujo de la siguiente manera:
#3) Proporcionar condiciones que justifiquen historias de usuarios derivadas.
Podemos ver que está surgiendo información más detallada debido a la descomposición de los requisitos comerciales de alto nivel en historias de usuarios detalladas de bajo nivel y en el diagrama de flujo. A partir de este diagrama de flujo, podemos obtener los detalles técnicos necesarios para la implementación de la visualización.
- El tiempo de carga de la pantalla para mostrar la entrada de destino debe ser de 1 segundo.
- El teclado de entrada de destino debe tener caracteres alfanuméricos y símbolos especiales.
- El botón de activación/desactivación de GPS debe estar presente en la pantalla de entrada de destino de navegación.
La información anterior satisface las historias de usuario y hace posible que el requisito se pruebe de forma discreta y mensurable, evitando cualquier confusión con el requisito mientras se implementa como características.
#4) Diagramas de estructura metálica para explicar el flujo de trabajo de los objetos.
Del caso de uso anterior, derivaremos un diagrama de estructura metálica que hará que la interfaz de usuario sea más clara.
#5) Definición de requisitos no funcionales fuera de los requisitos de negocio.
Es imperativo que los requisitos de software detallados se deriven de los requisitos de negocio de alto nivel, pero muchas veces solo se identifican los requisitos funcionales que indican cómo se comportará un sistema para una entrada/acción particular del usuario.
Sin embargo, los requisitos funcionales no aclaran el rendimiento de los sistemas ni otros parámetros cualitativos como la disponibilidad, la fiabilidad, etc.
Ejemplos:
a) Tomaremos el ejemplo del sistema de infoentretenimiento automotriz anterior.
Si el conductor (usuario final) del automóvil reproduce música desde USB y la guía de navegación está en progreso, también recibe una llamada entrante a través de Bluetooth en modo Manos libres, luego la carga en la CPU y el consumo de RAM aumenta a un nivel máximo a medida que se ejecutan múltiples procesos en segundo plano.
En este punto, si el conductor toca una interfaz de pantalla táctil del sistema de información y entretenimiento para rechazar la llamada entrante a través de SMS de respuesta automática (de la misma manera que lo hacemos en nuestros teléfonos móviles), el sistema debería poder realizar esta tarea y no debería colgarse ni bloquearse. Este es el rendimiento del sistema cuando la carga es alta y probamos la disponibilidad y confiabilidad.
b) Otro caso es el escenario de Estrés.
Tome un ejemplo, el sistema de infoentretenimiento recibe SMS consecutivos (tal vez 20 SMS en 10 segundos) a través del teléfono Bluetooth conectado. El sistema de infoentretenimiento debe ser capaz de manejar todos los SMS entrantes y en ningún momento debe perderse ninguna de las notificaciones de SMS entrantes en la HMI de Infoentretenimiento.
Los ejemplos anteriores son casos de requisitos no funcionales que no se pudieron probar únicamente a través de requisitos funcionales. Aunque a veces, los clientes no proporcionan estos requisitos no funcionales. Es responsabilidad de la organización proporcionarles esta información cuando se entrega un producto al cliente.
Comprender los casos de requisitos no funcionales
La siguiente tabla explica los requisitos no funcionales:
| SL No | Función/caso de uso | Carga de CPU(máx.) | Uso de RAM (máx. de 512 MB) | Parámetros de rendimiento |
|---|---|---|---|---|
| 1 | Max no. de dispositivos Bluetooth que se pueden vincular al sistema de infoentretenimiento | 75% | 300 MB | 10 dispositivos Bluetooth |
| 2 | Tiempo para descargar 2000 contactos de teléfono en el sistema de Infoentretenimiento después del emparejamiento y la conexión Bluetooth | 90% | 315 MB | 120 Segundos |
| 3 | Tiempo para escanear todas las estaciones de FM disponibles en el sintonizador en el sistema de infoentretenimiento | 50% | 200 MB | 30 Segundos |
Requisitos no funcionales, a diferencia de los requisitos funcionales, tome el ciclo de vida completo de un proyecto para implementarlo, ya que se implementan de forma incremental en los respectivos Sprints ágiles o en diferentes iteraciones.
Así es como derivamos los Requisitos de Software de los Requisitos Comerciales.
Diferencia Entre Los Requisitos De Negocio Y Los Requisitos de Software
Hemos visto anteriormente cómo derivar los requisitos de Software de los requisitos de negocio de alto nivel. Los requisitos de software permiten al programador y al ingeniero de pruebas desarrollar el sistema y probarlo de manera eficiente. Por lo tanto, ahora sabemos que los requisitos comerciales son requisitos de lenguaje natural de alto nivel para el cliente, mientras que los requisitos de software son requisitos detallados de bajo nivel que ayudan en la implementación del sistema de software.
veamos la diferencia detallada entre el requisito de dos tipos.
| Requisitos comerciales | Requisitos de software |
|---|---|
| Son requisitos de alto nivel por parte de un cliente que dice «qué» debe hacer el sistema. Estos requisitos no dicen «cómo» deben funcionar los requisitos. | Se concentran en el aspecto de» cómo » de los requisitos del cliente. Estos requisitos explican cómo funcionaría/implementaría el sistema. |
| Estos requisitos de acuerdo con el objetivo de negocio de una organización. Ejemplo: El usuario debería poder establecer el destino de navegación. |
Estos requisitos explican los conocimientos técnicos de los requisitos. Ejemplo: Cuando el usuario hace clic en el icono de destino de navegación, la base de datos debe cargar los detalles de destino para que el usuario los introduzca. |
| Los requisitos de negocio se centran en el beneficio de la organización. Ejemplo: El distribuidor debe proporcionar al usuario información para actualizar la función de navegación en el sistema de Infoentretenimiento si la navegación no está presente en el Sistema y el usuario toca el icono de navegación. |
Los requisitos de software se ocupan de los detalles de implementación de los requisitos empresariales en el sistema. Ejemplo: Cuando el usuario hace clic en el icono de navegación del sistema de Infoentretenimiento, se debe iniciar una llamada a la API para mostrar un mensaje al usuario para la actualización del sistema. |
| Los requisitos de negocio normalmente se escriben en lenguaje natural o historias de usuario de alto nivel. | Los requisitos de software son funcionales y no funcionales. Ejemplo: entre los requisitos no funcionales se encuentran el rendimiento, el estrés, la portabilidad, la usabilidad, la optimización de la memoria, la apariencia, etc. |
Conclusión
El análisis de requisitos es la columna vertebral de cualquier modelo SDLC.
Un problema perdido durante el análisis de requisitos y atrapado en las pruebas unitarias podría costar decenas de miles de dólares a una organización y este costo podría llevar a millones de dólares si proviene del mercado como devolución de llamada (en 2017, EE.UU. cobró al fabricante de bolsas de aire, Takata, una multa de 1 billón de dólares debido a la explosión de bolsas de aire).
La organización terminaría realizando tareas de control de daños como análisis de causa raíz, preparación de documentos de 5 por qué,análisis de árbol de fallas, documento 8D, etc. en lugar de concentrarse en el desarrollo y la calidad del software.
En el peor de los casos, la organización se vería arrastrada a demandas legales presentadas por el cliente si la función afectada está relacionada con la seguridad, como el acceso de seguridad, el airbag, el ABS (Sistema de frenos antibloqueo), etc.