Documentacin de requerimientos

El resultado del desarrollo de requerimientos es un documento que

cumple el rol de acuerdo con el cliente y los desarrolladores acerca
el producto que se va a construir:
En un documento general se detallan los requerimeintos del negocio y
requerimientos del sistema representados como casos de uso.
En la SRS (software requirements specification) se describen los requerimientos
funcionales y no funcionales descriptos en forma detallada.

Se puede representar requerimientos de diversas formas:

Documentos descriptos en lenguaje natural cuidadosamente estructurado.
Modelos graficos que ilustren la transformacion de los procesos, los estados de
un sistema y sus cambios, relaciones de datos, flujos logicos u objetos con sus
asociaciones.
Especificaciones formales que definen requerimientos usando modelos
matemticos.

SRS: Especificacion de
Requerimientos de Software
Tambien llamada
Especificacion funcional
Especificacion de producto
Documento de requerimientos
Especificacion del sistema

Es la base para la planificacion del

proyecto, para el diseno, codificacion,
testing y documentacion.

A quien le interesa la SRS

Clientes
Gerentes de Proyectos
Equipos de desarrollo
Grupos de testing
Equipo de mantenimiento y soporte
Escritores de documentacion
Personal de capacitacion
Personal que controla el ambito legal

Organice el documento
orientado a toda la audiencia
Utilice secciones y subsecciones.
Indente, justifique los parrafos para ser mas claro.
Enfatice con letra bold, italic y diferentes fuentes de datos.
Cree una tabla de contenidos, indice para facilitar encontrar
informacion.
Numere todos los graficos y tablas y utilice esta referencia.
Utilice hipervinculos para relacionar temas en las SRS o en otros
documentos.
Utilice templates, plantillas de ejemplo que organicen la
informacion.
Tengan en cuenta la priorizacion de requerimientos, que esta
prioridad coincida con la numeracion sugerida para los
requerimientos y si es necesario realice la jerarquizacion de los
mismos.

Una Plantilla de la SRS

Introduccion: presenta un resumen del documento.

Proposito: describe el producto o aplicacion a la que pertenecen los
requerimientos que seran descriptos, y como ayuda este a los objetivos
del negocio.
Convenciones del documento: describe las normas o estandares
usados,
Audiencia a quien va dirigida
Alcance del Proyecto.
Referencias: lista cualquier documento que complemente la SRS.

Descripcion general
Perspectiva del producto: justificacion del desarrollo del producto, tener
en cuenta que el producto puede ser un componente de un sistema
mas grande.
Caracteristicas del producto: lista de caracteristicas generales del
producto.
Caracteristicas y clases de usuarios: describe la s categorias de
usuarios relacionados con estos requerimientos.
Ambiente operativo

Restricciones de diseno e implementacion:

Tecnologia especificas, herramientas, lenguaje de programacion, base de
datos, que deben ser usardas o evitadas.
Tipos y versiones de aplicativos por ej, de los browsers Web.
Estandares o convenciones de desarrollo establecidos.
Compatibilidad con otros productos, aplicativos, subsitemas, versiones
anteriores del mismo sistema, etc.
Limitaciones impuestas por las reglas de negocio
Limitaciones del hardware, tiempo de ejecucion de los servicios,
restricciones de memoria, restricciones de procesador, tamano,
concurrencia, costo, etc.
Convenciones de interfaces de usuario.
Documentacion de usuario: Entregables que seran adjuntados con la version
ejecutable del software.
Supuestos y dependencias

Caracteristicas del Sistema

Caracteristica X del sistema: Control de ortografia
Descripcion y prioridad: Indicar un orden de prioridad en su implementacion.
Entradas y Salidas: acciones de usuario, senales de dispositivos externos, u
otros disparadores.
Requerimeintos Funcionales: detalle el comportamiento ampliando la
caracterisitca X del sistema, plantee cursos alternativos y situaciones
excepcionales.

Requerimientos de interfaces externas: Proveer informacion para

asegurar que el sistema se comunicara adecuadamente con los
componentes externos.
Interfaces de usuario.
Interfaces de hardware
Interfaces de Software
Interfaces de comunicacion

Otros requerimientos no funcionales

Requerimeintso de performance
Requerimeintos de seguridad
Requerimientos de resguardo
Requerimientos de calidad

Otros requerimientos
Glosario
Modelos de Analisis
Temas pendientes

Guia para escribir

requerimientos
La mejor maestra es la experiencia
Escribir sentencias completas que respeten las reglas gramaticales
y de puntuacion. Tratar de que sean sentencias y parrafos cortos y
concisos.
Utilizar voz activa: El sistema debe hacer algo y no Algo pasa
Usar terminos consistentes y definidos en el glosario, cuidado con
usar sinonimos.
Detalle los requerimeinos para clarificarlos y evitar la ambiguedad.
Ubique el requerimiento en un escenario, seguido por una accion
verbal y luego el resultado observable. El sistema debe mostrar
una lista con todos los productos quimicos en stock
Si declara un requerimiento de la forma El usuario debe
especifique el actor puntual: El recepcionista
Use listas, figuras, graficos y tablas para presentar informacion
visual

Enfatice la informacion mas importante:

Utilice la repeticion, espacios en blanco, sombreado, etc.

Evite el lenguaje ambiguo:

Algunos ejemplos..
El administrador de tareas de background debe mostrar mensajes
de estado a intervalos regulares no menos de cada 60 segundos
Que mensajes de estado se mostraran?
En que casos esto se mostrara al usuario?
Cuanto tiempo permanece visible?

Como reescribirian el requerimiento:

El administrador de tareas de background (BTM) debe mostrar
mensajes de estado en un area designada de la interfaz de usuario.
El mensaje debe actualizarse cada 60 mas o menos 10 desde que la
tarea comienza.
El mensaje debe permanecer visible continuamente.
En cada comunicacion con el proceso de la tarea de background el
BTM debe mostrar el porcentaje de avance de dicha tarea.
El BTM debera mostrar un mensaje Finalizado cuando la tarea de
background se termine
El BTM debera mostrar un mensaje cuando detecte que la tarea de
background esta estancada.

Observe que
Cada uno de estos requerimientos genera
casos de pruebas diferentes.
Si muchos requerimientos estan
agrupados en uno solo es muy facil omitir
detalles.
Observe que no se especifica como se
mostrara el estado del mensaje, ya que
esto es una cuestion del diseno.

Mas ejemplos
El Editor XML debe permitir mostrar y ocultar caracteres
no imprimibles instantaneamente.
El requerimiento esta incompleto ya que no aclara en que casos
permitir el cambio.
El software lo cambiara por si solo o el usuario decidira cuando?
En que ambito se permitira esto?, texto seleccionado, el
documento entero, pagina activa, etc.?
Que clase de caracteres no imprimibles? Texto oculto,
caracteres de control, tags, u otros?
El termino Instantaneamente que significa?

Este requerimiento no puede ser verificable hasta que

estos aspectos queden aclarados.
El usuario debe poder cambiar (mostrarlos u ocultarlos)
todos los tags de XML en un documento que esta siendo
editado. El cambio debe visualizarse en 0.1 segundo o
menos.

La carga de productos, de ser posible, deberia ser

validada on line contra el catalogo de productos
existentes.
Que significa si fuera posible? Si fuera factible tecnicamente? Si
se pudiera acceder al catalogo en tiempo de ejecucion?
Si no esta seguro si el requerimiento puede realizarse utilice
algo para destacarlo, por ej. (TBD: to be determined), a
confirmar, etc, no planteee frases como de ser posible
Este requerimiento no aclara que sucede si la validacion no se
cumple.
Evite utilizar palabras imprecisas como deberia. Siempre es
mas clara la palabra debe, tiene que.

En el momento de ingresar los productos el sistema

debe validar los mismos contra el catalogo de productos.
Si el producto no se encuentra en la lista el sistema
debe mostrar un error y rechazar la orden.