PARTES DE UN SRS

IEEE std. 830

UDIS. FI. UPM

ndice General I
1 Introducci n o
1.1 1.2 1.3 1.4 1.5 Prop sito . . . . . . . . . . . . . . . . . o Ambito del Sistema . . . . . . . . . . . . De niciones, Acr nimos y Abreviaturas . o Referencias . . . . . . . . . . . . . . . . Visi n General del Documento . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3
3 3 3 3 3

2 Descripci n General o
2.1 2.2 2.3 2.4 2.5 2.6

Perspectiva del Producto . . . . Funciones del Producto . . . . . Caracter sticas de los Usuarios .
Restricciones . . . . . . . . . . Suposiciones y Dependencias . . Requisitos Futuros . . . . . . . . . . . . . . . . . . . . . . . . .

4
4 4 4 4 5 5

3 Requisitos Espec cos

3.1 3.2 3.3 3.4 3.5 3.6

Interfaces Externas . . . . Funciones . . . . . . . . . Requisitos de Rendimiento Restricciones de Dise~o . . n Atributos del Sistema . . . Otros Requisitos . . . . .

5
7 7 8 8 9 9

4 Ap ndices e

IEEE std. 830

UDIS. FI. UPM

1 Introducci n o
En esta secci n se proporcionar una introducci n a todo el documento de o a o Especi caci n de Requisitos Software ERS. Consta de varias subsecciones: o prop sito, mbito del sistema, de niciones, referencias y visi n general del o a o documento. En esta subsecci n se de nir el prop sito del documento ERS y se especi o a o car a quien va dirigido el documento. a

1.1 Prop sito o

1.2 Ambito del Sistema

En esta subsecci n o Se podr dar un nombre al futuro sistema p.ej. MiSIstema a Se explicar lo que el sistema har y lo que no har . a a a Se describir n los bene cios, objetivos y metas que se espera alcanzar a con el futuro sistema Se referenciar n todos aquellos documentos de nivel superior p.e. en a Ingenier a de Sistemas que incluyen Hardware y Software, deber a man

tenerse la consistencia con el documento de especi caci n de requisitos o globales del sistema, si existe En esta subsecci n se de nir n todos los t rminos, acr nimos y abreviaturas o a e o utilizadas en la ERS. En esta subsecci n se mostrar una lista completa de todos los documentos o a referenciados en la ERS. Esta subsecci n describe brevemente los contenidos y la organizaci n del o o resto de la ERS. 3

1.3 De niciones, Acr nimos y Abreviaturas o

1.4 Referencias

1.5 Visi n General del Documento o

IEEE std. 830

UDIS. FI. UPM

2 Descripci n General o
En esta secci n se describen todos aquellos factores que afectan al producto o y a sus requisitos. En esta secci n no se describen los requisitos, sino su o contexto. Esto permitir de nir con detalle los requisitos en la secci n 3, a o haciendo que sean m s f ciles de entender. a a Normalmente, esta secci n consta de las siguientes subsecciones: Perso pectiva del producto, funciones del producto, caracter sticas de los usuarios,
restricciones, factores que se asumen y futuros requisitos. Esta subsecci n debe relacionar el futuro sistema producto software con o otros productos. Si el producto es totalemente independiente de otros productos, tambien debe especi carse aqu . Si la ERS de ne un producto que
es parte de un sistema mayor, esta subsecci n relacionar los requisitos del o a sistema mayor con la funcionalidad del producto descrito en la ERS, y se identi car n las interfaces entre el producto mayor y el producto aqu desa
crito. Se recomienda utilizar diagramas de bloques. En esta subsecci n de la ERS se mostrar un resumen, a grandes rasgos, o a de las funciones del futuro sistema. Por ejemplo, en una ERS para un programa de contabilidad, esta subsecci n mostrar que el sistema soportar el o a a mantenimiento de cuentas, mostrar el estado de las cuentas y facilitar la a a facturaci n, sin mencionar el enorme detalle que cada una de estas funciones o requiere. Las funciones deber n mostrarse de forma organizada, y pueden utilia zarse gr cos, siempre y cuando dichos gr cos re ejen las relaciones entre a a funciones y no el dise~o del sistema. n Esta subsecci n describir las caracter sticas generales de los usuarios del o a
producto, incluyendo nivel educacional, experiencia y experiencia t cnica. e Esta subsecci n describir aquellas limitaciones que se imponen sobre los o a desarroladores del producto 4

2.1 Perspectiva del Producto

2.2 Funciones del Producto

2.3 Caracter sticas de los Usuarios

2.4 Restricciones

IEEE std. 830 Pol ticas de la empresa

Limitaciones del hardware Interfaces con otras aplicaciones Operaciones paralelas Funciones de auditor a
Funciones de control Lenguajes de programac n o Protocolos de comunicaci n o Requisitos de abilidad Criticalidad de la aplicaci n o Consideraciones acerca de la seguridad.

UDIS. FI. UPM

Esta subsecci n de la ERS describir aquellos factores que, si cambian, pueo a den afectar a los requisitos. Por ejemplo, los requisitos pueden presuponer una cierta organizaci n de ciertas unidades de la empresa, o pueden preo suponer que el sistema correr sobre cierto sistema operativo. Si cambian a dichos detalles en la organizaci n de la empresa, o si cambian ciertos detalles o t cnicos, como el sistema operativo, puede ser necesario revisar y cambiar e los requisitos. Esta subsecci n esbozar futuras mejoras al sistema, que podr n analizarse o a a e implementarse en un futuro.

2.5 Suposiciones y Dependencias

2.6 Requisitos Futuros

3 Requisitos Espec cos

Esta secci n contiene los requisitos a un nivel de detalle su ciente como para o permitir a los dise~adores dise~ar un sistema que satisfaga estos requisitos, n n y que permita al equipo de pruebas plani car y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo requisito aq i u 5

IEEE std. 830

UDIS. FI. UPM

especi cado describir comportamientos externos del sistema, perceptibles a por parte de los usuarios, operadores y otros sistemas. Esta es la secci n m s larga e importante de la ERS. Deber n aplicarse o a a los siguientes principios: El documento deber a ser perfectamente legible por personas de muy
distintas formaciones e intereses. Deber n referenciarse aquellos documentos relevantes que poseen algua na in uencia sobre los requisitos. Todo requisito deber ser un vocamente identi cable mediante alg n a
u c digo o sistema de numeraci n adecuado. o o Lo ideal, aunque, en la pr ctica, no siempre realizable, es que los rea quisitos posean las siguientes caracter sticas:
Correcci n La ERS es correcta si y s lo si todo requisito que guo o ra aqu y que ser implementado en el sistema re eja alguna
a necesidad real. La correcci n de la ERS implica que el sistema o implementado ser el sistema deseado. a No ambiguos Cada requisito tiene una sola interpretaci n. Para elio minar la ambiguedad inherente a los requisitos expresados en lenguaje natural, se deber an utilizar gr cos o notaciones formales.
a En el caso de utilizar t rminos que, habitualmente, poseen m s de e a una interpretaci n, se de nir n con precisi n en el glosario. o a o Completos Todos los requisitos relevantes han sido inclu dos en la
ERS. Conviene incluir todas las posibles respuestas del sistema a los datos de entrada, tanto v lidos como no v lidos. a a Consistentes Los requisitos no pueden ser contradictorios. Un conjunto de requisitos contradictorio no es implementable. Clasi cados Normalmente, no todos los requisitos son igual de importantes. Los requisitos pueden clasi carse por importancia esenciales, condicionales u opcionales o por estabilidad cambios que se espera que afecten al requisito. Esto sirve, ante todo, para no emplear excesivos recursos en implementar requisitos no esenciales. Veri cables La ERS es veri cable si y s lo si todos sus requisitos o son veri cables. Un requisito es veri cable  testeable" si existe un proceso nito y no costoso para demostrar que el sistema cumple con el requisito. Un requisito ambiguo no es, en general, 6

IEEE std. 830

UDIS. FI. UPM

veri cable. Expresiones como a veces", bien", adecuado", etc. introducen ambiguedad en los requisitos. Requisitos como en caso de accidente la nube t xica no se extender m s all de 25 Km" o a a a no es veri cable por el alto costo que conlleva. Modi cables La ERS es modi cable si y s lo si se encuentra estructuo rada de forma que los cambios a los requisitos pueden realizarse de forma f cil, completa y consistente. La utilizaci n de herramientas a o autom ticas de gesti n de requisitos por ejemplo RequisitePro o a o Doors facilitan enormemente esta tarea. Trazables La ERS es trazable si se conoce el or gen de cada requisito y
se facilita la referencia de cada requisito a los componentes del dise~o y de la implementaci n. La trazabilidad hacia atr s" indica n o a el or gen documento, persona, etc. de cada requisito. La traza
bilidad hacia delante" de un requisito R indica qu componentes e del sistema son los que realizan el requisito R. Se describir n los requisitos que afecten a la interfaz de usuario, interfaz con a otros sistemas hardware y software e interfaces de comunicaciones. Esta subsecci n quiz la m s larga del documento deber especi car too a a a das aquellas acciones funciones que deber llevar a cabo el software. Nora malmente aunque no siempre, son aquellas acciones expresables como el sistema deber


". Si se considera necesario, podr n utilizarse notaciones a a gr cas y tablas, pero siempre supeditadas al lenguaje natural, y no al rev s. a e Es importante tener en cuenta que, en 1983, el Est ndar de IEEE 830 a establec a que las funciones deber an expresarse como una jerarqu a funcional


en paralelo con los DFDs propuestos por el an lisis estructurado. Pero el a Est ndar de IEEE 830, en sus ultimas versiones, ya permite organizar esta a subsecci n de m ltiples formas, y sugiere, entre otras, las siguientes: o u Por tipos de usuario: Distintos usuarios poseen distintos requisitos. Para cada clase de usuario que exista en la organizaci n, se especi car n o a los requisitos funcionales que le afecten o tengan mayor relaci n con sus o tareas. Por objetos: Los objetos son entidades del mundo real que ser n re ea jadas en el sistema. Para cada objeto, se detallar n sus atributos y sus a 7

3.1 Interfaces Externas

3.2 Funciones

IEEE std. 830

UDIS. FI. UPM

funciones. Los objetos pueden agruparse en clases. Esta organizaci n o de la ERS no quiere decir que el dise~o del sistema siga el paradigma n de Orientaci n a Objetos. o Por objetivos: Un objetivo es un servicio que se desea que ofrezca el sistema y que requiere una determinada entrada para obtener su resultado. Para cada objetivo o subobjetivo que se persiga con el sistema, se detallar n las funciones que permitan llevarlo a cabo. a Por est mulos: Se especi car n los posibles est mulos que recibe el sis
a
tema y las funciones relacionadas con dicho est mulo.
Por jerarqu a funcional: Si ninguna de las anteriores alternativas re
sulta de ayuda, la funcionalidad del sistema se especi car como una a jerarqu a de funciones que comparten entradas, salidas o datos internos.
Se detallar n las funciones entrada, proceso, salida y las subfunciones a del sistema. Esto no implica que el dise~o del sistema deba realizarse n seg n el paradigma de Dise~o Estructurado. u n Para organizar esta subsecci n de la ERS se elegir alguna de las anteriores o a alternativas, o incluso alguna otra que se considere m s conveniente. Deber , a a eso s , justi carse el porqu de tal elecci n.
e o Se detallar n los requisitos relacionados con la carga que se espera tenga a que soportar el sistema. Por ejemplo, el n mero de terminales, el n mero u u esperado de usuarios simultaneamente conectados, n mero de transacciones u por segundo que deber soportar el sistema, etc. a Tambi n, si es necesario, se especi car n lo requisitos de datos, es decir, e a aquellos requisitos que afecten a la informaci n que se guardar en la base o a de datos. Por ejemplo, la frecuencia de uso, las capacidades de acceso y la cantidad de registros que se espera almacenar decenas, cientos, miles o millones. Todo aquello que restrinja las decisiones relativas al dise~o de la aplicaci n: n o Restricciones impuestas por otros est ndares, limitaciones del hardware, etc. a

3.3 Requisitos de Rendimiento

3.4 Restricciones de Dise~o n

IEEE std. 830

UDIS. FI. UPM

Se detallar n los atributos de calidad las ilities" del sistema: Fiabilidad, a mantenibilidad, portabilidad, y, muy importante, la seguridad. Deber esa peci carse qu tipos de usuario estan autorizados, o no, a realizar ciertas e tareas, y c mo se implementar n los mecanismos de seguridad por ejemplo, o a por medio de un 'login' y una 'password'

3.5 Atributos del Sistema

3.6 Otros Requisitos

Cualquier otro requisito que no encaje en ninguna de las secciones anteriores.

4 Ap ndices e
Pueden contener todo tipo de informaci n relevante para la ERS pero que, o propiamente, no forme parte de la ERS. Por ejemplo: 1. Formatos de entrada salida de datos, por pantalla o en listados. 2. Resultados de an lisis de costes. a 3. Restricciones acerca del lenguaje de programaci n o