Plantilla ERS
Plantilla ERS
Plantilla ERS
2. Audiencia
Las personas hacia las que va dirigido el documento
3. Tabla de contenidos
Debe mostrar los ttulos (hasta 3 niveles) con la misma prioridad que tienen los apartados del documento
4. Introduccin
Esta seccin debe incluir: una descripcin de cada uno de los diferentes apartados que contiene el documento, as como una descripcin breve del proyecto.
Descripcin general de la nueva propuesta Descripcin de la mejora de procesos (Diagramas de flujo y cuadro)
Descripcin de la Responsable Departamento Apoyo del Sistema de Funcionalidades (Casos
Pgina 1 de 6
de uso)
9. Catlogo de Requerimientos
Esta seccin se divide en las siguientes subsecciones en las que se describen los requerimientos del sistema. Cada uno de los grandes grupos de requerimientos de informacin, funcionales y no funcionales, podrn dividirse para ayudar a la legibilidad del documento, por ejemplo dividiendo cada subseccin en requerimientos asociados a un determinado objetivo, requerimientos con caractersticas comunes, etc.
10.
Perfiles de usuario
Este apartado debe contener una lista con los perfiles o actores que se hayan identificado, especificados mediante la plantilla para actores de casos de uso descrita a continuacin: ACT-<id> Versin Autores Fuentes Descripcin Comentarios <nombre descriptivo> <nmero de la versin actual> <quien (es) lo escribe (n)> <quien (es) lo solicita (n)> <Descripcin del rol que representa este actor>
Indicar el nombre del perfil, el departamento al que pertenece, descripcin de sus responsabilidades
Pgina 2 de 6
11.
Requerimientos funcionales
Esta sesin debe dividirse por gestiones (mantenimientos), para cada gestin se debe indicar lo siguiente: Diagrama de Casos de Uso Muestra grficamente todas las funcionalidades del sistema que abarcar el proyecto, es decir, todas las pactadas con el usuario como alcance del mismo. Se debe seguir el estndar de UML para realizar el diagrama general de casos de uso. Requerimientos de informacin y restricciones Esto indica la informacin requerida para el concepto(s) manejado en la gestin y sus restricciones. Cada dato debe indicar el tipo (texto(cantidad de caracteres mximo), nmero(tipoentero,decimal)). Existen tres tipos de restricciones base en los requerimientos de informacin. Unicidad (indicando cual es la llave), Obligatoriedad (indicando cuales datos son obligatorios), y Formato especial (indicando si algn dato tiene un formato especfico) Esto es conocido como requerimientos de almacenamiento y de restricciones de informacin que se hayan identificado, utilizando para especificarlos las plantillas para requerimientos de informacin descritas a continuacin:
de
Pgina 3 de 6
de
Casos de uso en formato expandido y sus restricciones Este apartado debe contener los casos de uso que se hayan identificado, especificados mediante la plantilla para requisitos funcionales descrita a continuacin: UC-<id> Versin Autor(es) Fuentes Objetivos Asociados Requerimientos Asociados Actores asociados Descripcin General Tipo: Precondiciones Postcondiciones Curso Tpico de Eventos <nombre descriptivo> <nmero de la versin actual> <quien (es) lo escribe (n)> <quien (es) lo solicita (n)> OBJ-X, OBJ-Y REQ-A, REQ-B ACT-1, ACT-2 <Breve descripcin de lo que hace en resumen el caso de uso> <Primario, Secundario>, <Esencial, Real> <Condiciones necesarias para poder ejecutar el CU> <Condiciones en las que queda el sistema despus de ejecutar el CU> Accin del Actor Respuesta del Sistema 1. <Acciones del actor> 2. <Respuestas del Sistema> 3. 4. Curso Alternativo: Lnea N: <Condicin, Accin> Lnea N+2: <Condicin, Accin> <Crtico, Importante, Deseable> <Inmediata, Puede Esperar> <En construccin, pendiente de negociacin, pendiente de verificacin, pendiente de validacin, validado> <Alta, media, baja>
Para el caso de uso en cada paso del curso normal de eventos, si el paso requiere una entrada de datos se debe indicar cuales son los datos de entrada, si posee una salida se debe indicar cuales son los datos que se muestran y en que formato se muestran, en los cursos alternos se
1er Cuatrimestre 2008 Pgina 4 de 6
debe indicar si ocurren excepciones en cuanto a formato de datos, obligatoriedad, repeticin de llaves entre otros. Para las restricciones del caso de uso se deben indicar todas las reglas del negocio que intervienen en el caso de uso
12.
Requerimientos no funcionales
Esta subseccin debe contener la lista los requisitos no funcionales del sistema que se hayan identificado, especificados mediante la plantilla para requisitos no funcionales descrita a continuacin: NOF- <id> Versin Autores Fuentes Objetivos Asociados Dependencias Descripcin Tipo <nombre descriptivo> <nmero de la versin actual> <quien (es) lo escribe (n)> <quien (es) lo solicita (n)> OBJ-X, OBJ-Y REQ-A, REQ-B El sistema debe <capacidad del sistema> <Interfaz de Usuario, Hardware, Software, Entregables, Estndares, Usabilidad, Integridad, Seguridad, Eficiencia, Rendimiento, Recursos, Portabilidad, Proteccin, Legales, Econmicos, Interoperabilidad > <Crtico, Importante, Deseable> <Inmediata, Puede Esperar> <En construccin, pendiente de negociacin, pendiente de verificacin, pendiente de validacin, validado> <Alta, media, baja>
13.
Esta seccin debe contener una matriz objetivorequerimiento, de forma que para cada objetivo se pueda conocer con qu requerimientos est asociado. El formato de la matriz de rastreabilidad puede verse en la siguiente figura:
OBJ-X
OBJ-Y
OBJ-Z
14.
Glosario de Trminos
El glosario de trminos muestra los distintos conceptos y significados que sern utilizados durante todo el anlisis y diseo del sistema. Se puede seguir el siguiente estndar para desarrollar el glosario de trminos:
Trmino Trminos ordenados alfabticamente Categora Actor, Concepto, Caso de Uso Descripcin Breve descripcin del trmino que ayuda al lector a ubicar en un contexto determinado el documento de requerimientos.
Pgina 5 de 6
15.
Modelo Conceptual
Muestra grficamente los conceptos identificados como parte del problema y las relaciones entre estos. Es la base del diagrama de clases de diseo, el cual surge dentro de la siguiente fase (fase de desarrollo). Se debe seguir el estndar de UML para realizar el modelo conceptual.
16.
Apndices
Los apndices se usarn para proporcionar informacin adicional a la documentacin obligatoria del documento. Slo deben aparecer si se consideran oportunos y se identificarn con letras ordenadas alfabticamente: A, B, C, etc.
Pgina 6 de 6