“Se refiere a la producción de un documento a su equivalente electrónico que pueda estar sistemáticamente repasado, evaluado y aprobado”. (IEEE Computer Society, 2004).
La Especificación de requisitos se refiere a: “Diferenciar y documentar los requisitos funcionales y no funcionales, identificar los atributos de calidad, requisitos importantes y restricciones, y verificar que los requisitos documentados sean completos y no sean ambiguos”. (Gottesdiener, 2009:17)
En esta fase se elaboran tres tipos de documentos:
-
Documento de definición del sistema: Define los requisitos del sistema de alto nivel desde las perspectiva del dominio, además se incluye información de fondo sobre los objetivos del sistema, su ambiente, declaración de limitaciones y los requisitos no funcionales.
-
Documento de requisitos del sistema: En este documento se manifiesta lo que requieren los desarrolladores del sistema; además se incluyen los requerimientos del usuario para el sistema como una especificación detallada de los requerimientos del sistema.
-
Documento de requisitos de software: Contiene una descripción completa de las necesidades y funcionalidades del sistema que se va a desarrollar además determina el alcance del sistema y la forma en la que realizará las funciones, definiendo los requerimientos funcionales y los no funcionales.
REDACCIÓN DE REQUERIMIENTOS
- Vital para entendimiento
- Buena redacción, facilita interpretación
- Redacción estándar, facilita comprensión
- La redacción cumple un papel principal en la etapa de validación de requerimientos.
- La consistencia en redacción agiliza todos los procesos con los requerimientos (Todos los requerimientos tienen el mismo estilo de redacción)
- Escribir requerimientos no es fácil.
- Sabemos que la experiencia nos ayudará a que estos sean mejores
Tengamos en cuenta siempre:
- Mantenga sentencias y párrafos CORTOS
- Escriba sentencias completas, con una apropiada gramática, ortografía y puntuación
- Asegurarse de que el proyecto tenga definido un glosario.
- Utilice siempre términos consistentes y definidos en el glosario.
- No olvidar utilizar sentencia “El sistema debe”, “deberá”, seguidas de una acción y finalmente un resultado.
- Para reducir ambigüedades evite términos subjetivos como: Amigable, fácil, simple, rápido, eficiente, soporte, fuerte, superior, aceptable, robusto.
- Dado que los requerimientos pueden ser identificados en diferentes niveles de abstracción, realice ejercicios de descomponer estos en varios requerimientos.
En la siguiente figura 7, se ve un ejemplo de como redactar nuevos requerimientos:
Figura 7. Redacción Requerimientos Nuevos (Elaboración propia)
En la siguiente figura 8, se ve un ejemplo de redacción para nuevos requerimientos:
Figura 8. Ejemplo de Redacción de Requerimientos Nuevos (Elaboración propia)
En la siguiente figura 9, se ve un ejemplo de redacción para nuevos requerimientos:
Figura 9. Redacción Requerimientos Errores, modificación y/o mejoras (Elaboración propia)
En la siguiente figura 10, se ve un ejemplo de redacción para requerimientos de errores, modificación y/o mejoras:
Figura 10. Ejemplos de redacción Requerimientos Errores, modificación y/o mejoras (Elaboración propia)
Ejemplo de redacción para párrafos NARRATIVOS:
Debe tener en cuenta que una narración, puede tener muchos requerimientos escondidos.
Cada condición, actividad, acción que usted encuentra en un párrafo, debe ser evaluada para especificarla como un requerimiento por separado.
Si encuentra “y” o “o”, “etc”, esto puede representar varios requerimientos separados.
Ejemplo:
Requerimos que en el momento de realizar una factura de crédito que el sistema automáticamente despliegue la pantalla de recaudo, donde el vendedor deberá digitar el valor del recaudo para esa factura. Ese valor de recaudo deberá ser igual al valor de la factura que acabó de crear, y además las opciones de pago que deberán aparecer deben ser solo las de cheque postfechado o crédito firmado. De igual forma el sistema valida si el vendedor tiene autorización para recibirle cheque a ese cliente y si no la tiene deberá esconder la opción de cheque postfechado. Cuando acabe de grabar ese recaudo, ese valor no deberá afectar la cartera, y si se recibió cheque, esta información de cheque deberá ser guardada para que sea impresa en la factura que se va a grabar.
Requerimientos identificados en el ejemplo:
REQ 1: El sistema deberá abrir el módulo de recaudo cuando el usuario indique que terminó de digitar la factura de crédito.
REQ 2: Cuando se cargue el módulo de recaudo después de haber grabado una factura de crédito el sistema deberá validar que el valor recaudado es igual al valor de la factura.
REQ 3: Cuando se cargue el módulo de recaudo después de haber grabado una factura de crédito el sistema deberá mostrar únicamente las opciones de CHEQUE POSTFECHADO o CREDITO FIRMADO
REQ 4: Cuando se cargue el módulo de recaudo después de haber grabado una factura de crédito el sistema deberá mostrar únicamente las opciones de CHEQUE POSTFECHADO o CREDITO FIRMADO