Sistema de gestin de eventos

Especificacin de Requerimientos de Software

Para eventos masivos

Versin 1.0
 Historial de Revisin
Fecha Version Descripcin Autor
14/08/2013 1.0 Gestion de eventos masivos ADSI-25
 Tabla de Contenidos
1. Introduccin

1.1 Propsito
1.2 Alcance
1.3 Definiciones, Siglas y Abreviaciones
1.4 Referencias
1.5 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 <Limitacin 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]
3.2.1 < Requerimiento de Usabilidad 1>
[La descripcin del requerimiento va aqui.]
3.3 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
 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]
3.9.3 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.]
3.9.4 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.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.]