Partes SRS
Partes SRS
Partes SRS
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
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
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
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.4 Referencias
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.4 Restricciones
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.
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
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
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.2 Funciones
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
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'
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