* INGENIERA DEREQUISITOSCecilia Hinojosa R. Marzo Julio 2012

*La IR es un factor crtico de xito en los

proyectos de desarrollo de software, segn Curtis, el exacto conocimiento del dominio del problema es crtico para el xito del proyecto.

*Boehm 1981: la etapa de requisitos demanda: *6% del costo *9% al 12% del tiempo *Stockman y Norris: *55% de los fallos se producen en la etapa de anlisis yespecificacin de requisitos

*Importancia

En 1979, la Government Account Office, (GAO) realiz un estudio en el que seleccionaron nueve proyectos de desarrollo de software para el gobierno norteamericano.

*Importancia

Factores de xito: 1. Implicacin de los usuarios 2. Apoyo de los directivos 3. Enunciado claro de los requisitos

CHAOS Report 1995 Standish Group

Factores de fracaso : 1. Falta de informacin por parte de los usuarios 2. Especificaciones y requisitos incompletos 3. especificaciones y requisitos cambiantes

*Importancia

*Segn la IEEE, requisito es:1. 2.Una condicin o capacidad que un usuario necesita para resolver un problema o lograr un objetivo. Una condicin o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, una especificacin u otro documento formal. Una representacin en forma de documento de una condicin o capacidad como las expresadas en (1) o en (2).

3.

*Requisito Definicin

*Existen varias clasificaciones de los requisitos:* de sistema * de hardware * de software * de usuario * de cliente * funcional * no funcional, entre otros.

*Requisitos -

Clasificacin

Por la naturaleza de la caracterstica deseada En qu mbito se debe entender el requisito Quin debe entender el requisito

*Requisitos -

Dimensiones

* Requerimientos funcionales: Son declaraciones de los servicios que debe proporcionar el sistema, la manera en que debe reaccionar ante peticiones y entradas particulares. Puede declarar explcitamente lo que el sistema no debe hacer. * Requerimientos no funcionales: Se refieren a las propiedades emergentes del sistema, tales como: fiabilidad, tiempo de respuesta, capacidad de almacenamiento. Tambin pueden restringir capacidad de dispositivos de entrada / salida o forma de almacenamiento de datos

*Requisitos tipos

*Requerimientos de usuario: Declaraciones enlenguaje natural y diagramas de los servicios que se espera el sistema proporcione y de las restricciones bajo las cuales debe funcionar.

*Requerimientos

del sistema: Son versiones extendidas de los requerimientos del usuario que son utilizados por los ingenieros de software, como punto de partida para el diseo del sistema.

*Requisitos - tipos

* Comprensible por clientes y usuarios * Correcta * No ambigua * Completa * Consistente * Verificable * Modificable * Rastreable * Anotada con importancia y estabilidad * Independiente del diseo y la implementacin

Caractersticas

*Requisitos

*Davis sugiere que la Ingeniera de Requisitosconsiste en el anlisis, documentacin y posterior evolucin de las necesidades del usuario y el comportamiento externo del sistema a ser construido [Davis90].

*Thayer define la Ingeniera de Requisitos como

la ciencia y disciplina interesada en establecer y documentar los requisitos de software. Consiste en la elicitacin, el anlisis, la especificacin, la verificacin y la administracin de los requisitos.

* Ingeniera de Requisitos Definicin

USO DE:

PARA:

Eficiencia

Calidad

*Definicin

LOS

Tcnicas Herramientas Lenguajes Mtodos

Descubrir Refinar Modelar Especificar

Requisitos del software

Cliente: Debe ser experto en los procesos relacionados con el software Estar comprometido con el proyecto de desarrollo

Desarrollador: Investigador Cuestionador Consultor Solucionador de problemas Alta capacidad de abstraccinAl finalizar el proceso de requerimientos, el desarrollador conocer ms del proceso y el cliente se involucrar en temas informticos

*Participantes

Todos aquellos que tienen algn inters en el cambio que est siendo considerado, que tienen algo que ganar o perder (Stakeholders)

* Jefe del proyecto * Diseadores del software * Expertos tcnicos * Analistas de negocios * Expertos de mercados * Responsables de venta o compra * Administradores * Usuarios

*Participantes

USUARIOS Estar familiarizado con sistemas de computacin Buen conocimiento del dominio de la aplicacin Tener conocimiento de gestin de desarrollo de sistemas Tener conocimientos de gestin y planificacin de implementacin de sistemas computacionales

PERSONAL TCNICO Conocimiento del dominio de la aplicacin y procesos del negocio Tcnicas a utilizar a nivel de hardware y software Facilidad de comunicacin

Proceso de ingeniera de requerimientos, anlisis costo / beneficio, implementacin de sistemas y cambio organizacional

Tener habilidad para tratar y Anlisis y evaluacin de comunicarse con las personas paquetes de software

*Destrezas

* Cite tres motivos por los cuales es importantela Ingeniera de Requisitos.

* Enumere los dominios de los requisitos * Segn la audiencia en qu se dividen losrequisitos?

* Enumere cinco caractersticas de los requisitos.

*IR - Autoevaluacin

ERS Definitivo

EduccinInicio

Declaracin informal de requerimient os

Validacin

Anlisis y Negociacin

ERS Borrador

Especificacin

Requerimient os convenidos

*Proceso de IR

*Objetivos de la Educcin* Conocerel dominio del problema: con el fin de entenderse con los clientes y usuarios y que sean capaces de transmitir dicho conocimiento al resto del equipo de desarrollo. las necesidades reales de clientes y usuarios: adems de aquellas necesidades explcitamente manifestadas por los clientes y usuarios, se debe llegar a descubrir el conocimiento tcito, es decir, aquellas necesidades que la mayor parte de las veces se asumen y toman por implcitas.

* Descubrir

*Educcin

* Se refiere a la captura y descubrimiento de los requisitos. * Es una actividad ms humana que tcnica. Se identificana los interesados (stakeholders) y se establecen las primeras relaciones entre ellos y el equipo de desarrollo.

* Fuentes de Requisitos* Metas: Factores crticos de xito (de la empresa). * Conocimiento del dominio de la aplicacin: Cosas que pueden resultarobvias a los expertos no lo son para los usuarios.

* Los interesados: Los afectados por el sistema. * El entorno fsico que rodea al sistema. * El entorno organizacional: Los procesos de negocio.

*Educcin

* Los usuarios no pueden/saben describir muchas de * Mucha informacin importante no llega averbalizarse.

sus tareas. Pueden hacer demandas irreales, ya que no conocen el costo de sus peticiones.

* La dinmica organizacional puede hacer queemerjan nuevos requerimientos.

* Los factores externos pueden influir en los

requisitos del sistema. Ej: factores polticos.

*Problemas de la

educcin

Brainstorming: Seleccionar un grupo variado de participantes. Eliminar crticas, juicios y evaluaciones mientras los participantes sugieren ideas. Producir muchas ideas. Recogerlas todas por escrito. Otro da, en otra sesin, se evalan las ideas (se puntan). Entrevistas: Es el mtodo tradicional, pero debe usarse en complemento con otras tcnicas, y no debe ser el primer paso de la educcin. Es fundamental: Entrevistar a la(s) persona(s) adecuadas, Preparar las preguntas con antelacin, Utilizar diagramas, modelos, etc.

*Tcnicas de educcin

Observacin y anlisis de tareas (mtodo etnogrfico): Un observador estudia a los futuros usuarios en su entorno de trabajo. A veces se utiliza el video. Anota todo aquello que es susceptible de mejora. Posteriormente, genera una serie de requisitos tentativos. Escenarios: Esquemas de la interaccin, deben incluir: * Lo que el usuario espera del sistema * Descripcin de flujo normal de eventos * Descripcin de situaciones excepcionales * Descripcin de actividades paralelas * Descripcin del estado del sistema cuando el escenario termina. .

*Tcnicas de educcin

Casos de uso: Identifican las interacciones entre los actores y el sistema. Prototipado: tiles cuando la incertidumbre es total acerca del futuro sistema.

*Tcnicas de educcin

Expertos del dominio Literatura del dominio Software similar

Identificar fuentes Adquirir conocimiento Decidir relevancia conocimiento Entender significado e impacto Modelos formales del dominio del problema

Estndares, normativa y base legal

Loucopoulos & Karakostas, 1995

*El proceso de

educcin

Expertos del dominio

Literatura del dominio

Obtener informacin de participantesModelos formales del dominio del problema

Software similar

Identificar requisitosEstndares, normativa y base legal

*El proceso deeduccin

Kotonya & Sommerville, 1998

* Indique cul es el objetivo de la educcin * Enumere tres tcnicas que se utilizan para la

educcin de requisitos * Enumere las actividades que se ejecutan en el proceso de educcin * Cite tres entradas importantes del proceso de educcin * Indique cul es el resultado del proceso de educcin.

autoevaluacin

*Educcin -

El objetivo principal :Asegurar la calidad de los requisitos educidos, antes de que stos pasen a formar parte del documento de especificaciones.

Objetivos secundarios:

* Precisar los lmites del sistema software * Precisar la interaccin entre el entorno y el sistema * Trasladar los requisitos del usuarios a requisitos delsoftware * Documentar los requisitos

*Anlisis

*Consensuar

los requisitos entre los propios clientes y usuarios: puede que distintos grupos de clientes y usuarios presenten distintas necesidades que sean contradictorias entre s. Normalmente es necesario negociar entre los distintos participantes hasta obtener una visin comn de los requisitos.

*Anlisis

*En el anlisis de requisitos se*Clasificacin *Modelizacin Conceptual *Negociacin

realizan tres tareas fundamentales:

*Anlisis

Requerimientos del negocio Ideas y soluciones Casos de uso y escenarios

Definiciones de datos

Reglas del negocio

RestriccionesRequerimientos de interfaces externas Atributos de Calidad

Requerimientosfuncionales y no-funcionales

*Clasificacin

*

Reglas del negocio: Las reglas de negocio definen hechos, restricciones, acciones que habilitan funciones, formulas de cmputo o inferencias derivadas de actividades de la organizacin.

*

Requerimientos funcionales: Los requerimientos funcionales describen el funcionamiento que el sistema observar bajo ciertas condiciones y las acciones que permitir el sistema llevar a cabo a los usuarios.

*Clasificacin

*

Requerimientos de negocio: Todo lo que describa beneficios de mercado, financieros o del negocio para los clientes o su organizacin, y que sean obtenidos del producto de software.

*

Casos de uso y escenarios: Los casos de uso son descripciones generales de metas del cliente o tareas del negocio que los usuarios deben realizar. Un patrn nico del caso de uso se conoce como escenario.

*Clasificacin

*Modelado conceptualCecilia Hinojosa R.

34

* Es una simplificacin de la realidad * Un modelo proporciona los planos

de un sistema, los planos pueden ser detallados o generales * Un buen modelo incluye aquellos elementos que son relevantes para el nivel dado de abstraccin. * Cada modelo es por tanto una abstraccin semnticamente cerrada del sistema. * Un modelo puede ser estructural, haciendo hincapi en la organizacin del sistema, o puede ser el comportamiento, haciendo hincapi en la dinmica del sistema

Grady Booch

*Qu es un modelo?Cecilia Hinojosa R.

35

* Dependiendo de la complejidad del problemase generarn los modelos necesarios, se seleccionarn las herramientas y equipos de trabajoRequiere: Modelado mnimo Proceso simple Herramientas simples 1 persona Requiere: Modelado Proceso bien definido Herramientas ms sofisticadas Un equipo de personas

Requiere: Modelado varias perspectivas Proceso complejo Herramientas complejas Equipos en varias disciplinas

*Cundo hacer modelos?Cecilia Hinojosa R.

36

Ayuda a :

Visualizar de manera global Aumentar gradualmente el conocimiento Proyectar o anticipar la estructura

funcionamiento de algo Simular la manipulacin de algo y observar los resultados. Tomar decisiones. Documentar para revisiones futuras.

o

*Por qu modelar?Cecilia Hinojosa R.

37

* Modelos conceptuales * Modelos orientados a procesos * Modelos orientados a datos/objetos * Modelos orientados a estados

Ingeniera de SoftwareCecilia Hinojosa R.

*Los modelos en la38

* Los modelos

conceptuales favorecen la comprensin de los requisitos del usuario, describen el dominio del discurso. funcionamiento del futuro sistema software

* Los modelos del sistema permiten anticipar el

* Modelos conceptuales vs. ModelosCecilia Hinojosa R.

del sistema

39

Modelo conceptual Objeto Describe el dominio del discurso (tareas cotidianas, reglas de negocio) Variable, generalmente mayor al del modelo del sistema Poco detallado

Modelo del sistema Describe futuro sistema software (clases, mensajes, procesos, mtodos) Se circunscribe estrictamente al mbito del futuro sistema software Contiene gran nivel de detalle para ser til en la implementacin Lo ms precisos posibles

Alcance

Detalle

Formalidad

vs. Modelos del sistemaCecilia Hinojosa R.

*Modelos conceptualesNiveles variados40

* Ontologa subyacenteLos modelos conceptuales tienen un propsito especfico y describen el dominio del discurso con:

* un lxico = smbolos o constructores * una sintaxis, la cual gobierna la combinacin delos smbolos constructores = reglas

*Modelos conceptualesCecilia Hinojosa R.

41

* Ejemplo:

*Modelos conceptualesTomado de Modelos conceptuales Diestes O.

Cecilia Hinojosa R.

42

*IRQA

Diseada para soportar las actividades realizadas en el proceso de especificacin de sistemas. Facilita y formaliza la comunicacin entre el cliente, el proveedor y los distintos miembros del equipo de desarrollo. Facilita la captura, organizacin y anlisis de las condiciones, as como la especificacin de la solucin mediante el apoyo metodolgico adaptable a cada cliente.

43:

* Herramientas de soporte IR

* IRQA

43: Facilita y formaliza la comunicacin entre el

cliente, el proveedor y los distintos miembros del equipo de desarrollo. Facilita la captura, organizacin y anlisis de las condiciones, as como la especificacin de la solucin mediante el apoyo metodolgico adaptable a cada cliente. aspectos funcionales del sistema; la definicin de la Misin del Sistema, la construccin del rbol de Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso. Adems, se introduce un Proceso de Anlisis que permite traducir el Modelo de Requisitos en el Modelo Conceptual, manteniendo la trazabilidad entre ambos.

* RETO: Propone un modelo de requisitos para capturar los

* Herramientas de soporte IR

* CONTROLA: Ofrece recursos importantes tales como:

Administracin de requisitos, administracin de casos de uso, administracin de casos de prueba y error, planeamiento de liberaciones, administracin de implementaciones, control de dependencia entre Implementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos. * OSRMT (Open Source Requirements Management Tool)4 Herramienta libre para la gestin de requisitos, cuyas principales caractersticas son: trabaja en arquitectura cliente/servidor, desarrollada bajo Java; la versin 1.3 trae un mdulo para manejar la trazabilidad y lo introduce para el control de cambios; as mismo, genera la documentacin de los requisitos tratados.

* Herramientas de soporte IR

* Documento:

* Descripcin de un proyecto de desarrollo de software:* Tema * Objetivo del sistema * Alcance del sistema * Descripcin de los usuarios y clientes * Descripcin del equipo de desarrollo * Restricciones del proyecto * Nivel de certeza de los requisitos * Riesgos del proyecto * Modelo de proceso de desarrollo de software elegido yjustificacin

*