Ingeniería de Requerimientos

Temario Problemas de los Proyectos de IT Importancia de los requerimientos. Definición de Requerimiento Lectores de Requerimientos Requerimientos Funcionales Requerimientos No Funcionales Dificultad para definir los Requerimientos Ingeniería de Requerimientos Importancia de la Ingeniería de Requerimientos Técnicas Utilizadas en la Ingeniería de

Requerimientos

Objetivos

Resaltar la importancia que tiene la Ingeniería de Requerimientos dentro del ciclo de desarrollo.

Dar a conocer las diferentes alternativas que existen para identificar requerimientos.

Ayudar a comprender la diferencia que existe entre las diferentes técnicas utilizadas en la Ingeniería de Requerimientos.

Minimizar las dudas que se tiene sobre los casos de uso.

Problemas de los proyectos de TI

Causas (Standish Gr.1995) Requerimientos incompletos (13.1%) Falta de involucramiento de usuarios (12.4%) Falta de recursos (10.6%) Expectativas no realistas (9.9%) Falta de soporte de ejecutivos (9.3%) Requerimientos y Especificaciones cambiantes (8.7%) Falta de planificación (8.1%) Sistema no se precisaba más (7.5%)

Problemas de los proyectos de TI

No se capturan requerimientos críticos.

Equipos de trabajo no entendieron bien el problema del negocio.

Los requerimientos no cubren las necesidades del negocio.

Mal entendimiento de los objetivos por el equipo de trabajo

Problemas comunes debido a personas y procesos

“La gerencia de proyectos consiste en la aplicación de conocimientos, habilidades, herramientas a las actividades del proyecto a fin de lograr los requerimientos del mismo” (fuente PMBOK).

Importancia de los requerimientos

Importancia de los requerimientos

“Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requerimientos de usuario en un sistema software”

JACOBSON, Ivar; BOOCH, Grady y RUMBAUGH, James 2000 El proceso unificado de desarrollo de software, Addison Wesley

Requerimiento:Descripción de los servicios que debe brindar un

sistema y sus restricciones Ingeniería de Requerimientos

Proceso de descubrir, analizar, documentar y verificar esos servicios y restricciones

Entender el problema de los usuarios en SU cultura y con SU lenguaje y construir el sistema que resuelve sus necesidades

Definiciones

Requerimiento El IEEE define:

Requisito o Requerimiento como: Condición o aptitud necesaria para resolver un

problema o alcanzar un objetivo. Condición o facilidad que debe proporcionar un

sistema o algunos de sus subsistemas para satisfacer un contrato, norma, especificación o cualquier otra condición impuesta formalmente a través de un documento.

Una representación documentada de una condición o facilidad

Requerimientos de Usuario:Declaraciones en lenguaje natural y en

diagramas de los servicios que se espera que el sistema provea y de las restricciones bajo las que cuales debe operar.

Diferentes niveles de descripción

Requerimientos del Sistema:Detalla los servicios y restricciones del sistema.Documento de Especificación funcional sirve

como contrato entre el comprador del sistema y el desarrollador de software.

Diferentes niveles de descripción

Especificación del diseño del software:Descripción abstracta del diseño del software que es

una base para el diseño detallado y la implementación.Agrega detalle a la especificación de requerimientos del

sistema .

Diferentes niveles de descripción

Gerencia de ClienteUsuarios Finales del SistemaIngenieros de ClientesGerencia de ContratistasArquitectos del Sistema

Requerimientosde Usuario

Requerimientos del Sistema

Usuarios Finales del SistemaIngenieros de ClienteArquitectos del SistemaDesarrolladores de Software

Especificación del diseño del Software

(Quizás) Ingenieros de ClientesArquitectos del SistemaDesarrolladores de Software

Lectores de Requerimientos

Describen la interacción entre el sistema y su entorno

Servicios o funciones que proveerá el sistema Ejemplos:

Se deben ingresar cédula, nombre y teléfono de cada cliente Se quiere un listado de los clientes por zona

Requerimientos Funcionales

Restricciones a los servicios o funciones ofrecidos por el sistema Describen restricciones que limitan las elecciones para construir una

solución Ejemplos:

Las consultas deben resolverse en menos de 3 segundos El lenguaje de programación debe ser Java

Se refieren al sistema como un todo mas que a rasgos particulares del mismo.

De forma ideal se deben expresar de forma cuantitativa utilizando métricas que se puedan probar objetivamente.

Requerimientos No Funcionales

Del Producto: Especifican restricciones al comportamiento del producto Ejemplos: desempeño, confiabilidad, portabilidad, usabilidad

De la Organización: Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador Ejemplos: estándares, lenguajes de programación, método de diseño

Externos: Se derivan de factores externos, como: Interoperabilidad: con otros sistemas Legislativos: privacidad, seguridad Éticos: dependen del contexto, las personas, etc

Requerimientos No Funcionales

Dificultades para definir los Requerimientos

Los requerimientos no son obvios y vienen de muchas fuentes.

Son difíciles de expresar en palabras (el lenguaje es ambiguo).

Existen muchos tipos de requerimientos y diferentes niveles de detalle.

La cantidad de requerimientos en un proyecto puede ser difícil de manejar.

Ingeniería de Requerimientos

Definición:Rama de la ingeniería del software que trata con el establecimiento de los objetivos, funciones y restricciones de los sistemas software.Asimismo, se ocupa de la relación entre estos factores con el objeto de establecer especificaciones precisas.

Ingeniería de Requerimientos

Objetivo: La obtención de requisitos del sistema que se desea construir a cierto nivel de abstracción y cumpliendo ciertas características haciendo de puente entre el espacio del problema y el espacio de la solución.

Puntos a considerar en IR

Objetivos del Negocio y Ambiente de trabajo Diferentes puntos de vista de los clientes Barreras de comunicación entre clientes y

analistas de requerimientos Integración del sistema con otros ya existentes Tamaño y complejidad Documentación de requerimientos

Personal involucrado

Usuario Final Usuario Líder Personal de Mantenimiento Analistas y programadores Personal de pruebas Dependiendo de la magnitud del proyecto

Administradores de proyecto, documentadores, diseñadores de BD, etc.

Importancia de la IR Permite gestionar las necesidades del proyecto en

forma estructurada: La IR proporciona un punto de partida para controles y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.

Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro.

Importancia de la IR

Mejora la calidad del software: Se busca cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).

Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a verificar sus requerimientos y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Importancia de la IR

Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso

Técnicas utilizadas en la Ingeniería de Requerimientos

Técnicas utilizadas en la Ingeniería de Requerimientos Su objetivo es obtener los requisitos Se eligen según el proyecto a desarrollarse

1) Entrevistas y Cuestionarios2) Tormenta de Ideas3) Prototipos4) Casos de Uso

Entrevistas y Cuestionarios

- Consiste en que el analista formule preguntas relacionadas con varios aspectos de sistemas.

- En general a:

- usuarios de sistemas existentes

- futuros usuarios

- gerentes

- empleados

- Son útiles las Preguntas Abiertas

Ejemplos de Preguntas Abiertas: Del Usuario

¿Quién es el cliente? ¿Quién es el usuario? ¿Son sus necesidades diferentes?

Del Proceso ¿Cuál es la razón por la que se quiere resolver este problema? ¿Cómo usted resuelve el problema actualmente? ¿Qué retrasos ocurren o pueden ocurrir?

Del Producto ¿Qué problemas podría causar este producto en el negocio? ¿En qué ambiente se usará el producto? ¿Cuáles son sus expectativas para los conceptos fácil de usar,

confiable, rendimiento? ¿Qué obstáculos afectan la eficiencia del sistema?

Entrevistas y Cuestionarios

Ventajas:- Se obtienen

información correcta- Sirven de pantallazo- Son flexibles- Permiten combinarse

con otras técnicas

Desventajas:- La información obtenida

al principio puede ser redundante o incompleta.

- Requiere mucha organización si hay que manejar mucha información

Entrevistas y Cuestionarios

Se comenzó a utilizar en empresas para:encontrar nuevas ideas , nuevos métodos futuros productosdesarrollar el pensamiento creativo a todos

los niveles

y se extendió al mundo del desarrollo de sistemas

Tormenta de ideas (brainstorming)

Los principales stakeholders se juntan en un cuarto Se establece el objetivo:

Que características esperan en el producto?Que servicios esperan que provea?Los objetivos permiten decidir cuando terminar

Se pide que cada participante escriba sus ideas, luego las ideas son leídas para que otros piensen en ideas relacionadas y de esa forma las ideas mutan y se combinan

Tormenta de ideas (brainstorming)

Tormenta de ideas (brainstorming)

Reglas: No hay que detenerse en pensar si la idea es o no del todo utilizable.

La intención es generar, en una primera instancia, muchas ideas. Luego, se irán eliminando en base a distintos criterios como, por ejemplo, "caro", "impracticable", "imposible", etc.

Equipo:DirectorSecretarioPersonas involucradas en el proyecto

El secretario lee cada idea y pregunta si es válida Si hay cualquier desacuerdo, la idea se queda

Agrupamiento de ideas Nombrar los grupos

Definición Se escribe una breve descripción de lo que la idea

significa para la persona que la escribió Ayuda a tener un entendimiento común del requerimiento Lleva unos minutos por idea

Tormenta de ideas (brainstorming)

Fases (1):- Descubrir hechos:

Comunicar con anticipación los temas a tratarExplicar los principios de una tormenta de

ideasHablar unos 10’ de temas sencillos y no

comprometidoDeterminar y plantear el problema.Dividirlo en partes (si es complejo)

-

Tormenta de ideas (brainstorming)

Fases (2):- Producir ideas (la tormenta propiamente dicha)

- Producir gran cantidad de ideas (según los principios vistos)

- Fin de reunión y próxima reunión- Descubrir soluciones:

Elaborar una lista definitiva de ideas y seleccionar las mas interesantes

Ponderar las más útilesClasificarlasPresentarlas de forma atractiva (ej: en soporte visual)

Tormenta de ideas (brainstorming)

Ventajas:- Los expertos

pueden introducir y unificar terminología para que todos las usen para expresar las nuevas ideas.

Desventajas- Es necesaria una

buena compenetración de todos

Tormenta de ideas (brainstorming)

Prototipos

Para validar los requerimientos hallados, se construyen prototipos.

Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final

Permiten conseguir una importante retroalimentación en cuanto a si el sistema diseñado en base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva.

Facilita la comprensión del desarrollador.

Prototipos

Prototipo rápido: Mecanismo para lograr validación pre-compromiso

Se utiliza para validar requerimientos en una etapa previa al diseño específico

También podemos llevar el caso de uso y bosquejar la interfase de usuario y, mediante el diálogo, manejamos la interactividad entre el usuario y el sistema.

Prototipos

Prototipo evolutivo: Es implementado sobre la arquitectura del producto final, el sistema final se obtiene de evolucionar el prototipo

Modificaciones y mejoras subsecuentes resultan en nuevas entregas de prototipos más maduros. Este proceso continúa hasta que se haya desarrollado el producto final.

Todo el ciclo de vida de un producto puede ser visto como una serie incremental de prototipos.

Ventajas:- Ayudan a validar y

desarrollar nuevos req.

- Ayudan a comprender req. que no están muy claros.

Desventajas El cliente puede llegar a

pensar que el prototipo es una versión del software que será desarrollado.

A menudo, el desarrollador hace compromisos de implementación para acelerar el desarrollo del prototipo

Prototipos

Mismos datos, pero…

Ingrese año: ____

mes: ____

día: ____

Julio 1998

1998 2025

1 31

Ene DicMartes 16 Oct. 2002

Un caso de uso representa una interacción típica entre un usuario y un sistema informático.

La descripción se centra en lo que debe hacerse, no en la manera de hacerlo.

No son exclusivos del mundo de OO, pueden ser utilizados en proyectos que sigan cualquier metodología de desarrollo

Casos de Uso

Los casos de uso sólo consideran los requisitos funcionales del proyecto, hay que añadir los no funcionales en la descripción.

Dirigen todo el proceso de desarrollo puesto que la mayoría de actividades (planificación, análisis, diseño, validación, test,..) se realizan a partir de los casos de uso.

Mecanismo importante para soportar la “trazabilidad” entre modelos.

Casos de Uso

ACTOR

Un actor representa un conjunto coherente de roles que juegan los usuarios de los casos de uso al interaccionar con el sistema.

Roles jugados por personas, dispositivos, u otros sistemas.

No forman parte del sistema Inician la ejecución de los casos de

uso

CASO DE USO

Un caso de uso es una descripción de la secuencia de interacciones que se produce entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea especifica.

El nombre del caso de uso debe reflejar la tarea especifica que el actor desea llevar a cabo usando el sistema

Relación de tipo Include

Es una relación de dependencia entre dos casos de uso. El caso de uso base, depende del caso de uso incluido.

El caso de uso incluido no puede ejecutarse sin el caso de uso que lo incluye, y no puede ser iniciado de forma independiente por el usuario

Se utiliza para extraer un comportamiento común a dos casos de uso y para simplificar un caos de uso complejo.

Relación de tipo Extend

Es una relación de dependencia entre dos casos de uso. El caso de uso extendido, depende del caso de uso base.

Se ejecuta el caso de uso base, pero bajo ciertas condiciones llama a otro caso de uso que extiende su comportamiento.

Se utiliza para modelar la parte del caso de uso que tiene un comportamiento opcional, es decir bajo ciertas condiciones.

Sistema de Pub

Barmen

Vender Bebida

Informar Bodega

Registrar Venta

Sistema de Bodega

«extend»

«include»

incluye

caso de uso

actor

extiende

Límite

Diagramas de Casos de Uso

Ejemplo de relaciones Include-Extend

Identificación

Giro por Internet

Cliente

Giro

<<extends>>

<<includes>>

Plantilla para casos de uso

Caso de Uso identificador / historia

Descripción objetivo a conseguir

Actores lista de actores

Asunciones Condiciones que deben cumplirse

Pasos interacciones entre los actores y el sistema necesarias para obtener el objetivo

Variaciones (opcional) cualquier variación en los pasos

No-funcional (opcional) lista requisitos no funcionales

Casos de Uso

Ventajas:- Representación de

req. desde el punto de vista del usuario

- Más de un rol para cada afectado

Desventajas En sistemas grandes,

toma mucho tiempo definir todos los casos de uso.

El análisis de calidad depende de la calidad con que se haya hecho la descripción inicial.