Apuntes para INGENIERIA DE SOFTWARE ESPECIFICACION DE REQUERIMIENTOS

R. Contreras A. - M. A. Pinningho J. Ingenier Civil Informtica a a Primer Semestre 2010

1.

Presentacin o

La actividad de especicacin de requerimientos de software es tan imo portante que incluso se considera que ya congura una nueva disciplina, llamada ingenier de requerimientos. Se preocupa con el desarrollo de una a especicacin que sea completa, consistente y no ambigua. La especicacin o o propuesta en estos trminos debe constituirse en el acuerdo bsico entre el e a usuario nal y el equipo encargado del desarrollo del software. Un requerimiento es una caracter stica que debe tener el sistema o una restriccin que debe satisfacer para que sea aceptado por el cliente. o Durante la obtencin de los requerimientos, el cliente y los desarroo lladores denen el propsito del sistema. El resultado de esta actividad, o si pensamos en el enfoque de orientacin a objetos usando un lenguaje como o UML, es una descripcin del sistema en trminos de actores y casos de uso. o e Los actores representan las entidades externas que interactan con el sisteu ma. Los actores juegan el rol de usuarios nales, otros computadores con los que necesita tratar el sistema (por ejemplo, una red de computadores) y el ambiente (por ejemplo, un proceso qu mico). Los casos de uso son secuencias de eventos generales que describen todas las acciones posibles entre un actor y un fragmento para un segmento de funcionalidad dado [1]. Insistiendo con UML, se pueden distinguir las siguientes actividades para obtener los requerimientos:

Identicacin de los actores. Durante esta actividad los desarrolladores o identican los diferentes tipos de usuario que soportar el sistema. a Identicacin de escenarios. Durante esta actividad los desarrolladoo res observan a los usuarios y desarrollan un conjunto de escenarios deta-llados para la funcionalidad t pica que proporcionar el sistema. a Los escenarios son ejemplos concretos de uso del sistema. Los desarrolladores usan estos escenarios para comunicarse con los usuarios y profundizar su comprensin del dominio de aplicacin. o o Identicacin de casos de uso. Una vez que los desarrolladores y usuao rios se ponen de acuerdo en un conjunto de escenarios, los desarrolladores derivan a partir de los escenarios un conjunto de casos de uso que representa por completo al sistema. Mientras que los escenarios son ejemplos concretos que ilustran un solo caso, los casos de uso son abstracciones que describen todos los casos posibles. Cuando se describen los casos de uso los desarrolladores determinan el alcance del sistema. Renamiento de los casos de uso. Durante esta actividad los desarrolladores se aseguran que la especicacin del sistema est completa o a detallando cada caso de uso y describiendo el comportamiento del sistema en presencia de errores y condiciones excepcionales. Identicacin de las relaciones entre casos de uso. Durante esta activio dad los desarrolladores consolidan el modelo de caso de uso eliminando redundancias. Esto asegura que la especicacin del modelo sea cono sistente. Identicacin de requerimientos no funcionales. Durante esta activio dad los desarrolladores usuarios y clientes se ponen de acuerdo en aspectos que son visibles ante el usuario pero que no estn relacionados a en forma directa con la funcionalidad. Esto incluye restricciones en el desempeo del sistema, su documentacin, los recursos que consume, n o su seguridad y su calidad. La especicacin de requerimientos debe atenerse a describir estrictao mente qu es lo que el software deber hacer. El problema de cmo sern e a o a satisfechos los requerimientos es un problema de la fase de diseo del softn ware.

Figura 1: Costo de los errores Los problemas centrales relacionados con esta fase del proceso de desarrollo de software se pueden resumir en las siguientes observaciones: 1. Es muy fcil postergar la actividad de especicacin rigurosa de los a o requerimientos, o realizarla de manera supercial. 2. En contraposicin, deciencias que se originan en esta actividad son o muy dif ciles y caras de ser corregidas posteriormente. Segn Boehm [2], la gura 1 resume la situacin que reeja el costo de la u o correccin de errores de software en funcin de la fase en la cual esos errores o o son identicados. Claramente, compensa invertir un esfuerzo bastante grande tratando de localizar errores en la fase de especicacin de requerimientos, gastando o para eso, por ejemplo, un hombre-mes, que esperar para localizar el error en la fase de operacin y necesitar unos 100 hombres-mes para su correccin. o o Adems del problema relacionado al costo para efectuar una correccin, a o hay otros problemas relacionados con la ausencia de una buena especicacin o de requerimientos. Se pueden mencionar los siguientes:

1. Un projecto jerrquico estructurado (top-down) se vuelve inviable por a falta de denicin en el nivel ms general del proyecto (el top). o a 2. El test es imposible por carecer de un paradigma de correccin contra o el cual confrontar el software desarrollado. 3. El usuario no puede participar del desarrollo, si no existe una denicin o clara de qu es lo que se est desarrollando para l. e a e 4. La administracin del proceso de desarrollo no puede tener control de o lo que debe ser producido por el equipo de desarrollo.

2.

Prctica actual en la especicacin de requeria o mientos

La prctica actual de la actividad de especicacin de requerimientos, a o en particular en el caso de Chile, es que, cuando los requerimientos son especicados, esto se hace utilizando un lenguaje informal y de manera extremadamente imprecisa. Una especicacin t o pica contiene una gran diversidad de trminos ambiguos (adecuado, suciente, tiempo-real, exible, etc.) e o trminos aparentemente precisos y sin embargo no denidos (ptimo, 99 e o por ciento conable), lo que es causa de un gran nmero de dicultades en u el proceso de desarrollo. Las especicaciones actuales contienen bastantes errores. Una especicacin de software considerada buena y publicada en un o estudio internacional ten entre uno y cuatro errores no triviales por pgina. a a Los mtodos y tcnicas usados en el anlisis de requerimientos son, de e e a manera general, los menos desarrollados del rea de software. Sin embargo, a una caracter stica general emerge de todos los mtodos principales actuale mente en uso: la nocin de ujo de informacin. El usuario cuando describe o o los requerimientos de un sistema habla, en general, de las funciones que desea ver implementadas. Los especialistas en ingenier de software idena tican los requerimientos del usuario en trminos de caminos o ujos de e informacin. La dinmica del sistema debe ser entendida antes para que se o a pueda identicar las funciones que es necesario ejecutar. Tales funciones son identicadas en trminos de transformaciones a que se someten los datos del e problema.

3.

Ingenier de requerimientos a

La ingenier de requerimientos pretende denir los requerimientos del a sistema que se est construyendo. La ingenier de requerimientos incluye a a dos actividades principales: la obtencin de los requerimientos, que da coo mo resultado una especicacin del sistema que el cliente comprende, y el o anlisis, que da como resultado un modelo de anlisis que los desarrolladoa a res pueden interpretar sin ambigedad. La obtencin de requerimientos es u o la ms desaante de las dos, debido a que necesita la colaboracin de varios a o grupos de participantes con diferentes niveles de conocimiento. Por un lado, el cliente y los usuarios son expertos en sus dominios y tienen una idea general de lo que debe hacer el sistema. Sin embargo, a menudo tienen poca experiencia en el desarrollo de software. Por otra parte, los desarrolladores tienen experiencia en la construccin de sistemas, pero con frecuencia tienen o muy poco conocimiento del ambiente diario de los usuarios. Por otra parte, hay varias razones por las que resulta imposible ser denitivos acerca de la especicacin de un problema [5]: o Los sistemas grandes en general se utilizan para mejorar situaciones presentes, pero aunque los sistemas actuales en uso sean bien conocidos, no resulta fcil anticipar qu efectos tendr el sistema mejorado a e a en la organizacin. o Los sistemas grandes en general tienen comunidades de usuarios que maniestan requerimientos y prioridades diferentes y muchas veces conictivas. As los requerimientos nales resultan ser normalmente , un compromiso. Los clientes (los que pagan) y los usuarios, son raramente las mismas personas. Los clientes imponen en los requerimientos ciertas condiciones en la base de costos y/o inversiones, las que pueden estar en conicto con los intereses de los usuarios. Muchos de los problemas se presentan a causa de la necesidad de documentar un sistema, de forma que pueda ser entendido por usuarios potenciales y al mismo tiempo generar una especicacin del sistema (conocida o normalmente como especicacin funcional), que sea la base del acuerdo o entre el cliente y el que produce el software. Casi siempre los usuarios preeren una descripcin del sistema de alto nivel de abstraccin por sobre o o

una especicacin detallada. Para dicultar un poco ms las cosas, probao a blemente es imposible construir una especicacin detallada sin incorporar o alguna actividad de diseo, haciendo nebulosa la frontera entre diseo y n n requerimientos. En consecuencia, las especicaciones deber producirse a diferentes an niveles de abstraccin. Estos niveles de especicacin son: o o Denicin de Requerimientos. Es una descripcin, en lenguaje o o natural, respecto de los servicios que el usuario espera le suministre el sistema. Es de esperar que esta denicin sea escrita de forma que o tanto el cliente y el usuario actual como clientes y usuarios potenciales puedan entenderla. Especicacin de Requerimientos. Es un documento estructurado o que presenta los servicios que el sistema debe tener, a un mayor grado de detalle. Este documento (llamado a veces especicacin funcional), o debe ser lo sucientemente preciso como para actuar como el acuerdo de desarrollo entre el cliente y el constructor del sistema. El pblico u objetivo de este documento tiene un perl eminentemente tcnico. Es e posible que se pueda emplear aqu tcnicas de especicacin formal, e o pero depender del background de los interlocutores. a Especicacin del Software. Una especicacin de software (espeo o cicacin del diseo) es una descripcin abstracta del software que o n o sirve de base a su diseo e implementacin. Aunque este documento n o y la Especicacin de Requerimientos estn claramente relacionados, o a la distincin ms relevante es que este documento est dirigido a dio a a seadores de software y no a usuarios o administradores. Por tal razn, n o este es un buen lugar para incorporar tcnicas de especicacin fore o males.

4.

El documento de requerimientos de software

En principio, los requerimientos deben ser completos y consistentes. Deben especicarse todas las funciones del sistema y ningn requerimiento u deber estar en conicto con otro. Esto es muy dif de conseguir, en para cil ticular si los requerimientos se presentan en lenguaje natural. As aceptando , que omisiones y errores pueden afectar al documento, deber estructurarse a de modo que su cambio sea fcil. Heninger [3] dice que hay seis requeria mientos que tal documento debe satisfacer: 6

1. Deber especicar solamente el comportamiento externo del sistema. a 2. Deber especicar las restricciones de implementacin. a o 3. Deber ser fcil de modicar. a a 4. Deber servir como una herramienta de referencia a los mantenedores a del sistema. 5. Deber registrarse claramente el ciclo de vida del sistema. a 6. Deber caracterizar respuestas aceptables ante eventos no deseados. a El documento de requerimientos es una combinacin de denicin de o o requerimientos y especicacin de requerimientos. La mejor forma de orgao nizarlo es como una serie de cap tulos presentando la especicacin detallada o como un apndice. Una estructura posible es la siguiente: e Introduccin. Deber describir la necesidad del sistema y colocarlo o a en un contexto, describiendo brevemente sus funciones y presentando una justicacin para el software. Deber incluir una descripcin sobre o a o cmo el sistema encaja en la organizacin o los objetivos estratgicos o o e de la organizacin que necesita el sotware. o Modelo del sistema. Esta seccin establece el modelo del sistema, que o muestra las relaciones entre los componentes del sistema y entre el sistema y su ambiente. Tambin deber tenerse un modelo abstracto e a de datos. Evolucin del sistema. Esta seccin deber describir las suposiciones o o a fundamentales en las que se sustenta el sistema y describir anticipadamente los cambios necesarios debidos a la evolucin del hardware, o cambios en las necesidades del usuario u otras similares. Requerimientos funcionales. Los servicios que se suministran al usuario son los elementos que aparecen en esta seccin, usando lenguaje nao tural con referencias cruzadas a especicaciones de requerimientos ms a detalladas. Requerimientos no funcionales. En esta parte, se establecen las restricciones impuestas a la operacin del sotware y las restricciones impueso tas al diseador del software, relacionndolas con los requerimientos n a funcionales. 7

Glosario. Se deben denir en esta seccin los trminos tcnicos usados o e e en el documento. No se debe hacer suposiciones sobre la experiencia o conocimiento del lector. Los apndices al documento de requerimientos deben incluir, a lo menos, e la informacin siguiente: o Especicacin de requerimientos funcionales. Contiene una especicao cin detallada de los requerimientos del sistema constituyendo proo bablemente la parte ms importante del documento. a Especicacin de requerimientos no funcionales. Es una ampliacin de o o la especicacin de requerimientos no funcionales presentada previao mente. Debe incluir detalles tales como representacin de datos, tiemo pos de respuesta espec cos, requerimientos de memoria, entre otros. Productos espec cos utilizados o estndares seguidos, tambin deben a e ser especicados. Hardware. Si el sistema requiere de hardware especial para su implementacin, debe describirse tanto el hardware como las interfaces o necesarias. Requerimientos de base de datos. Debe describirse la organizacin lgio o ca de los datos que usa el sistema y sus inter-relaciones. Tcnicas de e modelado de datos como el modelo entidad-relacin, por ejemplo, pueo den usarse para describir los requerimientos de bases de datos. Indice. El documento puede tener ms de una clase de a ndice. Tanto como un ndice alfabtico normal, puede haber un e ndice por cap tulo, un ndice de funciones, etc.

Referencias
[1] Bruegge, Bernd and Dutoit, Allen. Ingenier de Software Orientado a a Objetos. Prentice Hall, 2002. [2] Boehm, B. W. Software Engineering: R & D Trends and Defense Needs. In Research Directions in Software Technology, MIT Press, 1979. [3] Heninger, K.L. Specifying software requirements for complex systems. New techniques and their applications. IEEE Transactions on Software Engineering, 6 (1) 2-13, 1980. 8

[4] Oliveira, T.C., Matias Filho, I, Lucena, C.J.P., Cowan, D.D., Alencar, R. Software Process Representation and Analysis for Framework Instantiation. IEEE Transactions on Software Engineering, a ser publicado, 2004. [5] Sommerville, Ian. Software Engineering. Sixth Edition, Addison Wesley, 2000.