<Nombre de proyecto>
Especificaciones suplementarias
Versión <1.0>
[Nota: la siguiente plantilla se proporciona para utilizarla con Rational Unified Process. Se incluye texto encerrado entre corchetes y que se muestra en cursivas azules (style=InfoBlue) para proporcionar orientación al autor y debe suprimirse antes de publicar el documento. Un párrafo que se entre después de este estilo se establecerá automáticamente como normal (style=Body Text).]
Historial de revisiones
Fecha |
Versión |
Descripción |
Autor |
<dd/mmm/aa> |
<x.x> |
<detalles> |
<nombre> |
|
|
|
|
|
|
|
|
|
|
|
|
Tabla de contenido
1.3 Definiciones, acrónimos y abreviaciones
3.1 <Requisito de utilización uno>
4.1 <Requisito de fiabilidad uno>
5.1 <Requisito de rendimiento uno>
6.1 <Requisito de capacidad de soporte uno>
7.1 <Restricción de diseño uno>
8. Additional Consideraciones adicionales de ingeniería de sistemas
8.3 Otros requisitos de seguridad del producto
8.4 Requisitos relacionados con las personas
9. Requisitos de la documentación del usuario y del sistema de ayuda en línea
11.4 Interfaces de comunicaciones
13. Avisos legales, de copyright y de otro tipo
Especificaciones suplementarias
[La introducción a las Especificaciones suplementarias debe proporcionar una visión general de todo el documento. Debe incluir el propósito, el ámbito, las definiciones, los acrónimos, abreviaciones, las referencias y la visión general de estas Especificaciones suplementarias.
Las Especificaciones suplementarias capturan los requisitos del sistema que todavía no se han capturado en los casos de uso del modelo de caso de uso. Estos requisitos incluyen:
· Requisitos legales y de regulación, que incluyen los estándares de la aplicación.
· Los atributos de calidad del sistema que se debe construir, que incluyen los requisitos de utilización, fiabilidad, rendimiento y capacidad de soporte.
· Otros requisitos como los de los sistemas operativos y entornos, la compatibilidad con otro software y las restricciones de diseño.]
[Especifique el propósito de estas Especificaciones suplementarias.]
[Breve descripción del ámbito de estas Especificaciones suplementarias; los proyectos con los que está asociado y cualquier otro aspecto que se vea afectado o influenciado por este documento.]
[Esta subsección debe proporcionar las definiciones de todos los términos, acrónimos y abreviaciones necesarios para interpretar correctamente las Especificaciones suplementarias. Esta información se puede proporcionar mediante la referencia al proyecto Glosario.]
[Este subsección debe proporcionar una lista completa de todos los documentos a los que se hace referencia en otros lugares de las Especificaciones suplementarias. Cada documento se debe identificar por título, número de informe (si es aplicable), fecha y organización de publicación. Especifique las fuentes de las que se han obtenido las referencias. Esta información puede proporcionarse en referencia a un apéndice o a otro documento.]
[Esta subsección debe describir lo que contiene el resto de las Especificaciones suplementarias y explicar cómo está organizado el documento.]
[Esta sección describe los requisitos funcionales adicionales del sistema expresados en formato de lenguaje natural.]
[Descripción del requisito.]
[Esta sección debe incluir todos aquellos requisitos que afectan a la utilización. Ejemplos:
· Especifique el tiempo de formación necesario para que los usuarios normales y los usuarios avanzados sean productivos en operaciones determinadas
· Especifique tiempos medibles de tareas para las tareas típicas, o bien
· Especifique los requisitos que se deben cumplir para los estándares comunes de utilización, por ejemplo, los estándares de CUA de IBM o los estándares de GUI de Microsoft]
Descripción del requisito.
[Aquí se deben especificar los requisitos de fiabilidad del sistema. Las sugerencias son las siguientes:
· ¿Disponibilidad? Especifique el porcentaje de tiempo disponible ( xx,xx%) las horas de uso, el acceso al mantenimiento, las operaciones de modalidad degradada, etc.
· ¿Tiempo medio entre errores (MTBF) ? Normalmente se especifica en horas, pero también se podría especificar en términos de días, meses o años.
· ¿Tiempo medio de reparación (MTTR) ? ¿Cuántotiempo puede estar el sistema sin funcionar después de fallar?
· ¿Precisión? especifique la exactitud (resolución) y la precisión (según algún estándar conocido) que se necesita en la salida de los sistemas.
· ¿Índice máximo de errores o defectos? Normalmente se expresa en términos de errores/KLOC (miles de líneas de código) o errores/punto de función.
· ¿Índice de errores o defectos ? Se categorizan como errores menores, significativos y graves: los requisitos deben definir qué significa un ¿error grave? (por ejemplo, una pérdida completa de datos o la incapacidad de utilizar determinadas partes de la funcionalidad del sistema).]
[Descripción del requisito.]
[En esta sección se deben describir brevemente las características de rendimiento. Incluya tiempos de respuesta específicos. Siempre que sea aplicable, haga referencia a los casos de uso relacionados por su nombre. En general, se deben asociar 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.
· Tiempo de respuesta de una transacción (medio, máximo)
· Rendimiento (por ej., transacciones por segundo)
· Capacidad (por ej., el número de clientes o transacciones que puede albergar el sistema)
· Modalidades de degradación (cuál es la modalidad aceptable de operación cuando el sistema se ha degradado de alguna manera)
· Utilización de recursos: memoria, disco, comunicaciones, etc.]
[Descripción del requisito.]
[Esta sección indica los requisitos que mejorarán 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, los programas de utilidad de mantenimiento.]
[Descripción del requisito.]
[Esta sección debe indicar 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 o de diseño, componentes adquiridos, bibliotecas de clases, etc.]
[Descripción del requisito.]
[La ingeniería de sistemas requiere potencialmente que se traten otros tipos de requisitos:]
[Por ejemplo, peso, tamaño, alimentación,...]
[Por ejemplo, humedad, contaminantes, térmicos, eléctricos, mecánicos,...]
[Por ejemplo, seguridad, otros factores de calidad (por ej, capacidad de supervivencia)]
[Describa los requisitos impuestos al sistema en soporte de las personas que utilizarán y darán soporte al sistema: los ejemplos incluyen las capacidades de formación (se incluirá el equipo y los materiales para la formación), capacidades de mantenimiento, consideraciones ergonómicas no tratadas por las descripciones y los estándares de la interfaz.]
[Describa los requisitos impuestos al sistema debido a consideraciones logísticas - que incluyen mantenimiento, soporte, transporte, suministro y alojamiento de los sistemas existentes.]
[Describa los requisitos, si existen, para la documentación del usuario en línea, los sistemas de ayuda, la ayuda sobre avisos, etc.]
[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.]
[Esta sección define las interfaces que deben estar soportadas por el sistema. Debe contener la especificidad, los protocolos, los puertos, 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.]
[Describa las interfaces de usuario que va a implementar el sistema.]
[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.]
[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.]
[Describa las interfaces de comunicaciones con otros sistemas o dispositivos como las redes de área local, etc.]
[Define los requisitos de aplicación de licencias y otros requisitos de restricción de uso que mostrará el sistema.]
[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, los avisos de patente, las marcas registradas o los logotipos para el sistema.]
[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, internacionalización, cumplimiento del sistema operativo, etc.]