INGENIERA DE REQUISITOS

MSc(c): Pablo Ruiz Fundacin Universitaria de Popayn Septiembre 2011

Agenda
Los requisitos de software Ingeniera de requisitos

Tcnicas de ingeniera de requisitos

Qu son los requisitos?

Un requisito es una condicin o necesidad de

un usuario para resolver un problema o alcanzar un objetivo [IEEE] Una condicin o capacidad que debe ser atendida por el sistema [RUP]. Algo que el sistema debe hacer o una cualidad que el sistema debe poseer [Robertson Robertson].

Problemas
Los usuarios no saben lo que quieren. Un sistema tiene muchos usuarios y ninguno

tiene una visin de conjunto. No saben cmo hacer ms eficiente la operacin en su conjunto No saben qu partes de su trabajo pueden transformarse en software. No saben detallar lo que saben de forma precisa.

Solucin tradicional: analistas

Labores
obtener una lista de requisitos de cada usuario

adquirir una visin de conjunto

componer una especificacin completa, correcta y

estable

Desventajas
listas de requisitos son difciles de comprender y

de hacer bien difciles de transformar en especificaciones de diseo e implementacin

Objetivos generales
Enumerar los requisitos candidatos Comprender el contexto del sistema

Capturar requisitos funcionales

Capturar requisitos no funcionales

Requisitos funcionales
Definen lo que el sistema tiene que hacer, los

servicios que debe proporcionar al usuario Describen la funcionalidad del sistema

Requisitos no funcionales
Delimitan las condiciones en que el sistema

presta servicios a los usuarios

Velocidad de respuesta
Ancho de banda requerido Espacio en memoria o en disco ....

Caractersticas de un Requisito
Especificado por escrito: como todo contrato

o acuerdo entre dos partes. Posible de probar y verificar. Si un requerimiento no se pude comprobar . Entontes Cmo se sabe que si se cumpli con l o no? Conciso: un requisito es conciso si es fcil de leer y entender. Su redaccin debe ser simple para las personas que lo vayan a consultar en el futuro.

Caractersticas de un Requisito
Completo: Un requisito es completo si no

necesita ampliar detalles en su redaccin, es decir se proporciona la informacin suficiente para su comprensin Consistente: Un requisito es consistente si no es contradictorio con otro requisito No ambiguo: Un requisito no es ambiguo cuando tienen una sola interpretacin . El lenguaje usado en su definicin no debe causar confusin al lector.

Agenda
Los requisitos de software Ingeniera de requisitos

Tcnicas de ingeniera de requisitos

Ingeniera de Requisitos
Ingeniera de Requisitos ayuda a los ingenieros de

software a entender mejor el problema en cuya solucin trabajarn. Incluye el conjunto de tareas que conducen a comprender cul ser el impacto del software sobre el negocio, qu es lo que el cliente quiere y cmo interactuarn los usuarios finales con el software. [Pressman]

Ingeniera de Requisitos
Es el proceso mediante el cual se intercambian

diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinacin de mtodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos. [Leite89]
Definicin de lo que se desea hacer o producir

Importancia de la ingeniera de Requisitos

Permite gestionar las necesidades del proyecto en forma estructurada.

Mejora la capacidad de predecir cronogramas de los proyectos, as como sus resultados.

Disminuye los costos y retrasos del proyecto Mejora la calidad del software Mejora la comunicacin entre equipos Evita rechazos de los usuarios finales

Ingeniera de Requisitos
El proceso de ingeniera de requisitos puede ser descrito en 4 :
Elicitacin de los requisitos

Validacin

Anlisis

Especificacin

Identificacin de Requisitos, I

El propsito de la elicitacin de requisitos es

Elicitacin de los requisitos

ganar conocimientos relevantes del problema.

En esta actividad es donde los analistas de requisitos

deben trabajar junto con el cliente para descubrir el problema que el sistema debe resolver. Debe existir una buena comunicacin entre

desarrolladores y clientes; de esta comunicacin con el cliente depende que entendamos sus necesidades
Se debe descubrir los diferentes servicios que el sistema debe prestar y las restricciones .

Anlisis
Se trabaja sobre la base de la anterior actividad. Actividad la cual se enfoca a descubrir problemas con los requisitos del sistema identificados hasta

el momento. Por lo general se hace un anlisis luego de haber producido un bosquejo inicial del documento de requisitos. Se conceptan los requisitos, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones

Especificacin
Se documentan los requisitos acordados con

el cliente en un nivel apropiado de detalle. En la prctica esta actividad se va realizando conjuntamente con el anlisis. Se pude decir que la especificacin es el pasar en limpio el anlisis realizado previamente aplicando tcnicas o estndares de documentacin como UML.

Validacin
La validacin es la actividad que certifica que el modelo de los requisitos es consistente con las

intenciones de los clientes y los usuarios.

Se

verifica que los requisitos consistentes y que estn completos

sean

Agenda
Los requisitos de software Ingeniera de requisitos

Tcnicas de ingeniera de requisitos

Tcnicas de ingeniera de Requisitos

El anlisis de requisitos siempre comienza

con una comunicacin entre dos o ms partes. Un cliente tiene un problema al que puede encontrar una solucin basada en computadora. El desarrollador responde a la peticin del cliente. La comunicacin ha comenzado. Pero, el camino entre la comunicacin y el entendimiento est lleno de baches.

Tcnicas de ingeniera de Requisitos

Antes de mantener las reuniones con los clientes y usuarios e identificar los requisitos es

fundamental conocer el dominio del problema. Mantener reuniones con clientes y usuarios sin conocer las caractersticas de su actividad har que probablemente no se entiendan sus necesidades. Para conocer el dominio del problema se puede obtener informacin de fuentes externas al negocio del cliente

Tcnicas de ingeniera de Requisitos

Normalmente

clientes y analistas se enfrascan en el proyecto de forma unilateral y no en equipo. Cada parte define su propio territorio Este enfoque no es muy efectivo, abundan los malentendidos, se pierde informacin importante y nunca se establece una relacin de trabajo satisfactoria.

Tcnicas de ingeniera de Requisitos

Con los anteriores problemas, se han

desarrollado numerosas tcnicas para tratar de superarlos Cada tcnica puede aplicarse en una o ms actividades de la ingeniera de requerimientos; en la prctica, la tcnica ms apropiada para cada actividad depender del proyecto que est desarrollndose.

Entrevistas
Las entrevistas son la tcnica de elicitacin

ms utilizada, y de hecho son prcticamente inevitables en cualquier desarrollo. En las entrevistas se pueden identificar claramente tres fases [Piattini]: preparacin, realizacin y anlisis

Entrevistas
Preparacin de entrevistas: Las entrevistas

no deben improvisarse, por lo que conviene realizar las siguiente tareas previas:
Estudiar el dominio del problema Seleccionar a las personas a las que se va a

entrevistar (topdown)
Determinar el objetivo y contenido de las

entrevistas Planificar las entrevistas

Entrevistas
Realizacin de entrevistas: se distinguen tres etapas [Piattini]: Apertura
Desarrollo

Terminacin

Anlisis de las entrevistas

Reorganizar la informacin, contrastarla con

otras entrevistas o fuentes de informacin. Validar con el entrevistado para confirmar los contenidos.

Brainstorming
El brainstorming o tormenta de ideas es una

tcnica de reuniones en grupo cuyo objetivo es la generacin de ideas en un ambiente libre de crticas o juicios [Raghavan].

Las sesiones de brainstorming formadas

de cuatro a diez participantes, uno de los cuales es el jefe de la sesin.

Fases del brainstorming

Preparacin Seleccin de participantes Preparacin logstica

Generacin Jefe de proyecto expone un enunciado general del problema , que hace de semilla para que se generen ideas. Los participantes generan nuevas ideas de forma aleatoria Reglas Se prohbe la critica de ideas Se fomentan las ideas ms avanzadas y se estimula a los participantes a generar nuevas ideas Se debe generar un gran nmero de ideas, Se debe alentar a los participantes a combinar o completar las ideas de otros participantes

Fases del brainstorming

Consolidacin: en esta fase se deben organizar y

evaluar las ideas generadas durante la fase anterior. Se suelen seguir tres pasos: Revisar ideas: se revisan para clarificarlas Descartar ideas. Priorizar ideas. Documentacin: el jefe produce la documentacin oportuna conteniendo las ideas priorizadas y comentarios generados durante la consolidacin.

Casos de Uso
Los casos de uso son una tcnica para la especificacin de

requerimientos funcionales propuesta inicialmente en por Jacobson y actualmente forma parte de la propuesta de UML [Booch99].

Una descripcin de una secuencia de acciones que el sistema debe llevar a cabo para obtener un resultado observable para un actor particular [Booch]

Un caso de uso es la descripcin de una secuencia de

interacciones entre el sistema y uno o ms actores en la que se considera al sistema como una caja negra. Los actores son personas u otros sistemas que interactan con el sistema cuyos requerimientos se estn describiendo. Un actor puede participar en varios casos de uso y un caso de uso puede estar relacionado con varios actores

Casos de Uso
Los Casos de Uso facilitan la elicitacin de requisitos y son

fcilmente comprensibles por los clientes y usuarios.

Sirven de base a las pruebas del sistema y a la

documentacin para los usuarios. Los ms reconocidos especialistas en mtodos Orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar el comportamiento externo de un sistema Se escriben, generalmente, en lenguaje natural
No hay descripcin interna del sistema, solo la interaccin

con el mismo

Casos de Uso
Ventajas y desventajas
Caracterizacin detallada de todas las posibles

interacciones con el sistema Ayuda en el dibujo de los lmites del sistema, y con el alcance de los requerimientos Los casos de uso no captura en dominio del conocimiento Un caso de uso no es especificacin precisa, solo es la representacin de un problema puntual

Usando casos de Uso

Dibujar los lmites Identificar los actores fuera de los lmites del sistema que interactan con l
Para cada actor

Identificar los posibles casos de uso Establecer escenarios concretos para ilustrar cada caso de uso Agrupar escenarios similares en casos de uso si son una variacin sobre un tema

Usando casos de Uso

Para cada caso de uso Escribirlo Especificar reglas para eleccin del mismo y para interactuar con l Considerar alternativas Ver posibles superposiciones de casos de uso Template de caso de uso:
Nombre: Resumen: Actores: Precondiciones: Descripciones: Excepciones: Postcondiciones:

Un ejemplo de caso de uso

Nombre: Orden de pedido Precondicin: un usuario vlido est conectado al sistema Descripcin: 1. El caso de uso comienza con un pedido del cliente 2. El cliente entra su nombre y direccin 3. Si el cliente entra solo el cdigo postal, el sistema debe agregar la ciudad y la provincia. 4. El cliente entrar todos los cdigo de los productos deseados y la cantidad solicitada 5. El sistema indicar el nombre del producto y el precio unitario del mismo 6. El sistema totalizar la cantidad de productos pedidos y el total de la venta 7. El cliente indicar la forma de pago, si es tarjeta el nmero de la misma 8. El cliente apretar la tecla enviar 9. El sistema verificar la informacin, guardar la orden de pedido como pendiente y la forma de pago 10. Una vez confirmado el pago, la orden se cambiar a confirmada y se le indica esto al cliente, el caso de uso finaliza Excepciones: En el paso 9, si hay informacin incorrecta, el sistema le preguntar al cliente que quiso poner Postcondiciones: La orden fue salvada en el sistema y fue marcada como confirmada

Un ejemplo de caso de uso

Los Casos de Uso y UML

La notacin de los casos de uso fue incorporada al lenguaje estndar de modelado UML y fue

avalada por las principales empresas que desarrollan software en el mundo. La mejor forma de empezar a entender un sistema es a partir de los servicios o funciones que ofrece a su entorno