Home > Especificaci��n de Requisitos seg��n el est��ndar de IEEE 830

Especificaci��n de Requisitos seg��n el est��ndar de IEEE 830

Page 1
Especificaci��n de Requisitos seg��n el est��ndar de IEEE 830
IEEE Std. 830-1998 22 de Octubre de 2008
Resumen Este documento presenta, en castellano, el formato de Especifica- ci��n de Requisitos Software (ERS) seg��n la ��ltima versi��n del est��ndar IEEE 830. Seg��n IEEE, un buen Documento de Requisitos, pese a no ser obligatorio que siga estrictamente la organizaci��n y el formato da- dos en el est��ndar 830, sı deber�� incluir, de una forma o de otra, toda la informaci��n presentada en dicho est��ndar. El est��ndar de IEEE 830 no est�� libre de defectos ni de prejuicios, y por ello ha sido jus- tamente criticado por m��ltiples autores y desde m��ltiples puntos de vista, lleg��ndose a cuestionar incluso si es realmente un est��ndar en el sentido habitual que tiene el t��rmino en otras ingenierıas. El presente documento no pretende pronunciarse ni a favor ni en contra de unos u otros: tan s��lo reproduce, con prop��sitos fundamentalmente docentes, c��mo se organizarıa un Documento de Requisitos seg��n el est��ndar IEEE 830.

Page 2
ÍNDICE 2
Índice
1. Introducci��n 3 1.1. Prop��sito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. ��Ambito del Sistema . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Definiciones, Acr��nimos y Abreviaturas . . . . . . . . . . . . . 3 1.4. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5. Visi��n General del Documento . . . . . . . . . . . . . . . . . . 4 2. Descripci��n General 4 2.1. Perspectiva del Producto . . . . . . . . . . . . . . . . . . . . . 4 2.2. Funciones del Producto . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Caracterısticas de los Usuarios . . . . . . . . . . . . . . . . . . 5 2.4. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Suposiciones y Dependencias . . . . . . . . . . . . . . . . . . . 5 2.6. Requisitos Futuros . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requisitos Espec��ıficos 6 3.1. Interfaces Externas . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Requisitos de Rendimiento . . . . . . . . . . . . . . . . . . . . 9 3.4. Restricciones de Dise˜no . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Atributos del Sistema . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Otros Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Ap��ndices 9

Page 3
1 INTRODUCCI ��ON 3
1. Introducci��n
En esta secci��n se proporcionar�� una introducci��n a todo el documento de Especificaci��n de Requisitos Software(ERS). Consta de varias subsecciones: prop��sito, ambito del sistema, definiciones, referencias y visi��n general del documento.
1.1. Prop��sito
En esta subsecci��n se definir�� el prop��sito del documento ERS y se espe- cificar�� a qui��n va dirigido el documento.
1.2.��Ambito del Sistema
En esta subsecci��n: Se podr�� dar un nombre al futuro sistema (p.ej. MiSistema) Se explicar�� lo que el sistema har�� y lo que no har��. Se describir��n los beneficios, objetivos y metas que se espera alcanzar con el futuro sistema. Se referenciar��n todos aquellos documentos de nivel superior (p.e. en In- genierıa de Sistemas, que incluyen Hardware y Software, deberıa man- tenerse la consistencia con el documento de especificaci��n de requisitos globales del sistema, si existe).
1.3. Definiciones, Acr��nimos y Abreviaturas
En esta subsecci��n se definir��n todos los t��rminos, acr��nimos y abrevia- turas utilizadas en la ERS.
1.4. Referencias
En esta subsecci��n se mostrar�� una lista completa de todos los documen- tos referenciados en la ERS.

Page 4
2 DESCRIPCI ��ON GENERAL 4
1.5. Visi��n General del Documento
Esta subsecci��n describe brevemente los contenidos y la organizaci��n del resto de la ERS.
2. Descripci��n General
En esta secci��n se describen todos aquellos factores que afectan al pro- ducto y a sus requisitos. No se describen los requisitos, sino su contexto. Esto permitir�� definir con detalle los requisitos en la secci��n 3, haciendo que sean m��s f��ciles de entender. Normalmente, esta secci��n consta de las siguientes subsecciones: Pers- pectiva del producto, funciones del producto, caracterısticas de los usuarios, restricciones, factores que se asumen y futuros requisitos.
2.1. Perspectiva del Producto
Esta subsecci��n debe relacionar el futuro sistema (producto software) con otros productos. Si el producto es totalemente independiente de otros pro- ductos, tambi��n debe especificarse aquı. Si la ERS define un producto que es parte de un sistema mayor, esta subsecci��n relacionar�� los requisitos del sistema mayor con la funcionalidad del producto descrito en la ERS, y se identificar��n las interfaces entre el producto mayor y el producto aquı des- crito. Se recomienda utilizar diagramas de bloques.
2.2. Funciones del Producto
En esta subsecci��n de la ERS se mostrar�� un resumen, a grandes rasgos, de las funciones del futuro sistema. Por ejemplo, en una ERS para un pro- grama de contabilidad, esta subsecci��n mostrar�� que el sistema soportar�� el mantenimiento de cuentas, mostrar�� el estado de las cuentas y facilitar�� la facturaci��n, sin mencionar el enorme detalle que cada una de estas funciones requiere. Las funciones deber��n mostrarse de forma organizada, y pueden utili- zarse gr��ficos, siempre y cuando dichos gr��ficos reflejen las relaciones entre funciones y no el dise˜no del sistema.

Page 5
2 DESCRIPCI ��ON GENERAL 5
2.3. Caracter��ısticas de los Usuarios
Esta subsecci��n describir�� las caracterısticas generales de los usuarios del producto, incluyendo nivel educacional, experiencia y experiencia t��cnica.
2.4. Restricciones
Esta subsecci��n describir�� aquellas limitaciones que se imponen sobre los desarrolladores del producto Polıticas de la empresa Limitaciones del hardware Interfaces con otras aplicaciones Operaciones paralelas Funciones de auditorıa Funciones de control Lenguaje(s) de programacion Protocolos de comunicaci��n Requisitos de habilidad Criticalidad de la aplicaci��n Consideraciones acerca de la seguridad
2.5. Suposiciones y Dependencias
Esta subsecci��n de la ERS describir�� aquellos factores que, si cambian, pueden afectar a los requisitos. Por ejemplo, los requisitos pueden presu- poner una cierta organizaci��n de ciertas unidades de la empresa, o pueden presuponer que el sistema correr�� sobre cierto sistema operativo. Si cambian dichos detalles en la organizaci��n de la empresa, o si cambian ciertos detalles t��cnicos, como el sistema operativo, puede ser necesario revisar y cambiar los requisitos.

Page 6
3 REQUISITOS ESPECÍFICOS 6
2.6. Requisitos Futuros
Esta subsecci��n esbozar�� futuras mejoras al sistema, que podr��n anali- zarse e implementarse en un futuro.
3. Requisitos Espec��ıficos
Esta secci��n contiene los requisitos a un nivel de detalle suficiente como para permitir a los dise˜nadores dise˜nar un sistema que satisfaga estos requi- sitos, y que permita al equipo de pruebas planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo requisito aquı es- pecificado describir�� comportamientos externos del sistema, perceptibles 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 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 algu- na influencia sobre los requisitos. Todo requisito deber�� ser unıvocamente identificable mediante alg��n c��digo o sistema de numeraci��n adecuado. Lo ideal, aunque en la pr��ctica no siempre realizable, es que los requi- sitos posean las siguientes caracterısticas: • Correccion: La ERS es correcta si y s��lo si todo requisito que figura aquı (y que ser�� implementado en el sistema) refleja alguna necesidad real. La correcci��n de la ERS implica que el sistema implementado ser�� el sistema deseado. • No ambiguos: Cada requisito tiene una sola interpretaci��n. Para eliminar la ambig��edad inherente a los requisitos expresados en lenguaje natural, se deber��n utilizar gr��ficos o notaciones forma- les. En el caso de utilizar t��rminos que, habitualmente, poseen m��s de una interpretaci��n, se definir��n con precisi��n en el glosario. • Completos: Todos los requisitos relevantes han sido incluidos en la ERS. Conviene incluir todas las posibles respuestas del sistema a los datos de entrada, tanto v��lidos como no v��lidos.

Page 7
3 REQUISITOS ESPECÍFICOS 7 • Consistentes: Los requisitos no pueden ser contradictorios. Un con- junto de requisitos contradictorio no es implementable. • Clasificados: Normalmente, no todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por importancia (esenciales, condicionales u opcionales) o por estabilidad (cam- bios que se espera que afecten al requisito). Esto sirve, ante todo, para no emplear excesivos recursos en implementar requisitos no esenciales. • Verificables: La ERS es verificable si y s��lo si todos sus requisitos son verificables. Un requisito es verificable (testeable) si existe un proceso finito y no costoso para demostrar que el sistema cumple con el requisito. Un requisito ambiguo no es, en general, verifi- cable. Expresiones como a veces, bien, adecuado, etc. introducen ambig��edad en los requisitos. Requisitos como ��en caso de acci- dente la nube t��xica no se extender�� m��s all�� de 25Km�� no es verificable por el alto costo que conlleva. • Modificables: La ERS es modificable si y s��lo si se encuentra es- tructurada de forma que los cambios a los requisitos pueden rea- lizarse de forma f��cil, completa y consistente. La utilizaci��n de herramientas autom��ticas de gesti��n de requisitos (por ejemplo RequisitePro o Doors) facilitan enormemente esta tarea. • Trazables: La ERS es trazable si se conoce el origen de cada requi- sito y se facilita la referencia de cada requisito a los componentes del dise˜no y de la implementaci��n. La trazabilidad hacia atr��s indica el origen (documento, persona, etc.) de cada requisito. La trazabilidad hacia delante de un requisito R indica qu�� compo- nentes del sistema son los que realizan el requisito R.
3.1. Interfaces Externas
Se describir��n los requisitos que afecten a la interfaz de usuario, interfaz con otros sistemas (hardware y software) e interfaces de comunicaciones.
3.2. Funciones
Esta subsecci��n (quiz�� la m��s larga del documento) deber�� especificar todas aquellas acciones (funciones) que deber�� llevar a cabo el software. Nor-

Page 8
3 REQUISITOS ESPECÍFICOS 8 malmente (aunque no siempre), son aquellas acciones expresables como ��el sistema deber�� ...��. Si se considera necesario, podr��n utilizarse notaciones gr��ficas y tablas, pero siempre supeditadas al lenguaje natural, y no al rev��s. Es importante tener en cuenta que, en 1983, el Est��ndar de IEEE 830 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 Est��ndar de IEEE 830, en sus ��ltimas versiones, ya permite organizar esta subsecci��n de m��ltiples formas, y sugiere, entre otras, las siguientes: Por tipos de usuario: Distintos usuarios poseen distintos requisitos. Pa- ra cada clase de usuario que exista en la organizaci��n, se especificar��n los requisitos funcionales que le afecten o tengan mayor relaci��n con sus tareas. Por objetos: Los objetos son entidades del mundo real que ser��n refle- jadas en el sistema. Para cada objeto, se detallar��n sus atributos y sus funciones. Los objetos pueden agruparse en clases. Esta organizaci��n de la ERS no quiere decir que el dise˜no del sistema siga el paradigma de Orientaci��n a Objetos. Por objetivos: Un objetivo es un servicio que se desea que ofrezca el sistema y que requiere una determinada entrada para obtener su resul- tado. Para cada objetivo o subobjetivo que se persiga con el sistema, se detallar��n las funciones que permitan llevarlo a cabo. Por estımulos: Se especificar��n los posibles estımulos que recibe el sis- tema y las funciones relacionadas con dicho estımulo. Por jerarquıa funcional: Si ninguna de las anteriores alternativas resulta de ayuda, la funcionalidad del sistema se especificar�� como una jerar- quıa de funciones que comparten entradas, salidas o datos internos. Se detallar��n las funciones (entrada, proceso, salida) y las subfunciones del sistema. Esto no implica que el dise˜no del sistema deba realizarse seg��n el paradigma de Dise˜no Estructurado. Para organizar esta subsecci��n de la ERS se elegir�� alguna de las ante- riores alternativas, o incluso alguna otra que se considere m��s conveniente. Deber��, eso sı, justificarse el porqu�� de tal elecci��n.

Page 9
4 AP ��ENDICES 9
3.3. Requisitos de Rendimiento
Se detallar��n los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el n��mero de terminales, el n��mero esperado de usuarios simultaneamente conectados, n��mero de transacciones por segundo que deber�� soportar el sistema, etc. Tambi��n, si es necesario, se especificar��n lo requisitos de datos, es decir, aquellos requisitos que afecten a la informaci��n que se guardar�� en la base 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).
3.4. Restricciones de Dise˜no
Todo aquello que restrinja las decisiones relativas al dise˜no de la aplica- ci��n: Restricciones de otros est��ndares, limitaciones del hardware, etc.
3.5. Atributos del Sistema
Se detallar��n los atributos de calidad (las ��ilities��) del sistema: Fiabilidad, mantenibilidad, portabilidad, y, muy importante, la seguridad. Deber�� espe- cificarse qu�� tipos de usuario est��n autorizados, o no, a realizar ciertas tareas, y c��mo se implementar��n los mecanismos de seguridad (por ejemplo, por me- dio de un login y una password).
3.6. Otros Requisitos
Cualquier otro requisito que no encaje en otra secci��n.
4. Ap��ndices
Pueden contener todo tipo de informaci��n relevante para la ERS pero que, 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. 3. Restricciones acerca del lenguaje de programaci��n.

Set Home | Add to Favorites

All Rights Reserved Powered by Free Document Search and Download

Copyright © 2011
This site does not host pdf,doc,ppt,xls,rtf,txt files all document are the property of their respective owners. complaint#nuokui.com
TOP