Plantilla ers

1,228
-1

Published on

h

Published in: Economy & Finance
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,228
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
32
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Plantilla ers

  1. 1. BISOFT 21 Proyecto de Ingeniería de Software 3 Nombre del EquipoERS Especificación de Requerimientos del Software1. PortadaDebe incluir, como mínimo: logo de Cenfotec, nombre y/o logo del equipo, nombre y/o logo delcliente, nombre y/o logo del producto, nombre del documento, nombre del curso (BISOFT 21Proyecto 3), nombre de los profesores del curso, fecha de entrega y período lectivo.2. AudienciaLas personas hacia las que va dirigido el documento3. Tabla de contenidosDebe mostrar los títulos (hasta 3 niveles) con la misma prioridad que tienen los apartados deldocumento4. IntroducciónEsta sección debe incluir: una descripción de cada uno de los diferentes apartados que contieneel documento, así como una descripción breve del proyecto.5. Participantes del proyectoEsta sección debe contener una lista con todos los participantes en el proyecto, tantodesarrolladores como clientes y usuarios. Para cada participante se deberá indicar su nombre, elpapel que desempeña en el proyecto, la organización a la que pertenece y cualquier otrainformación adicional que se considere oportuna.6. Descripción del Sistema ActualEsta sección debe contener una descripción del sistema actual. Para describir el sistema actualpuede utilizarse cualquier técnica que se considere oportuno, por ejemplo Modelado del Negociocon Diagramas de Actividad de UML o diagramas de flujo. En caso de que el cliente no cuentecon 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 procesosinvolucrados.• Descripción de los procesos actuales (Diagramas de flujo y cuadro). Realice undiagrama 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 losprocesos actuales.7. Descripción de propuesta de mejora del sistema actualEsta sección debe contener una descripción de la propuesta de mejora u optimización delsistema 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 (Casos1er Cuatrimestre 2008 Página 1 de 6
  2. 2. BISOFT 21 Proyecto de Ingeniería de Software 3 Nombre del EquipoERS tarea Información Propuesto de uso)• Descripción de los beneficios de la mejora8. Objetivos del SistemaEsta sección debe contener una lista con los objetivos que se esperan alcanzar cuando elsistema 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óndeberá de tener una descripción amplia del mismo. Un objetivo, para este caso, es algo que elsistema 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>Comentarios9. Catálogo de RequerimientosEsta sección se divide en las siguientes subsecciones en las que se describen losrequerimientos 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, porejemplo dividiendo cada subsección en requerimientos asociados a un determinado objetivo,requerimientos con características comunes, etc.10.Perfiles de usuarioEste 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>ComentariosIndicar el nombre del perfil, el departamento al que pertenece, descripción de susresponsabilidades1er Cuatrimestre 2008 Página 2 de 6
  3. 3. BISOFT 21 Proyecto de Ingeniería de Software 3 Nombre del EquipoERS11.Requerimientos funcionalesEsta sesión debe dividirse por gestiones (mantenimientos), para cada gestión se debe indicar losiguiente:Diagrama de Casos de UsoMuestra 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 UMLpara realizar el diagrama general de casos de uso.Requerimientos de información y restriccionesEsto indica la información requerida para el concepto(s) manejado en la gestión y susrestricciones.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 Formatoespecial (indicando si algún dato tiene un formato específico)Esto es conocido como requerimientos de almacenamiento y de restricciones de información quese hayan identificado, utilizando para especificarlos las plantillas para requerimientos deinformación descritas a continuación:Plantilla para requerimiento de almacenamientoREQ- <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-YDependencias REQ-A, REQ-BDescripción El sistema debe…Datos específicos Del concepto relevante descrito en el campo anteriorImportancia <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>Comentarios1er Cuatrimestre 2008 Página 3 de 6
  4. 4. BISOFT 21 Proyecto de Ingeniería de Software 3 Nombre del EquipoERSPlantilla para restricciónRES- <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-YDependencias REQ-A, REQ-BDescripció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>ComentariosCasos de uso en formato expandido y sus restriccionesEste apartado debe contener los casos de uso que se hayan identificado, especificadosmediante 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-YAsociadosRequerimientos REQ-A, REQ-BAsociadosActores asociados ACT-1, ACT-2Descripción <Breve descripción de lo que hace en resumen el caso de uso>GeneralTipo: <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 SistemaEventos 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>ComentariosPara el caso de uso en cada paso del curso normal de eventos, si el paso requiere una entradade datos se debe indicar cuales son los datos de entrada, si posee una salida se debe indicarcuales son los datos que se muestran y en que formato se muestran, en los cursos alternos se1er Cuatrimestre 2008 Página 4 de 6
  5. 5. BISOFT 21 Proyecto de Ingeniería de Software 3 Nombre del EquipoERSdebe indicar si ocurren excepciones en cuanto a formato de datos, obligatoriedad, repetición dellaves entre otros.Para las restricciones del caso de uso se deben indicar todas las reglas del negocio queintervienen en el caso de uso12.Requerimientos no funcionalesEsta subsección debe contener la lista los requisitos no funcionales del sistema que se hayanidentificado, especificados mediante la plantilla para requisitos no funcionales descrita acontinuació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-YDependencias REQ-A, REQ-BDescripció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>Comentarios13.Matriz de Rastreabilidad (opcional)Esta sección debe contener una matriz objetivo–requerimiento, de forma que para cada objetivose pueda conocer con qué requerimientos está asociado. El formato de la matriz derastreabilidad puede verse en la siguiente figura: OBJ-X OBJ-Y OBJ-Z …. REQ-1 • • …. … … … … CU-1 • • …. … … … … NOF-1 • • …. … … … …14.Glosario de TérminosEl glosario de términos muestra los distintos conceptos y significados que serán utilizadosdurante todo el análisis y diseño del sistema. Se puede seguir el siguiente estándar paradesarrollar el glosario de términos:Término Categoría DescripciónTérminos Actor, Concepto, Breve descripción del término que ayuda al lector a ubicar en un contextoordenados Caso de Uso determinado el documento de requerimientos.alfabéticamente1er Cuatrimestre 2008 Página 5 de 6
  6. 6. BISOFT 21 Proyecto de Ingeniería de Software 3 Nombre del EquipoERS15.Modelo ConceptualMuestra gráficamente los conceptos identificados como parte del problema y las relaciones entreestos. 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éndicesLos apéndices se usarán para proporcionar información adicional a la documentación obligatoriadel documento. Sólo deben aparecer si se consideran oportunos y se identificarán con letrasordenadas alfabéticamente: A, B, C, etc.1er Cuatrimestre 2008 Página 6 de 6

×