BISOFT 21 Proyecto de Ingeniera de Software 3 ERS

Nombre del Equipo

Especificacin de Requerimientos del Software

1. Portada
Debe incluir, como mnimo: logo de Cenfotec, nombre y/o logo del equipo, nombre y/o logo del cliente, nombre y/o logo del producto, nombre del documento, nombre del curso (BISOFT 21 Proyecto 3), nombre de los profesores del curso, fecha de entrega y perodo lectivo.

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.

5. Participantes del proyecto

Esta seccin debe contener una lista con todos los participantes en el proyecto, tanto desarrolladores como clientes y usuarios. Para cada participante se deber indicar su nombre, el papel que desempea en el proyecto, la organizacin a la que pertenece y cualquier otra informacin adicional que se considere oportuna.

6. Descripcin del Sistema Actual

Esta seccin debe contener una descripcin del sistema actual. Para describir el sistema actual puede utilizarse cualquier tcnica que se considere oportuno, por ejemplo Modelado del Negocio con Diagramas de Actividad de UML o diagramas de flujo. En caso de que el cliente no cuente con un sistema automatizado, describir los procesos que se desean automatizar. Esta seccin se compone de lo siguiente. Descripcin general de la forma en que trabaja actualmente, identificando los procesos involucrados. Descripcin de los procesos actuales (Diagramas de flujo y cuadro). Realice un diagrama de flujos o de actividad y el siguiente cuadro para cada proceso.
# Descripcin de la tarea Responsable Departamento Apoyo del Sistema de Informacin Actual

Descripcin de la problemtica actual. Identifique la problemtica existente en los procesos actuales.

7. Descripcin de propuesta de mejora del sistema actual

Esta seccin debe contener una descripcin de la propuesta de mejora u optimizacin del sistema actual. Esta seccin se compone de lo siguiente:
#

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

1er Cuatrimestre 2008

BISOFT 21 Proyecto de Ingeniera de Software 3 ERS tarea Informacin Propuesto

Nombre del Equipo

de uso)

Descripcin de los beneficios de la mejora

8. Objetivos del Sistema

Esta seccin debe contener una lista con los objetivos que se esperan alcanzar cuando el sistema software a desarrollar est en explotacin, especificados mediante la plantilla adjunta. El objetivo debe contener un nombre, con verbos en infinitivo, y en la seccin de descripcin deber de tener una descripcin amplia del mismo. Un objetivo, para este caso, es algo que el sistema debe cumplir, y que rene la descripcin de varios requerimientos. OBJ-<id> Versin Autores Fuentes Descripcin Importancia Urgencia Estado Estabilidad Comentarios <nombre descriptivo> <nmero de la versin actual> <quien (es) lo escribe (n)> <quien (es) lo solicita (n)> El sistema debe <Crtico, Importante, Deseable> <Inmediata, Puede Esperar> <En construccin, pendiente de negociacin, pendiente de verificacin, pendiente de validacin, validado> <Alta, media, baja>

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

1er Cuatrimestre 2008

Pgina 2 de 6

BISOFT 21 Proyecto de Ingeniera de Software 3 ERS

Nombre del Equipo

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:

Plantilla para requerimiento de almacenamiento

REQ- <id> Versin Autores Fuentes Objetivos Asociados Dependencias Descripcin Datos especficos Importancia Urgencia Estado Estabilidad Comentarios <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 Del concepto relevante descrito en el campo anterior <Crtico, Importante, Deseable> <Inmediata, Puede Esperar> <En construccin, pendiente de negociacin, pendiente verificacin, pendiente de validacin, validado> <Alta, media, baja>

de

1er Cuatrimestre 2008

Pgina 3 de 6

BISOFT 21 Proyecto de Ingeniera de Software 3 ERS

Nombre del Equipo

Plantilla para restriccin

RES- <id> Versin Autores Fuentes Objetivos Asociados Dependencias Descripcin Importancia Urgencia Estado Estabilidad Comentarios <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 La informacin debe satisfacer la siguiente restriccin <Crtico, Importante, Deseable> <Inmediata, Puede Esperar> <En construccin, pendiente de negociacin, pendiente verificacin, pendiente de validacin, validado> <Alta, media, baja>

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>

Importancia Urgencia Estado Estabilidad Comentarios

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
1er Cuatrimestre 2008 Pgina 4 de 6

BISOFT 21 Proyecto de Ingeniera de Software 3 ERS

Nombre del Equipo

cuales son los datos que se muestran y en que formato se muestran, en los cursos alternos se 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>

Importancia Urgencia Estado Estabilidad Comentarios

13.

Matriz de Rastreabilidad (opcional)

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:

REQ-1 . CU-1 . NOF-1 .

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 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

1er Cuatrimestre 2008

BISOFT 21 Proyecto de Ingeniera de Software 3 ERS alfabticamente

Nombre del Equipo

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.

1er Cuatrimestre 2008

Pgina 6 de 6