Requerimientos Funcionales Y No Funcionales

Analisis y diseño La mayoría de proyectos de software son complejos, y la estrategia primaria para superar la complejidad, es la descomposición (divide y vencerás). La estrategia es dividir el problema en unidades más pequeñas que sean manejables. Un enfoque tradicional para realizar esto fue el análisis y diseño estructurados, donde se trata de descomponer el problema en funciones o procesos. Este método origina una división jerárquica de procesos constituidos por sub-procesos. Por ejemplo, una descomposición por funciones o procesos en análisis y diseño estructurados, de un Sistema de Información de Biblioteca podría ser el siguiente: Otra forma de realizar la descomposición, es usando un esquema de análisis y diseño orientado a objetos. En este esquema, se busca descomponer el problema en objetos, y no en funciones. Por ejemplo, una descomposición orientada a objetos del Sistema de Información de Biblioteca podría ser la siguiente: Algunas de las tareas a realizarse en la etapa de análisis 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 diseño son las siguientes: 1. Definir los casos reales de uso. 2. Definir los reportes, la interfaz de usuario y la secuencia de las pantallas.

Definir el esquema de la base de datos.3. 5. Definir los diagramas de diseño de clases. Los requerimientos Los requerimientos son una descripción de las necesidades o deseos de un producto. Perfeccionar la arquitectura del sistema. Caso de estudio: el punto de venta Supongamos como caso de estudio el sistema de una terminal de punto de venta. en una forma en que pueda fácilmente ser transmitido al cliente y al equipo de desarrollo. Suponga que se nos ha contratado para crear este software. 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. Por lo general este tipo de sistemas comprenden hardware (un computador y un lector de código barras) y software (el sistema que se ejecuta en la terminal). 4. La meta principal en esta etapa es identificar y documentar lo que en realidad se necesita. 6. b) Metas . Esta terminal es un sistema automatizado con el que se registran las ventas y se realizan los pagos. Definir los diagramas de interacción.

y su inclusión no repercute significativamente en el costo ni en otras funciones. Las siguientes son algunas de las funciones más representativas del sistema de punto de venta: Funciones básicas: Referencia Función Categoría R1. o usando una captura manual de un código de producto.1 Registra la venta en proceso (actual): los productos comprados.5 Se registran las ventas efectuadas.En términos generales. la siguiente frase deberá tener sentido: “El sistema deberá hacer X”. c) Funciones del sistema Las funciones del sistema son lo que éste deberá de hacer. Las funciones pueden clasificarse en tres categorías: evidentes. Muchas de estas funciones se omiten (erróneamente) durante el proceso de obtención de requerimientos. • Análisis rápido y exacto de las ventas. evidente R1. se incluye el impuesto. Las ocultas también deben realizarse. evidente R1. Para verificar que X es en verdad una función del sistema. y puede que no sean visibles para el usuario. Más concretamente. Las superfluas son opcionales. oculta R1. y el usuario debe saber que se han realizado. la meta es una mayor automatización del pago en las cajas registradoras. Por ejemplo: “el sistema deberá autorizar pagos a crédito”. evidente R1. y dar soporte a servicios más rápidos. Hay que identificar estas funciones y listarlas en grupos lógicos. más baratos y mejores. oculta . la meta incluye: • Pago rápido de los clientes. ocultas y superfluas.3 Captura la información sobre el objeto comprado usando su código de barras y un lector. Las evidentes deben realizarse.4 Reduce las cantidades del inventario cuando se realiza una venta. • Control automático del inventario.2 Calcula el total de la venta actual.

capturando la cantidad ofrecida y calculando el saldo deudor. capturando la información crediticia a partir de una lectora de tarjetas. y autorizando los pagos con el servicio de autorización (externo) de cheques de la tienda a través de consulta telefónica. oculta R1.2 Maneja los pagos a crédito. los cuales tienden a ser valores discretos. o mediante captura manual. tiempo de respuesta. Por ejemplo: tiempo de respuesta = (psicológicamente correcto) metáfora de interfaz = (gráfico.6 El cajero debe introducir una identificación y una contraseña para poder utilizar el sistema. evidente R2. Los atributos tienen un posible conjunto de detalles de atributos. colorido. confusos o simbólicos.8 Ofrece mecanismos de comunicación entre los procesos y entre los sistemas. evidente Funciones de pago: Referencia Función Categoría R2.1 Maneja los pagos en efectivo. evidente R2.9 Muestra la descripción y el precio del producto registrado. plataformas.4 Registra los pagos en el sistema de cuentas por cobrar. basado en formularios) . y autorizando los pagos con el servicio de autorización (externa) de créditos de la tienda a través de una conexión por modem.3 Maneja los pagos con cheque. pues el servicio de autorización de crédito 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. oculta R1. evidente R2. tolerancia a fallas.7 Ofrece un mecanismo de almacenamiento persistente. metáfora de interfaz. Por ejemplo: facilidad de uso. evidente R1. capturando el número de RUT y teléfono mediante captura manual.R1.

Con colores.9 Mostrar la descripción y el precio del producto registrado. Además. 98. oculto tolerancia a fallas Debe registrar en las cuentas por cobrar en un plazo de 24 horas. metáfora de interfaz (detalle) Ventanas orientadas a la metáfora de un formulario y cuadros de diálogo. es conveniente describir todos los atributos del sistema que se relacionen claramente con las funciones especificadas. Función Categoría Atributo Detalles y restricciones Categoría R1. tolerancia a fallas (restricción de frontera) Debe registrar los pagos a crédito autorizados que se hagan a las cuentas por cobrar en un plazo de 24 horas.Algunos atributos del sistema también pueden tener restricciones de frontera del atributo. que son condiciones obligatorias de frontera.4 Registrar los pagos a crédito en el sistema de cuentas por cobrar. evidente tiempo de respuesta 1 segundo como máximo obligatorio metáfora de interfaz obligatorio Pantallas basadas en formularios. aun cuando se produzcan fallas de energía o del equipo. los detalles de los atributos y las restricciones de frontera pueden catalogarse como obligatorios u opcionales. Por ejemplo: Ref. obligatorio tiempo de respuesta 10 segundos como máximo obligatorio . aun cuando se produzcan fallas de energía o del equipo. R2. (detalle) Maximiza una navegación fácil con teclado y no con mouse. la descripción y el precio aparecerán en un segundo. Por ejemplo: tiempo de respuesta = (dos segundos como máximo) Algunos atributos del sistema de punto de venta son: Atributo Detalles y restricciones de frontera tiempo de respuesta (restricción de frontera) Cuando se registre un producto vendido. generalmente en un rango numérico de valores de un atributo. plataformas del sistema operativo (detalle) Microsoft Windows 95. Finalmente. 2000 y NT. pues el servicio de autorización de crédito debe a la tienda el importe del pago.

Actividades de la IR para diferentes modelos de procesos de Ingeniería de Software MODELO Oliver and Steiner 1996 EIA / IS-632 IEEE Std 1220.1994 CMM nivel Repetitivo RUP (2) Evaluar la información disponible Definir métricas efectivas Análisis de requerimientos Análisis de Requerimientos Identificación de requerimientos Análisis del Problema Análisis funcional Actividades Estudio de los requerimientos Identificación de Comprender las restricciones del necesidades de los sistema a desarrollar involucrados Análisis de los requerimientos Definir el sistema Crear un modelo del comportamiento del sistema Síntesis Validación de requerimientos .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:      Análisis del Problema Evaluación y Negociación Especificación Validación Evolución Tabla 1.

Crear un modelo de los objetos Ejecutar el análisis Análisis y control del sistema Análisis funcional Representación de los requerimientos Analizar el alcance del proyecto Evaluación y estudio Comunicación de los Modificar la de funciones requerimientos definición del sistema Verificación de funciones Validación de requerimientos Administrar los cambios de requerimientos Crear un plan secuencial de construcción y pruebas Síntesis Estudio y evaluación del diseño Verificación física Control .

El “Unified Modelling Languaje” (UML) En este capítulo se explica brevemente lo que es el UML (en relación al manejo de requerimientos) y su historia. Varios nuevos conceptos existen en UML. visualizar. Booch y Rumbaugh unieron fuerzas para forjar una unificación completa de los dos métodos. 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 métodos de Booch y OMT. OMT y OOSE). valores marcados y restricciones). OMT y OOSE que no funcionaran en la práctica. La información presentada esta basada en el documento referencia [A4] Introducción al UML El “Unified Modelling Languaje” (UML) provee a los analistas y arquitectos de sistemas que trabajan en el diseño y análisis de objetos de un lenguaje consistente para especificar. Ivar Jacobson y su compañía “Objectory” se unieron a Rational y a su trabajo de unificación. Procesos y ramas de procesamiento . Esta especificación es la evolución del las tres anteriores tecnologías orientadas a objetos lideres (Booch. así también es útil para hacer modelos de negocios. incluyendo:   Mecanismos de extensión (estereotipos. construir y documentar los artefactos de un sistema de software.8 de el “método unificado” fue dad a conocer en octubre de 1995. Debido a que los métodos Booch y OMT ya habían madurado independientemente y eran reconocidos como métodos líderes en el desarrollo orientado a objetos. uniendo el método OOSE (Object Oriented software engineering). el quitar elementos de los lenguajes de Booch. Poco después. Una versión preliminar 0. el añadir elementos de otros métodos que fueran mas efectivos y el inventar nuevas construcciones solamente cuando la solución existente no estuviera disponible. El UML es la unión de estos lenguajes de modelos y aún mas ya que incluye expresiones adicionales para manejar problemas de modelaje que los métodos anteriores no cubrían plenamente. El Nombre de Objectory es ahora dado mayormente para describir a el Proceso que acompaña al UML el “Rational unified process” Los objetivos de la unificación fueron: el mantenerlo simple.

El UML posee varios tipos de diagramas y construcciones que pueden ser usadas para el diseño de sistemas. la forma de que un modelo de Use cases es realizado en términos de objetos que son definidos por clases dentro de el sistema se puede describir con diagramas de colaboración. el artefacto específico para el manejo de requerimientos es el Use Case y los Actores. Las instancias de los actores son los usuarios del sistema. El UML puede ser extendido sin redefinir su núcleo. Una descripción completa de la notación UML se encuentra en el documento [A4]. Se han incorporado muchas técnicas líderes. UML para el manejo de requerimientos En este trabajo nos enfocaremos principalmente a la notación usada para el manejo de requerimientos. A esta secuencia de acciones se llama Use case. ellos llevan a cabo un numero de operaciones con el sistema y desarrollan una secuencia de transacciones en comunicación con el sistema. Muchas técnicas avanzadas pueden ser definidas usando el UML como base. pero se espera que técnicas adicionales influyan las versiones futuras del UML.. .” Los use cases se usan para especificar el comportamiento de el sistema sin definir su estructura.      Distribución y concurrencia Patrones y colaboración Diagramas de actividad Refinamiento (para manejar las relaciones entre los niveles de abstracción) Interfaces y componentes y Un lenguaje para restricciones Aunque el UML define un leguaje preciso. . ¿Que es un "Use Case"? Jacobsson en [A2] define a los use cases y a los actores como: “Los Actores representan lo que interactúa con el sistema. Ellos representan a todo lo que necesita intercambiar información con el sistema. no es una barrera para el desarrollo futuro en los conceptos de modelaje.

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 use case también puede tener compartimentos mostrando atributos y operaciones. Como es un clasificador. usualmente es en forma de texto. dependiendo de que es lo mas conveniente: texto libre es comúnmente usado. con el nombre del actor debajo de la figura. pero maquinas de estados además de es y métodos son ejemplos de otras formas de describir el comportamiento de el use case. Opcionalmente. Los puntos de extensión pueden ser listados en un compartimento de el use case con el encabezado puntos de extensión. Un actor también puede ser representado como una clase con el estereotipo de “actor” con todos los compartimentos de esta. Notación del Actor El icono estándar de un estereotipo de actor es la figura del “Mono de palo”. o una precondición o postcondición El comportamiento de un use case puede ser descrito de maneras muy diferentes. La descripción de la localización de el punto de extensión se da de la manera mas adecuada. un estereotipo puede ser colocado arriba de el nombre y una lista de propiedades también puede ser incluida abajo de el nombre. como el nombre de un estado en una máquina de estados. Una actor se considera que juega un rol diferente con relación a cada use case con el cual actúa. Cada punto de inserción tiene un nombre único dentro de el use case y además cuenta con una descripción de el punto de inserción dentro de el comportamiento de el use case. . pero también puede ser dado de otras formas. Un Punto de extensión es una referencia a un punto dentro del use case en el que las secuencias de acciones de otros use cases pueden ser insertadas. Semántica del Actor Un Actor define un conjunto coherente de roles los cuales pueden ser usados por los usuarios de una entidad cuando interactúan con esta entidad. un subsistema.Semántica del Use case Un use case es un tipo de clasificador que representa una unidad coherente de funcionalidad dentro de un sistema. Notación del Use Case Un use case es mostrado como una elipse conteniendo el nombre de el use case.

como es percibido por el exterior de el sistema.Diagramas de Use case Semántica Los diagramas de Use Case representan a los actores y a los use cases junto con sus relaciones.  Generalización – Una generalización de un use case A hacia el use case B indica que A es una especialización de B . Esta es la única relación entre los actores y los Use cases. Notación Un diagrama de use case es una gráfica de actores. e.  Extensión – una relación de extensión 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 extensión) por el comportamiento de especificado en el Use Case B. i. instancias de el actor e instancias de el use case se comunican entre si. el cual es referenciado por la relación externa. posiblemente algunas interfaces y las relaciones entre estos elementos. Ejemplo de Diagrama de use case Relaciones de los Use cases Hay varias relaciones estándar entre los use cases o entre los actores y los use cases. Los Use Cases representan la funcionalidad de un sistema o subsistema o clase. es decir por sus actores. un conjunto de use cases. extensiones e inclusiones entre los use cases.  Asociación – La participación de un actor en el Use Case. El comportamiento es insertado el punto definido como punto de extensión del Use Case B. Las relaciones son asociaciones entre los actores y los use cases generalizaciones entre los actores y generalizaciones.

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 básicamente la funcionalidad requerida por el sistema. Si analizamos las características de los requerimientos propuestas en los capítulos anteriores. como ya vimos explican el comportamiento requerido de un sistema en la perspectiva del actor. Inclusión – una relación de inclusión de el use Case A hacia el Use case B indica que una instancia de el use case A también contendrá el comportamiento especificado por B. Interfases La relación entre el actor y el use case puede ser refinada para especificar la interfase usada por el use case y el actor.  . 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.

Ejemplo de una limitante de los Use Cases. Las limitantes de los use cases generalmente son tan menores que la mayoría de los sistemas no se ven afectados por estas limitantes. ¿que clase genero la falla?. ¿Quien Genera la falla?. 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. ni de entrenamiento. por lo que señalar 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.  Materiales El material que debe de ser usado puede ser definido como un atributo de el use case. Una falla de un sistema es prácticamente impredecible. ¿Como realizamos el use case? Si un use case se realiza con la colaboración de clases. ni no funcionales. Los sistemas de tiempo real tienen requerimientos particulares que no se encuentran en otros sistemas. Sin embargo. Para realizar correctamente este use case deberíamos modelar el sistema entero y especificar para . un ejemplo de estos requerimientos es:  El Tiempo fuera de servicio (Ejemplo: "No mas de 6 minutos por año por máquina") –  La Independencia ("Las fallas de software y hardware serán restablecidas sin intervención humana") Si queremos modelar estos requerimientos en Use Cases nos encontraremos con varios obstáculos: ¿Quien es el actor? Si el requerimiento se enfoca a fallas de software o hardware. Pero no de desempeño. Restricciones de diseño 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 colaboración que realizan dicho use case.

Conclusiones El hecho de poder manejar un requerimiento como un Objeto hace de los use cases una herramienta sumamente poderosa en el manejo y especificación de requerimientos. Este tema de investigación es precisamente el que ha dado nacimiento al proyecto de tesis que alimenta el contenido de esta pagina web.3. Referencias [A4] OMG Unified Modeling Language Specification Version 1. Esto definitivamente no es un trabajo muy práctico que digamos.cada componente las acciones que podrían llevar a una falla. June 1999 . Sin embargo aun le falta evolucionar para cubrir en su totalidad toda la extensa gama de requerimientos que pueden ser aplicables a un sistema. Esperamos que los resultados que obtengamos sean satisfactorios (los cuales serán publicados en esta página a finales de año).

Sign up to vote on this title
UsefulNot useful