Requerimientos Funcionales Y No Funcionales

Analisis y diseo La mayora de proyectos de software son complejos, y la estrategia primaria para superar la complejidad, es la descomposicin (divide y vencers). La estrategia es dividir el problema en unidades ms pequeas que sean manejables. Un enfoque tradicional para realizar esto fue el anlisis y diseo estructurados, donde se trata de descomponer el problema en funciones o procesos. Este mtodo origina una divisin jerrquica de procesos constituidos por sub-procesos. Por ejemplo, una descomposicin por funciones o procesos en anlisis y diseo estructurados, de un Sistema de Informacin de Biblioteca podra ser el siguiente: Otra forma de realizar la descomposicin, es usando un esquema de anlisis y diseo orientado a objetos. En este esquema, se busca descomponer el problema en objetos, y no en funciones. Por ejemplo, una descomposicin orientada a objetos del Sistema de Informacin de Biblioteca podra ser la siguiente: Algunas de las tareas a realizarse en la etapa de anlisis son las siguientes: 1. Definir los requerimientos. 2. Definir los casos esenciales de uso. 3. Crear y perfeccionar los diagramas de casos de uso. 4. Crear y perfeccionar el modelo conceptual. 5. Crear y perfeccionar el glosario. 6. Definir los diagramas de secuencia de los sistemas. 7. Definir los contratos de operaciones. Algunas de las tareas a realizarse en la etapa de diseo son las siguientes: 1. Definir los casos reales de uso. 2. Definir los reportes, la interfaz de usuario y la secuencia de las pantallas.

3. Perfeccionar la arquitectura del sistema. 4. Definir los diagramas de interaccin. 5. Definir los diagramas de diseo de clases. 6. Definir el esquema de la base de datos. Caso de estudio: el punto de venta Supongamos como caso de estudio el sistema de una terminal de punto de venta. Esta terminal es un sistema automatizado con el que se registran las ventas y se realizan los pagos. Por lo general este tipo de sistemas comprenden hardware (un computador y un lector de cdigo barras) y software (el sistema que se ejecuta en la terminal). Suponga que se nos ha contratado para crear este software. Los requerimientos Los requerimientos son una descripcin de las necesidades o deseos de un producto. La meta principal en esta etapa es identificar y documentar lo que en realidad se necesita, en una forma en que pueda fcilmente ser transmitido al cliente y al equipo de desarrollo. Se recomienda aqu definir al menos los siguientes puntos: Panorama general Metas Funciones del sistema Atributos del sistema a) Panorama general Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizar en las ventas al menudeo. b) Metas

En trminos generales, la meta es una mayor automatizacin del pago en las cajas registradoras, y dar soporte a servicios ms rpidos, ms baratos y mejores. Ms concretamente, la meta incluye: Pago rpido de los clientes. Anlisis rpido y exacto de las ventas. Control automtico del inventario. c) Funciones del sistema Las funciones del sistema son lo que ste deber de hacer. Hay que identificar estas funciones y listarlas en grupos lgicos. Para verificar que X es en verdad una funcin del sistema, la siguiente frase deber tener sentido: El sistema deber hacer X. Por ejemplo: el sistema deber autorizar pagos a crdito. Las funciones pueden clasificarse en tres categoras: evidentes, ocultas y superfluas. Las evidentes deben realizarse, y el usuario debe saber que se han realizado. Las ocultas tambin deben realizarse, y puede que no sean visibles para el usuario. Muchas de estas funciones se omiten (errneamente) durante el proceso de obtencin de requerimientos. Las superfluas son opcionales, y su inclusin no repercute significativamente en el costo ni en otras funciones. Las siguientes son algunas de las funciones ms representativas del sistema de punto de venta: Funciones bsicas: Referencia Funcin Categora R1.1 Registra la venta en proceso (actual): los productos comprados. evidente R1.2 Calcula el total de la venta actual; se incluye el impuesto. evidente R1.3 Captura la informacin sobre el objeto comprado usando su cdigo de barras y un lector, o usando una captura manual de un cdigo de producto. evidente R1.4 Reduce las cantidades del inventario cuando se realiza una venta. oculta R1.5 Se registran las ventas efectuadas. oculta

R1.6 El cajero debe introducir una identificacin y una contrasea para poder utilizar el sistema. evidente R1.7 Ofrece un mecanismo de almacenamiento persistente. oculta R1.8 Ofrece mecanismos de comunicacin entre los procesos y entre los sistemas. oculta R1.9 Muestra la descripcin y el precio del producto registrado. evidente Funciones de pago: Referencia Funcin Categora R2.1 Maneja los pagos en efectivo, capturando la cantidad ofrecida y calculando el saldo deudor. evidente R2.2 Maneja los pagos a crdito, capturando la informacin crediticia a partir de una lectora de tarjetas, o mediante captura manual, y autorizando los pagos con el servicio de autorizacin (externa) de crditos de la tienda a travs de una conexin por modem. evidente R2.3 Maneja los pagos con cheque, capturando el nmero de RUT y telfono mediante captura manual, y autorizando los pagos con el servicio de autorizacin (externo) de cheques de la tienda a travs de consulta telefnica. evidente R2.4 Registra los pagos en el sistema de cuentas por cobrar, pues el servicio de autorizacin de crdito debe a la tienda el monto del pago. oculta d) Atributos del sistema Los atributos del sistema son cualidades no funcionales que a menudo se confunden con las funciones. Por ejemplo: facilidad de uso, tolerancia a fallas, tiempo de respuesta, metfora de interfaz, plataformas. Los atributos tienen un posible conjunto de detalles de atributos, los cuales tienden a ser valores discretos, confusos o simblicos. Por ejemplo: tiempo de respuesta = (psicolgicamente correcto) metfora de interfaz = (grfico, colorido, basado en formularios)

Algunos atributos del sistema tambin pueden tener restricciones de frontera del atributo, que son condiciones obligatorias de frontera, generalmente en un rango numrico de valores de un atributo. Por ejemplo: tiempo de respuesta = (dos segundos como mximo) Algunos atributos del sistema de punto de venta son: Atributo Detalles y restricciones de frontera tiempo de respuesta (restriccin de frontera) Cuando se registre un producto vendido, la descripcin y el precio aparecern en un segundo. metfora de interfaz (detalle) Ventanas orientadas a la metfora de un formulario y cuadros de dilogo. (detalle) Maximiza una navegacin fcil con teclado y no con mouse. tolerancia a fallas (restriccin de frontera) Debe registrar los pagos a crdito autorizados que se hagan a las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energa o del equipo. plataformas del sistema operativo (detalle) Microsoft Windows 95, 98, 2000 y NT. Finalmente, es conveniente describir todos los atributos del sistema que se relacionen claramente con las funciones especificadas. Adems, los detalles de los atributos y las restricciones de frontera pueden catalogarse como obligatorios u opcionales. Por ejemplo: Ref. Funcin Categora Atributo Detalles y restricciones Categora R1.9 Mostrar la descripcin y el precio del producto registrado. evidente tiempo de respuesta 1 segundo como mximo obligatorio
metfora de interfaz obligatorio Pantallas basadas en formularios. Con colores.

R2.4 Registrar los pagos a crdito en el sistema de cuentas por cobrar, pues el servicio de autorizacin de crdito debe a la tienda el importe del pago. oculto tolerancia a fallas Debe registrar en las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energa o del equipo. obligatorio
tiempo de respuesta 10 segundos como mximo obligatorio

A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades mostradas en la tabla anterior, podemos identificar y extraer cinco actividades principales que son:

Anlisis del Problema Evaluacin y Negociacin Especificacin Validacin Evolucin

Tabla 1. Actividades de la IR para diferentes modelos de procesos de Ingeniera de Software MODELO Oliver and Steiner 1996 EIA / IS-632 IEEE Std 1220- 1994 CMM nivel Repetitivo RUP (2)

Evaluar la informacin disponible Definir mtricas efectivas

Anlisis de requerimientos

Anlisis de Requerimientos

Identificacin de requerimientos

Anlisis del Problema

Anlisis funcional

Actividades

Estudio de los requerimientos

Identificacin de Comprender las restricciones del necesidades de los sistema a desarrollar involucrados Anlisis de los requerimientos Definir el sistema

Crear un modelo del comportamiento del sistema

Sntesis

Validacin de requerimientos

Crear un modelo de los objetos Ejecutar el anlisis

Anlisis y control del sistema

Anlisis funcional

Representacin de los requerimientos

Analizar el alcance del proyecto

Evaluacin y estudio Comunicacin de los Modificar la de funciones requerimientos definicin del sistema Verificacin de funciones Validacin de requerimientos Administrar los cambios de requerimientos

Crear un plan secuencial de construccin y pruebas

Sntesis Estudio y evaluacin del diseo Verificacin fsica Control

El Unified Modelling Languaje (UML)

En este captulo se explica brevemente lo que es el UML (en relacin al manejo de requerimientos) y su historia. La informacin presentada esta basada en el documento referencia [A4]

Introduccin al UML
El Unified Modelling Languaje (UML) provee a los analistas y arquitectos de sistemas que trabajan en el diseo y anlisis de objetos de un lenguaje consistente para especificar, visualizar, construir y documentar los artefactos de un sistema de software, as tambin es til para hacer modelos de negocios. Esta especificacin es la evolucin del las tres anteriores tecnologas orientadas a objetos lideres (Booch, OMT y OOSE). El UML es la unin de estos lenguajes de modelos y an mas ya que incluye expresiones adicionales para manejar problemas de modelaje que los mtodos anteriores no cubran plenamente. El desarrollo de el UML empez en octubre de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation iniciaron su trabajo para unificar los mtodos de Booch y OMT. Debido a que los mtodos Booch y OMT ya haban madurado independientemente y eran reconocidos como mtodos lderes en el desarrollo orientado a objetos, Booch y Rumbaugh unieron fuerzas para forjar una unificacin completa de los dos mtodos. Una versin preliminar 0.8 de el mtodo unificado fue dad a conocer en octubre de 1995. Poco despus, Ivar Jacobson y su compaa Objectory se unieron a Rational y a su trabajo de unificacin, uniendo el mtodo OOSE (Object Oriented software engineering). El Nombre de Objectory es ahora dado mayormente para describir a el Proceso que acompaa al UML el Rational unified process Los objetivos de la unificacin fueron: el mantenerlo simple, el quitar elementos de los lenguajes de Booch, OMT y OOSE que no funcionaran en la prctica, el aadir elementos de otros mtodos que fueran mas efectivos y el inventar nuevas construcciones solamente cuando la solucin existente no estuviera disponible. Varios nuevos conceptos existen en UML, incluyendo:

Mecanismos de extensin (estereotipos, valores marcados y restricciones), Procesos y ramas de procesamiento

Distribucin y concurrencia Patrones y colaboracin Diagramas de actividad Refinamiento (para manejar las relaciones entre los niveles de abstraccin) Interfaces y componentes y Un lenguaje para restricciones Aunque el UML define un leguaje preciso, no es una barrera para el desarrollo futuro en los conceptos de modelaje. Se han incorporado muchas tcnicas lderes, pero se espera que tcnicas adicionales influyan las versiones futuras del UML. Muchas tcnicas avanzadas pueden ser definidas usando el UML como base. El UML puede ser extendido sin redefinir su ncleo. UML para el manejo de requerimientos En este trabajo nos enfocaremos principalmente a la notacin usada para el manejo de requerimientos. Una descripcin completa de la notacin UML se encuentra en el documento [A4]. El UML posee varios tipos de diagramas y construcciones que pueden ser usadas para el diseo de sistemas, el artefacto especfico para el manejo de requerimientos es el Use Case y los Actores.

Que es un "Use Case"?

Jacobsson en [A2] define a los use cases y a los actores como: Los Actores representan lo que interacta con el sistema. Ellos representan a todo lo que necesita intercambiar informacin con el sistema. Las instancias de los actores son los usuarios del sistema, ellos llevan a cabo un numero de operaciones con el sistema y desarrollan una secuencia de transacciones en comunicacin con el sistema. A esta secuencia de acciones se llama Use case. .. Los use cases se usan para especificar el comportamiento de el sistema sin definir su estructura, la forma de que un modelo de Use cases es realizado en trminos de objetos que son definidos por clases dentro de el sistema se puede describir con diagramas de colaboracin.

Semntica del Use case

Un use case es un tipo de clasificador que representa una unidad coherente de funcionalidad dentro de un sistema, un subsistema, o una clase manifestada por una secuencia de mensajes intercambiados entre el sistema y uno o mas objetos externos (llamados actores) y por acciones que el sistema lleva a cabo.

Un Punto de extensin es una referencia a un punto dentro del use case en el que las secuencias de acciones de otros use cases pueden ser insertadas. Cada punto de insercin tiene un nombre nico dentro de el use case y adems cuenta con una descripcin de el punto de insercin dentro de el comportamiento de el use case.

Notacin del Use Case

Un use case es mostrado como una elipse conteniendo el nombre de el use case. Opcionalmente, un estereotipo puede ser colocado arriba de el nombre y una lista de propiedades tambin puede ser incluida abajo de el nombre. Como es un clasificador, un use case tambin puede tener compartimentos mostrando atributos y operaciones. Los puntos de extensin pueden ser listados en un compartimento de el use case con el encabezado puntos de extensin. La descripcin de la localizacin de el punto de extensin se da de la manera mas adecuada, usualmente es en forma de texto, pero tambin puede ser dado de otras formas, como el nombre de un estado en una mquina de estados, o una precondicin o postcondicin El comportamiento de un use case puede ser descrito de maneras muy diferentes, dependiendo de que es lo mas conveniente: texto libre es comnmente usado, pero maquinas de estados adems de es y mtodos son ejemplos de otras formas de describir el comportamiento de el use case.

Semntica del Actor

Un Actor define un conjunto coherente de roles los cuales pueden ser usados por los usuarios de una entidad cuando interactan con esta entidad. Una actor se considera que juega un rol diferente con relacin a cada use case con el cual acta.

Notacin del Actor

El icono estndar de un estereotipo de actor es la figura del Mono de palo, con el nombre del actor debajo de la figura. Un actor tambin puede ser representado como una clase con el estereotipo de actor con todos los compartimentos de esta.

Diagramas de Use case Semntica

Los diagramas de Use Case representan a los actores y a los use cases junto con sus relaciones. Los Use Cases representan la funcionalidad de un sistema o subsistema o clase, como es percibido por el exterior de el sistema, es decir por sus actores.

Notacin
Un diagrama de use case es una grfica de actores, un conjunto de use cases, posiblemente algunas interfaces y las relaciones entre estos elementos. Las relaciones son asociaciones entre los actores y los use cases generalizaciones entre los actores y generalizaciones, extensiones e inclusiones entre los use cases.

Ejemplo de Diagrama de use case

Relaciones de los Use cases

Hay varias relaciones estndar entre los use cases o entre los actores y los use cases. Asociacin La participacin de un actor en el Use Case, i. e. instancias de el actor e instancias de el use case se comunican entre si. Esta es la nica relacin entre los actores y los Use cases. Extensin una relacin de extensin entre el use case A y el use Case B indica que una instancia de el use case B puede ser aumentada (Dependiendo de ciertas condiciones especificadas en la extensin) por el comportamiento de especificado en el Use Case B. El comportamiento es insertado el punto definido como punto de extensin del Use Case B, el cual es referenciado por la relacin externa. Generalizacin Una generalizacin de un use case A hacia el use case B indica que A es una especializacin de B

 Inclusin una relacin de inclusin de el use Case A hacia el Use case B indica que una instancia de el use case A tambin contendr el comportamiento especificado por B. El comportamiento es incluido en el punto definido en A

Ejemplo de diagrama de Use case y algunas de sus relaciones

Limitantes de los Use Cases

Los use cases, como ya vimos explican el comportamiento requerido de un sistema en la perspectiva del actor. Si analizamos las caractersticas de los requerimientos propuestas en los captulos anteriores. Podemos ver que los use cases pueden definir los requerimientos de: Entorno Al definir quienes son los actores se est definiendo el entorno Funcionales Lo que ejecuta el use Case son bsicamente la funcionalidad requerida por el sistema. Interfases La relacin entre el actor y el use case puede ser refinada para especificar la interfase usada por el use case y el actor.

Restricciones de diseo Una norma oficial o el uso de cierto tipo de estructura de sistema puede ser especificado en el use case o en los diagramas de colaboracin que realizan dicho use case.

Materiales El material que debe de ser usado puede ser definido como un atributo de el use case. Pero no de desempeo, ni no funcionales, ni de entrenamiento.

Ejemplo de una limitante de los Use Cases.

Las limitantes de los use cases generalmente son tan menores que la mayora de los sistemas no se ven afectados por estas limitantes. Sin embargo, existe un tipo especial de sistema en el cual los use cases aun necesitan evolucionar para conseguir cubrir y especificar plenamente sus requerimientos: Estos son los sistemas de tiempo real. Los sistemas de tiempo real tienen requerimientos particulares que no se encuentran en otros sistemas, un ejemplo de estos requerimientos es:

El Tiempo fuera de servicio (Ejemplo: "No mas de 6 minutos por ao por mquina")

La Independencia ("Las fallas de software y hardware sern restablecidas sin intervencin humana")

Si queremos modelar estos requerimientos en Use Cases nos encontraremos con varios obstculos: Quien es el actor? Si el requerimiento se enfoca a fallas de software o hardware, Quien Genera la falla?. Una falla de un sistema es prcticamente impredecible, por lo que sealar a una entidad como la provocadora de una falla es imposible. Mas aun el especificar las acciones que esta entidad realiza con el use case para provocar la falla son ilimitadas. Como realizamos el use case? Si un use case se realiza con la colaboracin de clases, que clase genero la falla?. Para realizar correctamente este use case deberamos modelar el sistema entero y especificar para

cada componente las acciones que podran llevar a una falla. Esto definitivamente no es un trabajo muy prctico que digamos.

Conclusiones
El hecho de poder manejar un requerimiento como un Objeto hace de los use cases una herramienta sumamente poderosa en el manejo y especificacin de requerimientos. Sin embargo aun le falta evolucionar para cubrir en su totalidad toda la extensa gama de requerimientos que pueden ser aplicables a un sistema. Este tema de investigacin es precisamente el que ha dado nacimiento al proyecto de tesis que alimenta el contenido de esta pagina web. Esperamos que los resultados que obtengamos sean satisfactorios (los cuales sern publicados en esta pgina a finales de ao).

Referencias
[A4] OMG Unified Modeling Language Specification Version 1.3, June 1999