0% encontró este documento útil (0 votos)
397 vistas11 páginas

Formato ERS

Este documento provee una especificación de requerimientos del software para un proyecto. Incluye secciones para introducir el objetivo y alcance, definir términos clave, listar documentos relacionados, y describir requerimientos funcionales y no funcionales. También incluye una sección para casos de uso con resúmenes y diagramas. El propósito es reunir todos los requisitos del sistema para proveer una descripción completa antes del desarrollo de software.

Cargado por

angelesfire
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOC, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
397 vistas11 páginas

Formato ERS

Este documento provee una especificación de requerimientos del software para un proyecto. Incluye secciones para introducir el objetivo y alcance, definir términos clave, listar documentos relacionados, y describir requerimientos funcionales y no funcionales. También incluye una sección para casos de uso con resúmenes y diagramas. El propósito es reunir todos los requisitos del sistema para proveer una descripción completa antes del desarrollo de software.

Cargado por

angelesfire
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOC, PDF, TXT o lee en línea desde Scribd

Especificación de Requerimientos del Software <Nombre del Proyecto> | Versión: <x.y.

z>

Especificación de Requerimientos del Software


Proyecto: <Nombre del Proyecto
Versión: <x.y.z>

Descripción del proceso: El objetivo de este documento es obtener reunidos todos los
requerimientos del sistema, este describe las funciones del sistema, los requisitos no funcionales,
características del diseño, y otros elementos necesarios para proporcionar una descripción
completa y comprensiva de los requisitos para el software a desarrollar.

1
Especificación de Requerimientos del Software <Nombre del Proyecto> | Versión: <x.y.z>

Historial de Revisiones
Versión Fecha Autor Descripción
<x.y.z> <dd/mm/aa> <nombre> <especificaciones>

2
Especificación de Requerimientos del Software <Nombre del Proyecto> | Versión: <x.y.z>

3
Especificación de Requerimientos del Software <Nombre del Proyecto> | Versión: <x.y.z>

4
Especificación de Requerimientos del Software <Nombre del Proyecto> | Versión: <x.y.z>

Índice de Contenido

Especificación de Requerimientos del Software...................................................................................................................4


1. Introducción................................................................................................................................................................4
1.1 Objetivo..............................................................................................................................................................4
1.2 Alcance...............................................................................................................................................................4
1.3 Definición, Acrónimos y Abreviaturas...........................................................................................................4
1.4 Documentos relacionados.................................................................................................................................4
1.5 Visión General.....................................................................................................................................................4
2. Requerimientos Funcionales.......................................................................................................................................4
3. Requerimientos No Funcionales..................................................................................................................................5
3.1 Usabilidad.............................................................................................................................................................5
3.2 Confiabilidad........................................................................................................................................................5
3.3 Seguridad.............................................................................................................................................................5
3.4 Desempeño...........................................................................................................................................................5
3.5 Mantenimiento y Actualización...........................................................................................................................5
3.6 Soportabilidad y Operabilidad.............................................................................................................................6
3.7 Limitación de Diseño...........................................................................................................................................6
3.8 Requerimientos de Documentación en Línea y de Sistemas de Ayuda.............................................................6
3.9 Interfaces..............................................................................................................................................................6
4. Casos de Uso................................................................................................................................................................7
4.1 Resumen y Actores..................................................................................................................................................7
4.2 Especificaciones de Casos de Uso..........................................................................................................................7
4.3 Diagrama.................................................................................................................................................................8

5
Especificación de Requerimientos del Software <Nombre del Proyecto> | Versión: <x.y.z>

Especificación de Requerimientos del Software


1. Introducción

1.1 Objetivo
Mencionar el objetivo de este documento (esto debería ser relativamente corto).

1.2 Alcance
Describir el alcance, mencionar los proyectos asociados y determinar que se ve afectado por este
documento.

1.3 Definición, Acrónimos y Abreviaturas


En este apartado se debe mostrar las definiciones de todos los términos, siglas y abreviaciones
requeridos para entender este documento, a su vez estas se deben reflejar en el glosario del
sistema.

1.4 Documentos relacionados


Para poder visualizar las referencias a otros documentos, se debe de llenar la tabla que se muestra
a continuación:

Título Fecha Organización Identificador del


documento
<título> <dd/mm/aa> <nombre> <Id documento>

1.5 Visión General


Describir el contenido de la Especificación de Requerimientos del Software y explicar la
organización de este documento.

2. Requerimientos Funcionales
Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera
que éste provea. En este apartado se debe describir lo que el sistema tendrá que hacer, los factores
que afectan al producto y satisfacen los requerimientos. Se debe llenar la siguiente tabla:

Nombre del Requerimiento: Colocar el nombre del requerimiento funcional.

Identificación del requerimiento: Identificación del requerimiento funcional (con un número o un


conjunto de caracteres que debe verse reflejado en el apartado de
definición, acrónimos y abreviaturas).
Características: Esta característica fue previamente definida en el documento
Visión del Sistema. Estas características son las que generan
cada uno de los requerimientos que se expresarán en esta tabla.

6
Especificación de Requerimientos del Software <Nombre del Proyecto> | Versión: <x.y.z>

Aquí se debe de realizar una descripción del requerimiento funcional. Se debe colocar información
suficiente de tal manera que sirva de ayuda para el desarrollador del sistema. Cualquier
representación gráfica debe ser anexada en este apartado.
Atributo: Prioridad Alta /Media Alta / Media / Media
Baja / Baja La prioridad es: <colocar una de las
opciones>

7
Especificación de Requerimientos del Software <Nombre del Proyecto> | Versión: <x.y.z>

3. Requerimientos No Funcionales
Describa los requerimientos no funcionales para este documento. Los requerimientos no funcionales
tienen que ver con las características que de una u otra forma puedan limitar el sistema como son: el
rendimiento (en tiempo y espacio), confiabilidad, interfaces, Habilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

3.1 Usabilidad
En este apartado se debe incluir todos los requerimientos que afecten la usabilidad. Esto debe
incluir: el tiempo que se tomará un usuario en aprender a utilizar el sistema y se podría explicar por
qué debe ser rápido el aprendizaje, los tiempos medibles de tarea para las tareas típicas y los
requerimientos para concordar con estándares.

3.2 Confiabilidad
Aquí se deben detallar los requerimientos de confiabilidad del sistema. Describa las características
de confiabilidad explicado la posibilidad del sistema de realizar las funciones para las que fue
diseñado sin presentar fallos. Entre estos requerimientos puede mencionar características como la
disponibilidad, el porcentaje de fallas máximo, etc.

3.3 Seguridad
Aquí se deben detallar los requerimientos de seguridad del sistema. Esto incluye si el acceso al
sistema será controlado con nombres de usuario y contraseñas, que solo los usuarios con
privilegios de administrador podrán accesar a las funciones administrativas y los usuarios normales
no podrán.

3.4 Desempeño
En este apartado se debe ver reflejado las características de desempeño del sistema. Se debe
especificar: el tiempo de respuesta para una transacción (promedio), capacidad (número de clientes
y transacciones), rendimiento del procesamiento (Ej. transacciones por segundo) y cuando el
sistema se ha degradado cuál es el modo aceptable de operación.

3.5 Mantenimiento y Actualización


En este apartado se debe ver reflejado los requerimientos de mantenimiento y actualización. La
capacidad de mantenimiento es la habilidad que se tiene para realizar cambios al producto en el
tiempo y la capacidad de actualización es la habilidad que se tiene para entregar las versiones del
producto a bajo costo a los clientes con un mínimo de tiempo de descarga. Una característica clave
para apoyar este objetivo es la descarga automática de parches o actualizaciones y actualizaciones
del equipo del usuario final. También debemos utilizar formatos para archivos de datos que incluyan
suficientes metadatos para permitirnos trasformar con seguridad la información existente del
usuario durante una actualización.

3.6 Soportabilidad y Operabilidad


Especificar los requerimientos de soportabilidad y operabilidad del sistema. La soportabilidad la
habilidad de proveer soporte técnico eficiente y a buen precio y la operabilidad es la habilidad que
se tiene de hospedar y operar el software como un ASP (Proveedor de Servicios de Aplicaciones).

8
Especificación de Requerimientos del Software <Nombre del Proyecto> | Versión: <x.y.z>

3.7 Limitación de Diseño


En este apartado se debe indicar cualquier limitación de diseño en el sistema que es construido.
Esto significa la decisiones de diseño que se han asignado de forma obligatoria. Por ejemplo:
lenguajes de software, requerimientos del proceso de software, uso de herramientas de desarrollo,
componentes comprados, etc.

3.8 Requerimientos de Documentación en Línea y de Sistemas de Ayuda


En caso de que exista se debe describir los requerimientos, para la documentación en línea del
usuario, sistemas de ayuda, ayuda sobre avisos, etc.

3.9 Interfaces
En este apartado se definen las interfaces que debe apoyar la aplicación, como son: las interfaces
de usuario, interfaces de software, interfaces de . Para que el software pueda ser creado y probado
contra los requerimientos de la interfaz, debe incluir la especificidad adecuada protocolos,
puertos,direcciones lógicas, etc.
En caso de que aplique es conveniente hacer referencia a estándares de la aplicación
ocorporativos.

3.9.1 Interfaces de Usuario


Describir las interfaces de usuario que van a hacer ejecutadas por el software.

3.9.2 Interfaces de Software


Hay que describir las interfaces de software hacia otro componentes del sistema. Pueden ser:
componentes comprados, reutilizados o realizados para subsistemas fuera del alcance de
este documento.

3.9.3 Interfaces de Hardware


Aquí se describen comentarios de cualquier interfaz de hardware que debe ser apoyada por
el software, esto incluye: comportamiento, estructura lógica, etc.

3.9.4 Interfaces de Comunicaciones


Se debe definir las interfaces de comunicaciones a los demás sistemas o dispositivos como:
redes LAN y dispositivos seriales remoto

4. Casos de Uso

4.1 Resumen y Actores

9
Especificación de Requerimientos del Software <Nombre del Proyecto> | Versión: <x.y.z>

Casos de Uso Actores participantes


Realizar un resumen de los casos de uso Identificar los actores que intervienen.

4.2 Especificaciones de Casos de Uso


En este apartado se debe recoger la especificación completa de cada caso de uso. Esto incluye los campos:
nombre, descripción, actores, precondiciones, flujo normal, flujo alternativo, puntos de extensión, entre
otros. Se debe elaborar una tabla de especificación por cada caso de uso.

Caso de Uso
Nombre: Colocar nombre del caso de uso.
Descripción: Describir la responsabilidad y el propósito del caso
de uso.
Requerimiento: Identificar los requerimientos que abarcan a este
caso de uso.
Precondición: Tiene que ver con las condiciones en la que debe
estar el sistema para que se ejecute el caso de uso.
Ejemplo: registro y autenticación del cliente.
Flujo Normal:
En el flujo de casos de uso se describe lo que hace el actor y lo que hace el sistema en respuesta.
Se expresa en forma de un diálogo entre actor y sistema. El flujo básico del caso de uso describe
lo que sucede dentro del sistema. Este flujo puede ser representado en forma gráfica. Hay que
tomar en cuenta que el flujo de un caso de uso, debería tener entre cinco y siete pasos
aproximadamente.

Actor Sistema
Describir cada paso del flujo realizado por Describir cada paso del flujo realizado por algún
un actor. 1. 3. 5. recurso del sistema. 2. 4. 6.

Flujo Alterno:
el flujo alterno se refleja el comportamiento alternativo debido a las irregularidades que ocurren en
el flujo de eventos normal. Pueden ser tan largos como sea necesario para describir los eventos
asociados al comportamiento alternativo.

Actor Sistema
Describir cada paso alterno del flujo Describir cada paso alterno del flujo realizado por
realizado por un actor. 1.1 2.1 3.1 algún recurso del sistema. 1.2 2.2 3.2

10
Especificación de Requerimientos del Software <Nombre del Proyecto> | Versión: <x.y.z>

Caso de Uso
Poscondición: Listar las condiciones en que se encuentra el
sistema después de haberse ejecutado el sistema.
Requerimientos Especiales: Nombrar y describir cualquier requerimiento que no
halla sido abarcado por el flujo normal o los alternos.
Puntos de Extensión: Se debe mencionar y describir los puntos en los
cuales el flujo de eventos se extiende por otros
casos de uso.

Nota: Cada paso del flujo de los eventos debe ser enumerado, manteniendo una secuencia entre
los pasos del flujo realizado por un actor y los pasos del flujo realizado por algún recurso del
sistema.

4.3 Diagrama
En este apartado se deben reflejar los diagramas de casos de uso inicial del sistema. Los
diagramas de casos de uso son una representación gráfica de una parte o todos los actores y
casos de uso del sistema, incluyendo sus interacciones y estos pueden ser desarrollados en
una herramienta de modelado visual. La construcción del Diagrama de Casos de Uso se inicia
con la elaboración del Diagrama de Casos de Uso Inicial, el refinamiento del mismo puede
contemplarse en iteraciones posteriores.

11

También podría gustarte