PROFESORA:

Ing. Ritzaida Tomé

INTEGRANTES:

Anirza Pérez C.I.: 19.622.245

Noiralith Rosas C.I.: 17.021.799

Julio Malavé C.I.: 12.359.302

Victor Silva C.I.: 10.390.303

Jeferson Brito C.I.: 14.440.494

CIUDAD GUAYANA, OCTUBRE DE 2011

INSTITUTO UNIVERSITARIO POLITECNICO“SANTIAGO MARIŇO”EXTENSIÓN GUAYANA

ESCUELA DE INGENIERIA DE SISTEMASCATEDRA: ELECTIVA V

CAPTURA DE REQUISITOS

INDICE

INTRODUCCIÓN.....................................................................................................3

CAPTURA DE REQUISITOS...................................................................................4

REQUISITOS DE USUARIOS.................................................................................4

TECNICA DE BUSQUEDA DE HECHOS................................................................5

IMPORTANCIA DEL USUARIO..............................................................................6

REQUISITOS DE DOCUMENTACION....................................................................7

CASOS DE USOS...................................................................................................8

CAPTURA Y MODELADO DE REQUISITOS.........................................................9

ANALISIS DE REQUISITOS..................................................................................10

COMO HACER EL MODELO DE REQUISITOS...................................................11

REALIZACIÓN DE CASOS DE USO....................................................................14

DIAGRAMA DE CLASES......................................................................................15

DIBUJO DIAGRAMA DE CLASE..........................................................................17

CONCLUSIÓN.......................................................................................................18

BIBLIOGRAFIA......................................................................................................19

INTRODUCCIÓN

La captura de requerimientos es el proceso de identificar que quiere el “cliente” del sistema propuesto.

La clave en esta etapa es que estamos en el dominio de problema. En esta etapa debemos describir todo desde la perspectiva del “cliente” y en el lenguaje de programación a utilizar.

El mayor riesgo que tenemos en la captura de requerimientos es empezar pensando en términos de posibles soluciones. Eso debe esperar hasta la Fase de Análisis. Uno de los pasos de la Fase de Análisis será tomar los resultados de la Fase de Requerimientos y refundirlos en el lenguaje de la solución estimada.

En este trabajo se utiliza el Lenguaje Unificado de Modelado (UML), y ofrecemon

acercamientos a casos de uso guiados sobre cómo estos diagramas se usan para

modelar sistemas.

3

CAPTURA DE REQUISITOS

La captura de requisitos es de vital importancia debido a que:

Permite gestionar las necesidades del proyecto en forma estructurada, debido a que cada actividad tendrá los pasos a seguir.

Mejora la capacidad de predecir cronogramas de proyecto proporcionando un punto de partida para controlar actividades específicas.

Mejora la calidad del software pues si se cumple con todos los requisitos el software poseerá lo que el cliente desea por lo tanto tendrá buena calidad.

Evita rechazo de usuarios finales debido a que obliga a los usuarios a considerar sus requerimientos cuidadosamente.

REQUISITOS DE USUARIOS

La captura de requisitos es el proceso de averiguar, normalmente en circunstancias difíciles, lo que se debe construir”

• La captura de requisitos es complicada– Los usuarios habitualmente no saben expresar exactamente lo que quieren– Es difícil tener una visión global del problema a resolver

• La especificación de requisitos es un documento más técnico y elaborado de los documentos de análisis

• Es importante codificar los requisitos para poder seguirlos a lo largo del proceso de desarrollo de software

• Se puede utilizar una especificación jerárquica– Están todos codificados por niveles, al igual que las leyes.– Se desea que en las actas quede reflejado lo más exactamente posible el problema a resolver, y que en las reuniones de análisis se determine exactamente qué requisitos se añaden o se eliminan– Los requisitos relacionados se organizan dentro de un mismo nivel– Cada nivel 1 se puede hacer corresponder posteriormente con un caso de uso– Cada nivel 2 se puede hacer corresponder posteriormente con un escenario– Cada nivel 3 se puede hacer corresponder posteriormente con un sub-escenario

4

TECNICA DE BUSQUEDA DE HECHOS

Es importante la obtención de los requisitos (descripción de una condición o capacidad que debe cumplir un sistema) debido a que es el hilo conductor de todo desarrollo de software. Una obtención de requisitos con calidad demuestra que el trabajo realizado culminará con éxito esto se debe a dos factores:

1ro- La utilización adecuada de las técnicas de captura de requisitos con los clientes.

2do- La experiencia de las analistas del proyecto.

Se plantea que se debe a estos factores puesto que la experiencia de trabajo en el rol le permite al equipo de Analistas del Proyecto establecer que técnicas van a utilizar a la hora de la entrevista con el cliente debido a que los clientes no entienden el lenguaje informático, es por eso que se debe tener en cuenta el lenguaje el cual se va a aplicar a la hora de la entrevista con el cliente.

5

REQUISITOS

Las técnicas más utilizadas son:

Entrevistas y cuestionarios: se emplean para reunir información proveniente de personas o grupos. Durante la misma los analistas conversan con los entrevistados realizándole una serie de preguntas acerca del sistema.

Sistemas existentes: consiste en analizar los sistemas ya desarrollados que estén relacionados con el sistema que va a ser construido. Analizándose las interfaces de usuarios y las entradas y salidas que el mismo produce.

Lluvia de ideas: es un modelo que se utiliza para generar ideas en grupo obteniendo la mayor cantidad de requerimientos del sistema que se pueda.

Los Requisitos del Software pueden ser divididos en dos categorías Funcionales y No Funcionales.

Los Requisitos Funcionales son aquellos que definen la función que el sistema va a llevar a cabo, describiendo las transformaciones que el sistema realiza sobre las entradas para obtener las salidas.

Los Requisitos no Funcionales tienen que ver con características que de una u otra forma pueden limitar el sistema, como por ejemplo rendimiento, fiabilidad, seguridad, entre otros

Hay que tener en cuenta que los Requisitos deben estar todos bien redactados, posibles de probar, concisos (fácil de leer y entender), consistente (no es contradictorio con otro requisito) y no ambiguo (una sola interpretación).

Mediante la captura de Requisitos se pueden afrontar dificultades debido a:

Un Requerimiento puede cambiar a lo largo del ciclo de desarrollo. El usuario no sabe explicar lo que hace.

Usan el mismo término con diferente resultado.

IMPORTANCIA DEL USUARIO

El desarrollo de un Sistema de Información es un una tarea muy compleja, que suele tomar varios meses y a veces hasta años; actividad en la cual varias personas de diferentes disciplinas aportan sus conocimientos para alcanzar un objetivo común, la sistematización de un determinado proceso. Sin embargo, normalmente los usuarios no tienen claro cuál es su función dentro de este

6

proceso de sistematización; en ocasiones hasta llega a pensar que le está brindando una ayuda al informático con una actividad netamente técnica, la cual él considera que será para beneficio del informático y no para mejorar sus propios procesos.

El rol que el usuario desempeña dentro del desarrollo de un Sistema de Información es de suma importancia, ya que los sistemas se construyen para satisfacer las necesidades particulares del usuario, en función de los objetivos estratégicos de la organización y ninguna otra persona, incluyendo al analista del sistema, conoce mejor que el usuario mismo, sus propios requerimientos; razón por la cual se dice que el usuario es el “Dueño del Sistema”. Sin embargo, éste no es su único papel, ya que existen una serie de funciones que el usuario debe asumir durante todo el desarrollo del proyecto, las cuales van exigiendo una determinada categorización del usuario de acuerdo a la responsabilidad que tendrá dentro del proyecto.

El primer papel del usuario será como Responsable del Sistema, esta será la persona encargada de definir en forma clara los requerimientos del nuevo sistema. Para ello deberá enviarle al Jefe del Departamento de Tecnología, una solicitud en la que al menos detalle lo siguiente:

Nombre del Sistema. Objetivos Generales y Específicos. Descripción general del Sistema, especificando claramente su

funcionamiento. Alcances y Delimitación del Sistema, aquí se mencionará lo que se

espera que el sistema realice y además aquellos procesos que están fuera de la frontera del sistema.

Responsabilidades, dentro del equipo de trabajo, una persona del área usuario que cumplirá con el papel de Encargado del Proyecto (puede ser el mismo Responsable del Sistema).

El papel que juega el Encargado de Proyecto del área usuario, será de coordinar junto con el Líder de Proyectos del área técnica todo lo concerniente a la planificación, control y seguimiento del avance del proyecto. Este será un “Facilitador” entre los usuarios y el equipo técnico que desarrollará el sistema, velará por el buen cumplimiento de los requerimientos inicialmente planteados y será quien le reporte directamente al Responsable del Sistema.

REQUISITOS DE DOCUMENTACION

El término “documentación” se refiere a los manuales escritos sobre políticas,

regulaciones y procedimientos de operaciones estándar que la mayoría de las

empresas mantienen como guía para gerentes y empleados. Los manuales que

documentan o describen las operaciones para los procesos de datos

7

existentes, o sistemas de información que entran dentro del área de

investigación, también proporcionan una visión sobre la forma en la que el

negocio debería conducirse. Normalmente muestran los requerimientos y

restricciones del sistema (como cantidad de transacciones o capacidad de

almacenamiento de datos) y características de diseño (controles y verificación

del procesamiento).

Los registros permiten que los analistas se familiaricen con algunas

operaciones, oficinas de la compañía y relaciones formales a las que debe

darse apoyo. No obstante, no muestran como producen de hecho las

actividades, donde se ubica el poder verdadero para las decisiones, o como se

realizan las tareas en la actualidad. Los otros métodos con objeto de encontrar

datos estudiados en esta sección son más eficaces para proporcionar al

analista este tipo de información.

Selección de los registros para revisión

En la mayor parte de las empresas los manuales de estándares sobre

procedimientos de operación usualmente son obsoletos; a menudo no se

mantienen al corriente lo suficiente para señalar los procedimientos existentes.

Los diagramas de organización muestran como las diferentes unidades

deberían relacionarse con otras; pero muchas no reflejan las operaciones

actuales.

• Especificación de la conducta externa del sistema.

• Especificar los límites de la implementación.

• Fácil de cambiar.

• Sirve como una herramienta de referencia para mantenimiento.

CASOS DE USOS

Los casos de uso son una técnica para especificar el comportamiento de un sistema:

“Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.”

Todo sistema de software ofrece a su entorno –aquellos que lo usan– una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo

8

externo a un sistema lo usa. Cuando decimos “alguien o algo “hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software.

Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está “ejecutando” el caso de uso ingresando pedido

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores. En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

CAPTURA Y MODELADO DE REQUISITOS

Los más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.

Pasos para la Definición de un Caso de Uso:

ID NOMBRE REFERENCIAS CRUZADAS CREADO POR ULTIMA ACTUALIZACION POR FECHA DE CREACION FECHA DE ULTIMA ACTUALIZACION ACTORES DESCRIPCION TRIGGER PRE-CONDICION POST-CONDICION

9

FLUJO NORMAL FLUJOS ALTERNATIVOS INCLUDES FRECUENCIA DE USO REGLAS DE NEGOCIO REQUERIMIENTOS ESPECIALES NOTAS Y ASUNTO

El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal objeto o entidad del sistema que es afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su interior.

ANALISIS DE REQUISITOS

El proceso de estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema, de hardware o de software” - “El proceso de estudio y refinamiento de requisitos”Requisito: -“Una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado”“Requisito” se aplica a las condiciones: -“que debe cumplir o poseer un sistema o uno de sus componentes para satisfacer un contrato, una norma o una especificación”. El cliente no entiende del proceso de La definición de requisitos diseño y desarrollo de software debe ser el fruto de trabajo conjunto porque Los analistas no suelen entender completamente el problema del cliente

Describir diferentes enfoques para descubrir los requerimientos. Explicar la necesidad de un análisis desde múltiples perspectivas Ilustrar un enfoque estructurado al análisis de requerimientos

10

Explicar por qué influyen los factores organizacionales y sociales en los requerimientos del sistema

Ejemplo:

Un sistema está formado por varias actividades o procesos, cada uno de los cuales contiene varios sub-procesos con marcadas interrelaciones entre ellos. Por ejemplo un proceso de cuentas por pagar puede estar integrado por tres sub-procesos que podrían llamarse: autorización de la factura, revisión del adeudo en la cuenta y elaboración del cheque.

A su vez cada sub-proceso se divide en sub-proceso más específico.

Los nombres dados a los procesos especifican acciones y procedimientos de control que realizan

Cada proceso se etiqueta además con un número que identifica de donde proviene (excepto el diagrama de contexto que solo se identifica con un nivel 0 más el nombre que se le proporcione)

En términos generales todo componente de los DFD (Diagramas de flujo de datos) se etiquetan con un nombre que sea representativo.

COMO HACER EL MODELO DE REQUISITOS

Un modelo es un bosquejo que representa un conjunto real con cierto grado de precisión y en la forma más completa posible, pero sin pretender aportar una réplica de lo que existe en la realidad. Los modelos son muy útiles para describir, explicar o comprender mejor la realidad, cuando es imposible trabajar directamente en la realidad en sí.

Por ejemplo, si quisiera explicar lo que es un hipopótamo, se le podría presentar en un dibujo, mejor aún sería una fotografía y todavía mejor, un modelo en tres dimensiones en una escala determinada. Para ciertos fines esto sería mucho más fácil que trasladarse al África para ver un hipopótamo en su ambiente natural.

Ejemplo:

PLANTEAMIENTO DEL PROBLEMA

Un concesionario de venta de vehículos requiere llevar su gestión de venta de vehículos, controlando que clientes compran, que vendedores efectúan la venta y que vehículos son vendidos y se requiere diseñar un sistema acorde a las siguientes especificaciones:

11

1. El concesionario dispone de un catalogo de vehículos definidos por marca, modelo, cilindrada y precio.

2. Cada uno de los modelos dispondrá de opciones adicionales (accesorios) tales como aire acondicionado, pintura metalizada, etc. Estos accesorios están definidos por un nombre y una descripción. Un accesorio puede ser común para varios modelos variando solo el precio en cada caso.

3. La información de los clientes debe tener: la Cedula, Nombre, dirección y teléfono.

4. Un cliente puede entregar su vehículo usado como parte de pago en la compra de uno nuevo, este vehículo usado debe tener la placa, marca, modelo, precio fijado, se debe tener también la fecha en que se hace esta operación.

5. Se desea tener la nomina de vendedores y debe tener: Cedula, nombre, dirección, teléfono.

6. En la operación de venta se debe tener los detalles de la operación incluyendo, el vendedor, los accesorios adicionales que adquirió el cliente, y si ha entregado un vehículo usado como parte de la operación.

12

MODELO ENTIDAD – RELACION

13

REALIZACIÓN DE CASOS DE USO

La asignación de responsabilidades y el diseño de colaboraciones son etapas muy importantes y creativas durante el diseño, mientras se elaboran los diagramas o mientras se programa.

La realización de un caso de uso describe cómo se realiza un caso de uso particular en el modelo de diseño, en función de los objetos que colaboran.

No aspiramos a describirlos todos en un sólo diagrama

¿POR QUÉ MODELAMOS?

Construimos modelos para comprender mejor el sistema que estamos desarrollando.

A través del modelado se consiguen cuatro objetivos:

Nos ayuda a visualizar como es ó queremos que sea un sistema.

Nos permite especificar la estructura ó el comportamiento de un sistema.

Nos proporcionan plantillas que nos guían en la construcción de un sistema.

Documentan las decisiones que hemos tomado.

14

DIAGRAMA DE CLASES

Un diagrama de Clases representa las clases que serán utilizadas dentro del sistema y las relaciones que existen entre ellas. Nos sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de convencimiento. Un diagrama de clases está compuesto por los siguientes elementos: Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

Diagrama:

Los diagramas se utilizan generalmente para facilitar el entendimiento de largas cantidades de datos y la relación entre diferentes partes de los datos también para realizar cálculos electrónicos.

Atributo:

Es la expresión gráfica que ilustra a base de recuadros y flechas los pasos que se deben seguir para producir algo. En donde los recuadros enmarcan a los agentes encargados de ejecutar lo que señalan las flechas que representan las acciones ó pasos.

Clase:Es la unidad básica que encapsula toda la información de un Objeto.

Método, UML: Es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño.

Atributos:Un atributo es la cualidad que se adjudica o predica de un ser con sentido de identidad.

Herencia:En la programación orientada a objetos, la herencia es un mecanismo que permite derivar una clase de otra, de manera que extienda su funcionalidad.

Composición:

15

La composición en referencia al lenguaje visual, supone la organización de los elementos que forman el conjunto de la imagen, con el fin de obtener un efecto de unidad y orden.

Clase Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el

entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde:

Superior:Contiene el nombre de la Clase.

Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser prívate, protected o public).

Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: prívate, protected o public).

16

DIBUJO DIAGRAMA DE CLASE

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc.) además posee algo particular que es Descapotable, en cambio Camión también hereda las características de Vehículo (Precio, VelMax, etc.) pero posee como particularidad propia Acoplado, Tara y Carga. Cabe destacar que fuera de este entorno, lo único "visible" es el método Características aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición pública, en cambio atributos como Descapotable no son visibles por ser privados.

17

CONCLUSIÓN

Luego de estudiar cada uno de los diagramas de UML, así como su utilidad para proyectos de ingeniería inversa y para muchos otros tipos de sistemas, se puede concluir que aunque no es la única herramienta para el análisis y diseño de sistemas, sí es una opción muy poderosa que puede ofrecer excelentes soluciones y una gran ayuda a la hora de crear o diseñar un sistema.

Esto también ayuda a trabajar ordenadamente, ahorrando tiempo, dinero y muchos problemas que se podrían desencadenar como consecuencia de no tener una adecuada y correcta documentación de las partes que componen un sistema.

Por supuesto que este trabajo explica lo referente a la captura de requisitos y modelado de manera breve, pero la idea que se da es suficiente como para presentar un buen panorama de lo que es el UML y los usos que tiene, así como de los elementos que lo componen.

18

BIBLIOGRAFIA

1. http://agamenon.uniandes.edu.co/~pfigueroa/soo/uml

http://www.rational.com/uml/

2. http://www.dcc.uchile.cl/~psalinas/uml/modelo.html

3. http://www.monografias.com/trabajos82/lenguaje-uml-importancia-modelar/

lenguaje-uml-importancia-modelar.shtml

4. http://es.wikipedia.org/wiki/Caso_de_uso

5. http://www.dcc.uchile.cl/~psalinas/uml/modelo.html

6. http://lsi.ugr.es/~mvega/isoo/larman/cap17[1].pdf

7. http://www.mitecnologico.com/Main/TecnicasDeRecopilacionDeInformacion

8. http://dis.unal.edu.co/~fgonza/courses/2003/ingSoft1/CAP5.pdf

9. http://www.uned.ac.cr/redti/tercera/documentos/articulo7.pdf

10.http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-

sistemas-uml.pdf

19