Requisitos de software Calidad

La calidad de los requisitos es un tema de discusión entre los profesionales de requisitos de software. Aquí hay cuatro puntos de vista considerados sobre la calidad de los requisitos del software, eso es lo que hace un buen requisito o un buen conjunto de requisitos.

¿Por qué es importante la calidad de los requisitos?

A menudo resulta útil ver las cosas al revés. Pregúntese, ¿cuál es el impacto de tener requisitos deficientes? Este gráfico ilustra el punto de que existe un aumento no lineal en el retrabajo causado por requisitos deficientes.

El costo de los requisitos de software de mala calidad al generar retrabajos
una comparación de requisitos atributos de calidad según diferentes fuentes:

Nuestra vista

Recomendamos algo muy cercano al IIBA BABOK de la siguiente manera

  • Claro: significado funcional inequívoco.
  • Conciso: no contiene contenido extraño e innecesario.
  • Orientado al usuario: se centra en lo que el usuario necesita lograr.
  • Completo: tanto internamente completo (todos los pasos funcionales dentro de un requisito) como en conjunto, todos los eventos CRUD cubiertos
  • Coherente: los nombres de usuarios y objetos son consistentes en un conjunto de requisitos
  • Mensurable: se puede dimensionar en puntos de función COSMIC
  • Comprobable: Si es mensurable, normalmente también es comprobable.
  • Valioso : es necesario para ofrecer capacidades esenciales al usuario.
  • Sin diseño: excluye “cómo” debe implementarse.
  • Único: no hay funcionalidad duplicada en el conjunto de requisitos

Y la descripción general del IIBA sobre requisitos de calidad dice lo siguiente:

Si bien la calidad está determinada en última instancia por las necesidades de las partes interesadas que utilizarán los requisitos o los diseños, los requisitos de calidad aceptables exhiben muchas de las siguientes características:

  • Atómico: autónomo y capaz de entenderse independientemente de otros requisitos o diseños.
  • Completo: suficiente para guiar el trabajo posterior y con el nivel apropiado de detalle para que el trabajo continúe. El nivel de integridad requerido difiere según la perspectiva o la metodología, así como también el punto del ciclo de vida donde se examina o representa el requisito.
  • Coherente: alineado con las necesidades identificadas de las partes interesadas y que no entre en conflicto con otros requisitos.
  • Conciso: no contiene contenido extraño e innecesario.
  • Factible: razonable y posible dentro del riesgo, cronograma y presupuesto acordados, o considerado lo suficientemente factible como para investigar más a fondo a través de experimentos o prototipos.
  • inequívoco: el requisito debe establecerse claramente de tal manera que quede claro si una solución satisface o no la necesidad asociada.
  • Comprobable: capaz de verificar que se ha cumplido el requisito o diseño. Los niveles aceptables de verificación del cumplimiento dependen del nivel de abstracción del requisito o diseño.
  • Priorizado: clasificados, agrupados o negociados en términos de importancia y valor frente a todos los demás requisitos.
  • Comprensible: representado utilizando terminología común de la audiencia.

La sección 4.3 de IEEE Std 830 proporciona una lista de atributos de calidad deseados de una especificación de software, que son:

“Un SRS debería ser:

  1.  Correcto;
  2. Sin ambigüedades;
  3. Completo;
  4. Coherente;
  5. Clasificados por su importancia y/o estabilidad;
  6. Verifiable
  7.  Modificable;
  8. Trazable”.

Características de los requisitos comprobables Para que los requisitos se consideren comprobables, idealmente deberían tener todas las características siguientes: Descripción general de las pruebas basadas en requisitos 8

1. Determinista: dado un estado inicial del sistema y un conjunto de entradas, debe poder predecir exactamente cuáles serán las salidas.

2. Inequívoco: todos los miembros del proyecto deben obtener el mismo significado de los requisitos; de lo contrario son ambiguos.

3. Correcto: Las relaciones entre causas y efectos se describen correctamente.

4. Completo: Se incluyen todos los requisitos. No hay omisiones.

5. No redundante: así como el modelo de datos proporciona un conjunto de datos no redundante, los requisitos deben proporcionar un conjunto no redundante de funciones y eventos.

6. Se presta al control de cambios: los requisitos, como todos los demás entregables de un proyecto, deben colocarse bajo control de cambios.

7. Trazable: Los requisitos deben ser trazables entre sí, con los objetivos, con el diseño, con los casos de prueba y con el código.

8. Legible por todos los miembros del equipo del proyecto: las partes interesadas del proyecto, incluidos los usuarios, desarrolladores y evaluadores, deben llegar a la misma comprensión de los requisitos.

9. Escrito en un estilo coherente: los requisitos deben escribirse en un estilo coherente para que sean más fáciles de entender.

10. Las reglas de procesamiento reflejan estándares consistentes: las reglas de procesamiento deben escribirse de manera consistente para que sean más fáciles de entender.

11. Explícito: Los requisitos nunca deben ser implícitos.

12. Lógicamente consistente: No debe haber errores lógicos en las relaciones entre causas y efectos.

13. Se presta a la reutilización: los buenos requisitos se pueden reutilizar en proyectos futuros.

14. Conciso: Los requisitos deben redactarse de manera breve, con la menor cantidad de palabras posible.

15. Anotado por criticidad: no todos los requisitos son críticos. Cada requisito debe indicar el grado de impacto que tendría un defecto en el mismo en la producción. De esta manera, se puede determinar la prioridad de cada requisito y poner el énfasis adecuado en desarrollar y probar cada requisito. No necesitamos cero defectos en la mayoría de los sistemas. Necesitamos pruebas suficientemente buenas.

16. Factible: Si el diseño del software no es capaz de cumplir los requisitos, entonces los requisitos no son factibles.

Extraído de Descripción general del proceso de prueba basado en requisitos

El acrónimo “INVEST” puede recordarte que las buenas historias son:

  • I - Independiente
  • norte – Negociable
  • V - Valioso
  • mi – Estimable
  • S - Pequeño
  • t – Comprobable

No existe un estándar único que determine lo que constituye un requisito de software de buena calidad. Además, lo que puede considerarse un buen requisito para Software de la aplicacion probablemente diferirá de un buen software de sistemas requisito.

Requisitos de atributos de calidad.

Garantía de calidad de requisitos automatizados

Requisitos de las pruebas de ScopeMaster. Como SonarQube para los requisitos, ScopeMaster examina cada requisito (o historia de usuario) para detectar la intención funcional y evalúa cada requisito según los criterios de calidad enumerados anteriormente. No puede detectar todas las fallas, pero puede encontrar aproximadamente 50% de ellas. Una vez que ha analizado los requisitos individualmente, los examina en el contexto del conjunto de requisitos. Esto proporciona información que simplemente no es posible con herramientas como Jira y Azure DevOps, AlcanceMaster interpreta y analiza requisitos, no sólo los almacena. Esto le libera tiempo para considerar otros aspectos importantes de sus requisitos. Hace que su trabajo de mejorar la calidad de los requisitos sea más rápido y sencillo. Hace el trabajo duro por ti.

Requisitos Calidad de un vistazo
Resultados de las pruebas de la historia del usuario de inicio de sesión.

En la tabla que se muestra, las columnas significan:

  1. El puntuación de calidad del requisito individual (con cierta consideración por el contexto) prueba de más de 350 palabras, frases y patrones lingüísticos para mayor claridad.
  2. Claro y funcional Contiene declaraciones inequívocas de funcionalidad (descripción de movimientos de datos).
  3. Orientado al usuario Un usuario es identificado como el sujeto dentro del requisito, realizando una acción con datos.
  4. Conciso la relación entre palabras y tamaño funcional, dentro de límites razonables
  5. Medible y comprobable Si se detecta una intención funcional, entonces es mensurable y comprobable; nuevamente estamos determinando si hubo una intención funcional clara.
  6. Completo (dentro del conjunto) significa tipos de objetos que se identifican dentro de este requisito y que tienen acciones CRUD complementarias para garantizar un conjunto completo de actividades de mantenimiento en todo el conjunto de requisitos.
  7. Completo (funcionalidad enterrada) funcionalidad detectada en las notas/criterios de aceptación que debería haber estado en el propio requisito.
  8. Beneficios ¿Ha habido un esfuerzo por describir los beneficios o el valor de este requisito?

Puntuación de calidad

ScopeMaster reconoce que los requisitos no existen por sí solos. Él entiende el contexto de un conjunto de requisitos y por eso determina los puntajes de calidad en dos niveles:

  1. Puntuación de calidad para cada requisito individual
  2. Puntuación de calidad para un conjunto de requisitos

ScopeMaster realiza cientos de pruebas estáticas y potencialmente miles de pruebas dinámicas sobre cada requisito y brinda al autor comentarios inmediatos. Vos tambien aprender a escribir mejores requisitos a medida que avanza.

Requisitos Puntuación de calidad