P. 1
Requerimientos Funcionales Y No Funcionales

Requerimientos Funcionales Y No Funcionales

|Views: 34|Likes:

More info:

Published by: Wilmer Jose Sifontes on Apr 16, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

08/21/2013

pdf

text

original

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.

3. 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. 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. 4. b) Metas . 6. Esta terminal es un sistema automatizado con el que se registran las ventas y se realizan los pagos. 5. Definir el esquema de la base de datos. Suponga que se nos ha contratado para crear este software. Los requerimientos Los requerimientos son una descripción de las necesidades o deseos de un producto. Perfeccionar la arquitectura del sistema. La meta principal en esta etapa es identificar y documentar lo que en realidad se necesita. 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). Definir los diagramas de diseño de clases. Definir los diagramas de interacción.

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

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

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

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. 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.

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 .

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. Poco después. Esta especificación es la evolución del las tres anteriores tecnologías orientadas a objetos lideres (Booch. OMT y OOSE). valores marcados y restricciones).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. 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. Procesos y ramas de procesamiento . uniendo el método OOSE (Object Oriented software engineering). incluyendo:   Mecanismos de extensión (estereotipos. 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. construir y documentar los artefactos de un sistema de software. Booch y Rumbaugh unieron fuerzas para forjar una unificación completa de los dos métodos. 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. así también es útil para hacer modelos de negocios. 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. visualizar. 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. OMT y OOSE que no funcionaran en la práctica. Ivar Jacobson y su compañía “Objectory” se unieron a Rational y a su trabajo de unificación. el quitar elementos de los lenguajes de Booch.8 de el “método unificado” fue dad a conocer en octubre de 1995. Una versión preliminar 0. Varios nuevos conceptos existen en UML.

el artefacto específico para el manejo de requerimientos es el Use Case y los Actores. Se han incorporado muchas técnicas líderes. 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. . pero se espera que técnicas adicionales influyan las versiones futuras del UML.. UML para el manejo de requerimientos En este trabajo nos enfocaremos principalmente a la notación usada para el manejo de requerimientos.” Los use cases se usan para especificar el comportamiento de el sistema sin definir su estructura. A esta secuencia de acciones se llama Use case. 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. Una descripción completa de la notación UML se encuentra en el documento [A4]. ¿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 llevan a cabo un numero de operaciones con el sistema y desarrollan una secuencia de transacciones en comunicación con el sistema. El UML puede ser extendido sin redefinir su núcleo. Muchas técnicas avanzadas pueden ser definidas usando el UML como base. Las instancias de los actores son los usuarios del sistema. El UML posee varios tipos de diagramas y construcciones que pueden ser usadas para el diseño de sistemas. .      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.

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 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 Use case Un use case es un tipo de clasificador que representa una unidad coherente de funcionalidad dentro de un sistema. con el nombre del actor debajo de la figura. Notación del Actor El icono estándar de un estereotipo de actor es la figura del “Mono de palo”. Como es un clasificador. Notación del Use Case Un use case es mostrado como una elipse conteniendo el nombre de el use case. o una precondición o postcondición El comportamiento de un use case puede ser descrito de maneras muy diferentes. pero también puede ser dado de otras formas. Los puntos de extensión pueden ser listados en un compartimento de el use case con el encabezado puntos de extensión. un use case también puede tener compartimentos mostrando atributos y operaciones. La descripción de la localización de el punto de extensión se da de la manera mas adecuada. Opcionalmente. un subsistema. 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. Un actor también puede ser representado como una clase con el estereotipo de “actor” con todos los compartimentos de esta. usualmente es en forma de texto. 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. pero maquinas de estados además de es y métodos son ejemplos de otras formas de describir el comportamiento de el use case. 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. dependiendo de que es lo mas conveniente: texto libre es comúnmente usado.

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

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. 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. como ya vimos explican el comportamiento requerido de un sistema en la perspectiva del actor. 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.  . 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.

por lo que señalar a una entidad como la provocadora de una falla es imposible. ¿Quien Genera la falla?. Para realizar correctamente este use case deberíamos modelar el sistema entero y especificar para . Las limitantes de los use cases generalmente son tan menores que la mayoría de los sistemas no se ven afectados por estas limitantes.  Materiales El material que debe de ser usado puede ser definido como un atributo de el use case. Sin embargo. Los sistemas de tiempo real tienen requerimientos particulares que no se encuentran en otros sistemas. Una falla de un sistema es prácticamente impredecible. Ejemplo de una limitante de los Use Cases. 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. ni no funcionales. 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. ¿que clase genero la falla?. Pero no de desempeño. 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 colaboración de clases. ni de entrenamiento. 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.

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. Referencias [A4] OMG Unified Modeling Language Specification Version 1. Esto definitivamente no es un trabajo muy práctico que digamos. 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. Sin embargo aun le falta evolucionar para cubrir en su totalidad toda la extensa gama de requerimientos que pueden ser aplicables a un sistema.cada componente las acciones que podrían llevar a una falla. June 1999 . Esperamos que los resultados que obtengamos sean satisfactorios (los cuales serán publicados en esta página a finales de año).

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->