INGENIERA DE REQUERIMIENTOS

NOTAS DEL CURSO Ingeniera de Software I

DRA. MARIA DEL PILAR GMEZ GIL
Versin : 01-Oct-12

INGENIERA DE REQUERIMIENTOS*

Entender los requerimientos de una solucin basada en software es una de las tareas mas difciles para un(a) Ing. de software. Como otras actividades de Ing. de Sw, sta debe adaptarse a las necesidades del proceso, proyecto, producto y gente que hace el software. La Ing. de Requerimientos provee de un mecanismo apropiado para entender que quiere el consumidor, analizar sus necesidades, valorar la factibilidad de construccin, negociar una solucin razonable, especificar de manera no ambigua una solucin, validar la especificacin y administrar los requerimientos conforme se transforman.

*Referencia: captulo 7 libro de texto (Pressman 2005)

(C) P. Gmez-Gil, INAOEP 2009

Tareas de la Ing. de Requerimientos

Iniciacin (Inception) Obtencin (Elicitation) Elaboracin Negociacin Especificacin Validacin (Validation) Administracin

Algunas de estas funciones pueden ocurrir en paralelo y ajustarse a las necesidades del proyecto

(C) P. Gmez-Gil, INAOEP 2009

Iniciacin

Como se empieza un proyecto? Algunas veces inicia por conversaciones informales, otras de manera mas formal; normalmente como resultado de una necesidad importante En esta parte, los ingenieros de software realizan preguntas libres de contexto (generales), para establecer un entendimiento bsico del problema, determinar las personas que quieren una solucin, la naturaleza de la solucin, y la efectividad de las colaboraciones y comunicaciones preeliminares que se generan entre el consumidor y el desarrollador

(C) P. Gmez-Gil, INAOEP 2009

Obtencin de Requerimientos

Se refiere a definir formalmente los requerimientos de la solucin. Es difcil porque como ya se ha visto:
Hay

problemas de definicin de alcances Hay problemas de entendimiento entre los involucrados Hay problemas de volatilidad (los requerimientos cambian con el tiempo)
(C) P. Gmez-Gil, INAOEP 2009

Elaboracin

Esta actividad expande y refina la informacin obtenida en la tarea de iniciacin Se enfoca en realizar modelos tcnicos refinados de las funciones del software, caractersticas y limitantes. Es bsicamente una funcin de modelado. Se conduce a travs de la definicin de escenarios del usuario que describen la interaccin del usuario final con el sistema Se define el dominio del problema desde varios puntos de vista: informacin, funciones y comportamiento

(C) P. Gmez-Gil, INAOEP 2009

Negociacin

Los usuarios y consumidores normalmente piden mas de lo que se puede hacer con los recursos con que se cuenta. Casi siempre diferentes involucrados (stakeholders) piden cosas diferentes, por lo que hay que conciliar intereses a travs de negociaciones. Hay varias maneras para negociar, y depende de la cultura de la organizacin y tamao del proyecto

(C) P. Gmez-Gil, INAOEP 2009

Especificacin

Especificacin significa diferentes cosas para diferentes personas en el rea de Ing. de software. Este es el producto de trabajo final de la ingeniera de requerimientos. Sirve como base para actividades subsecuentes. Describe la funcin y desempeo de un sistema y las restriccin que tiene. Hay muchas tcnicas para escribir especificaciones: diagramas, narraciones en prosa, modelos matemticos, dibujos, etc.

(C) P. Gmez-Gil, INAOEP 2009

Validacin

El producto generado por la ingeniera de requerimientos debe ser evaluado en trminos de congruencia y calidad. Se debe asegurar que la especificacin concuerda con las expectativas del usuario y que no es ambigua. Deben detectarse y corregirse errores, omisiones e inconsistencias con respecto a los estndares establecidos en el proyecto. El mecanismo comn de validacin es la revisin tcnica formal.
(C) P. Gmez-Gil, INAOEP 2009

Administracin de requerimientos

Actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requerimientos y cambios que ocurren en ellos a travs de todo el proceso de desarrollo. La administracin empieza con la identificacin de cada requerimiento. Posteriormente se generan tablas que permitirn darles seguimiento. Algunas de stas son: Tablas de caractersticas Tablas de fuentes Tablas de dependencias Tablas de subsistemas Tablas de interfaces

(C) P. Gmez-Gil, INAOEP 2009

Descripcin detallada de las Tareas de la Ing. de Requerimientos

Iniciacin
Obtencin

(Inception)

(Elicitation) Elaboracin Negociacin Especificacin Validacin (Validation) Administracin

(C) P. Gmez-Gil, INAOEP 2009

Pasos del proceso de Iniciacin.

1.
2. 3.

4.

Identificacin de involucrados (Stakeholders). Reconocimiento de diferentes puntos de vista. Desarrollo de un ambiente colaborativo. Implica identificar puntos en comn, reas de conflicto e inconsistencias. Aplicacin de preguntas iniciales.
(C) P. Gmez-Gil, INAOEP 2009

Algunas preguntas Iniciales tpicas

Primeras

Quin est detrs de la requisicin de este trabajo? Quin usar la solucin ? Cual es el beneficio econmico de una solucin exitosa? Hay otras fuentes para obtener la solucin buscada que se necesitarn? Qu sera una buena salida para generar una solucin eficiente? Que problemas aparecern con esta solucin? Podra describirme el medio ambiente en que la solucin funcionar? Qu aspectos de desempeo o limitaciones afectan la solucin?

Siguientes:

(C) P. Gmez-Gil, INAOEP 2009

Algunas preguntas tpicas (2)

Siguientes:

Es Usted la persona correcta a preguntarle? Son sus respuestas oficiales? Considera mis preguntas relevantes al problema que Usted tiene? Le estoy preguntando demasiado? Puede alguien mas darme informacin adicional ?
(C) P. Gmez-Gil, INAOEP 2009

Caractersticas de un(a) buen(a) Ing. de Requerimientos

Habilidad para captar conceptos abstractos sintetizndolos y reorganizndolos en divisiones lgicas. Habilidad para obtener hechos importantes confusas. Habilidad para entender el medio ambiente. Habilidad para "ver el bosque a travs de las hojas". de situaciones

Habilidad para comunicarse bien en forma verbal y escrita.

(C) P. Gmez-Gil, INAOEP 2009

Generacin de las Necesidades del Cliente

Herramientas para obtener informacin de las necesidades del Cliente: Cuestionarios Entrevistas Estudio de campo

Revisin de documentos en la base de datos de conocimiento de la organizacin

Autoaprendizaje

(C) P. Gmez-Gil, INAOEP 2009

Cuestionarios

Los cuestionarios son tiles especialmente cuando hay una gran cantidad de usuarios finales.
El diseo de un cuestionario requiere de tiempo y dedicacin, ya que un cuestionario deficiente produce frustracin y prdida de inters en el usuario. El cuestionario debe ser fcil de procesar En caso de que el cuestionario no se aplique a todos los usuarios, se debe seleccionar correctamente al grupo que realice el cuestionario.

(C) P. Gmez-Gil, INAOEP 2009

Entrevistas

La entrevista es una herramienta muy til para obtener informacin.

Se puede llevar a cabo en cualquier nivel dentro de la organizacin, desde el presidente hasta el obrero en la lnea de ensamble.
La entrevista debe prepararse adecuadamente.

(C) P. Gmez-Gil, INAOEP 2009

Consejos para Realizar una Entrevista

1) Preparacin de la entrevista: a) b) Buscar el apoyo del gerente de departamento o jefe donde se llevar a cabo la entrevista. Preparar la entrevista para un tiempo determinado, y drselo a conocer al entrevistado. Identificar de antemano la posicin del entrevistado en la organizacin, sus responsabilidades y actividades. Acordar de antemano la hora y el lugar de la entrevista. Evitar las interrupciones. Preparar el contenido de la entrevista: temas, preguntas etc.

c)
d) e)

(C) P. Gmez-Gil, INAOEP 2009

Consejos Para Realizar Una Entrevista (continuacin)

2) Conduciendo la entrevista: a) b) Presentarse al entrevistado y presentar al proyecto en el que se trabaja. Asegurarse de se entendieron correctamente las responsabilidades del entrevistado. Realizar preguntas de la forma: "tengo entendido que... ". Estudiar el mtodo de decisin del entrevistado. Evitar palabras tcnicas o rebuscadas. Darse una idea del "sentimiento" del entrevistado con respecto al sistema. Escuchar al entrevistado. Preguntar al entrevistado sobre algunas ideas propias que pudieron olvidarse. Al final de la entrevista resumir las conclusiones y escribir una bitcora. No tomar demasiadas notas. Grabar la entrevista la mayora de las veces resulta anti-productivo.
(C) P. Gmez-Gil, INAOEP 2009

c) d) e)
f) g) h) i) j)

Algunos Problemas Durante las Entrevistas

- Respuestas falsas por temor a admitir ignorancia
- El usuario tiende a decir lo que el entrevistador quiere or - Boicoteo de informacin - Actitud cerrada hacia cambios - Pesimismo total - Desvo del objetivo fundamental hacia otros problemas de la organizacin

(C) P. Gmez-Gil, INAOEP 2009

Tareas de la Ing. de Requerimientos

Iniciacin

(Inception)

Obtencin
Elaboracin Negociacin

(Elicitation)

Especificacin Validacin

(Validation) Administracin

(C) P. Gmez-Gil, INAOEP 2009

Continuando con el anlisis...

Segn [Larman 99] las principales actividades asociadas al anlisis son:

Definir

los casos de uso Definir el modelo conceptual Definir los diagramas de colaboracin Definir diagramas de diseo de clases

(C) P. Gmez-Gil, INAOEP 2009

Obtencin de Requerimientos

Incluye juntas colaborativas de definicin, despliegue de funciones y descripcin de escenarios Los productos que genera son: Una declaracin de necesidades y factibilidades Una declaracin delimitada del alcance del sistema o producto Una lista de consumidores, usuarios y otros involucrados (stakeholders) que participaron en la definicin del documento Una descripcin del medio ambiente tcnico del sistema Una lista de requerimientos, de preferencia organizados por funcin, y las restricciones de dominio que los afectan Un conjunto de escenarios de uso que dan idea del uso del producto en diferentes condiciones operativas Prototipos desarrollados

(C) P. Gmez-Gil, INAOEP 2009

Desarrollo de casos de uso

Un caso de uso describe el comportamiento del sistema en condiciones diferentes, as como la respuesta del sistema a las requisiciones de uno o mas stakeholders El primer paso es definir por escrito los actores que estarn involucrados en el sistema. Los actores son personas o dispositivos que usan el producto dentro de un contexto o funcin. Representan los roles de las personas o dispositivos De manera formal un actor es cualquier cosa que se comunica con el sistema o producto y que es externa a ste. Cada actor puede tener uno o mas objetivos cuando usa el sistema. Se pueden identificar actores primarios, aquellos que interactan directamente con el sistema, y secundarios, aquellos que de alguna manera dan soporte al sistema, a fin de que lo primarios puedan realizar su trabajo

(C) P. Gmez-Gil, INAOEP 2009

Desarrollo de casos de uso (2)

Una vez que se han identificado los actores, lo siguiente es desarrollar el caso de uso. Jacobson sugiere hacer las siguientes preguntas:

Quienes son los actores primarios y secundarios? Cuales son las metas de los actores? Que precondiciones deben existir antes de que la historia empiece? Que tareas principales son realizadas por el actor? Que excepciones se pueden considerar con respecto a la descripcin de la historia?

Contina...
(C) P. Gmez-Gil, INAOEP 2009

Desarrollo de casos de uso (2)

Que

variaciones en las interacciones del actor son posibles? Qu sistemas de informacin adquirir, producir o cambiar el actor? El actor tendr que informar al sistema acerca de cambios en el medio ambiente externo? Que informacin desea el usuario del sistema? Desea el actor ser informado acera de cambios inesperados?

(C) P. Gmez-Gil, INAOEP 2009

Smbolos usados en los Diagrama de Casos de Uso de UML*

Caso de Uso

(C) P. Gmez-Gil, INAOEP 2009

Ejemplo de un Diagrama de Casos de Uso1

1.

Sistema de control de registro para maquinas tragamonedas. Alvarez, V. et al.Otoo 04

(C) P. Gmez-Gil, INAOEP 2009

Escenarios

Cada ovalo en el diagrama de casos de uso debe ser descrito detalladamente, a travs de un escenario.

(C) P. Gmez-Gil, INAOEP 2009

Informacin principal a Incluir en la descripcin de un escenario

Nombre del caso de uso Actor principal Objetivo Pre-condiciones Iniciador del caso de uso Descripcin del Escenario Excepciones Prioridades Disponibilidad Frecuencia de Uso Canales de comunicacin con actores Canales con actores secundarios Puntos an no resueltos
(C) P. Gmez-Gil, INAOEP 2009

Descripcin escenarios
(C) P. Gmez-Gil, INAOEP 2009

[Computer, 02]

Otra Plantilla para describir escenarios

(C) P. Gmez-Gil, INAOEP 2009

[Larman,99]

Ejemplo de caso de uso del proyecto Casa Segura

Involucrados:
Dueo

de la casa Administrador de la configuracin (probablemente la misma persona que el dueo) Sensores Subsistema de monitoreo

Escogiendo como actor al dueo de la casa

(C) P. Gmez-Gil, INAOEP 2009

Sistema Casa Segura

(C) P. Gmez-Gil, INAOEP 2009

Interacciones de dueo de la casa con el sistema

Introduce un password para permitir otras interacciones Pregunta sobre el status de una zona de seguridad Pregunta sobre el status de un sensor Oprime el botn pnico en caso de una emergencia Activa o desactiva el sistema de seguridad

(C) P. Gmez-Gil, INAOEP 2009

Ejemplo de caso de uso del proyecto Casa Segura

[Pressman 2004]

(C) P. Gmez-Gil, INAOEP 2009

Diagrama de actividades

Representa el flujo de interaccin con respecto a un escenario especfico Los rectngulos indican funciones, las flechas indican flujo, los diamantes indican ramas de decisin y las lneas horizontales indican que ocurren actividades en paralelo.

(C) P. Gmez-Gil, INAOEP 2009

Diagrama de actividades para Licitacin de Requerimientos

[Pressman 2004]

(C) P. Gmez-Gil, INAOEP 2009

Diagramas tipo Swimlane (carriles)

Son una variacin de los de actividades. Permiten representar el flujo de actividades y al mismo tiempo indicar que actor(a) o clase tiene la responsabilidad de la accin descrita por el rectngulo. Se divide con lneas verticales el diagrama, una columna por cada actor (como los canales de nado en una piscina).
(C) P. Gmez-Gil, INAOEP 2009

Diagrama tipo carriles

Fig. 8.8 [Pressman 04]

(C) P. Gmez-Gil, INAOEP 2009

Unified Modeling Language (UML)1

UML es:
Un

lenguaje que permite especificar, visualizar y construir artefactos de software Un lenguaje destinado a los sistemas que utilizan conceptos orientados a objetos Notacin estndar para construir modelos orientados a objetos Solo una notacin. No es un mtodo o proceso de desarrollo
(C) P. Gmez-Gil, INAOEP 2009

Historia de UML

En el 2009 ya se liber la versin 2.2

(C) P. Gmez-Gil, INAOEP 2009

Diagramas de UML 2.0

Tres tipos, 13 diagramas:

1.

Diagramas de estructura esttica. Incluyen Diagramas

de Clase, Diagramas de Objetos, Diagramas de Componente, Diagramas de Estructura Compuesta, Diagramas de Paquete y Diagramas de Entrega (Deployment) Diagramas de Comportamiento. Incluyen Diagramas de Caso de Uso, Diagramas de Actividades y Diagramas de Estado de Mquina Diagramas de Interaccin. Incluyen Diagramas de Secuencia, Diagramas de Comunicacin, Diagramas de Sincronizacin (timing) y Diagramas Generales de Interaccin (Interaction Overview Diagram)

2.

3.

(C) P. Gmez-Gil, INAOEP 2009

Consultar Object Management Group: UML Resource Page: http://www.uml.org/

(C) P. Gmez-Gil, INAOEP 2009

ANEXO. EJEMPLO DE CASOS DE USO: SISTEMA PRISCUS

(C) P. Gmez-Gil, INAOEP 2009

Diagrama de flujo de datos de Priscus

[Perea-Centeno 2012]

Bibliografa Anexo
Perea Centeno Liliana. Interfaz web para el reconocimiento de texto manuscrito y antiguo a travs del proyecto Priscus. Tesis de Licenciatura. Instituto de Estudios Superiores A.C, Benemrita Universidad Autnoma de Puebla. 2012 Cuevas-Farfn E, Gmez-Gil P. PRISCUS: Reconocedor ptico de caracteres manuscritos y antiguos. Memorias tcnicas del 9 Encuentro de Investigacin. Instituto Nacional de Astrofsica, ptica y Electrnica. Tonantzintla, Puebla. 6 y 7 de Noviembre 2008.