Fundamentos de Ingeniera de Software

Unidad 2 Ingeniera de Requisitos

Ingeniera de Requisitos

Ingeniera de Requisitos
Lo ms difcil en la construccin de un sistema software es decidir precisamente qu construir... No existe tarea con mayor capacidad de lesionar al sistema, cuando se hace mal... Ninguna otra tarea es tan difcil de rectificar a posteriori... Frederick Phillips Brooks, Jr., 1987

Ingeniera de Requisitos
La evidencia emprica demuestra que:
Los requisitos contienen demasiados errores Muchos de estos errores no se detectan al principio Muchos de estos errores podran ser detectados al principio.

Ingeniera de Requisitos
La evidencia emprica demuestra que:
No detectar estos errores incrementar los costes (tiempo, dinero) de forma exponencial Adems, los programadores obedecen los requisitos (cuando existen).

Ingeniera de Requisitos
Consecuencias
El sistema resultante no satisfar a los usuarios Se producirn desacuerdos entre usuarios y desarrolladores Puede ser imposible demostrar si el software cumple, o no, los requisitos Se gastar tiempo y dinero en construir el sistema equivocado

Ingeniera de Requisitos
Complejidad
No estamos hablando de sistemas de 15 30 requisitos. Tambin hay:
Sistemas de cientos de requisitos Sistemas de miles de requisitos Sistemas de 5.000 requisitos Sistemas de ms de 10.000 Sistemas de incluso 60.000 (!) requisitos

Ingeniera de Requisitos
1995/2001: The Chaos Report
http://www.standishgroup.com Gasto anual en EEUU: $250 mil millones en unos 175.000 proyectos.
31,1% (23%) son cancelados 52,7% (49%) cuestan un 190% ms de lo estimado Un 16,2% (28%) ser finalizado a tiempo y dentro del presupuesto, pero el producto final poseer (aprox.) la mitad de los requisitos iniciales

Ingeniera de Requisitos
La crisis del software y los requisitos
Boehm, 1975: 45% de los errores tienen su orgen en los requisitos y en el diseo preliminar. DeMarco, 1984: 56% de los errores que tienen lugar en un proyecto Sw. Se deben a una mala Especificacin de Requisitos Chaos Report: Los factores principales que conducen al fracaso en los proyectos Sw. Son:
Falta de comunicacin con los usuarios Requisitos incompletos Cambios a los requisitos

Ingeniera de Requisitos
Problema

Acumulacin de errores
Especificacin Incorrecta

ESP. REQUISITOS
DISEO

Especificacin Correcta

Diseo Correcto

Diseo Errneo

Diseo basado en una Especificacin Errnea

Prog. basados en un Diseo Errneo Errores Incorregibles

IMPLEMENTACIN
PRUEBA

Programas Correctos Funciones Correctas

Programas Errneos Errores Corregibles

Prog. basados en la Especificacin Errnea

Errores Ocultos

PRODUCTOS IMPERFECTOS

Ingeniera de Requisitos
Solucin?
No se ha encontrado solucin universalmente vlida Hay serias dudas acerca de si dicha solucin existe
Nos movemos en la frontera socio-tcnica de los sistemas: borrosa, voluble e inconsistente Los requisitos es donde lo formal se encuentra con lo informal (M. Jackson) Los requisitos estn vivos: emergen, interactan, cambian, desaparecen...

Desconfa de quien ofrezca la solucin definitiva a estos problemas !!!

Ingeniera de Requisitos
Qu es?
La 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, 2006: 155

La Ingeniera de Requisitos es el proceso de desarrollar una especificacin de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema.
Sommerville, 2005: 82

Ingeniera de Requisitos
Qu son los requisitos?
Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal
Std 610.12-1900, IEEE: 62

Ingeniera de Requisitos
Tipos de requisitos:
Funcionales
Describe los servicios (funciones) que se esperan del sistema. Definen las funciones que el sistema realizar. Describen el qu?, no el Cmo?. Se convertirn en algoritmos, reglas de negocio y cdigo del sistema.

Ejemplo:
El sistema aceptar pagos con VISA

Ingeniera de Requisitos
Tipos de requisitos:
No funcionales
Son restricciones sobre los requisitos funcionales. Son caractersticas que limitan al sistema en rendimiento, interfaces de usuario, fiabilidad, mantenimiento, seguridad, portabilidad, etc.

Ejemplo:
El sistema aceptar pagos con VISA
de forma segura y con un tiempo de respuesta menor de 5 segundos

Ingeniera de Requisitos
Caractersticas:
Especificado por escrito Como todo contrato o acuerdo entre ambas partes. Posible de probar o verificar

Si un requisito no se puede comprobar, cmo se sabe si se cumpli con l o no?

Conciso

Es fcil de leer y entender. Redaccin simple y clara para su futuro.

Ingeniera de Requisitos
Caractersticas:
Completo

No se necesita ampliar detalles en su redaccin.

Consistente

No es contradictorio con otro requisito.

No ambiguo

Tiene una sola interpretacin.

Ingeniera de Requisitos
Dificultades para definir:
Los requisitos no son obvios y vienen de distintas maneras. Son difciles de expresar con palabras. La cantidad de requisitos en un proyecto es demasiado grande. Un requisito puede cambiar a los largo del ciclo de desarrollo.

Ingeniera de Requisitos
Dificultades para definir:
El usuario no puede explicar bien lo que quiere. Hablan de lo que no funciona. Los usuarios y clientes tienen distinto vocabulario que los desarrolladores.

2.1. TAREAS DE LA INGENIERA DE REQUISITOS

2.1. Tareas de la Ingeniera de Requisitos

Lizka Johany Herrera:
1. Extraccin
Es el descubrimiento de los requisitos del sistema. Analistas deben trabajar de cerca al cliente para descubrir:
El problema que el sistema va a resolver. Los servicios que el sistema va a prestar. Las restricciones que se pueden presentar.

Aceptacin del sistema ligada con la satisfaccin del cliente en los requisitos descubiertos. Obtener requisitos: a travs de entrevistas o comunicacin con clientes o usuarios, para saber cules son sus expectativas.

2.1. Tareas de la Ingeniera de Requisitos

Lizka Johany Herrera:
2. Anlisis
Descubrir problemas encontrados en los requisitos. Actividades para esto:
Leer, limitarlos, investigar, intercambiar ideas, resaltar problemas grandes, buscar alternativas y soluciones. Por ltimo se rene con el cliente para discutir los requisitos refinados.

Analizar requisitos detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseo.

2.1. Tareas de la Ingeniera de Requisitos

Lizka Johany Herrera:
3. Especificacin
Se documentan los requisitos acordados con el cliente en un nivel apropiado de detalle. Pasar en limpio el anlisis y acotamiento de requisitos. Se utilizan estndares y/o tcnicas de documentacin:
Casos de uso Obtencin de requisitos basada en casos de uso.

Documentar requisitos igual que todas las etapas, los requisitos deben estar debidamente documentados.

2.1. Tareas de la Ingeniera de Requisitos

Lizka Johany Herrera:
4. Validacin
Ratificar los requisitos. Asegurarse que los requisitos representan una descripcin aceptable del sistema a desarrollar. Requisitos consistentes y completos. Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la aplicacin. Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretenda.

2.1. Tareas de la Ingeniera de Requisitos

Ejemplo de lo que podemos encontrar en un documento de requisitos
1. 2. El sistema mantendr la temperatura de la caldera entre 70 y 80 El sistema mantendr un registro de todos los materiales de la biblioteca, incluyendo libros, peridicos, revistas, videos y CDRoms El sistema permitir a los usuarios realizar una bsqueda por ttulo, autor o ISBN El interfaz de usuario se implementar sobre un navegador Web El sistema deber soportar al menos 20 transacciones por segundo El sistema permitir que los nuevos usuario se familiaricen con su uso en menos de 15 minutos.

3. 4. 5.
6.

2.2. TCNICAS DE LA INGENIERA DE REQUISITOS

2.2. Tcnicas de la Ingeniera de Requisitos

Existen distintas tcnicas para la obtencin de requisitos. Slo hablaremos de las ms utilizadas:
Entrevistas y cuestionarios Sistemas existentes Lluvia de ideas Prototipos Casos de uso

2.2. Tcnicas de la Ingeniera de Requisitos

Entrevistas y cuestionarios
Se emplean para reunir informacin de personas o grupos. La entrevista: conversacin entre el analista y el encuestado. El cuestionario: serie de preguntas relacionadas con varios aspectos del sistema. El xito de esta tcnica depende de la habilidad del entrevistador y de la preparacin para la misma.

2.2. Tcnicas de la Ingeniera de Requisitos

Sistemas existentes
Consiste en analizar distintos sistemas relacionados con el sistema a ser construido. Se analiza:
Interfaces de usuario. Entradas de datos. Salidas de resultados.

2.2. Tcnicas de la Ingeniera de Requisitos

Lluvia de ideas
Usado para generar ideas. Objetivo generar la mxima cantidad de requisitos posibles. No pensar si el requisito es bueno o malo. Al tener una gran cantidad ir eliminando segn importancia o prioridad.

2.2. Tcnicas de la Ingeniera de Requisitos

Prototipos
Simulaciones del posible producto. Se utilizan al no tener clara la idea de algn requisito. Se construye y se presenta con el cliente. Se obtiene una importante retroalimentacin. Etapas:
Captura de requisitos. Definicin de objetivos globales entre cliente y analistas. Se profundiza en las reas del software de mayor inters. Se presenta al cliente y se retroalimenta.

2.2. Tcnicas de la Ingeniera de Requisitos

Casos de uso
Son utilizados para especificar el comportamiento del sistema. Permiten describir la posible secuencia de interacciones entre el sistema y los actores.

2.2. Tcnicas de la Ingeniera de Requisitos

Casos de uso
Descripcin de un conjunto de escenarios, donde un escenario es un evento provocado por un actor. El autor Sommerville los define como una tcnica que se basa en escenarios para la obtencin de requerimientos.

2.3. MODELADO DE REQUISITOS

2.3. Modelado de requisitos

Casos de uso
El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, adems de la forma, tipo y orden en como los elementos interactan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos:
Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicacin.

2.3. Modelado de requisitos

Casos de uso
Actor:
Una definicin previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino ms bien la labor que realiza frente al sistema.

2.3. Modelado de requisitos

Casos de uso
Caso de uso
Es una operacin/tarea especfica que se realiza tras una orden de algn agente externo, sea desde una peticin de un actor o bien desde la invocacin desde otro caso de uso.

2.3. Modelado de requisitos

Casos de uso
Relaciones:
Asociacin
Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha simple.

Dependencia o Instanciacin
Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relacin se denota con una flecha punteada.

2.3. Modelado de requisitos

Casos de uso
Relaciones:
Generalizacin
Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relacin esta orientado exclusivamente para casos de uso (y no para actores). extends: Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas). uses: Se recomienda utilizar cuando se tiene un conjunto de caractersticas que son similares en ms de un caso de uso y no se desea mantener copiada la descripcin de la caracterstica.

2.3. Modelado de requisitos

Casos de uso
Como ejemplo esta el caso de una Mquina Recicladora:
Sistema que controla una mquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:
Registrar el nmero de temes ingresados. Imprimir un recibo cuando el usuario lo solicita: Describe lo depositado El valor de cada item Total El usuario/cliente presiona el botn de comienzo

2.3. Modelado de requisitos

Casos de uso
Como ejemplo esta el caso de una Mquina Recicladora:
El sistema debe controlar y/o aceptar:
Existe un operador que desea saber lo siguiente: Cuantos temes han sido retornados en el da. Al final de cada da el operador solicita un resumen de todo lo depositado en el da. El operador debe adems poder cambiar: Informacin asociada a temes. Dar una alarma en el caso de que: Item se atora. No hay ms papel.

2.3. Modelado de requisitos

Casos de uso
Como una primera aproximacin identificamos a los actores que interactuan con el sistema:

2.3. Modelado de requisitos

Casos de uso
Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la informacin de un Item o bien puede Imprimir un informe:

2.3. Modelado de requisitos

Casos de uso
Adems podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

2.3. Modelado de requisitos

Casos de uso
Otro aspecto es la impresin de comprobantes, que puede ser realizada despus de depositar algn item por un cliente o bien puede ser realizada a peticin de un operador.

2.3. Modelado de requisitos

Casos de uso
Entonces, el diseo completo del diagrama Use Case es:

2.4. HERRAMIENTAS CASE PARA LA INGENIERA DE REQUISITOS

Resumen