<Nombre Proyecto> Especificacin de Requerimientos de Software Para <Subsistema o Caracterstica>

Version <1.0>
[Nota: La siguiente plantilla es proveda para su uso con el Rational Unified Process. El texto encerrado por corchetes y mostrado en cursiva azul (estilo=InfoBlue) esta incluido para proveer una gua al autor y debera ser eliminado antes de publicar el documento. Un prrafo ingresado siguiendo este estilo automticamente ser seteado a normal. (estilo=Body Text).]

Historial de Revisin
Fecha <dd/mm/yy> Versin <x.x> <detalles> Descripcin Autor <nombre>

Tabla de Contenidos
1. Introduccin 1.1 1.2 1.3 1.4 1.5 Propsito Alcance Definiciones, Siglas y Abreviaciones Referencias Visin General

2. Descripcin 3. Especificacin de los Requerimientos 3.1 Funcionalidad 3.1.1 < Requerimiento de Funcionalidad 1> 3.2 Usabilidad 3.2.1 < Requerimiento de Usabilidad 1> 3.3 Confiabilidad 3.3.1 < Requerimiento de Confiabilidad 1> 3.4 Ejecucin 3.4.1 <Requerimiento de Rendimiento 1> 3.5 Compatibilidad 3.5.1 < Requerimiento de Compatibilidad Nro.1> 3.6 Limitaciones del diseo 3.6.1 <Limitacion del diseo 1> 3.7 Documentacin en lnea del usuario y Requerimientos de ayuda al sistema 3.8 Componentes Comprados 3.9 Interfaces 3.9.1 Interfaces de usuario 3.9.2 Interfaces de hardware 3.9.3 Interfaces de software 3.9.4 Interfaces de comunicacin 3.10 Requerimientos de concesin de licencias 3.11 Avisos de derechos de autor, legales y otros 3.12 Normas Aplicables 4. Informacin de Apoyo

Especificacin de Requerimientos de Software

1. Introduccin
[La Introduccin de la Especificacin de Requerimientos de Software (SRS) debe proveer una visin general de todo el SRS. Debe incluir el propsito, alcance, definiciones, acrnimos, abreviaciones, referencias y visin general del SRS.] [Note: La Especificacin de Requerimientos de Software (SRS) captura todos los Requerimientos para el sistema, o para una porcin del sistema. El seguimiento es un tpico bosquejo de SRS para un proyecto usando solo el tradicional estilo de requerimientos de lenguaje natural sin modelos de caso de uso. Se capturan todos los requerimientos en un documento, con secciones aplicables insertadas de las Especificaciones Suplementarias (que ya no sern necesarias). Para una plantilla de un SRS usando modelamiento de casos de uso, que consiste en un paquete conteniendo casos de uso del modelo de casos de uso y Especificaciones Suplementarias y otra informacin de apoyo, vea rup_SRS-uc.dot.] [Muchos arreglos diferentes de un SRS son posibles. Consulte IEEE830 [1998] para una mayor explicacin de estas elaboraciones, as como otras opciones para la organizacin de un SRS.] 1.1 Propsito [Especifique el propsito de este SRS. El SRS debe describir completamente el comportamiento externo de la aplicacin o del subsistema identificado. Tambin describe los requerimientos no funcionales, las limitaciones del diseo y otros factores necesarios para proporcionar una descripcin completa y comprensiva de los requerimientos para el software.] 1.2 Alcance [Una breve descripcin de la aplicacin de software SRS; la funcin o agrupacin otro subsistema, qu modelo de casos de uso (s) est asociado, y cualquier otra cosa que se ve afectada o influenciada por este documento.] 1.3 Definiciones, Siglas y Abreviaciones [Esta subseccin debe proporcionar las definiciones de todos los trminos, siglas y abreviaturas requeridas para interpretar apropiadamente el SRS. Esta informacin puede ser proporcionada por referencia al Glosario del proyecto.] 1.4 Referencias [Esta seccin debe proporcionar una lista completa de todos los documentos referenciados en cualquier lugar en el SRS. Cada documento debe ser identificado por ttulo, nmero de informe (si procede), fecha y organizacin que publica. Especificar las fuentes de donde las referencias se pueden obtener. Esta informacin puede ser proporcionada por referencia a un apndice o a otro documento.] 1.5 Vista General [Esta subseccin debe describir lo que el resto de la SRS contiene y explicar cmo est organizado el documento.]

2.

Descripcin
[Esta seccin del SRS debe describir los factores generales que afectan al producto y sus requerimientos. Esta seccin no establece requerimientos especficos. En cambio, proporciona una base para los requerimientos que se definen en detalle en la seccin 3 y los hace ms fciles de entender. Incluir estos elementos como: - Perspectiva del producto - Funciones del producto - Caractersticas de los usuarios - Limitaciones

- Supuestos y dependencias - Subconjuntos de requerimientos]

3.

Requerimientos Especficos
[Esta seccin del SRS debe contener todos los requerimientos de software a un nivel de detalle suficiente para permitir a los diseadores disear un sistema para satisfacer estos requerimientos, y los probadores para probar que el sistema cumple estos requerimientos. Al utilizar modelos de casos de uso, estos requerimientos son capturados por los casos de uso y las especificaciones complementarias aplicables. Si el modelado de casos de uso no se utiliza, las lneas generales para especificaciones adicionales se pueden insertar directamente en esta seccin, como se muestra abajo.]

3.1 Funcionalidad [Esta seccin describe los requisitos funcionales del sistema para los requisitos que se expresan en el estilo del lenguaje natural. Para muchas aplicaciones, esto puede constituir la mayor parte del paquete de SRS y se debera pensar a la organizacin de esta seccin. Esta seccin es generalmente organizado por funcin, pero los mtodos alternativos de organizacin tambin puede ser apropiados, por ejemplo, la organizacin por usuario u organizacin por subsistemas. Los requisitos funcionales pueden incluir conjuntos de caractersticas, capacidades y seguridad. Cuando las herramientas de desarrollo de aplicaciones, tales como herramientas de necesidades, herramientas de modelado, etc, son empleados para captar la funcionalidad, esta seccin del documento se refieren a la disponibilidad de esos datos, indicando la ubicacin y el nombre de la herramienta que se utiliza para capturar los datos .] 3.1.1 < Requerimiento de Funcionalidad 1> [La descripcin del requerimiento va aqui.] 3.2 Usabilidad [Esta seccin debe incluir todos los requisitos que afectan a la usabilidad. Por ejemplo, - Especificar el tiempo de entrenamiento necesario para un usuario normal y un usuario de la energa para ser productivos en particular las operaciones - Especificar mediciones de los tiempos para las tareas tpicas o basar los requisitos del nuevo sistema de usabilidad en otros sistemas que los usuarios conocen y les gusta - Especificar la obligacin de ajustarse a las normas comunes de usabilidad, como las normas de IBM CUA los estndares de Microsoft interfaz grfica de usuario] < Requerimiento de Usabilidad 1> [La descripcin del requerimiento va aqui.] Confiabilidad [Requerimientos para la confiabilidad del sistema debe ser especificada aqu. Continuacin algunas sugerencias: - Disponibilidad a especificar el porcentaje de tiempo disponible (xx, xx%), horas de uso, acceso para mantenimiento, las operaciones de modo de degradado, etc - Tiempo medio entre fallos (MTBF) - esto por lo general se especifica en horas, pero tambin puede ser especificada en trminos de das, meses o aos. - Tiempo medio de reparacin (MTTR)-por cunto tiempo el sistema les permite estar fuera de operacin despus de que ha fallado? - Precisin especifican precisin (resolucin) y la precisin (por alguna norma se conoce) que se requiere en la salida del sistema. - Nmero mximo de bugs y defectos Tarifa-por lo general se expresa en trminos de errores por cada mil de lneas de cdigo (bugs / kloc) o por errores de puntos de funcin (bugs / punto de funcin-). - Errores o defecto clasificarse Tarifa-en trminos de menor importancia, significativo, y fallos crticos: el requisito (s) debe definir qu se entiende por una "crtica" errores, por ejemplo, la

3.2.1 3.3

prdida completa de datos o una incapacidad total para el uso de determinadas partes de la funcionalidad del sistema.] 3.3.1 < Requerimiento de Confiabilidad 1> [La descripcin del requerimiento va aqui.]

3.4 Rendimiento [Las caractersticas de rendimiento del sistema se deben abordar en esta seccin. Incluye los tiempos de respuesta especfica. En su caso, los asuntos de referencia relacionadas con el uso por su nombre. - Tiempo de respuesta para una transaccin (promedio, mximo) - Rendimiento de procesamiento, por ejemplo, las transacciones por segundo - La capacidad, por ejemplo, el nmero de clientes o transacciones que el sistema puede adaptarse - Modos de degradacin (lo que es el modo aceptable de funcionamiento cuando el sistema se ha degradado de alguna manera) - Utilizacin de recursos, como memoria, disco, comunicaciones, etc 3.4.1 < Requerimiento de Rendimiento 1> [La descripcin del requerimiento va aqui.]

3.5 Compatibilidad [Esta seccin indica los requerimientos que mejoraran la capacidad de soporte o mantenimiento del sistema que est siendo construido, incluyendo las normas de codificacin, convenciones de nombres, las bibliotecas de clases, el acceso mantenimiento, los servicios de mantenimiento.] 3.5.1 < Requerimiento de Compatibilidad 1> [La descripcin del requerimiento va aqui.]

3.6 Limitaciones del Diseo [Esta seccin debe indicar todas las limitaciones de diseo en el sistema que est siendo construido. Limitaciones del diseo representan las decisiones de diseo que han recibido el mandato y deben ser atendidas. Los ejemplos incluyen lenguajes de programacin, los requerimientos de proceso del software, el uso pre-escrito de herramientas de desarrollo, arquitectnico y restricciones de diseo, componentes comprados, las bibliotecas de clases, etc] 3.6.1 <Limitacin del diseo 1> [La descripcin del requerimiento va aqui.]

3.7 Documentacin en lnea del usuario y Requerimientos de ayuda al sistema [Describe los requerimientos, si las hubiere, para la documentacin en lnea del usuario, sistemas de ayuda, ayuda sobre anuncios, etc] 3.8 Componentes Comprados [Esta seccin describe los componentes comprados para ser utilizados con el sistema, cualquier concesin de licencias aplicables o restricciones de uso, y cualquier compatibilidad y la interoperabilidad asociados o interfaz de normas.] 3.9 Interfaces [Esta seccin define las interfaces que deben ser apoyadas por la aplicacin. Debe contener una adecuada especificidad, protocolos, puertos y direcciones lgicas, etc para que el software pueda ser desarrollado y verificado en contra de los requisitos de interfaz.] 3.9.1 Interfaces de Usuario [Describe las interfaces de usuario que seran implementadas por el software].

3.9.2

Interfaces de Hardware [Esta seccin define las interfaces de hardware que sean compatibles con el software, incluyendo la estructura lgica, direcciones fsicas, el comportamiento esperado, etc] Interfaces de Software [Esta seccin describe las interfaces de software a otros componentes del sistema de software. Estos pueden comprar los componentes, los componentes reutilizados desde otra aplicacin o componentes que estn siendo desarrollados para subsistemas fuera del alcance de este SRS pero con el que esta aplicacin de software debe interactuar.] Interfaces de Comunicaciones [Describe cualquier interfaces de comunicacin con otros sistemas o dispositivos tales como redes de rea local y remota de dispositivos de serie, etc]

3.9.3

3.9.4

3.10 Requerimientos de concesin de licencias [Define los requerimientos de concesin de licencias de ejecucin o de otros requerimientos de restriccin de uso que se expondrn por el software.] 3.11 Avisos de derechos de autor, legales y otros [Esta seccin describe todas las Limitaciones de las medidas legales, garantas, avisos de copyright, aviso de patente, logotipo, marca o logotipo de las cuestiones de cumplimiento para el software.] 3.12 Normas Aplicables [Esta seccin describe por referencia cualquier estndar aplicable y las secciones especficas de alguna de esos estndares que se aplican al sistema que se describe. Por ejemplo, esto podra incluir estndares legales, normas de calidad y regulacin, los estndares del sector para la usabilidad, la interoperabilidad, la internacionalizacin, el cumplimiento del sistema operativo, etc]

4.

Informacin de Apoyo
[La informacin de apoyo hace que el SRS ms fcil de usar. Incluye: - Tabla de contenidos - ndice - Apndices Estos pueden incluir guiones grficos de casos de uso o prototipos de interfaz de usuario. Cuando se incluyen apndices, el SRS debe especificar si los anexos deben ser considerados parte de los requisitos o no son parte.]