<Nombre del Proyecto> Documento de Requerimientos de Software

Versin <1.0>

Proyecto: xx DRS Documento de Requerimientos de Software <Nombre fsico del documento>

Versin: Fecha:

1.0 dd/mm/aaaa

Historial de Revisin
Fecha <dd/mmm/aaaa> Versin <x.x> Descripcin <detalle> Autor <Nombre>

Proyecto: xx DRS Documento de Requerimientos de Software <Nombre fsico del documento>

Versin: Fecha:

1.0 dd/mm/aaaa

Tabla de Contenidos
1. INTRODUCCIN.......................................................................................................................4 1.1 Propsito...........................................................................................................................4 1.2 Alcance.............................................................................................................................4 1.3 Definiciones, Acrnimos y Abreviaturas..........................................................................4 1.4 Referencias........................................................................................................................4 1.5 Visin General .................................................................................................................4 2. DESCRIPCIN GENERAL.......................................................................................................4 3. REQUISITOS ESPECFICOS....................................................................................................5 3.1 REQUERIMIENTOS DEL NEGOCIO............................................................................5 3.2 REQUERIMIENTOS TCNICOS ..................................................................................5 3.2.1 Usabilidad......................................................................................................................5 3.2.2 Reliability ......................................................................................................................5 3.2.3 Performance...................................................................................................................6 3.2.4 Soporte...........................................................................................................................6 3.2.5 Restricciones de Diseo.................................................................................................7 3.2.6 Otros...............................................................................................................................7 4. Informacin Adicional.................................................................................................................7

Proyecto: xx DRS Documento de Requerimientos de Software <Nombre fsico del documento>

Versin: Fecha:

1.0 dd/mm/aaaa

Documento de Requerimientos de Software

1. INTRODUCCIN
1.1 Propsito
[Especificar el propsito de este documento. El DRS debe describir plenamente el comportamiento externo de la aplicacin o el subsistema identificado. Tambin se describen los requisitos no funcionales, las limitaciones de diseo y otros factores necesarios para proporcionar una descripcin completa y exhaustiva de los requisitos para el software.]

1.2 Alcance
[Una breve descripcin de la aplicacin de software que se aplica el DRS; de la funcin o de otra agrupacin de subsistema; qu modelos de caso de uso se asocia con; y cualquier otra cosa es decir afectan o influenciados por este documento.]

1.3 Definiciones, Acrnimos y Abreviaturas

[Esta subseccin debe proporcionar las definiciones de todos los trminos, siglas y abreviaturas necesarias para interpretar correctamente el DRS. Esta informacin puede ser proporcionada por referencia al Glosario del Proyecto.]

1.4 Referencias

[Esta subseccin debera proporcionar una lista completa de todos los documentos que se hace referencia en cualquier lugar del DRS. Cada documento debe ser identificado por el ttulo, nmero de informe (si procede), fecha y organizacin de publicacin. Especificar las fuentes desde el cual pueden obtenerse las referencias. Esta informacin podr facilitarse por referencia a un apndice o a otro documento.]

1.5 Visin General

[Esta subseccin debe describir lo que contiene el resto del DRS y explicar cmo est organizado el documento.]

2.

DESCRIPCIN GENERAL

[Esta seccin del DRS debe describir los factores generales que afectan al producto y sus requerimientos. Esta seccin no establece requisitos especficos. En cambio, proporciona una base para los requisitos que se definen en detalle en la seccin 3 y los hace ms fciles de entender. Incluir estos elementos como: Perspectiva del producto o Indicar si es un producto independiente o parte de un sistema mayor. En el caso de tratarse de un producto que forma parte de un sistema mayor, un diagrama que site el producto dentro del sistema e identifique sus conexiones facilita la comprensin.

Funciones del Producto o o Resumen de las funcionalidades principales que el producto debe realizar, sin entrar en informacin de detalle. Las funcionalidades deben estar organizadas de manera que el cliente o cualquier interlocutor pueda entenderlo perfectamente. Para ello se pueden utilizar mtodos textuales o grficos.

Proyecto: xx DRS Documento de Requerimientos de Software <Nombre fsico del documento>

Versin: Fecha:

1.0 dd/mm/aaaa

Caractersticas de usuario restricciones supuestos y dependencias subconjuntos de requisitos]

3.

REQUISITOS ESPECFICOS

[Esta es la seccin ms extensa y ms importante del documento. Esta seccin del DRS debe contener todos los requisitos de software a un nivel de detalle suficiente para permitir a los diseadores disear un sistema para satisfacer esas necesidades, y los tester para probar que el sistema cumple estos requisitos. Al utilizar modelos de Casos de Uso, estos requisitos se capturan en los casos de uso y las especificaciones complementarias aplicables. Si el modelo de casos de uso no se utiliza, las lneas generales para especificaciones adicionales se pueden insertar directamente en esta seccin, como se muestra a continuacin.] [Los requisitos se dispondrn en forma de listas numeradas para su identificacin, seguimiento, trazabilidad y validacin]

3.1 REQUERIMIENTOS DEL NEGOCIO

[Esta seccin describe los requisitos especificados por el negocio. Ejemplo: RQN1-El proceso de Contratar profesor requiere de una interfaz web en la cual el aspirante pueda registrar sus datos.] Requerimiento 1 Requerimiento 2

3.2 REQUERIMIENTOS TCNICOS 3.2.1 Usabilidad

[Esta seccin debe incluir todos los requisitos que afectan a la usabilidad. Por ejemplo,

Especificar el tiempo de capacitacin necesaria para un usuario normal y un usuario avanzado para ser productivos en particular en las operaciones.

Especificar horas de tareas medibles para las tareas tpicas o basar los requisitos del nuevo sistema de usabilidad en otros sistemas que los usuarios conocen y les gusta.

Especificar el requisito para ajustarse a las normas comunes de usabilidad, tales como el estndar CUA de IBM, estndar de interfaces de IBM Un Requisito de Usabilidad [La descripcin del requisito]

3.2.2

Reliability

Proyecto: xx DRS Documento de Requerimientos de Software <Nombre fsico del documento>

Versin: Fecha:

1.0 dd/mm/aaaa

[Requirements for reliability of the system should be specified here. Some suggestions follow: Availabilityspecify the percentage of time available ( xx.xx%), hours of use, maintenance access, degraded mode operations, etc. Mean Time Between Failures (MTBF) this is usually specified in hours, but it could also be specified in terms of days, months or years. Mean Time To Repair (MTTR)how long is the system allowed to be out of operation after it has failed? Accuracyspecify precision (resolution) and accuracy (by some known standard) that is required in the systems output. Maximum Bugs or Defect Rateusually expressed in terms of bugs per thousand of lines of code (bugs/KLOC) or bugs per functionpoint( bugs/function-point). Bugs or Defect Ratecategorized in terms of minor, significant, and critical bugs: the requirement(s) must define what is meant by a critical bug; for example, complete loss of data or a complete inability to use certain parts of the systems functionality.] Reliability Requirement One> [The requirement description.]

3.2.3

Performance

[The systems performance characteristics should be outlined in this section. Include specific response times. Where applicable, reference related Use Cases by name. response time for a transaction (average, maximum) throughput, for example, transactions per second

capacity, for example, the number of customers or transactions the system can accommodate degradation modes (what is the acceptable mode of operation when the system has been degraded in some manner) resource utilization, such as memory, disk, communications, etc. Performance Requirement One [The requirement description goes here.]

3.2.4

Soporte

[En esta seccin se indica los requisitos que mejoren la compatibilidad y facilidad de mantenimiento del sistema que est siendo construido, incluyendo los estndares de codificacin, convenciones de nombres, las bibliotecas de clases, el acceso mantenimiento, utilidades de mantenimiento.] Supportability Requirement One [The requirement description goes here.]

Proyecto: xx DRS Documento de Requerimientos de Software <Nombre fsico del documento>

Versin: Fecha:

1.0 dd/mm/aaaa

[En esta seccin se debe indicar todas las limitaciones de diseo en el sistema que est siendo construido. Las limitaciones de diseo representan las decisiones de diseo que han sido indicadas inicialmente y deben ser respetadas. Los ejemplos incluyen lenguajes de programacin, los requisitos del proceso de software, el uso previsto de las herramientas de desarrollo, de arquitectura y diseo, los componentes adquiridos, las bibliotecas de clases, etc.]

3.2.5

Restricciones de Diseo

Una restriccin de Diseo> [The requirement description goes here.]

3.2.6

Otros

[Describes the requirements, if any, for on-line user documentation, help systems, help about notices, etc.]

4.

Informacin Adicional
Table of contents Index Appendices

[The supporting information makes the DRS easier to use. It includes:

These may include use-case storyboards or user-interface prototypes. When appendices are included, the DRS should explicitly state whether or not the appendices are to be considered part of the requirements.]