15 TIPS PARA ESCRIBIR MEJORES REQUERIMIENTOS DE SOFTWARE
Según IBM, hacer un buen trabajo con los requisitos puede ahorrarle a su organización una fortuna. Los documentos de especificación de requisitos (RSD) son el principal medio de comunicación entre usuarios y desarrolladores, y deben prepararse con tanto cuidado como cuando se redacta un contrato. El DSR debe considerarse un acuerdo vinculante que contiene las condiciones que rigen si la solución propuesta será aceptable o no. Los requisitos de elaboración no son difíciles y se pueden mejorar a través del aprendizaje y la práctica continua. Sin embargo, no hay sustituto para buenos requisitos. Los analistas deben prestar atención a cada pequeño detalle, desde el estilo, la estructura y la presentación hasta el contenido, para aumentar las posibilidades de ofrecer sistemas exitosos.
Tabla de contenido
Entonces, ¿cuándo puedes decir que has escrito un buen requerimiento?
Aunque no existe un enfoque único para los requisitos de redacción (existen diferentes escuelas de pensamiento sobre lo que constituye una buena declaración de requisitos), cumplir con esta estructura recomendada sin duda mejorará la claridad de sus requisitos.
Idealmente, cada declaración de requisitos (escrita desde la perspectiva del usuario) debe contener:
- 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
Además del desafío de garantizar que cada declaración de requisitos cumpla con la estructura anterior, aquí hay algunos consejos útiles sobre qué hacer y qué no hacer, que deben tenerse en cuenta.
15 consejos para escribir un buen requisito
- 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.
- Evite el uso de cláusulas de expulsión como pero, excepto y si es necesario.
- Cada requisito debe formar una oración completa sin palabras de moda o acrónimos.
- Cada requisito debe contener un sujeto (usuario / sistema) y un predicado (resultado previsto, acción o condición).
- 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.
- Evite la ambigüedad causada por el uso de acrónimos como etc, aprox. y similares. Esto es algo que es muy común.
- 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.
- Evite divagar, usar oraciones innecesariamente largas o hacer referencias a documentos inalcanzables.
- 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.
- Evita la duplicación y las declaraciones contradictorias.
- No exprese sugerencias o posibilidades. Puede identificarlos donde quiera que vea las declaraciones con palabras como podría, debería, supondría, etc.
- 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.
- 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.
- Use declaraciones positivas como "El sistema debe ...", en lugar de "El sistema no ..."
- "Debe" debe usarse donde se establecen los requisitos, "Will" debe usarse para representar declaraciones de hechos; & "Debería" representar un objetivo a alcanzar.