<Cdigo del Proyecto>-<Nombre del Proyecto>

Especificacin de Requerimientos del Software

(SRS)

Versin X.Y

Cajamarca, 2011
<Cdigo del Proyecto> <Nombre del Proyecto> Versin: x.y
Especificacin de Requerimientos del Software (SRS) Fecha: dd/mmm/yy
Proyecto 1

Tabla de Contenidos
1. Introduccin 3
1.1 Propsito 3
1.2 Alcance 3
1.3 Definiciones, Acrnimos y abreviaturas 3
1.4 Referencias 3
1.5 Generalidades 3

2. Descripcin Global 3
2.1 Reporte del Modelo de Casos de Uso 3
2.2 Consideraciones y Dependencias 3

3. Requerimientos Especficos 3
3.1 Funcionalidad 4
3.1.1 <Cdigo del Requerimiento> < Caso de Uso 1> 4
3.2 Facilidad de Uso 4
3.2.1 <Requerimiento de Uso 1> 4
3.3 Confiabilidad 4
3.3.1 <Cdigo del Requerimiento> <Requerimiento de Confiabilidad 1> 5
3.4 Desempeo 5
3.4.1 <Cdigo del Requerimiento> <Requerimiento de Desempeo 1> 5
3.5 Facilidad de Soporte 5
3.5.1 <Cdigo del Requerimiento> <Requerimiento de Soporte 1> 5
3.6 Restricciones de Diseo 5
3.6.1 <Cdigo del Requerimiento> <Restriccin de Diseo 1> 5
3.7 Interfaces 5
3.7.1 Interfaces de Usuarios 5
3.7.2 Interfaces de Hardware 6
3.7.3 Interfaces de Software 6
3.7.4 Interfaces de Comunicacin 6
3.8 Documentacin en Lnea y Requerimientos de Ayuda del Sistema 6
3.9 Requerimientos de Licencia 6
3.10 Metodologa de Desarrollo 6
3.11 Componentes Adquiridos 6
3.12 Otros Estndares Aplicables 6

Realizado por: <Elaborado Por> Pgina 2 de 7

Revisado por: <Revisado Por>
Aprobado por: <Aprobado Por>
<Cdigo del Proyecto> <Nombre del Proyecto> Versin: x.y
Especificacin de Requerimientos del Software (SRS) Fecha: dd/mmm/yy
Proyecto 1

Especificacin de Requerimientos del Software

(SRS)
1. Introduccin
[La introduccin a este documento debe incluir una visin general de todo el documento. Incluye el
propsito, alcance, definiciones, acrnimos, abreviaturas, referencias y generalidades del
proyecto.]
1.1 Propsito
[Especifica el propsito que cumple este documento para el proyecto.]

1.2 Alcance
[Una breve descripcin del alcance de este documento; con qu proyecto est asociado y cualquier
cosa que se pueda ver afectado o influenciado por este documento.]

1.3 Definiciones, Acrnimos y abreviaturas

[En esta seccin se debe de proveer las definiciones de todos los trminos, acrnimos y
abreviaturas requeridas para interpretar de manera apropiada el contenido de este documento.]

1.4 Referencias
[Esta seccin provee una lista completa de todos los documentos referencias o usados como base
para elaborar este documento. Identifique cada documento por su ttulo, nmero de reporte (si
aplica), fecha y organizacin que lo publica. Especifique las fuentes a partir de las cuales se
pueden obtener.]

1.5 Generalidades
[Esta seccin describe lo contenido en el resto del documento y explica como el documento se
encuentra organizado en lo adelante.]

2. Descripcin Global
2.1 Reporte del Modelo de Casos de Uso
[Cuando se usa modelamiento de caso de uso, esta seccin contiene una visin general del modelo
de casos de uso (al nivel de los paquetes funcionales y los actores para cada uno de ellos, as como
las integraciones) aplicables al sistema software o subsistema software. Este reporte incluye una
lista de con nombre y breve descripcin de todos los casos de usos y los actores, junto con los
diagramas y las relaciones aplicables entre ellos.]

2.2 Consideraciones y Dependencias

[En esta seccin se describen cualquier consideracin clave sobre factibilidad tcnica,
disponibilidad de subsistemas o componentes a utilizar, o cualquier otra consideracin que sustente
la viabilidad tcnica del producto.]

3. Requerimientos Especficos
[Esta seccin debe cubrir todos los requerimientos del software a un nivel de detalle suficiente que
permita a los diseadores realizar el diseo de un sistema que satisfaga dichos requerimientos y a
los testers probar que el sistema satisface dichos requerimientos. Cuando se use el modelamietno
con casos de uso se debern reflejar en trmino de casos de usos y actores.

NOTA: Todos los requerimientos deben ser perfectamente identificados a fin de poder realizar su
seguimiento en el tiempo. Para se propone emplear como esquema de identificacin de los
Realizado por: <Elaborado Por> Pgina 3 de 7
Revisado por: <Revisado Por>
Aprobado por: <Aprobado Por>
<Cdigo del Proyecto> <Nombre del Proyecto> Versin: x.y
Especificacin de Requerimientos del Software (SRS) Fecha: dd/mmm/yy
Proyecto 1

requerimientos el siguiente:
<Cdigo del Proyecto><cdigo del subsistema o mdulo><Tipo de Requerimiento><nmero
consecutivo>
Una vez establecido el cdigo del requerimiento no se debera cambiar durante el proceso de
desarrollo. ]

3.1 Funcionalidad
[Esta seccin describe los requerimientos funcionales del sistema para los requerimientos
definidos, expresado en lenguaje natural simple. Esta seccin podra organizarse en trmino de los
subsistemas funcionales en los que se descompondr el producto software.]

3.1.1 <Cdigo del Requerimiento> < Caso de Uso 1>

[Descripcin suficientemente detallada para el caso de uso.]

3.2 Facilidad de Uso

[Esta seccin deber incluir todos aquellos requerimientos que afecten la facilidad de uso del
producto. Por ejemplo:

Tiempo de requerimiento para un usuario normal y para un usuario experto en

convertirse en un ente productivo para ciertas operaciones del sistema.

Tiempos para tareas que puedan ser medidas para una tarea que sea tpica o usar la
facilidad de uso basada en las experiencias con soluciones similares.

Requerimientos que se ajusten a estndares para facilidad de uso, tales como IBMs CUA
standards y Microsofts GUI standards, o estndares definidos por la propia
organizacin. ]

3.2.1 <Requerimiento de Uso 1>

[Colocar aqu la descripcin detallada del requerimiento.]

3.3 Confiabilidad
[Los requerimientos de confiabilidad del sistema debe ser especificado siguiendo las sugerencias
siguientes:

Disponibilidad especificar el porcentaje de tiempo que el producto deber estar

disponible (xx.xx%), horas de uso, acceso al mantenimiento, modos de operacin
degradados, etc.

El tiempo medio entre dos fallas continuas (MTBF) usualmente especificado en horas,
pero puede ser en termino de das u otra unidad de medida.

Tiempo Medio de Reparacin (MTTR Mean Time to Repair)cuanto tiempo el sistema

puede estar fuera de operacin despus de haber fallado?1

Precisinresolucin y precisin requerido en las salidas del sistema..

Nmero Mximo de Defectos o Ratio de Defectosexpresados en trminos de defectos por

cientoso miles de ineas de cdigo (bugs/KLOC) o defectos por puntos de funcin
( bugs/function-point) permisibles (esto determina cierto criterio de calidad).

Defectos clasificados (Ratio)categorizados en defectos menores, significativos y

Realizado por: <Elaborado Por> Pgina 4 de 7

Revisado por: <Revisado Por>
Aprobado por: <Aprobado Por>
<Cdigo del Proyecto> <Nombre del Proyecto> Versin: x.y
Especificacin de Requerimientos del Software (SRS) Fecha: dd/mmm/yy
Proyecto 1

crticos]

3.3.1 <Cdigo del Requerimiento> <Requerimiento de Confiabilidad 1>

[Colocar aqu la descripcin del requerimiento.]

3.4 Desempeo
[Las caractersticas del desempeo, la que debe de incluir tiempos de respuestas especficos.
Cuando se requiera se deber hacer referencia explcita a los casos de usos sobre los que el
requerimiento se establece.

Tiempo de respuesta de una transaccin (promedio, mximo)

Transacciones por segundos (Throughput resultados obtenidos en una cierta unidad de

tiempo)

Capacidad, por ejemplo, el nmero de clientes o transacciones que el sistema puede

soportar.

Utilizacin de recursos, tales como memoria, disco, comunicaciones, y otros.

3.4.1 <Cdigo del Requerimiento> <Requerimiento de Desempeo 1>

[Colocar la descripcin del requerimientos.]

3.5 Facilidad de Soporte

[Esta seccin debe cubrir cualquier requerimiento que mejore la capacidad del soporte o
mantenimiento del sistema, incluyendo estndares de codificacin, convenciones para nombrar
(variables, operaciones, clases, funciones, procedimientos, atributos, parmetros, etc), libreras de
clases o cdigo.]

3.5.1 <Cdigo del Requerimiento> <Requerimiento de Soporte 1>

[Colocar la descripcin del requerimiento.]

3.6 Restricciones de Diseo

[Esta seccin debe tener las restricciones de diseo sobre el sistema. Estas restricciones
representan decisiones de diseo ajustadas a estndares definidos por la organizacin. Algunos
ejemplos a considerar incluyen, lenguajes, herramientas definidas, restricciones sobre la
arquitectura, componentes adquiridos, etc.]

3.6.1 Restricciones sobre la Arquitectura

3.6.1.1 <Cdigo del Requerimiento> <Restriccin de Diseo 1>

[Colocar aqu la descripcin.]

3.6.2 Restricciones sobre los Componentes

3.6.2.1 <Cdigo del Requerimiento> <Restriccin de Diseo 1>

[Colocar aqu la descripcin.]

3.7 Interfaces
[En esta seccin se deber definir las interfaces que deber soportar el sistema. Debe contener
adecuada especificacin sobre protocolos, puestos, direcciones lgicas..]

Realizado por: <Elaborado Por> Pgina 5 de 7

Revisado por: <Revisado Por>
Aprobado por: <Aprobado Por>
<Cdigo del Proyecto> <Nombre del Proyecto> Versin: x.y
Especificacin de Requerimientos del Software (SRS) Fecha: dd/mmm/yy
Proyecto 1

3.7.1 Interfaces de Usuarios

[Apoyar con el prototipo del producto software. Esto puede plasmarse en un documento a parte y
referenciarlo desde esta seccin.]

3.7.2 Interfaces de Hardware

[Describir las interfaces con hardware soportadas por el software, incluyendo estructura lgica,
direcciones fsicas, comportamientos esperados, y dems.]

3.7.3 Interfaces de Software

[Describir las interfaces con otros componentes del sistema integrado. Pueden ser componentes
adquiridos o re-usados de otras aplicaciones o simplemente componentes a ser desarrollados para
otros subsistemas desarrollados por otros equipos de proyecto..]

3.7.4 Interfaces de Comunicacin

[Describir las interfaces de comunicacin con otros Sistemas o dispositivos tales como redes de
rea local, dispositivos, etc.]

3.8 Documentacin en Lnea y Requerimientos de Ayuda del Sistema

[Describir aqu los requerimientos del sistema de documentacin en lnea y de las ayudas al
usuario.]

3.9 Requerimientos de Licencia

[Definir los requerimientos de licencias del producto (esto se debe solicitar cuando el proyecto se
tercerice).]

3.10 Metodologa de Desarrollo

[Definir los requerimientos de desarrollo (esto se debe solicitar cuando el proyecto se tercerice).]

3.11 Componentes Adquiridos

[Describir cualquier componente adquirido a ser usado con el sistema, incluyendo aspectos tales
como licencias o restricciones de uso (cantidad de usuarios, etc) y aspectos de compatibilidad y de
interoperatividad asociado, o los estndares de las interfaces de integracin.]

3.12 Otros Estndares Aplicables

[Considerar otros estndares aplicables al producto que no hayan sido definidos en las secciones
anteriores. Si los estndares aplican a requerimientos especficos, referenciar aquellos
requerimientos que se ven afectados por estos estndares., por ejemplo estndares legales, de
calidad o regulatorios, de la industria, interoperatividad, de sistema operativo, base de datos, etc.]

Realizado por: <Elaborado Por> Pgina 6 de 7

Revisado por: <Revisado Por>
Aprobado por: <Aprobado Por>
<Cdigo del Proyecto> <Nombre del Proyecto> Versin: x.y
Especificacin de Requerimientos del Software (SRS) Fecha: dd/mmm/yy
Proyecto 1

Historia de las Revisiones

Fecha Versin Descripcin Autor

<dd/mmm/yy> <x.x> <detalles> <nombre>

Realizado por: <Elaborado Por> Pgina 7 de 7

Revisado por: <Revisado Por>
Aprobado por: <Aprobado Por>