¿Qué es el análisis y la recopilación de requisitos en SDLC?

what is requirement analysis

Este tutorial explica qué es el análisis de requisitos, los pasos del análisis de requisitos, los ejemplos y los objetivos de la recopilación de requisitos en SDLC:

El desarrollo de software es una tarea enorme que crea un producto de software funcional.

El producto de software se construye según los requisitos del cliente. En su mayoría, este producto de software cumple con lo que el cliente / usuario final esperaba, mientras que a veces este producto no cumple completamente con lo que el cliente / usuario final esperaba.

Lo que vas a aprender:

• ¿Qué es el análisis de requisitos?
  • Etapas / pasos del análisis de requisitos
    • # 1) Reunión de requisitos
    • # 2) Análisis de los requisitos reunidos
    • # 3) Documentar los requisitos analizados
  • Conversión de requisitos comerciales en requisitos de software
  • Comprensión de casos de requisitos no funcionales
  • Diferencia entre requisitos comerciales y requisitos de software
• Conclusión
  • Lectura recomendada

¿Qué es el análisis de requisitos?

Entendamos el análisis de requisitos con la ayuda de un ejemplo.

Expectativa del cliente / usuario final:

El cliente / usuario final recibe:

Como puede analizar a partir de las imágenes anteriores, existe una discrepancia 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, una comprensión incorrecta de los requisitos del cliente por parte de los programadores y el equipo de calidad, etc.

Sin embargo, como puede ver, ya sea por alguna razón para la entrega incorrecta del producto, la razón principal es el requisito. Por lo tanto, si se hubiera realizado una correcta comprensión, captura, implementación y prueba 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, la 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 del desarrollo de software (SDLC)

Etapas / pasos del análisis de requisitos

Como puede ver, el análisis de requisitos es la primera actividad en SDLC seguida de la especificación funcional y así sucesivamente. 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, resultados, desafíos y medidas correctivas en el análisis de requisitos.

El análisis de requisitos comienza con:

1. Recopilación de requisitos que también se llama como elicitación.
2. A esto le sigue analizando los requisitos recopilados para comprender la exactitud y viabilidad de convertir estos requisitos en un posible producto.
3. Y finalmente, documentando los requisitos recogidos.

# 1) Reunión de requisitos

Para asegurarse de que todos los pasos mencionados anteriormente se ejecuten adecuadamente, se deben recopilar requisitos claros, concisos y correctos del cliente. El cliente debe poder definir sus requisitos correctamente y el analista de negocios debe poder recopilarlos de la misma manera que el cliente pretende transmitirlos.

Muchas veces no es posible que la recopilación de requisitos la realicen los analistas comerciales del cliente de manera eficiente. Esto puede 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 (QC y QA), cualquier proveedor externo que pueda brindar soporte en el proyecto, el usuario final al que está destinado el producto, los programadores de software, otro equipo dentro de la organización que podría 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 prestigioso OEM) que necesita Pila de autosar y Cargador de arranque binarios que se reciben de otro proveedor.

Involucrar a varias partes interesadas en la etapa de recopilación de requisitos ayuda a comprender las diversas 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 mostrárselo 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 presentar requisitos claros.

La creación de este prototipo depende de dos tipos de producto:

1. Dentro de la organización existe un producto similar al que pretendían los clientes.
2. 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 fue desarrollado 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 puede exhibirse a otro OEM.

tenga en cuenta , no es aconsejable mostrar al cliente el producto / protoproducto que está en desarrollo, ya que puede violar el Acuerdo de confidencialidad firmado con otro cliente para quien 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 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 información y entretenimiento con HMI tangible, puertos de conector de dispositivos, caja de arena, etc.

Esto ayudará al cliente a comprender cómo se vería el producto final y proporcionará sus requisitos con mucha más claridad.

(ii) El segundo caso se puede lograr creando un modelo de trabajo básico haciendo una 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 todas las partes interesadas pueden ser invitadas y, por lo tanto, pueden anotar los diversos requisitos proporcionados por el cliente (en algunos casos, si las partes interesadas son más numerosas, se podría designar a un escribiente independiente para anotar al cliente requisitos o historias de usuarios para que el analista de negocios pueda concentrarse en moderar la reunión).

Los requisitos recopilados pueden tener la forma de historias de usuarios (en desarrollo ágil), casos de uso, documentos en 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 moderno. 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 poder ver lo que hay en la vista trasera de mi automóvil'.

Podría haber muchos 'por qué,' preguntas formuladas 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 poder ver lo que hay en la vista trasera de mi automóvil', haciendo una pregunta 'por qué 'Podría dar' Como usuario, debería poder ver lo que hay en la vista trasera de mi automóvil, para poder estacionar mi auto de manera segura ”.

Haciendo la pregunta 'por qué' también ayuda a crear requisitos objetivos y atómicos a partir de enormes declaraciones en lenguaje natural dadas por el cliente. Esto se puede implementar fácilmente más adelante en el código.

que es un codigo de seguridad de red

Otra forma de recopilar el requisito es en forma de casos de uso . Un caso de uso es un enfoque paso a paso para lograr un resultado determinado. Esto no dice cómo funcionará el software en la entrada del usuario, sino que dice qué se espera de las entradas del usuario.

Ejemplo:

# 2) Análisis de los requisitos reunidos

Después de la recopilación de requisitos, comienza el análisis de los requisitos. En esta etapa, varias partes interesadas se sientan y realizan una sesión de lluvia de ideas. Analizan los requisitos recopilados y buscan la viabilidad de implementarlos. Discuten entre ellos 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: Clientespuede solicitar una vista envolvente del sistema de la cámara con una función de cámara retrovisora ​​que ayudará a estacionamiento el coche. El cliente también puede solicitar el Remolque función de enganche que también utiliza la cámara trasera para funcionar.

Si el cliente indica el requisito de que la cámara de visión trasera estacionamiento La asistencia debe funcionar en todo momento sin excepción, entonces el Remolque característica nunca funcionaría y viceversa.

(ii) Un analista de negocios podría haber entendido el requisito del cliente diferente a como un programador habría interpretado.

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 tanto, conviene comprobarlo.

Una posible medida correctiva podría ser siguiendo un método ágil de desarrollo de software, siguiendo los casos de uso que proporciona el cliente, etc.

# 3) Documentar los requisitos analizados

Una vez que se realiza el análisis de requisitos, comienza la documentación de requisitos. Varios tipos de requisitos surgen del análisis 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 de Bluetooth en la HMI de infoentretenimiento, se debe mostrar la pantalla de Bluetooth'

(v) Especificación de requisitos no funcionales (es decir, rendimiento, estrés, carga, etc.).

Ejemplo: “Debería ser posible emparejar 15 dispositivos Bluetooth con un sistema de infoentretenimiento sin que se degrade el rendimiento del sistema”.

(nosotros) Requisitos de la interfaz de usuario.

Ejemplo: 'En la pantalla Tuner 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 costes.

Veamos ahora el proceso de conversión Requisitos comerciales a Requisitos de Software (funcional y no funcional).

Conversión de requisitos comerciales en requisitos de software

Los requisitos comerciales, 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 basándose 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 a los requisitos funcionales y no funcionales.

Para hacer esto, se pueden seguir los siguientes pasos:

cómo abrir archivos dat en windows

1. Divida los requisitos comerciales de alto nivel en historias de usuario detalladas.
2. Derivar un diagrama de flujo para definir el flujo de actividades.
3. Proporcionar la condición que justifique las historias de usuario derivadas.
4. Diagramas de alambre para explicar el flujo de trabajo de los objetos.
5. Definición de requisitos no funcionales fuera de los requisitos comerciales.

Comencemos por tomar un ejemplo de sistema de infoentretenimiento automotriz.

El requisito empresarial dice: 'El usuario final debe poder acceder al cuadro de widget de navegación desde la HMI del sistema de infoentretenimiento y debe poder establecer la dirección de destino'.

Por lo tanto, los pasos enumerados anteriormente se pueden implementar como:

# 1) Desglose los requisitos comerciales de alto nivel en historias de usuario detalladas.

Convirtamos este requisito empresarial en una historia de usuario de alto nivel ' Como usuario, debería poder acceder al cuadro del widget de navegación para poder ingresar la dirección de destino ”. Esta historia de usuario cuenta lo que necesita el usuario final. Intentaremos definir cómo implementar este requisito.

Comencemos haciendo posibles preguntas a esta historia de usuario a saber.

1. ¿Quiénes son los usuarios?
2. ¿Cómo puedo acceder a la navegación integrada (desde la tarjeta SD) o desde SmartPhone?
3. ¿Qué tipo de entradas de destino puedo ingresar?
4. ¿Debería poder ingresar al destino incluso cuando el automóvil está estacionado?

Estas son historias de usuarios de nivel más detalladas 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 historias secundarias de los usuarios y comenzar a cuestionar. Tomemos (n. ° 3):

1. ¿Puedo ingresar entradas de destino como coordenadas geográficas, dirección postal, mediante reconocimiento de voz, etc.?
2. ¿Necesito GPS para introducir coordenadas geográficas?
3. ¿Puedo ingresar la dirección de destino actual buscando en el historial de direcciones?

# 2) Derivación de un diagrama de flujo para definir el flujo de actividades.

Ahora podemos ver que el requisito comercial 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 las historias de usuario derivadas.

Podemos ver que está surgiendo información más detallada debido a la descomposición del requisito empresarial de alto nivel en historias de usuario 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, a saber.

• 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 los usuarios y hace posible que el requisito se pruebe de manera discreta y mensurable, evitando cualquier confusión con el requisito mientras se implementa como características.

# 4) Diagramas de alambre para explicar el flujo de trabajo de los objetos.

A partir del caso de uso anterior, derivaremos un diagrama de estructura alámbrica que hará que la interfaz de usuario sea más clara.

# 5) Definición de requisitos no funcionales fuera de los requisitos del negocio.

Es imperativo que los requisitos de software detallados se deriven de los requisitos comerciales de alto nivel, pero muchas veces solo se identifican los requisitos funcionales, lo que indica cómo se comportará un sistema ante una entrada / acción particular del usuario.

Sin embargo, los requisitos funcionales no aclaran el rendimiento de los sistemas y otros parámetros cualitativos como la disponibilidad, la fiabilidad, etc.

Ejemplos:

a) Tomaremos el ejemplo del sistema de información y entretenimiento para automóviles 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 realizan múltiples procesos corriendo en segundo plano.

En este punto, si el conductor toca la interfaz de la pantalla táctil del sistema de infoentretenimiento para rechazar una llamada entrante a través de un 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 o bloquearse. Este es el rendimiento del sistema cuando la carga es alta y probamos la disponibilidad y confiabilidad.

b) Otro caso es el escenario Stress.

Tome un ejemplo, el sistema de infoentretenimiento recibe SMS consecutivos (tal vez 20 SMS en 10 segundos) a través de un teléfono Bluetooth conectado. El sistema de infoentretenimiento debe poder manejar todos los SMS entrantes y en ningún momento debe perderse ninguna notificación de SMS entrante en la HMI de infoentretenimiento.

Los ejemplos anteriores son casos de requisitos no funcionales que no se pudieron probar a través de requisitos funcionales únicamente. Aunque a veces, los clientes no brindan estos requisitos no funcionales. Es responsabilidad de la organización proporcionarles esta información cuando se entrega un producto al cliente.

Comprensión de casos de requisitos no funcionales

La siguiente tabla explica los requisitos no funcionales:

Los requisitos no funcionales, a diferencia de los requisitos funcionales, requieren el ciclo de vida completo de un proyecto para implementarse, ya que se implementan de forma incremental en los respectivos Agile Sprints o en diferentes iteraciones.

Entonces, así es como derivamos los requisitos de software de los requisitos comerciales.

Diferencia entre requisitos comerciales y requisitos de software

Hemos visto anteriormente cómo derivar los requisitos de software a partir de requisitos empresariales 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 del cliente de alto nivel, mientras que los requisitos de software son requisitos detallados de bajo nivel que ayudan en la implementación del sistema de software.

Analicemos la diferencia detallada entre los dos tipos de requisitos.

Conclusión

El análisis de requisitos es la columna vertebral de cualquier modelo SDLC.

Un problema no detectado durante el análisis de requisitos y detectado en las pruebas unitarias podría costar decenas de miles de dólares a una organización y este costo podría generar millones de dólares si proviene del mercado como una devolución de llamada (en 2017, el fabricante de bolsas de aire de EE.UU., Takata multa de $ 1 mil millones debido a la explosión de bolsas de aire).

La organización terminaría realizando tareas de control de daños como el análisis de la causa raíz, la preparación de documentos del 5 por qué, el análisis del árbol de fallas, el 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 característica afectada está relacionada con la seguridad, como el acceso de seguridad, airbag, ABS (sistema de frenos antibloqueo), etc.

Lectura recomendada

• Fases, metodologías, procesos y modelos de SDLC (ciclo de vida de desarrollo de software)
• Características de requisitos funcionales y requisitos no funcionales
• ¿Cómo probar la especificación de requisitos de software (SRS)?
• 5 errores mortales en la gestión de requisitos y cómo superarlos
• ¿Cómo probar una aplicación sin requisitos?
• Medidas para SSDLC (ciclo de vida de desarrollo de software seguro)
• Modelo en espiral: ¿Qué es el modelo en espiral SDLC?
• ¿Qué es el modelo de cascada SDLC?