You are on page 1of 9

La Especificacio n de Requisitos con Casos de Uso: Buenas y Malas Practicas

Jose Antonio Pow Sang Portillo
Pontificia Universidad Cato lica del Peru Av. Universitaria cdra. 18, San Miguel Lima-32- PERU japowsang@pucp.edu.pe

Resumen. El uso de UML como esta ndar para la construccio n de software se ha extendido en los ultimos an os. Es por eso que el empleo de los casos de uso, como parte del esta ndar UML, se ha incrementado. El propo sito de los casos de uso es describir en lenguaje natural la funcionalidad completa de un sistema a desarrollar y su empleo se realiza en el proceso de especificaci o n de requisitos del sistema. Lamentablemente, la bibliografı a existente, muestra muchas formas de aplicar los casos de uso y no son pocas las veces en que su empleo es inadecuado. Algunas de las causas son: mala interpretacio n del esta ndar UML y secuencia incorrecta de actividades para la creaci o n de casos de uso. Este artı culo presenta un esquema de trabajo para afrontar el proceso en menci o n utilizando casos de uso. Se incluye, en este esquema, las actividades que se deben realizar, la utilizacio n correcta de casos de uso y los errores que se cometen frecuentemente en cada una de las actividades. Cabe resaltar que este esquema de trabajo es aplicado en los proyectos que forman parte de los cursos del a rea de Ing. de Software de la PUCP a nivel pre y post grado. Tambi e n, es utilizado en las tesis para optar el tı tulo de Ing. Inform a tico. Palabras claves: Especificacio n de Requisitos de Software, Ingenier ı a de Requisitos, Casos de Uso, Escenarios.

Abstract. The use of UML as a standard to construct software has been increased over the last years. For this reason, the utilization of use cases has been growing. The purpose of the use cases is to describe software functionality using natural language. Use cases are used in software requirement specification process. Unfortunately, the authors show many ways to apply use cases and their use is not according to UML. Sometimes people misunderstand UML standard and follow an inadequate sequence of activities to obtain requirements with use cases. This article shows a method to face requirements process with use cases. This article also includes the correct use of use cases and common mistakes. T he method is used in undergraduate and postgraduate Software Engineering courses at PUCP. Keywords: Software Requirements Specification, Requirements Engineering, Use Cases, Sceneries .

Los objetivos de este proceso son identificar. se explicar a n los errores comunes que se producen en cada una de esas actividades. Adem a s. es decir determinar las caracterı sticas que debera n tener el sistema o las restricciones que deber a cumplir para que sea aceptado por el cliente y los futuros usuarios del sistema de software. 2 . Actor Caso de Uso Figura 1. Es importante resaltar que los actores son abstracciones de papeles o roles y no necesariamente tienen una correspondencia directa con personas. Los tipos de relaciones que pueden existir son: ” include„ . Introduccio n Uno de los primeros procesos que se realizan en un proyecto de construcci o n de software es la especificacio n de requisitos.1. Actualmente. con el detalle adecuado. lo que el usuario necesita del sistema de software. UML y la Especificacio n de Requisitos Para determinar la funcionalidad de un sistema a desarrollar. Representaci o n grafica de actor y caso de uso UML especifica que para representar gr a ficamente la relacio n entre un actor y caso de uso se debe trazar una lı nea que los una a la que se le denomina ” relacio n de comunicacio n„ . Los actores y los casos de uso forman un modelo al que se le denomina ” modelo de casos de uso „ . validar y documentar los requisitos de software. Este artı culo muestra las actividades y la secuencia a seguir para realizar una especificaci o n de requisitos empleando casos de uso. La figura 1 muestra la notacio n que se debe utilizar para representar un actor y un caso de uso. ” extends„ y ” generalization„ . UML sen ala que los casos de uso pueden tener relaciones entre s ı . 2. Algunas de las causas son: mala interpretaci o n del est a ndar UML y secuencia incorrecta de actividades para la creaci o n de casos de uso. detallando su comportamiento. Adema s. que el documento de requisitos de software se considera como un contrato entre el cliente y el equipo de desarrollo del sistema. Es por ello. la bibliografı a existente muestra muchas formas de aplicar los casos de uso y no son pocas las veces en que su empleo es incorrecto. Es por ese motivo que el empleo de casos de uso se estaimponiendo frente a otras te cnicas de especificaci o n de requisitos. el cual se traduce en resultados que pueden ser observados por el actor. el caso de uso hace referencia al sistema a construir. Los casos de uso describen las cosas que los actores quieren que el sistema haga. por lo que un caso de uso deber ı a ser una tarea completa desde la perspectiva del actor. el desarrollo de software orientado a objetos y el uso de UML se han incrementado. UML [8] sen ala el uso de dos elementos: el actor y el caso de uso. El producto final de este proceso es el documento de especificaci o n de requisitos de software y en e ste se sen ala. Lamentablemente. Dicho modelo muestra el comportamiento del sistema desde la perspectiva del usuario y servir acomo producto de entrada para el ana lisis y disen o del sistema. La figura 2 muestra un ejemplo de casos de uso con relaciones de tipo ” generalization„ . Las entidades externas podr ı an ser personas u otros sistemas. A diferencia del actor. El actor representa una entidad externa que interactua con el sistema.

Colocar orden Empleado de Televentas Colocar orden por tele fono Colocar orden por Internet Cliente Figura 2. especificar casos de uso e identificar relaciones entre casos de uso. 3 . La secuencia de actividades . Cata logo de requisitos Documento de Especificaci on de Requisitos de Software Lista de requisitos funcionales Lista de requisitos no funcionales Descripcion de actores Descripcion de casos de uso Diagramas de casos de uso Especificacion de casos de uso Figura 3. Diagrama de casos de uso con relaci o n ” generalizationí entre casos de uso. indica el contenido de los productos de la especificacio n de requisitos de software mediante un diagrama de clases. 3. El primero de ellos contiene la lista de requisitos de software clasificada por tipo y prioridad. Diagrama de clases que representan los productos de la especificaci o n de requisitos Las actividades para la especificaci o n de requisitos de software usando casos de uso son las siguientes: identificar y clasificar requisitos. identificar casos de uso. La figura 4 muestra la secuencia en que se deben realizar las actividades y sus resultados. es el resultado de la adaptaci o n de las propuestas metodolo gicas de Bernd Bruegge [3]. identificar actores. especifica el comportamiento del sistema a un grado de detalle mayor al del cata logo de requisitos. y el segundo de ellos. identificar escenarios. Rational Unified Process [9] y Me trica Versio n 3 [7] para la especificaci o n de requisitos. Actividades para la Especificacio n de Requisitos con Casos de Uso Los resultados de la especificacio n de requisitos son dos productos: el cat a logo de requisitos y el documento de especificacio n de requisitos de software. La figura 3. que se detallan en este ac a pite.

de la manera en que e ste reaccionara a entradas particulares y de co mo se comportar a en situaciones particulares. el sistema de software. estos deber a n ser clasificados en dos grupos: requisitos funcionales y requisitos no funcionales. Esta actividad es el punto de partida para las siguientes actividades del pro ceso de obtenci o n de requisitos y se refiere a la identificacio n de los requisitos del sistema de software a desarrollar. los requisitos funcionales declaran expl ı citamente lo que el sistema no debe hacer. respuesta en el tiempo y capacidad de almacenamiento. En esta actividad. La tabla 1 muestra una relaci o n de requisitos funcionales y no funcionales 4 . Los requisitos funcionales son declaraciones de los servicios que proveer ael sistema. los no funcionales no se refieren directamente a las funciones especı ficas que entrega el sistema. sino a sus propiedades como fiabilidad. A continuaci o n se explica cada una de las actividades propuestas. Luego de haber obtenido la lista de requisitos. deberemos responder a los siguientes cuestionamientos: ‘que le permitirahacer. Actividad 1: Identificar y clasificar requisitos. En algunos casos. Los requisitos funcionales son restricciones de los servicios o funciones ofrecidos por el sistema.Identificar y clasificar requisitos Identificar actores Identificar escenarios Identificar casos de uso Especificar casos de uso Cata logo de requisitos Descripci on de actores Descripci on de casos de uso Diagramas de caso de uso Especificacion de casos de uso [ incluir relaciones entre casos de uso ] Identificar relaciones entre casos de uso [ especificacion completa ] Actividad opcional Figura 4: Actividades para la especificaci o n de requisitos usando casos de uso. A diferencia de los requisitos funcionales. al usuario? y ‘el cliente o usuario me solicita alguna restriccio n para construir el sistema de software? Contestando a esas preguntas se deberarealizar una lista que contendralos requisitos del sistema.

Juan Pe rez podrı a ser cliente y operador dependiendo el momento y el uso que haga del sistema. se tienen que indicar. los actores podrı an ser: bibliotecario y cliente (si es que hay mo dulos de consulta de libros). Actividad 2: Identificar actores. Diagrama de casos de uso para un sistema de biblioteca Actividad 5: Especificar de casos de uso Luego de haber identificado los casos de uso. Luego de haber identificado los requisitos funcionales y no funcionales se proceder aa identificar los actores del sistema. A esta lista se le conoce como cat a logo de requisitos. otro software. Requisitos Funcionales El sistema permitiraregistrar los clientes de la empresa. al que se le puede denominar ” Consultar bibliografı a„ (Ver figura 5). El sistema encuentra un unico libro y lo muestra. 4. la forma en la que el actor 5 . El caso de uso es el que especifica todos los escenarios posibles para una parte de funcionalidad dada. Para encontrar actores del sistema se puede buscar en las categorı as de personas. 2. En el caso de un sistema de ventas. de esta manera. Un escenario. nombre o apellido. obteni e ndose. segun Bruegge [3] ” es una descripcio n concreta. Requisitos No Funcionales La interfaz de usuario del sistema se implementar a sobre un navegador Web El sistema debera soportar al menos 20 transacciones por segundo El sistema permitira que los nuevos usuarios se familiaricen con su uso en menos de 15 minutos. estos requisitos se clasificar a n segun su importancia. una lista que contendralos requisitos clasificados por dos criterios: tipo de requisito (funcional y no funcional) e importancia. La diferencia entre escenarios y casos de uso radica en que un escenario es una instancia de un caso de uso [3]. el libro de la biblioteca es ’Especificacio n de Requisitos de Software de Alan Davis y co digo B 73-825„ Cabe resaltar que no es necesario documentar los escenarios de manera formal. es decir. dispositivos de hardware o redes de computadoras. En un sistema. Ejemplo de Requisitos funcionales y no funcionales 1. un usuario del sistema puede actuar como muchos actores. El sistema permitiraa los usuarios realizar una busqueda de los clientes por DNI. Cliente Consultar bibliografı a Figura 5. 5. por ejemplo. Juan P e rez selecciona realizar busqueda y cuando aparece el formulario ingresa en tı tulo de libros la frase ’especificacio n de requisitos .Tabla 1. en el sistema de biblioteca las consultas de bibliografı a por Internet por parte de Juan P e rez y cualquier otro cliente se puede agrupar en un solo caso de uso. Esto quiere decir que carece de importancia la creacio n de documentos que describan todos los escenarios posibles del sistema. un escenario muestra la secuencia de pasos que se produce cuando un actor interactua con el sistema en una situacio n especı fica y un tiempo determinado. 3. Para un sistema de biblioteca. todos los escenarios similares se agrupan en un solo caso de uso. enfocada e informal de una sola caracter ı stica del sistema desde el punto de vista de un solo actor „ . es decir. ya que su propo sito es servir en la identificacio n de los casos de uso del sistema. Luego. Un ejemplo de escenario para un sistema de biblioteca es el siguiente: ” Juan Pe rez se conecta al sistema de la Biblioteca Nacional a trave s de Internet. Por ejemplo. detalladamente. Actividad 3: Identificar escenarios. los actores podrı an ser: el cliente (si se realiza ventas por Internet). el vendedor y el sistema de facturaci o n. Actividad 4: Identificar casos de uso. en un banco.

1 Errores en la identificaci o n de actores Los errores introducidos en esta etapa se deben principalmente a no comprender qui e nes son los actores del sistema. por lo tanto el vendedor serı a el actor del sistema. 2. especifican los pasos que se producir a n en situaciones excepcionales. Postcondiciones. en base a las especificaciones de casos de uso. que contienen las secuencias de pasos que se producir a n como alternativas al flujo ba sico del caso de uso. Es importante resaltar que durante esta actividad se pueden producir las siguientes situaciones que deben tenerse en cuenta y que no deben ser motivo de preocupaci o n: 1. las relaciones ” include„ . 2. En algunos casos se incluyen actores que realmente no lo son. 4. Flujos alternativos. La relacio n ” extend„ se produce cuando existe una secuencia de acciones que se producen en ocasiones excepcionales. ya que deber ı a formar parte de otro caso de uso.interactua con el sistema. del cual heredan dos o m a s casos de uso. Esto se determina mediante la especificaci o n y documentacio n de cada caso de uso. es decir. en un sistema en el que se realizan pedidos de productos. que sen ala la secuencia de pasos que se va a producir en la mayor ı a de las veces en que ese caso de uso se ejecute. se considera al cliente como un actor (Ver figura 6). 4. Para ello. Para ello. ” extends„ y ” generalization„ entre casos de uso. Un caso de uso que debe partirse en dos casos de uso. Es importante resaltar que esta actividad es opcional. 3. 6 . la secuencia de pasos que se repite entre ellos. La relacio n ” include„ se debera determinar cuando la especificacio n de dos o m a s casos de uso contenga secuencias de acciones iguales. En ese caso. RUP [9]precisa que la especificaci o n de cada caso de uso debe contener lo siguiente: 1. En esta actividad se identifican. 4. por ejemplo. 3. Dos casos de uso que deben formar uno solo. ser aextraı da de esos casos de uso y se crear aun nuevo caso de uso que los incluya. que sen alan los estados en que debe estar el sistema para que se pueda ejecutar el caso de uso. se crea un caso de uso gen e rico al cual se le denomina caso de uso padre. Un caso de uso que debe eliminarse. Realmente quien ingresa los pedidos en el sistema es el vendedor y no el cliente. Precondiciones. En cuanto a la relacio n ” generalization„ se identifica cuando existen casos de uso cuyo prop o sito es similar y contienen secuencias de acciones parecidas. La relacio n ” generalization„ entre casos de uso es an a loga a la relacio n de ” herencia„ entre clases. Actividad 6: Identificar relaciones entre casos de uso (opcional). que sen alan el estado en que el sistema quedar aluego de haberse ejecutado el caso de uso. Flujo ba sico. Errores Comunes en la Especificacio n de Requisitos usando Casos de Uso En cada una de las actividades especificadas anteriormente se produc en y generan errores. A continuacio n se incluyen algunos de los m a s frecuentes. se crearaun nuevo caso de uso que contenga dicha secuencia de pasos y dicho caso de uso extenderala funcionalidad del caso uso original.

En el ejemplo de la figura 6. si el sistema permitiera registrar los pedidos por Internet. es considerar las opciones del men u o funciones del sistema como casos de uso (puede revisar el libro de Larman [6] y podra encontrar este tipo de errores). Considerar que los casos de uso son funciones del sistema. 7 .2 Errores en la identificaci o n de casos de uso Un error muy extendido. Diagrama de caso de uso para el registro de pedidos. Esta actividad la podrarealizar accediendo a las opciones del men u agregar. Crear cliente Usuario Modificar cliente Usuario Actualizar clientes Eliminar cliente Figura 7. modificar y eliminar clientes. 4. lo que al usuario le importa es actualizar la informacio n de clientes. y que es cometido en la mayorı a de la bibliografı a sobre casos de uso. en un sistema donde se debe almacenar la informaci o n de los clientes. Kurt Bittner [1]sen ala que los casos de uso deben mostrar lo que el usuario necesita del sistema y no mostrar las funciones u opciones del men u que permitira n realizar lo solicitado. el cliente sı serı a un actor del sistema. por lo tanto la funcionalidad del sistema ser arepresentada con el caso de uso ” Actualizar cliente„ (ver figura 7). por ejemplo.Cliente Registrar pedido Vendedor Figura 6.

se aconseja que no haya m a s de dos niveles de relaciones de tipo ” include„ o ” extend„ en un diagrama de casos de uso. ya que son elementos que se determinan en la etapa de dise n o. Algunos de los errores que se cometen son los siguientes: • Introducir palabras que se refieran a componentes de ventanas como: botones.4. la figura 9 muestra el caso de uso ” Buscar Cliente„ . ” grabar en la tabla clientes en la base de datos „ u ” ordena los datos con el algoritmo de la burbuja„ son oraciones que no deben incluirse en una especificaci o n. <<include>> <<include>> Ingresar datos cliente Usuario Verificar datos cliente Guardar datos del cliente Figura 8. Error: el caso de uso que es incluido por uno solo. pero no que componente de la ventana se va a utilizar para mostrar dicha informaci o n. La especificacio n de casos de uso debe contener informacio n exacta y precisa que permita realizar una buena estimacio n del esfuerzo requerido para realizar las etapas de an a lisis. lo cual serı a incorrecto. • Mencionar elementos correspondientes al dise n o de algoritmos o de base de datos en la especificaci o n de casos de uso. <<include>> Usuario Actualizar clientes Buscar cliente Figura 9. Los errores que se producen en esta actividad se deben a la inclusi o n de cuestiones de dise n o en la especificacio n de casos de uso. Para evitar cometer este error. el cual es incluido so lo por el caso de uso ” Actualizar clientes„ . Se debe tener en cuenta que los casos de uso incluidos deben obtenerse luego de haber realizado las especificaciones de los casos de uso. opciones de menu. Error: casos de uso como DFD Otro error frecuente es crear un caso de uso que es incluido por un solo caso de uso. disen o y codificacio n. de manera similar al diagrama que se muestra en la figura 8. listas desplegables. por ejemplo. por ejemplo. se pueden producir retrasos debido a modificaciones de la base de datos. Si la informaci o n no es exacta. Es por eso que se ven diagramas de casos de uso que parecen DFDs . mas no para el dise n o del sistema.4 Errores en el uso de las relaciones entre casos de uso. Otro error es incluir ” etc„ o ” ası sucesivamente„ cuando se indica la informaci o n que se debe ingresar o mostrar. Los errores que se producen al incluir relaciones entre los casos de uso se deben principalmente a confundir los casos de uso con los procesos de los diagramas de flujo de datos (DFD) de Yourdon [11]. sino se estarı a realizando el disen o de pantallas en el proceso de especificaci o n de requisitos. 4. ya que en ese momento es que se determinar a n cua les son los pasos que se repiten entre los diferentes casos de uso y es all ı donde se determinan las relaciones de tipo ” include„ . cambios en el disen o de las pantallas o en el c o digo fuente producto de las especificaciones tard ı as de requisitos. etc. 8 . En la especificacio n de casos de uso debe incluirse la informacio n que seraingresada o sera mostrada.3 Errores en la especificaci o n de los casos de uso. La te cnica de casos de uso se debe utilizar para la especificacio n de requisitos del sistema.

March 2001. 10. 1998.. Yourdon E. Bruegge B. http://www. 11. 1995. 5. Estas actividades han permitido minimizar los errores en la aplicacio n del est a ndar UML y lo que es importante. Prentice Hall Hispanoamericana. Architectures. 1.13. 4. 2002. Addison-Wesley. Me xico.uml. 5. El uso de las relaciones de casos de uso es opcional y no es necesaria para realizar un documento de especificacio n de requisitos adecuado y detallado. J. http://www. OMG Unified Modeling Language . Ingenierıa de Software Orientado a Objetos . USA.. S. Espan a. Heumann. 2001. J . USA. Design Patterns: elements of reusable object-oriented software.. Addison-Wesley. USA. Schneider... Winters.. 8. Ana lisis Estructurado Moderno.P.3. Second Edition . 9. W.Se puede encontrar bibliograf ı a en la que se emplea la relacio n ” use„ entre casos de uso. USA.com. K.. de manera similar a los patrones de dise n o [4] y los antipatrones [2] de software. 9 . USA. Rational Unified Process version 2001A. E.. Conclusiones y Trabajo Futuro En este artı culo se muestran las actividades que se deben realizar para la especificacio n de requisitos utilizando casos de uso. Introduccion al Ana lisis y Disen o Orientado a Objetos. Error: uso de notaci o n antigua de UML. Introduction to Business Modeling Using the Unified Modeling Language . El presente trabajo es un inicio para el establecimiento de patrones en la aplicacio n de casos de uso. M e xico. 1999 Rational Software. USA. por lo que su utilizacio n debe evitarse (ver figura 10). 2000. UML y Patrones. 2001.00. Prentice Hall Hispanoamericana.J. John Wiley & Sons.therationaledge.. Massachussets. C. G.04. 1989. Bibliografıa Bittner. 6. Why Use Cases Are Not Functions. Object Management Group.org. finalizar el proceso con un documento de especificaci o n de requisitos libre de errores y util para las etapas de an a lisis y disen o. 7. Larman. and Projects in Crisis. Applying Use Cases. USA. The Rational Edge. USA. Gamma.. 6. 1999 Ministerio de Administraciones Publicas. 3. <<include>> <<use>> Actualizar tareas del proyecto Seleccionar tareas _Jefe de Proyecto <<use>> <<include>> Realizar seguimiento de tareas Figura 10. Addison-Wesley. Allen. AntiPatterns: Refactoring Software. Brown. 2. Se debe tener en cuenta que dicha relacio n corresponde a versiones anteriores a UML versi o n 1. Ana lisis del Sistema de Informaci on-Metrica Version 3. 2000.