h

1. BISOFT 21 Proyecto de Ingeniería de Software 3 Nombre del Equipo
ERS
Especificación de Requerimientos del Software
1. Portada
Debe incluir, como mínimo: 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 período lectivo.
2. Audiencia
Las personas hacia las que va dirigido el documento
3. Tabla de contenidos
Debe mostrar los títulos (hasta 3 niveles) con la misma prioridad que tienen los apartados del
documento
4. Introducción
Esta sección debe incluir: una descripción de cada uno de los diferentes apartados que contiene
el documento, así como una descripción breve del proyecto.
5. Participantes del proyecto
Esta sección 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 desempeña en el proyecto, la organización a la que pertenece y cualquier otra
información adicional que se considere oportuna.
6. Descripción del Sistema Actual
Esta sección debe contener una descripción del sistema actual. Para describir el sistema actual
puede utilizarse cualquier técnica 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 sección se compone de lo siguiente.
• Descripción general de la forma en que trabaja actualmente, identificando los procesos
involucrados.
• Descripción de los procesos actuales (Diagramas de flujo y cuadro). Realice un
diagrama de flujos o de actividad y el siguiente cuadro para cada proceso.
# Descripción de la tarea Responsable Departamento Apoyo del Sistema de
Información Actual
• Descripción de la problemática actual. Identifique la problemática existente en los
procesos actuales.
7. Descripción de propuesta de mejora del sistema actual
Esta sección debe contener una descripción de la propuesta de mejora u optimización del
sistema actual.
Esta sección se compone de lo siguiente:
• Descripción general de la nueva propuesta
• Descripción de la mejora de procesos (Diagramas de flujo y cuadro)
# Descripción de la Responsable Departamento Apoyo del Sistema de Funcionalidades (Casos
1er Cuatrimestre 2008 Página 1 de 6

2. BISOFT 21 Proyecto de Ingeniería de Software 3 Nombre del Equipo
ERS
tarea Información Propuesto de uso)
• Descripción de los beneficios de la mejora
8. Objetivos del Sistema
Esta sección debe contener una lista con los objetivos que se esperan alcanzar cuando el
sistema software a desarrollar esté en explotación, especificados mediante la plantilla adjunta.
El objetivo debe contener un nombre, con verbos en infinitivo, y en la sección de descripción
deberá de tener una descripción amplia del mismo. Un objetivo, para este caso, es algo que el
sistema debe cumplir, y que reúne la descripción de varios requerimientos.
OBJ-<id> <nombre descriptivo>
Versión <número de la versión actual>
Autores <quien (es) lo escribe (n)>
Fuentes <quien (es) lo solicita (n)>
Descripción El sistema debe…
Importancia <Crítico, Importante, Deseable>
Urgencia <Inmediata, Puede Esperar>
Estado <En construcción, pendiente de negociación, pendiente de verificación,
pendiente de validación, validado>
Estabilidad <Alta, media, baja>
Comentarios
9. Catálogo de Requerimientos
Esta sección se divide en las siguientes subsecciones en las que se describen los
requerimientos del sistema. Cada uno de los grandes grupos de requerimientos de información,
funcionales y no funcionales, podrán dividirse para ayudar a la legibilidad del documento, por
ejemplo dividiendo cada subsección en requerimientos asociados a un determinado objetivo,
requerimientos con características 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 continuación:
ACT-<id> <nombre descriptivo>
Versión <número de la versión actual>
Autores <quien (es) lo escribe (n)>
Fuentes <quien (es) lo solicita (n)>
Descripción <Descripción del rol que representa este actor>
Comentarios
Indicar el nombre del perfil, el departamento al que pertenece, descripción de sus
responsabilidades
1er Cuatrimestre 2008 Página 2 de 6

3. BISOFT 21 Proyecto de Ingeniería de Software 3 Nombre del Equipo
ERS
11.Requerimientos funcionales
Esta sesión debe dividirse por gestiones (mantenimientos), para cada gestión se debe indicar lo
siguiente:
Diagrama de Casos de Uso
Muestra gráficamente 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 estándar de UML
para realizar el diagrama general de casos de uso.
Requerimientos de información y restricciones
Esto indica la información requerida para el concepto(s) manejado en la gestión y sus
restricciones.
Cada dato debe indicar el tipo (texto(cantidad de caracteres máximo), nùmero(tipo-
entero,decimal)).
Existen tres tipos de restricciones base en los requerimientos de información. Unicidad
(indicando cual es la llave), Obligatoriedad (indicando cuales datos son obligatorios), y Formato
especial (indicando si algún dato tiene un formato específico)
Esto es conocido como requerimientos de almacenamiento y de restricciones de información que
se hayan identificado, utilizando para especificarlos las plantillas para requerimientos de
información descritas a continuación:
Plantilla para requerimiento de almacenamiento
REQ- <id> <nombre descriptivo>
Versión <número de la versión actual>
Autores <quien (es) lo escribe (n)>
Fuentes <quien (es) lo solicita (n)>
Objetivos Asociados OBJ-X, OBJ-Y
Dependencias REQ-A, REQ-B
Descripción El sistema debe…
Datos específicos Del concepto relevante descrito en el campo anterior
Importancia <Crítico, Importante, Deseable>
Urgencia <Inmediata, Puede Esperar>
Estado <En construcción, pendiente de negociación, pendiente de
verificación, pendiente de validación, validado>
Estabilidad <Alta, media, baja>
Comentarios
1er Cuatrimestre 2008 Página 3 de 6

4. BISOFT 21 Proyecto de Ingeniería de Software 3 Nombre del Equipo
ERS
Plantilla para restricción
RES- <id> <nombre descriptivo>
Versión <número de la versión actual>
Autores <quien (es) lo escribe (n)>
Fuentes <quien (es) lo solicita (n)>
Objetivos Asociados OBJ-X, OBJ-Y
Dependencias REQ-A, REQ-B
Descripción La información debe satisfacer la siguiente restricción…
Importancia <Crítico, Importante, Deseable>
Urgencia <Inmediata, Puede Esperar>
Estado <En construcción, pendiente de negociación, pendiente de
verificación, pendiente de validación, validado>
Estabilidad <Alta, media, baja>
Comentarios
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 continuación:
UC-<id> <nombre descriptivo>
Versión <número de la versión actual>
Autor(es) <quien (es) lo escribe (n)>
Fuentes <quien (es) lo solicita (n)>
Objetivos OBJ-X, OBJ-Y
Asociados
Requerimientos REQ-A, REQ-B
Asociados
Actores asociados ACT-1, ACT-2
Descripción <Breve descripción de lo que hace en resumen el caso de uso>
General
Tipo: <Primario, Secundario>, <Esencial, Real>
Precondiciones <Condiciones necesarias para poder ejecutar el CU>
Postcondiciones <Condiciones en las que queda el sistema después de ejecutar el CU>
Curso Típico de Acción del Actor Respuesta del Sistema
Eventos 1. <Acciones del actor> 2. <Respuestas del Sistema>
3. 4.
Curso Alternativo:
Línea N: <Condición, Acción>
Línea N+2: <Condición, Acción>
Importancia <Crítico, Importante, Deseable>
Urgencia <Inmediata, Puede Esperar>
Estado <En construcción, pendiente de negociación, pendiente de verificación,
pendiente de validación, validado>
Estabilidad <Alta, media, baja>
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
cuales son los datos que se muestran y en que formato se muestran, en los cursos alternos se
1er Cuatrimestre 2008 Página 4 de 6

5. BISOFT 21 Proyecto de Ingeniería de Software 3 Nombre del Equipo
ERS
debe indicar si ocurren excepciones en cuanto a formato de datos, obligatoriedad, repetición 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 subsección debe contener la lista los requisitos no funcionales del sistema que se hayan
identificado, especificados mediante la plantilla para requisitos no funcionales descrita a
continuación:
NOF- <id> <nombre descriptivo>
Versión <número de la versión actual>
Autores <quien (es) lo escribe (n)>
Fuentes <quien (es) lo solicita (n)>
Objetivos Asociados OBJ-X, OBJ-Y
Dependencias REQ-A, REQ-B
Descripción El sistema debe <capacidad del sistema>
Tipo <Interfaz de Usuario, Hardware, Software, Entregables, Estándares,
Usabilidad, Integridad, Seguridad, Eficiencia, Rendimiento,
Recursos, Portabilidad, Protección, Legales, Económicos,
Interoperabilidad >
Importancia <Crítico, Importante, Deseable>
Urgencia <Inmediata, Puede Esperar>
Estado <En construcción, pendiente de negociación, pendiente de
verificación, pendiente de validación, validado>
Estabilidad <Alta, media, baja>
Comentarios
13.Matriz de Rastreabilidad (opcional)
Esta sección debe contener una matriz objetivo–requerimiento, 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 ….
REQ-1 • •
…. … … … …
CU-1 • •
…. … … … …
NOF-1 • •
…. … … … …
14.Glosario de Términos
El glosario de términos muestra los distintos conceptos y significados que serán utilizados
durante todo el análisis y diseño del sistema. Se puede seguir el siguiente estándar para
desarrollar el glosario de términos:
Término Categoría Descripción
Términos Actor, Concepto, Breve descripción del término que ayuda al lector a ubicar en un contexto
ordenados Caso de Uso determinado el documento de requerimientos.
alfabéticamente
1er Cuatrimestre 2008 Página 5 de 6

6. BISOFT 21 Proyecto de Ingeniería de Software 3 Nombre del Equipo
ERS
15.Modelo Conceptual
Muestra gráficamente los conceptos identificados como parte del problema y las relaciones entre
estos. Es la base del diagrama de clases de diseño, el cual surge dentro de la siguiente fase
(fase de desarrollo). Se debe seguir el estándar de UML para realizar el modelo conceptual.
16.Apéndices
Los apéndices se usarán para proporcionar información adicional a la documentación obligatoria
del documento. Sólo deben aparecer si se consideran oportunos y se identificarán con letras
ordenadas alfabéticamente: A, B, C, etc.
1er Cuatrimestre 2008 Página 6 de 6