15 TIPS PARA ESCRIBIR MEJORES REQUERIMIENTOS DE SOFTWARE

Entonces, ¿cuándo puedes decir que has escrito un buen requerimiento?

• Un rol de usuario que se beneficia del requisito
• Un estado deseable que el rol del usuario quiere lograr
• Una métrica que permite que el requisito sea probado, donde corresponda

15 consejos para escribir un buen requisito

1. Defina un requisito a la vez: cada requisito debe ser atómico. No tengas la tentación de usar conjunciones como y, o también, con y similares. Esto es particularmente importante porque palabras como estas pueden causar que los desarrolladores y evaluadores se pierdan los requisitos. Una forma de lograr esto es dividiendo los requisitos complejos hasta que cada uno pueda considerarse un caso de prueba discreto.
2. Evite el uso de cláusulas de expulsión como pero, excepto y si es necesario.
3. Cada requisito debe formar una oración completa sin palabras de moda o acrónimos.
4. Cada requisito debe contener un sujeto (usuario / sistema) y un predicado (resultado previsto, acción o condición).
5. Evite describir cómo el sistema hará algo. Solo discuta qué hará el sistema. Abstenerse de diseño del sistema. Normalmente, si se sorprende mencionando nombres de campo, lenguaje de programación y objetos de software en el documento de especificaciones de requisitos, se encuentra en la zona incorrecta.
6. Evite la ambigüedad causada por el uso de acrónimos como etc, aprox. y similares. Esto es algo que es muy común.
7. Evite el uso de términos indefinibles como fácil de usar, versátil, robusto, aproximadamente, impacto mínimo, etc. Tales términos a menudo significan cosas diferentes para diferentes personas, lo que dificulta definir sus casos de prueba y se presta para interpretaciones subjetivas.
8. Evite divagar, usar oraciones innecesariamente largas o hacer referencias a documentos inalcanzables.
9. No especules; evite elaborar listas de deseos de características que son imposibles de lograr. Decir que quieres que un sistema maneje todas las fallas inesperadas es una ilusión, ya que ningún sistema será nunca el 100% de lo que quieres que sea.
10. Evita la duplicación y las declaraciones contradictorias.
11. No exprese sugerencias o posibilidades. Puede identificarlos donde quiera que vea las declaraciones con palabras como podría, debería, supondría, etc.
12. Evite crear un rompecabezas donde los requisitos se distribuyan entre los documentos, lo que provocará que los documentos de referencia cruzada. Esto puede hacer que su RSD sea extremadamente difícil de leer.
13. No se refiera a un requisito que aún no se ha definido. Una vez más, su objetivo es hacer que el documento sea tan fácil de leer como sea posible.
14. Use declaraciones positivas como "El sistema debe ...", en lugar de "El sistema no ..."
15. "Debe" debe usarse donde se establecen los requisitos, "Will" debe usarse para representar declaraciones de hechos; & "Debería" representar un objetivo a alcanzar.