PRACTICA 1

DOCUMENTO DE REQUISITOS
 Establece lo que se espera del sistema.  Debe incluir tanto la definicin como la especificacin de requisitos.  NO es un documento de diseo. Debe establecer QU hace el sistema, pero no CMO.  Los requisitos deben establecerse de forma que sea posible su seguimiento en el sistema final.  Los requisitos deben ser completos y consistentes. CARACTERSTICAS DE UN DOCUMENTO DE REQUISITOS  Debe especificar slo el comportamiento externo del sistema.  Debe especificar las restricciones de implementacin.  Debe servir como referencia para las tareas de mantenimiento.  Debe reflejar consideraciones sobre el ciclo de vida.  Debe contener respuestas aceptables a eventos no deseados.

EJEMPLO:

Editor de documentos estructurados

DOCUMENTO DE REQUISITOS DEL SOFTWARE 1. INTRODUCCIN Este documento especifica los requisitos que debe cumplir el programa de edicin de documentos estructurados, propuesto como proyecto prctico en esta asignatura. 2. DESCRIPCIN GENERAL Se trata de manejar documentos tcnicos organizados, de la manera habitual, en secciones, subsecciones, etc. Cada seccin tiene un ttulo, una secuencia de prrafos, que puede estar vaca, y una secuencia de subsecciones, que tambin puede estar vaca. La estructura del documento puede describirse simblicamente de la siguiente manera, usando notacin BNF:
<documento> ::= <seccin> <seccin> ::= <ttulo> + {<prrafo>} + {<seccin>} <ttulo> ::= texto

PRACTICA 1
<prrafo> ::= texto

2.1 MODO DE OPERACIN El editor trabajar, en realidad de dos maneras distintas, segn se est operando sobre elementos no terminales (ttulos, prrafos y secciones) o sobre elementos terminales (texto). Al primer modo lo denominaremos modo estructura, y al segundo modo texto. Se pasar automticamente de un modo a otro al ir recorriendo los distintos elementos del documento .A continuacin se muestra un ejemplo ilustrativo:
Prrafo anterior 1. Seccin primera Primer prrafo 1.2 Primera subseccin Un prrafo Otro prrafo 1.3 Otra subseccin Prrafo n Prrafo anterior 1. Seccin primera Primer prrafo 1.2 Primera subseccin Un prrafo Otro prrafo 1.3 Otra subseccin Prrafo p Prrafo anterior 1. Seccin primera Primer prrafo 1.2 Primera subseccin Un prrafo Otro prrafo 1.3 Otra subseccin Prrafo q Prrafo anterior 1. Seccin primera Primer prrafo 1.2 Primera subseccin
Un prrafo Otro prrafo 1.3 Otra subseccin Prrafo q

Prrafo anterior

Primer prrafo 1.2 Primera subseccin Un prrafo Otro prrafo 1.3 Otra subseccin Prrafo q Prrafo anterior 1. Seccin primera Primer prrafo 1.2 Primera subseccin Un prrafo Otro prrafo 1.3 Otra subseccin Prrafo

2.2 REQUISITOS FUNCIONALES 1. Existir un nico programa principal, que se llamar EDITDOC 2. La informacin de cada documento tendr la siguiente estructura:
<documento> ::= <seccin> <seccin> ::= <ttulo> + {<prrafo>} + {<seccin>} <ttulo> ::= texto <prrafo> ::= texto

PRACTICA 1

3. La presentacin en pantalla se har numerando automticamente las secciones a varios niveles, y reformando los ttulos y prrafos para adaptarlos al ancho de la pantalla. 4. En modo estructura, las teclas de cursor permitirn sealar y selecciones un ttulo, un prrafo, una seccin, una secuencia de prrafos seguidos o una secuencia de secciones seguidas. 5. En modo estructura se podr borrar, cortar, copiar o reemplazar los elementos seleccionados. Las operaciones de cortar, copiar y reemplazar operarn entre el documento y un buffer interno nico.
6. La operacin de reemplazar slo permitir sustituir la parte del documento seleccionada por otra compatible almacenada en el buffer : ttulo n texto prrafo(s) n texto(s) seccin(es) n seccin(es) En modo estructura se podrn usar las teclas de tabulacin (adelante o atrs) para recorrer el documento, seleccionado cada elemento en modo texto (si es ttulo o prrafo), y abriendo huecos delante y detrs de cada elemento. Cuando se abra un hueco, se podr insertar el contenido del buffer (si es compatible), o aadir informacin nueva en modo texto. En modo texto se editar un ttulo o prrafo como una lnea de texto de longitud ilimitada. En la pantalla se ir presentando dicho texto ajustndose al ancho de la pantalla, reformando automticamente el ttulo o prrafo a medida que se aaden o eliminan caracteres.

7.

8.

2.3 REQUISITOS OPCIONALES 1. Se podr exportar el documento en formato HTML, RTF, u otro similar. 2. Se podrn exportar e importar documentos de texto con los prrafos y secciones separados por lneas en blanco, y reconociendo los ttulos de las secciones por su numeracin. 2.4 REQUISITOS NO FUNCIONALES 1. El programa no deber imponer ninguna limitacin en el tamao del documento, nmero de secciones o prrafos, longitud de los ttulos o prrafos, nivel de anidamiento de las secciones, etc.

PRACTICA 1

HERRAMIENTAS Describiremos distintas tcnicas y herramientas que se utilizan para llevar a cabo cada una de las actividades del proceso de Ingeniera de Requerimientos y obtener un buen documento de requisitos.

Extraccin. Esta fase representa el comienzo de cada ciclo. Son las actividades involucradas en el descubrimiento de los requerimientos del sistema. Anlisis. Sobre la base de la extraccin realizada previamente, comienza esta fase -que se presenta sumamente compleja en un proyecto donde el dominio es desconocido- en la cual sea apunta a descubrir problemas con los requerimientos del sistema identificados hasta el momento. Especificacin. En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. Validacin. Su objetivo es validar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripcin, por lo menos, aceptable del sistema que se debe implementar.

PRACTICA 1

POR QUE SE REALIZARON LOS REQUISITOS (PROBLEMAS)?

Sin requisitos escritos, el equipo de desarrollo: no sabe cul es su objetivo, no puede inspeccionar su trabajo, no puede probarlo, no puede analizar su productividad, no puede reflexionar sobre sus prcticas, no puede predecir el tamao y esfuerzo del siguiente trabajo, no puede satisfacer a sus clientes o brevemente, no hay ingeniera profesional sin requisitos escritos. Una forma de no escribirlos significa no mantener las versiones, no publicarlas. Cada uno de los requisitos debe ser... o expresado con propiedad, fcilmente accesible para todo el personal involucrado, numerado de forma unvoca, acompaado por pruebas que lo verifiquen, teniendo en cuenta en el diseo y el cdigo o probado aisladamente y con otros requisitos adems de estar validado por las pruebas al finalizar la construccin de la aplicacin Sin requisitos escritos sera imposible hacer todo esto The Chaos Report (1994, 1996, 1998, 2000, 2003) exitoso: termina bien (tiempo, dinero, requisitos), completo pero deficiente: termina y funciona (+ tiempo, + dinero, requisitos), cancelado: no termina la adecuada gestin de los requisitos es el factor ms importante de xito en un proyecto, por encima de las pruebas, el diseo, la programacin...

Boehm afirma que slo entre un 9% y un 12% de la duracin de un proyecto se invierte en la IR (Ingeniera de Requisitos). Otro estudio ms reciente (1996) confirma estos datos:  Entre el 5% y el 15% de los costos de un proyecto se dedican a la IR.  El 15% de la duracin del proyecto se emplea en IR.  Estos porcentajes parecen sorprendentes si se piensa que los errores ms numerosos, ms costosos de reparar y que ms tiempo consumen se deben a esta fase. Los errores en esta fase son los ms numerosos:  Boehm afirma que el 10% de los errores se producen en IR.  Estudios ms recientes afirman que entre el 44% y el 80% de los errores proceden de IR. El coste crece exponencialmente con el retraso en subsanarlo:  Boehm afirma que la reparacin de un error en la fase de codificacin cuesta entre 5 y 10 veces ms.  En la fase de mantenimiento cuesta entre 100 y 200 veces ms. Mejorar esta fase puede reportar grandes beneficios. CONCLUSION Un documento de requisitos nos va a mostrar como desarrolladores de sistemas, la estructura de cmo realizaremos el sistema, sirviendo como gua este documento oficial, el cual contiene una serie de cuestiones que debern satisfacer al cliente en su totalidad, basndonos en la utilizacin de herramientas para elaborar dicho documento y obtener un software de calidad. Su importancia radica en que no se podr llegar a los objetivos, ya que si el escrito no se elabora, se perder en su totalidad el conocer lo que se desea crear. Sin embargo hay que tomar en cuenta que no solo es crear el documento de requisitos siguiendo un mtodo o ciertas reglas puesto que lo ms importante es la comunicacin que entable el desarrollador con su cliente, existiendo un acuerdo comn. 5