<Nombre del Proyecto>

Especificación de Requisitos de Software

<Sistema Completo o Subsistema>

Versión <1.0>

[Nota: La siguiente plantilla se proporciona para su uso con Rational Unified

Process. El texto entre corchetes y que se muestran en letra cursiva azul
(estilo = InfoBlue) se incluye para proporcionar orientación al autor, y debe
suprimirse antes de publicar el documento.]
Proyecto: xx Versión: 1.0
SRS – Especificación de Requisitos de Software Fecha: dd/mm/aaaa
<Identificador del documento>

Historial de Revisión
Fecha Versión Descripción Autor
<dd/mmm/aaaa> <x.x> <detalle> <Nombre>
Proyecto: xx Versión: 1.0
SRS – Especificación de Requisitos de Software Fecha: dd/mm/aaaa
<Identificador del documento>

Tabla de Contenidos

1. INTRODUCCIÓN.................................................................................................................4
1.1 Propósito....................................................................................................................4
1.2 Alcance......................................................................................................................4
1.3 Definiciones, Acrónimos y Abreviaturas..................................................................4
1.4 Referencias................................................................................................................4
1.5 Visión General...........................................................................................................4

2. DESCRIPCIÓN GENERAL.................................................................................................4

3. Requerimientos Específicos.........................................................................................5
3.1 Functionality..............................................................................................................5
3.2 Usability.....................................................................................................................5
3.3 Reliability..................................................................................................................6
3.4 Performance...............................................................................................................6
3.5 Supportability............................................................................................................7
3.6 Design Constraints.....................................................................................................7
3.7 On-line User Documentation and Help System Requirements.................................7
3.8 Purchased Components..............................................................................................7
3.9 Interfaces...................................................................................................................7
3.10 Licensing Requirements............................................................................................8
3.11 Legal, Copyright, and Other Notices.........................................................................8
3.12 Applicable Standards.................................................................................................8

4. Supporting Information..................................................................................................8
Proyecto: xx Versión: 1.0
SRS – Especificación de Requisitos de Software Fecha: dd/mm/aaaa
<Identificador del documento>

Especificación de Requisitos de Software

1. INTRODUCCIÓN
[La introducción de la Especificación de requisitos de software (SRS) debe
proporcionar una vista general de la SRS. Debe incluir el objetivo, el alcance, las
definiciones y acrónimos, las referencias, y la vista general del SRS.]
[Note: La especificación de requisitos de software (SRS) captura los requisitos de
software completos para el sistema, o una parte del sistema. El siguiente es un
esquema SRS típico para un proyecto con requisitos de estilo de lenguaje natural
sólo tradicional – no con modelado de casos de uso. Captura todos los requisitos en
un solo documento, con las secciones aplicables insertadas desde las
especificaciones complementarias (que ya no sería necesario). Para una plantilla de
un SRS utilizando el modelado de casos de uso, que consiste en un paquete que
contiene los casos de uso del modelo de casos de uso y especificaciones
complementarias aplicables y otra información de apoyo, ver rup_SRS-uc.dot.]
1.1 Propósito
[Especificar el propósito de este SRS. El SRS debe describir plenamente el
comportamiento externo de la aplicación o el subsistema identificado.
También se describen los requisitos no funcionales, las limitaciones de diseño
y otros factores necesarios para proporcionar una descripción completa y
exhaustiva de los requisitos para el software.]
1.2 Alcance
[Una breve descripción de la aplicación de software que se aplica el SRS; de la
función o de otra agrupación 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, Acrónimos y Abreviaturas
[Esta subsección debe proporcionar las definiciones de todos los términos,
siglas y abreviaturas necesarias para interpretar correctamente el SRS. Esta
información puede ser proporcionada por referencia al Glosario del Proyecto.]
1.4 Referencias
[Esta subsección debería proporcionar una lista completa de todos los
documentos que se hace referencia en cualquier lugar del SRS. Cada
documento debe ser identificado por el título, número de informe (si procede),
fecha y organización de publicación. Especificar las fuentes desde el cual
pueden obtenerse las referencias. Esta información podrá facilitarse por
referencia a un apéndice o a otro documento.]
1.5 Visión General
[Esta subsección debe describir lo que contiene el resto del SRS y explicar
cómo está organizado el documento.]

2. DESCRIPCIÓN GENERAL
[Esta sección del SRS debe describir los factores generales que afectan al producto
y sus requerimientos. Esta sección no establece requisitos específicos. En cambio,
proporciona una base para los requisitos que se definen en detalle en la sección 3 y
los hace más fáciles de entender. Incluir estos elementos como:
 Perspectiva del producto
Proyecto: xx Versión: 1.0
SRS – Especificación de Requisitos de Software Fecha: dd/mm/aaaa
<Identificador del documento>

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 sitúe el producto dentro del sistema e
identifique sus conexiones facilita la comprensión.
 Funciones del Producto
o Resumen de las funcionalidades principales que el producto debe
realizar, sin entrar en información de detalle.
o Las funcionalidades deben estar organizadas de manera que el
cliente o cualquier interlocutor pueda entenderlo perfectamente. Para
ello se pueden utilizar métodos textuales o gráficos.
 características de usuario
 restricciones
 supuestos y dependencias
 subconjuntos de requisitos]

3. REQUISITOS ESPECÍFICOS
[Esta es la sección más extensa y más importante del documento. Esta sección del
SRS debe contener todos los requisitos de software a un nivel de detalle suficiente
para permitir a los diseñadores diseñar 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 líneas generales para especificaciones adicionales se pueden insertar
directamente en esta sección, como se muestra a continuación.]
[Los requisitos se dispondrán en forma de listas numeradas para su identificación,
seguimiento, trazabilidad y validación]
3.1 FUNCIONALES
[Esta sección describe los requisitos funcionales del sistema para los
requisitos que se expresan en el estilo: lenguaje natural. Para muchas
aplicaciones, esto puede constituir la mayor parte del paquete de SRS y se
debería pensar en la organización de esta sección. Esta sección está
generalmente organizada por función, pero los métodos alternativos de
organización también pueden ser apropiados, por ejemplo, la organización por
el usuario u organización por subsistemas. Los Requisitos Funcionales pueden
incluir conjuntos de características, capacidades y seguridad.
Cuando las herramientas de desarrollo de aplicaciones, tales como
herramientas de requisitos, herramientas de modelado, etc., son empleadas
para captar la funcionalidad, esta sección del documento se refiere a la
disponibilidad de esos datos, indicando la ubicación y el nombre de la
herramienta que se utiliza para capturar los datos.]
3.1.1 <Un Requisito Funcional >
[La descripción del requisito]

3.2 Usabilidad
[Esta sección debe incluir todos los requisitos que afectan a la usabilidad.
Por ejemplo,
Proyecto: xx Versión: 1.0
SRS – Especificación de Requisitos de Software Fecha: dd/mm/aaaa
<Identificador del documento>

 Especificar el tiempo de capacitación 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 típicas 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 estándar CUA de IBM, estándar de interfaces de
IBM

3.2.1 <Un Requisito de Usabilidad>

[La descripción del requisito]

3.3 Reliability
[Requirements for reliability of the system should be specified here. Some
suggestions follow:
• Availability—specify 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?
• Accuracy—specify precision (resolution) and accuracy (by some
known standard) that is required in the system’s output.
• Maximum Bugs or Defect Rate—usually expressed in terms of
bugs per thousand of lines of code (bugs/KLOC) or bugs per function-
point( bugs/function-point).
• Bugs or Defect Rate—categorized 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 system’s functionality.]
3.3.1 <Reliability Requirement One>
[The requirement description.]

3.4 Performance
[The system’s 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.
Proyecto: xx Versión: 1.0
SRS – Especificación de Requisitos de Software Fecha: dd/mm/aaaa
<Identificador del documento>

3.4.1 <Performance Requirement One>

[The requirement description goes here.]

3.5 Soporte
[En esta sección se indica los requisitos que mejoren la compatibilidad y
facilidad de mantenimiento del sistema que está siendo construido,
incluyendo los estándares de codificación, convenciones de nombres, las
bibliotecas de clases, el acceso mantenimiento, utilidades de mantenimiento.]
3.5.1 <Supportability Requirement One>
[The requirement description goes here.]

3.6 Restricciones de Diseño

[En esta sección se debe indicar todas las limitaciones de diseño en el sistema
que está siendo construido. Las limitaciones de diseño representan las
decisiones de diseño que han sido indicadas inicialmente y deben ser
respetadas. Los ejemplos incluyen lenguajes de programación, los requisitos
del proceso de software, el uso previsto de las herramientas de desarrollo, de
arquitectura y diseño, los componentes adquiridos, las bibliotecas de clases,
etc.]
3.6.1 <Una restricción de Diseño>
[The requirement description goes here.]

3.7 Documentación de Usuario en Línea y Sistema de Ayuda

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

3.8 Componentes Adquiridos

[This section describes any purchased components to be used with the
system, any applicable licensing or usage restrictions, and any associated
compatibility and interoperability or interface standards.]
3.9 Interfaces
[Esta sección define las interfaces que deben ser soportadas por la aplicación.
Debe contener suficiente especificidad, protocolos, puertos y direcciones
lógicas, etc. para que el software pueda ser desarrollado y verificado con los
requisitos de interfaz.]
3.9.1 Interfaces de Usuario
[Describe la interfaz de usuario que es implementada por el software.]
3.9.2 Interfaces de Hardware
[Esta sección define las interfaces de hardware que son compatibles
con el software, incluyendo la estructura lógica, direcciones físicas,
comportamiento esperado, etc..]
3.9.3 Interfaces de Software
[This section describes software interfaces to other components of the
software system. These may be purchased components, components
reused from another application or components being developed for
subsystems outside of the scope of this SRS but with which this
software application must interact.]
Proyecto: xx Versión: 1.0
SRS – Especificación de Requisitos de Software Fecha: dd/mm/aaaa
<Identificador del documento>

3.9.4 Communications Interfaces

[Describe any communications interfaces to other systems or devices
such as local area networks, remote serial devices, etc.]

3.10 Requisitos de licencia

[Defines any licensing enforcement requirements or other usage restriction
requirements that are to be exhibited by the software.]

3.11 Requerimientos Legales, Copyright y Otros

[This section describes any necessary legal disclaimers, warranties, copyright
notices, patent notice, wordmark, trademark, or logo compliance issues for
the software.]

3.12 Applicable Standards

[This section describes by reference any applicable standard and the specific
sections of any such standards which apply to the system being described. For
example, this could include legal, quality and regulatory standards, industry
standards for usability, interoperability, internationalization, operating system
compliance, etc.]
4. Supporting Information
[The supporting information makes the SRS easier to use. It includes:
 Table of contents
 Index
 Appendices
These may include use-case storyboards or user-interface prototypes. When
appendices are included, the SRS should explicitly state whether or not the
appendices are to be considered part of the requirements.]