Buenas practicas - lecciones aprendidas en la especificaciones de requerimientos

Definición
Un requerimiento es la condición o capacidad que necesita el usuario para resolver un problema o alcanzar un objetivo. Es la condición o capacidad que debe satisfacer o poseer un sistema o una componente de un sistema para satisfacer un contrato, un standard, una especificación u otro documento formalmente impuesto [IEEE610].

Recomendaciones / sugerencias para el documento de requerimientos
"La experiencia es la mejor escuela para escribir requerimientos adecuados"

- Wiegers

• Oraciones con gramática, sintaxis y puntuación adecuada
• Oraciones cortas y directas
• Voz activa, imperativos: "el sistema debe hacer algo" y no "algo debe hacerse"
• Usar los términos consistentemente y de acuerdo a la definición del glosario
• No use sinónimos: no varíe el lenguaje para atraer al lector
• Descomponga un requerimiento de alto nivel en detalle suficiente para clarificarlo y eliminar la ambigüedad
• Use una forma consistente de redactar: "el sistema debe"+verbo
• Especifique la acción que dispara el comportamiento del sistema
• Evite el "debería", "podría" y condicionales
• En "El usuario debe..." especifique al usuario: "El cajero debe..."
• Presente información visualmente, las masas de texto no ayudan
• Enfatice la información más importante

Términos ambiguos y su modificación

Término ambiguo	Formas de mejorarlo
aceptable, adecuado	Defina qué constituye la aceptabilidad y cómo el sistema la juzga
tanto como sea practicable	No deje en manos de los desarrolladores determinar qué es practicable.
al menos, como mínimo, no más que, no exceder	Especificar los valores mínimos y máximos aceptables
Entre	Defina si los puntos extremos están o no en el rango
depende de	Describa la naturaleza de la dependencia. ¿Otro sistema provee input a este sistema, debe instalarse otro sistema antes que su sofwtware sea ejecutado o su sistem depende de otro para ejecutar algún cálculo o servicio?
Eficiente	Defina como el sistema usa eficientemente recursos, cuan rápidamente ejecuta operaciones o como es de fácil para la gente usarlo
rápido, veloz	Especifique la mínima velocidad aceptable a la que el sistema ejecuta alguna acción
Flexible	Describa las formas en la que el sistema debe cambiar en respuesta a condiciones cambiantes o necesidades del negocio
mejorado, mejor, más rápido, superior	Cuantifique cuanto mejor o más rápido constituye una mejora adecuada en un área funcional específica
incluyendo, incluyendo pero no limitado a, y así sucesivamente, etc. tal como	La lista de ítems debería incluir todas las posibilidades. De otro modo no podría usarse para diseño o testeo
maximice, minimice, optimice	Establezca los valores máximo y mínimo aceptable para algún parámetro
normalmente, idealmente	Describa también el comportamiento del sistema bajo condiciones anormales o no-ideales
Opcionalmente	Clarifique si se trata de una opción del sistema, del usuario o del desarrollador
razonable, cuando es necesario, donde sea apropiado	Explique como se produce este juicio
Robusto	Defina como el sistema maneja las excepciones y responde a condiciones operacionales no esperadas
transparente, suave, grácil	Traduzca las expectativas del usuario en caracterísrticas observables del producto
Varios	Establezca cuantos o proveea las cotas mínima y máxima del rango
no debería	Establezca los requerimientos positivos, diciendo que hará el sistema
estado del arte	Defina qué significa
Suficiente	Explique con cuanto de algo se establece la suficiencia
soporte, disponible	Defina exactamente que funciones debe ejecutar el sistema que soporten alguna capacidad
Amistoso, fácil, simple	Describa las características del sistema que alcanzarán las necesidades de uso del usuario y las expectativas de usabilidad

Características de una buena especificación de requerimientos - factores de calidad de una especificación de requerimientos

• Correcta
• No ambigua
• Completa
• Consistente
• Rankeada / Clasificacion por importancia
• Verificable
• Modificable
• Traceable
• Independiente del diseño
• Concisa / Breve
• Organizada
• Anotada

Correcta
Una especificación de requerimientos es correcta "sí y sólo si todo requerimiento formular en ella es uno que el software debe satisfacer"

No ambigua
Una especificación de requerimientos no es ambigua "sí y sólo si todo requerimiento formulado en ella tiene una sola interpretación".
Ello requiere que al menos cada característica del producto final se describa con un único término.
Debe evitarse toda afirmación ambigua:
"Todos los clientes tienen el mismo campo de control"
"Todos los archivos son controlados por un bloque de control de archivo"
El lenguaje natural es fuente de ambigüedades.

Completa
Una especificación de requerimientos es completa "sí y sólo si incluye los siguientes elementos:
Todos los requerimientos significativos que impone al software
Todas las respuestas del software a todas las clases posibles de inputs
Todas las etiquetas y referencias a las figuras, tablas y diagramas de la especificación de requerimiento y las definiciones de los términos y unidades de medida"
Este atributo es el más difícil de definir y detectar violaciones, por lo que hay que dedicarle tiempo y trabajar a conciencia.

Consistente
(Hablamos de consistencia interna)
Una especificación de requerimientos es internamente consistente sí y sólo si ningún subconjunto de requerimientos está en conflicto.
Tipos de inconsistencias
Comportamiento conflictivo: dos partes especifican diferentes y conflictivos: estímulos para inducir una respuesta, respuestas a un mismo estímulo y condición.
Términos conflictivos: dos términos diferentes se utilizan para definir lo mismo
Características conflictivas: dos partes requieren rasgos contradictorios
Inconsistencia temporal: dos partes requieren comportamientos temporales contradictorios.

Rankeada / Clasificacion por importancia
Que cada requerimiento tenga una identificación que indica la importancia. Se los puede clasificar, por ejemplo, en "Esenciales" (el software no es aceptable sin éstos), "Condicionales" (pueden mejorar el software, pero no es inaceptable si está ausente) u "Opcionales" (esa función puede o no estar presente).
Que cada requerimiento tenga una identificación de la estabilidad. La estabilidad se puede expresar en términos del número de cambios que se esperan.

Verificable
Todo requerimiento incluido en ella es "verificable", es decir que exista un proceso finito y efectivo en costo con el que chequear que el sistema a construir satisface el requerimiento.
En general los requerimientos ambiguos no son verificables.
Ejemplos de requerimientos no verificables:
- El producto debe trabajar bien
- El producto debería tener una buena interfase
- El programa no debe entrar nunca en un loop infinito
- El output del programa debe estar habitualmente dentro de los 10 segundos
Ejemplos de requerimientos verificables
- A partir de producido el evento X, se obtendrá el output del proceso: debe estar dentro de los 20 segundos el 60% de las transacciones y dentro de los 30 segundos el 99% de las transacciones.
- Algunas de las fuentes de no verificabilidad son las ambigüedades, problemas no resolubles y cantidades no medibles.

Modificable
Cualquier cambio puede hacerse: fácilmente, manteniendo la "completitud" y consistentemente.
Requiere tener una organización coherente y fácil de usar, no ser redundante.

Traceable / Rastreable
Si es claro el origen de cada requerimiento y facilita la referencia de cada requerimiento en futuros desarrollos o mejoras de la documentación.
Tipos de rastreabilidad: hacia delante y hacia atrás.
Beneficios:
- Importancia en operaciones y mantenimiento
- Claridad del origen de cada requerimiento
- Facilita negociar los requerimientos
- Facilita referenciar cada requerimiento individual establecido en la especificación de requerimientos

Independiente del diseño
No debe implicar una arquitectura específica de software o algoritmo, dado que no se debe limitar a esta instancia de una única alternativa de diseño. Hay excepciones aceptables.

Concisa / Breve
A igualdad de cualidades, la mejor es la mas corta

Organizada
Una especificación de requerimientos es organizada si los requerimientos que contiene son fácilmente localizables

Anotada
Las anotaciones a una especificación de requerimientos proveen guía al desarrollo de la organización del documento. Hay dos casos de anotaciones requeridas: necesidad y estabilidad

Tipos de requerimientos según las capacidades o características

Necesidades: Capacidades o características requeridas al sistema de software para resolver el problema. Posibles formas:
Funcionalidad
Comportamiento del sistema
Performance, tiempo de respuesta
Necesidades operacionales
Características de las interfaces de hw y sw.

Deseos: Capacidades o características de un sistema de software deseadas por los stakeholders, no son imprescindibles para resolver el problema. Posibles formas:
Funcionalidad extra
Comportamientos específicos del sistema
Características de la interfase del usuario
Algoritmos particulares

Expectativas: Capacidades o características del sistema de software esperadas por los stakeholders. A menudo no explícitas, y por ello se pierden fácilmente. Posibles formas:
Aspectos específicos del dominio, funcionalidad
Confiabilidad
Características de la interfase con el usuario
Características de performance

Referencias
[IEEE610] Definición IEEE-Std-610 (1990)