<Nombre de proyecto>

Especificación de requisitos de sistema

 

 

 

Versión <1.0>

 

 

[Nota: se proporciona la siguiente plantilla para utilizar con Rational Unified Process. El texto que aparece entre corchetes y que se visualiza en cursiva azul (style=InfoBlue) se incluye para proporcionar instrucciones al autor y se debe suprimir antes de publicar el documento. Un párrafo entrado siguiendo este estilo se establece automáticamente en normal (style=Body Text).]


Historial de revisiones

Fecha

Versión

Descripción

Autor

<dd/mmm/aa>

<x.x>

<detalles>

<nombre>

 

 

 

 

 

 

 

 

 

 

 

 

 


Tabla de contenido

1.       Introducción         

1.1     Propósito     

1.2     Ámbito     

1.3     Definiciones, acrónimos y abreviaciones     

1.4     Referencias     

1.5     Visión general     

2.       Descripción global    

3.       Requisitos específicos

3.1     Capacidades del sistema

3.1.1         <Capacidad del sistema uno>        

3.2     Requisitos no funcionales

3.2.1 Utilización 

3.2.2 Fiabilidad 

3.2.3 Rendimiento 

3.2.4 Capacidad de soporte 

3.2.5 Restricciones de diseño 

3.2.6 Consideraciones adicionales de la ingeniería de sistemas 

3.2.6.1 Requisitos físicos 

3.2.6.2 Requisitos del entorno 

3.2.6.3 Otros requisitos de seguridad del producto 

3.2.6.4 Requisitos relacionados con las personas 

3.2.6.5 Requisitos de logística 

3.2.7 Requisitos de la documentación del usuario y del sistema de ayuda en línea 

3.2.8 Componentes adquiridos 

3.2.9 Interfaces 

3.2.9.1 Interfaces de usuario 

3.2.9.2 Interfaces de hardware 

3.2.9.3 Interfaces de software 

3.2.9.4 Interfaces de comunicaciones 

3.2.10 Requisitos de licencia 

3.2.11 Avisos legales, de copyright y de otro tipo 

3.2.12 Estándares aplicables

4.       Información de soporte    


Especificación de requisitos del sistema

1.                  Introducción

[La introducción a la Especificación de los requisitos del sistema (SysRS) proporciona una visión general de todos los SysRS. Incluye el propósito, el ámbito, las definiciones, los acrónimos, las abreviaciones, las referencias y la visión general de los SysRS.]

[Nota: los SysRS capturan los requisitos completos del sistema para el sistema o para una parte del sistema. A continuación se proporciona un esquema típico de SysRS para un proyecto utilizando solamente requisitos de estilo de lenguaje natural - sin modelado de casos de uso.  Captura todos los requisitos en un único documento, con las Especificaciones suplementarias combinadas, o material equivalente insertado.]

1.1     Propósito

[Especifique el propósito de este SysRS. El SysRS describe completamente las capacidades funcionales y de comportamiento del sistema identificado. También describe los requisitos no funcionales, las restricciones de diseño y otros factores necesarios para proporcionar una descripción amplia y completa de los requisitos del sistema.]

1.2     Ámbito

[Breve descripción del sistema al que se aplica el SysRS o cualquier otro aspecto afectado o influenciado por este documento.]

1.3     Definiciones, acrónimos y abreviaciones

[Esta subsección proporciona las definiciones de todos los términos, acrónimos y abreviaciones necesarios para interpretar adecuadamente el SysRS. Esta información se puede proporcionar mediante referencia al proyecto Glosario.]

1.4     Referencias

[Esta subsección proporciona una lista completa de todos los documentos a los que se hace referencia en otros lugares del SysRS. Identifique cada documento por título, número de informe (si es aplicable), fecha y organización de publicación. Especifique las fuentes de las que pueden obtenerse las referencias. Esta información se puede proporcionar mediante la referencia a un apéndice o a otro documento.]

1.5     Visión general

[Esta subsección describe lo que contiene el resto del SysRS y explica cómo está organizado el documento.]

2.                  Descripción global

[Esta sección del SysRS describe los factores generales que afectan al sistema y sus requisitos. Esta sección no indica requisitos específicos.  En su lugar, proporciona información de fondo para estos requisitos, que se definen en detalle en la Sección 3 y facilita su comprensión. Incluya elementos como los siguientes:

En esta sección se puede hacer referencia al artefacto de visión, en lugar de replicar material de ese documento.]

3.                  Requisitos específicos

[Esta sección del SysRS contiene todos los requisitos del sistema a un nivel de detalle suficiente para permitir a los diseñadores diseñar un sistema para satisfacer estos requisitos y a los verificadores verificar que el sistema satisface estos requisitos.]

3.1               Capacidades del sistema

[Esta sección describe las capacidades necesarias del sistema, expresadas en forma de lenguaje natural. Para muchos sistemas, esto puede constituir la mayor parte del paquete del SysRS y se debe pensar en la organización de esta sección. Esta sección se organiza normalmente por característica, función o grupo funcional (rastreando desde el artefacto de visión), pero es posible que también sean adecuados métodos de organización alternativos, como por ejemplo la organización por usuario o rol.

Esta sección describe el perfeccionamiento de la característica o función en los requisitos constitutivos, detallando los requisitos que de esta forma se derivan. Se describe el comportamiento que es necesario que muestre el sistema en soporte de estos requisitos derivados, junto con los requisitos de rendimiento asociados (tiempo de respuesta, velocidad, productividad, velocidades, frecuencia, exactitud, precisión, capacidad, etc.). Esta descripción del comportamiento también incluye comportamiento en caso de condiciones de error o anomalía (manejo de una entrada errónea, condiciones inesperadas, recuperación, etc.). Es posible que no sea necesario especificar en todos los casos cómo se van a manejar los errores y los sucesos inesperados. En muchos casos, se puede dejar esta decisión en manos del arquitecto del sistema.]

3.1.1          <Capacidad del sistema uno>

[Descripción de la capacidad y su perfeccionamiento.]

3.2                 Requisitos no funcionales

[Nota: si se ha producido el artefacto de especificaciones suplementarias, puede simplemente incluirlo aquí. Trata los mismos temas.]

3.2.1          Utilización

[Esta sección incluye todos aquellos requisitos que afectan a la utilización. Ejemplos:

3.2.1.1     <Requisito de utilización uno>

[Descripción del requisito.]

3.2.2          Fiabilidad

[Especifique aquí los requisitos de fiabilidad del sistema. Las sugerencias son las siguientes:

3.2.2.1     <Requisito de fiabilidad uno>

[Descripción del requisito.]

3.2.3          Rendimiento

[En esta sección describa brevemente las características de rendimiento del sistema. Incluya tiempos de respuesta específicos. Siempre que sea aplicable, haga referencia a los casos de uso relacionados por su nombre. En general, asocie todas las capacidades necesarias, ya sea descritas en formato de caso de uso o simplemente mediante texto, con alguna sentencia de rendimiento (describiendo cómo el sistema debe proporcionar la capacidad o función). Es mejor mantener estas sentencias de rendimiento próximas a la capacidad afectada (en la parte "requisitos especiales" de una descripción de caso de uso, por ejemplo). Aquí puede mantener sentencias de requisitos que sea necesario verificar, pero que no están alineadas con ninguna capacidad específica. Algunas de las características de rendimiento son las siguientes:

3.2.3.1      <Requisito de rendimiento uno>

[Descripción del requisito.]

3.2.4          Capacidad de soporte

[Esta sección indica los requisitos que mejoran la capacidad de soporte o de mantenimiento del sistema que se está creando, incluyendo los estándares de codificación, los convenios de denominación, las bibliotecas de clases, el acceso al mantenimiento y los programas de utilidad de mantenimiento.]

3.2.4.1    <Requisito de capacidad de soporte uno>

[Descripción del requisito.]

3.2.5          Restricciones de diseño

[Esta sección indica las restricciones de diseño del sistema que se está creando. Las restricciones de diseño representan decisiones de diseño que son obligatorias y que se deben cumplir. Los ejemplos incluyen lenguajes de software, requisitos de proceso de software, uso prescrito de herramientas de desarrollo, restricciones arquitectónicas y de diseño, componentes adquiridos, bibliotecas de clases, etc.]

3.2.5.1     <Restricción de diseño uno>

[Descripción del requisito.]

3.2.6     Consideraciones adicionales de ingeniería de sistemas

[La ingeniería de sistemas requiere potencialmente que se traten otros tipos de requisitos:]

3.2.6.1  Requisitos físicos

[Por ejemplo, peso, tamaño, alimentación, etc.]

3.2.6.2  Requisitos del entorno

[Por ejemplo, humedad, contaminantes, térmicos, eléctricos, mecánicos, etc.]

3.2.6.3  Otros requisitos de seguridad del producto

[Por ejemplo, seguridad, otros factores de calidad (por ejemplo, capacidad de supervivencia).]

3.2.6.4   Requisitos relacionados con las personas

[Describa los requisitos impuestos al sistema en soporte de las personas que utilizan y dan soporte al sistema. Los ejemplos incluyen las capacidades de formación (se incluirá el equipo y los materiales para la formación), las capacidades de mantenimiento y consideraciones ergonómicas no tratadas por las descripciones y los estándares de la interfaz.]

3.2.6.5   Requisitos logísticos

[Describa los requisitos impuestos al sistema debido a consideraciones de logística, que incluyen mantenimiento, soporte, transporte, suministro y alojamiento de los sistemas existentes.]

3.2.7          Requisitos de la documentación del usuario y del sistema de ayuda en línea

[Describe los requisitos, si existen, para la documentación del usuario en línea, los sistemas de ayuda, la ayuda sobre avisos, etc.]

3.2.8          Componentes adquiridos

[Esta sección describe los componentes adquiridos que se utilizarán con el sistema, las restricciones de uso o licencia aplicables, así como los estándares de interfaz o compatibilidad/interoperatibilidad asociados.]

3.2.9          Interfaces

[Esta sección define las interfaces que deben estar soportadas por el sistema. Contiene la especificidad, los protocolos, los puertos y las direcciones lógicas, etc. adecuados para que se pueda desarrollar y verificar el sistema en relación a los requisitos de la interfaz. También se debe describir los requisitos que se impondrán a las interfaces internas al sistema. Estos surgirán, por ejemplo, cuando exista la restricción de que el diseño del sistema utilice componentes de hardware o software internamente.]

3.2.9.1     Intefaces de usuario

[Describa las interfaces de usuario que va a implementar el sistema.]

3.2.9.2      Interfaces de hardware

[Esta sección define las interfaces de hardware a las que va a dar soporte el sistema, incluyendo la estructura lógica, las direcciones físicas, el comportamiento esperado, etc.]

3.2.9.3       Interfaces de software

[Esta sección describe las interfaces de software a las que dará soporte el sistema, en términos de las operaciones y las señales soportadas (y para las cuales es necesario soporte), los protocolos y las características de los datos.]

3.2.9.4       Interfaces de comunicaciones

[Describa las interfaces de comunicaciones con otros sistemas o dispositivos como las redes de área local, etc.]

3.2.10        Requisitos de licencia

[Define los requisitos de aplicación de licencias u otros requisitos de restricción de uso que mostrará el sistema.]

3.2.11        Avisos legales, de copyright y de otro tipo

[Esta sección describe los requisitos de cumplimiento necesarios de las declaraciones de limitación de responsabilidad legal, las garantías, los avisos de copyright, el aviso de patente, las marcas registradas o los logotipos.]

3.2.12        Estándares aplicables

[Esta sección describe por referencia los estándares aplicables y las secciones específicas de tales estándares que se aplican al sistema que se está describiendo. Por ejemplo, podría incluir estándares legales, cualitativos o normativos, estándares del sector para la utilización, interoperatividad, internacionalidad, cumplimiento del sistema operativo, etc.]

4.                  Información de soporte

[La información de soporte facilita la utilización del SysRS.  Incluye lo siguiente:

Estos pueden incluir información sobre prototipos arquitectónicos y de interfaz de usuario. Cuando se incluyen estos apéndices, el SysRS debe indicar explícitamente si los apéndices se consideran o no parte de los requisitos.]