Estándar documentos de requisitos – versión 0.1 SERVIBANCA

LOGO
SERVIBANCA
Standard
Documento Requisitos
Versión X.X
Estándar documentos de requisitos – versión 0.1
SERVIBANCA
Estándar documentos de requisitos
Este documento esta destinado a capturar los requerimientos
capturados desde el cliente debido al resultado de las entrevistas,
encuestas, estudios y prototipeo con él.
1.1 captura de requisitos de usuarios
Aun cuando los requerimientos de los usuarios se originan a
partir de sus percepciones propias acerca de sus necesidades, es
necesario especificar estos requerimientos, a través de experiencias
anteriores con otros softwares. Es necesario poder llegar al mejor
acuerdo con el cliente a través de entrevistas y encuestas. El proceso
de captura de requerimientos es un proceso iterativo, y las
actividades para capturar los requerimientos deben ser repetidas
varias veces antes de que el documento de requerimientos de usuario
este completa.
1.2 determinación ambiente operacional
Determinar el ambiente operacional debiera ser el primer paso
en la definición de los requerimientos del usuario. Debe quedar claro
en que contexto del mundo real el software deberá operar, esta
descripción narrativa puede ser soportada por diagramas. Así también
debe especificarse la interacción con sistemas externos que puedan
verse involucrados en la futura operación del software.
1.3 especificación de los requerimientos de usuario
Cuando el ambiente operacional ha sido establecido, los
requerimientos
del
usuario
son
extraídos
y
organizados.
2
________________________________________
Estándar documentos de requisitos – versión 0.1
SERVIBANCA
Estándar documentos de requisitos – versión 0.1
SERVIBANCA
Consideraciones acerca de implementación serán omitidas, a menos
que ellas sean un requerimiento en si.
1.3.1 Clasificación de los requerimientos de usuario.
Los requerimientos de usuario caben en 2 categorías:
Requerimientos de capacidad
Requerimientos de Restricciones
Capacidades necesitadas por el Restricciones puestas por el usuario
usuario
para
solucionar
un en como el problema será resuelto o
problema o alcanzar objetivos.
el objetivo alcanzado.
Requerimientos de capacidad describen funciones y operaciones
necesitadas por el usuario. Definiciones de cantidad y precisión deberían
formar parte de las descripciones de las especificaciones de de una función
que se desee realice el sistema.
Los requerimientos de restricción ponen límites en la manera
que el software debe ser construido y operado. Por ejemplo, definiciones de
comunicaciones con sistemas externos, interfases de programas que ya
pueden existir, ya sea por que el software pertenece a un sistema más
grande, o por que el usuario necesita que ciertos protocolos, estándars,
computadores, sistemas operativos, librerías o kernels sean usados.
Los requerimientos de interfases podrían variar de acuerdo al tipo de
software que se esta construyendo. Para sistemas interactivos, el usuario
puede querer definir ejemplos de cuadros de diálogos requeridos,
incluyendo como debería ser manejado por el hardware (Ej.: Mouse,
teclado, paneles, etc.) y la asistencia que debería proveer el software (Ej.:
Ayuda en línea). Para sistemas batch, bastará con indicar los parámetros
que se necesitan, el tipo de salida y formato de esta.
Restricciones que el usuario quisiese colocar en el software incluyen
la calidad de los atributos tales como adaptabilidad, disponibilidad,
portabilidad y seguridad. El usuario debe describir las consecuencias que
pueden generar las perdidas de disponibilidad, u hoyos de seguridad, para
que el desarrollador pueda apreciar de manera precisa cuan critico es cada
función que desarrolla.
________________________________________
Estándar documentos de requisitos – versión 0.1
3
SERVIBANCA
Estándar documentos de requisitos – versión 0.1
SERVIBANCA
1.3.2 Atributos de requerimientos de usuario
Cada requerimiento de usuario debe incluir los atributos listados abajo
(a) Identificadores - cada requerimiento del usuario debe incluir
un identificador, para facilitar su seguimiento en las subsecuentes etapas.
(b)
Necesidad – requerimientos de usuario esenciales deben ser
marcados como tal. Requerimientos esenciales del usuario no son
negociables; los otros pueden ser menos vitales y pueden ser objeto de
negociación.
(c)
Prioridad – para entregas incrementales, cada usuario debe
incluir una medida de prioridades para que el desarrollador pueda fijarse un
orden de desarrollo.
(d)
Estabilidad – algunos de los requerimientos pueden saberse
que serán estables durante la vida esperada del software; otros pueden
depender de la respuesta de las siguientes fases de desarrollo, o pueden ser
objeto a cambios durante el ciclo de vida del software. Aquellos
requerimientos inestables deben ser marcados.
(e) Fuente – la fuente de cada requerimiento de usuario debe ser
especificada. Esto puede ser una referencia a un documento externo, (Ej.:
documento de requerimientos de usuarios) o el nombre del usuario, o
grupos de usuarios, que provean el requerimiento dado.
(f) Claridad - un requerimiento de usuario debe ser tan claro que
sólo posea una sola interpretación posible. Esto implica que no debe haber
ambigüedad. Si un termino usado en un contexto particular tiene múltiples
significados, el termino debe ser clasificado o reemplazado por otros mas
específicos.
(g) Verificabilidad – Cada requerimiento de usuario debe ser
verificable. Esto significa que debe ser posible:
- Chequear que el requerimiento ha sido incorporado al diseño
- Probar que el Software implementará el requerimiento
- Testear que el software implementa el requerimiento
________________________________________
Estándar documentos de requisitos – versión 0.1
4
SERVIBANCA