Repblica Bolivariana de Venezuela Ministerio del Poder Popular para la Educacin Universitaria Universidad Politcnica Territorial del Oeste

de Sucre Clodosbaldo Russin Cuman Estado Sucre

Integrantes: TSU Mara Milln TSU Rosemary Rengel TSU Joan Zabala

Cuman, Abril de 2013

Introduccin

Una especificacin de requisitos del software es una descripcin completa del comportamiento del sistema a desarrollar e incluye un conjunto de casos de uso que describen todas las interacciones que se prevn que los usuarios tendrn con el software. Tambin contiene requisitos no funcionales (o suplementarios), que imponen restricciones al diseo o funcionamiento del sistema.

Por otro lado, es importante mencionar que los requisitos no son ms que la condicin o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado [Piattini, 1996]. Esta definicin se extiende y se aplica a las condiciones que debe cumplir o poseer un sistema o uno de sus componentes para satisfacer un contrato, una norma o una especificacin.

La IEEE indica que un buen documento de requisitos debe contemplar toda la informacin presentada en el estndar 830-1998 y aunque propone una organizacin de dicha informacin, no exige estrictamente el formado de dicha informacin. Fundamentndose en estos requisitos, el desarrollador de software proceder al modelado de la futura aplicacin.

Contenido Las estrategias recomendadas para la especificacin de los requisitos del software estn descritas segn el estndar IEEE 830-1998. Este estndar describe las estructuras posibles, contenido deseable, y calidades de una especificacin de requisitos del software. Para estructura un documento cumpliendo con el estndar IEEE 830-1998, se debe hacer de la siguiente manera: 1. INTRODUCCIN En esta seccin se proporcionar una introduccin a todo el documento de Especificacin de Requisitos Software (ERS). Consta de varias subsecciones: propsito, mbito del sistema, definiciones, referencias y visin general del documento.

1.1. Propsito El objeto de la especificacin es definir de manera clara y precisa todas las funcionalidades y restricciones del sistema que se desea construir.

1.2. mbito del Sistema Se podr dar un nombre al futuro sistema (ej. MiSistema) Se explicar lo que el sistema har y lo que no har. Se describirn los beneficios, objetivos y metas que se espera alcanzar con el futuro sistema. Se referenciarn todos aquellos documentos de nivel superior (por ej. en Ingeniera de Sistemas, que incluyen Hardware y Software, deber mantenerse la consistencia con el documento de especificacin de requisitos globales del sistema, si existe).

1.3. Definiciones, Acrnimos y Abreviaturas Se van a definir todos los trminos, acrnimos y abreviaturas utilizadas en la ERS.

1.4. Referencias Se mostrar una lista completa de todos los documentos referenciados en la ERS.

1.5. Visin General del Documento Deben describirse brevemente los contenidos y la organizacin del resto de la ERS.

2. DESCRIPCIN GENERAL Aqu se describen todos aquellos factores que afectan al producto y a sus requisitos. No se describen los requisitos, sino su contexto. Esto permitir definir con detalle los requisitos en la seccin, haciendo que sean ms fciles de entender. Normalmente, esta seccin consta de las siguientes subsecciones: Perspectiva del producto, funciones del producto, caractersticas de los usuarios, restricciones, factores que se asumen y futuros requisitos.

2.1. Perspectiva del Producto Se debe relacionar el futuro sistema (producto software) con otros productos. Si el producto es totalmente independiente de otros productos, tambin debe especificare aqu. Si la ERS define un producto que es parte de un sistema mayor, esta subseccin relacionar los requisitos del sistema mayor con la funcionalidad del producto descrito en la ERS, y se identificarn las interfaces entre el producto mayor y el producto aqu descrito. Se recomienda utilizar diagramas de bloques.

2.2. Funciones del Producto Se mostrar un resumen, a grandes rasgos, de las funciones del futuro sistema. Por ejemplo, en una ERS para un programa de contabilidad, tambin reflejar que el sistema soportar el mantenimiento de cuentas, el estado de las cuentas y facilitar la facturacin, sin mencionar el enorme detalle que cada una de estas funciones requiere.

Las funciones debern mostrarse de forma organizada, y pueden utilizarse grficos, siempre y cuando dichos grficos reflejen las relaciones entre funciones y no el diseo del sistema.

2.3. Caractersticas de los Usuarios Aqu se describirn las caractersticas generales de los usuarios del producto, incluyendo nivel educacional, experiencia y experiencia tcnica.

2.4. Restricciones Se describir aquellas limitaciones que se imponen sobre los desarrolladores del producto Polticas de la empresa Limitaciones del hardware Interfaces con otras aplicaciones Operaciones paralelas Funciones de auditora Funciones de control Lenguaje(s) de programacin Protocolos de comunicacin Requisitos de habilidad Criticalidad (propiedad de ciertos sistemas complejos abiertos, no lineales y en
desequilibrio de auto organizarse para alcanzar un punto crtico desde el cual pueden experimentar cambios) de la aplicacin

Consideraciones acerca de la seguridad

2.5. Suposiciones y Dependencias Describir aquellos factores que, si cambian, pueden afectar a los requisitos. Por ejemplo, los requisitos pueden presuponer una cierta organizacin de ciertas unidades de la empresa, o pueden presuponer que el sistema correr sobre cierto sistema operativo. Si cambian dichos detalles en la organizacin de la empresa, o

si cambian ciertos detalles tcnicos, como el sistema operativo, puede ser necesario revisar y cambiar los requisitos.

2.6. Requisitos Futuros Disear futuras mejoras al sistema, que podrn analizarse e implementarse en un futuro.

3. REQUISITOS ESPECFICOS Esta seccin contiene los requisitos a un nivel de detalle suficiente como para permitir a los diseadores disear un sistema que satisfaga estos requisitos, 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 especificado describir comportamientos externos del sistema, perceptibles por parte de los usuarios, operadores y otros sistemas. Esta es la seccin ms larga e importante de la ERS. Debern aplicarse los siguientes principios: El documento tiene que ser perfectamente legible por personas de muy distintas formaciones e intereses. Debern referenciarse aquellos documentos relevantes que poseen alguna influencia sobre los requisitos. Todo requisito deber ser identificable mediante algn cdigo o sistema de numeracin adecuado. Lo ideal, aunque en la prctica no siempre realizable, es que los requisitos posean las siguientes caractersticas: Correccin: La ERS es correcta si y slo si todo requisito (y que ser implementado en el sistema) refleja alguna necesidad real. La correccin de la ERS implica que el sistema implementado ser el sistema deseado. No ambiguos: Cada requisito tiene una sola interpretacin. Para eliminar la ambigedad inherente a los requisitos expresados en lenguaje natural, se debern utilizar grficos o notaciones formales.

En el caso de utilizar trminos que, habitualmente, poseen ms de una interpretacin, se definirn con precisin 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 validos como no validos. Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto 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 (cambios 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 slo si todos sus requisitos son verificables. Un requisito es verificable si existe un proceso finito y no costoso para demostrar que el sistema cumple con el requisito. Un requisito ambiguo no es, en general, verificable. Expresiones como a veces, bien, adecuado, etc. Introducen ambigedad en los requisitos. Requisitos como en caso de accidente la nube txica no se extender ms all de 25Km" no es verificable por el alto costo que conlleva. Modificables: La ERS es modificable slo si se encuentra estructurada de forma que los cambios a los requisitos pueden realizarse de forma fcil, completa y consistente. Trazables: La ERS es trazable si se conoce el origen de cada requisito y se facilita la referencia de cada requisito a los componentes del diseo y de la implementacin. La trazabilidad hacia atrs indica el origen (documento, persona, etc.) de cada requisito. La trazabilidad hacia delante de un requisito R indica que componentes del sistema son los que realizan el requisito R.

3.1. Interfaces Externas Se describirn los requisitos que afecten a la interfaz de usuario, interfaz con otros sistemas (hardware y software) e interfaces de comunicaciones.

3.2. Funciones Esta subseccin (quiz la ms larga del documento) deber especificar todas aquellas acciones (funciones) que deber llevar a cabo el software. Normalmente (aunque no siempre), son aquellas acciones expresables como el sistema deber. . ."Si se considera necesario, podrn utilizarse notaciones grficas y tablas, pero siempre supeditadas al lenguaje natural, y no al revs. Es importante tener en cuenta que, en 1983, el Estndar de IEEE 830 establecer que las funciones debern expresarse como una jerarqua funcional. Pero el estndar de IEEE 830, en sus ltimas versiones, ya permite organizar esta subseccin de mltiples formas, y sugiere, entre otras, las siguientes: Por tipos de usuario: Distintos usuarios poseen distintos requisitos. Para cada clase de usuario que exista en la organizacin, se especificarn los requisitos funcionales que le afecten o tengan mayor relacin con sus tareas. Por objetos: Los objetos son entidades del mundo real que sern reflejadas en el sistema. Para cada objeto, se detallarn sus atributos y sus funciones. Los objetos pueden agruparse en clases. Esta organizacin de la ERS no quiere decir que el diseo del sistema siga el paradigma de Orientacin 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 resultado. Para cada objetivo o subobjetivo que se persiga con el sistema, se detallarn las funciones que permitan llevarlo a cabo. Por estmulos: Se especificarn los posibles estmulos que recibe el sistema y las funciones relacionadas con dicho estmulo. Por jerarqua funcional: Si ninguna de las anteriores alternativas resulta de ayuda, la funcionalidad del sistema se especificar como una jerarqua de

funciones que comparten entradas, salidas o datos internos. Se detallarn las funciones (entrada, proceso, salida) y las subfunciones del sistema. Esto no implica que el diseo del sistema deba realizarse segn el paradigma de Diseo Estructurado. Para organizar esta subseccin de la ERS se elegir alguna de las anteriores alternativas, o incluso alguna otra que se considere ms conveniente. Deber, eso s, justificarse el porqu de tal eleccin.

3.3. Requisitos de Rendimiento Se detallarn los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el nmero de terminales, el nmero esperado de usuarios simultneamente conectados, nmero de transacciones por segundo que deber soportar el sistema, etc. Tambin, si es necesario, se especificarn lo requisitos de datos, es decir, aquellos requisitos que afecten a la informacin 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 Diseo Todo aquello que restrinja las decisiones relativas al diseo de la aplicacin: Restricciones de otros estndares, limitaciones del hardware, etc.

3.5. Atributos del Sistema Se detallarn los atributos de calidad del sistema: Fiabilidad, mantenibilidad, portabilidad, y, muy importante, la seguridad. Deber especificarse qu tipos de usuario estn autorizados, o no, a realizar ciertas tareas, y cmo se implementarn los mecanismos de seguridad (por ejemplo, por medio de un usuario y una contrasea).

3.6. Otros Requisitos Cualquier otro requisito que no encaje en otra seccin.

4. Apndices Pueden contener todo tipo de informacin 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 anlisis de costes. 3. Restricciones acerca del lenguaje de programacin.

Conclusiones

Segn la ltima versin del estndar IEEE 830, un buen Documento de Requisitos, deber incluir, de una forma u otra, toda la informacin presentada en
dicho estndar.

Para conseguir el xito en cualquier desarrollo de software es esencial la comprensin total de los requisitos del usuario. No importa lo bien diseado o codificado que pueda estar, si no se ha analizado correctamente puede defraudar al usuario y frustrar al desarrollador.

El anlisis de requisitos es la fase ms importante en el desarrollo de un proyecto software, ya que es en esta fase en la que el usuario indica las especificaciones del futuro sistema, porque de un correcto anlisis depender la correcta implementacin de la aplicacin.

Bibliografa

Universidad Jaime I, Espaa. 5 curso de Ingeniera Informtica 2000-2001. [On-Line]. Disponible en: siml.googlecode.com/files/ERS.pdf

Universidad Complutense de Madrid. IEEE Std. 830-1998. 2008. [On Line]. Disponible en:
http://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf