INGENIERÍA DE REQUISITOS

UNIVERSIDAD NACIONAL HERMILIO VALDIZANFACULTAD DE INGENIERÍA INDUSTRIAL Y DE SISTEMAS

EAP INGENIERÍA DE SISTEMAS

SESION 3

Un cliente entra a tu oficina, se sienta te mira directo a los ojos y dice :“Yo sé que ud. piensa que entiende lo que digo, pero lo que Ud. no entiende es que lo que digo no es realmente lo que quiero decir”

Ralph Young

TU PEOR PESADILLA!!!!

REQUERIMIENTOS O REQUISITOS?

Requirements Engineering = Ingeniería de RequisitoRequest Engineering = Ingeniería de Requerimiento

¿Qué es un Requerimiento?Es una definición abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste

REQUERIMIENTOS O REQUISITOS?

¿Qué es un Requisito?Son declaraciones que identifican atributos, capacidades , características y/o cualidades que necesita cumplir un sistema para que tenga valor y utilidad para el usuario .En otras palabras, los requisitos muestran qué elementos y funciones son necesarias para un proyecto.

¿QUE ES INGENIERÍA DE REQUISITOS?

• Es un proceso que comprende todas las actividades requeridas para crear y mantener un documento de requisitos del sistema

• El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema .

La meta de la ingeniería de requisitos es entregar una especificación de requisitos de software, correcta y completa.

“La parte más difícil de construir un sistema de software es decidir qué construir […]”

“Ninguna otra tarea afecta tanto negativamente al sistema, al final, si se realiza de manera incorrecta, al inicio.”

Frederick Phillips Brooks Professor Department of Computer Scienc.University of North Carolina. USA.

En la actualidad muchos de los desarrollos de aplicaciones fracasan porque no se hace un análisis correcto sobre la determinación de requisito que tiene el usuario para darle solución a su problema de información.

La IR que facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando sus necesidades, confirmando su viabilidad, negociando una solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transforme en necesidad operacional.

Tipos de usuarios del documento de requisitosClientes del sistema

Especifican los requisitos y los leen para chequear que atienden sus necesidades. Especifican cambios en los requisitos.

Gerentes Usan los documentos de requisitos para planificar una propuesta (oferta) para el sistema

y planificar el proceso de desarrollo.

Ingenieros de sistemas Usan los requisitos para entender qué sistema tiene que ser desarrollado.

Ingenieros de prueba de sistemas

Usan los requisitos para desarrollar pruebas de validación para el sistema.

Ing. de mantenimiento de sistemas

Usan los requisitos para ayudar a entender los sistemas y las relaciones entre sus partes.

IEEE/ANSI 830-1998:Standard for Software Requirements Specification

1.Introducción1.1.Propósito del documento de requisitos1.2.Alcance del proyecto1.3.Definiciones, acrónimos y abreviaturas1.4.Resumen del resto del documento

2.Descripción General2.1.Perspectiva del producto2.2.Funciones del producto2.3.Características de los usuarios2.4.Limitaciones generales2.5.Suposiciones y dependencias

3.Requisitos Específicos 3.1.Requisitos funcionales, no funcionales

4.Apéndices5.Índice

• Requisito:Propiedad que debe ser exhibida por un software para resolver un problema particular (SWEBOK).Condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado.

• Especificación de Requisitos Software (ERS, SRS): Documento formal de los Requisitos del Sistema SRS – Software Requirements Specification

Definiciones

• Ingeniería de Requisitos:“Conjunto de actividades para descubrir, documentar y mantener un conjunto de requisitos”Establecer los servicios que el cliente requiere de un sistema y las restricciones bajo las cuales opera y es desarrollado.

• Proceso de Ingeniería de Requisitos:“Conjunto estructurado de actividades de cuya ejecución se obtiene, valida y mantiene el documento de requisitos del sistema”

• Gestión de Requisitos: Actividad para gestionar los cambios en los requisitos de un sistema.

Definiciones

Qué es un requisito?Un requisito podría describir:

Una facilidad a nivel usuario Ej.: ‘el procesador de palabras debe incluir un verificador de ortografía y un comando de corrección’

Una propiedad muy general del sistemaEj.: ‘el sistema debe asegurar que la información personal nunca se haga disponible sin autorización’

Una restricción específica del sistema Ej.: ‘el sensor debe ser activado 10 veces por segundo’

Una restricción para el desarrollo del sistema Ej.: ‘el sistema debe ser desarrollado usando Ada’

Cómo llevar a cabo algún cálculo Ej.: ‘la nota final debe ser calculada sumando las notas del examen, proyecto y cursada del estudiante basado en la siguiente fórmula

nota final = nota_exam + 2 * nota_proy + 2/3 * nota_cursada’

Propiedades del dominio: “Cosas” en el dominio de aplicación que son verdaderas independientemente que se construya o no el sistema de software Requisitos: “Cosas” en el dominio de aplicación que se desean sean verdaderas mediante la construcción del sistema de software Especificación: Descripción de comportamiento (y datos) que el programa tiene que tener para cumplir los requisitos sólo puede ser descrito en términos de los fenómenos compartidos por la maquina y el dominio de aplicación

Acuerdo desarrolladores-stakeholdersAspecto contractualMultipartes (comunicación, conflicto y cambio de visiones)Base para el diseño del softwareMinimizar defectos tanto como sea posibleProyecto Técnicamente factibleSoporte para verificación y validaciónSoporte a la evolución del sistema

Rol de los requisitos

Stakeholder:Entidad que será afectada por el sistema y que tienen una influencia directa o indirecta sobre los requisitos del sistema.

• Usuarios finales del sistema• Gerentes involucrados en los procesos organizacionales

influenciados o que influencian al sistema• Ingenieros responsables por el desarrollo y mantenimiento

del sistema,• Clientes de la organización • Cuerpos externos tales como autoridades reguladoras o de

certificación.• …….

Posibles stakeholders de un sistema automatizado de señalización ferroviaria:

• Los Operadores responsables de ejecutar el sistema de señalización

• Tripulación del tren• Gerentes ferroviarios• Pasajeros• Ingenieros de instalación y mantenimiento de equipos• Autoridades de certificación de seguridad

STAKEHOLDERS

Documentos de RequerimientosExisten dos documentos que emanan del análisis de requerimientos:

Definición de requerimientos

Es un documento que debe escribirse en términos que el cliente pueda entender. Es decir, este documento es un listado completo de todas las cosas que el cliente espera que haga el sistema propuesto. Este documento es escrito en forma conjunta por el cliente y el desarrollador.

Documentos de RequerimientosEspecificación de requerimientos

Documento que reitera la definición de los requerimientos en los términos técnicos apropiados para el desarrollador del diseño de un sistema. Es la contrapartida técnica al documento de definición de requerimientos y es escrito por los analistas de requerimientos.

A veces un único documento puede servir para ambos propósitos, lo que lleva a un entendimiento común entre clientes, analistas de requerimientos y diseñadores.

Pero a menudo se necesitan ambos documentos.

Documentos de RequerimientosEs muy importante, que al usar ambos documentos exista una correspondencia directa entre cada requerimiento del documento de definición y aquellos documentos en la especificación.

Esto para que la visión del cliente este unida a la de los desarrolladores (esto se logra gracias a la gestión de configuración).

Clasificación de RequerimientosSegún el Tipo los requerimientos se clasifican en:

Requerimientos funcionales. Requerimientos no funcionales. Requerimientos del Dominio.

Según a quien van dirigidos se clasifican en:

Requerimientos del Usuario. Requerimientos del Sistema.

Clasificación de RequerimientosRequerimientos funcionales

Describen la funcionalidad o los servicios que se espera que el sistema proveerá. Dependen del tipo de software, del sistema que se desarrollo y de los posibles usuarios.

Cuando se expresan como Requerimientos del usuarios, se definen de forma general.

Cuando se expresan como requerimiento del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc.

Clasificación de RequerimientosRequerimientos no funcionales

Son los requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste, como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento.

Muchos requerimientos no funcionales se refieren al sistema como un todo más que a rasgos particulares del mismo.

A menudo son mas críticos que los funcionales. Mientras que un incumplimiento de un requerimiento funcional degrada el sistema, el de un requerimiento no funcional del sistema lo inutiliza.

Clasificación de RequerimientosRequerimientos no funcionales

Los requerimientos no funcionales se clasifican según su implicancia:

Del producto: especifican comportamiento del producto. Ej.: de desempeño en la rapidez de ejecución del sistema, cuanta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para el sistema sea aceptable, los de portabilidad y de usabilidad.

Organizacionales: se derivan de las políticas y procedimientos existentes en la organización del cliente y del desarrollador. Ej.: estándares en los procesos que deben utilizarse, requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar.

Clasificación de RequerimientosRequerimientos no funcionales

Externos: cubre todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Ej.: requerimientos de interoperabilidad, requerimientos legales, requerimientos éticos.

Un problema común con los requerimientos no funcionales es que algunas veces son difíciles de verificar.

De forma ideal los requerimientos no funcionales se deben expresar de manera cuantitativa utilizando métricas que se puedan probar de forma objetiva. En la práctica, es difícil. El costo es muy alto.

Clasificación de RequerimientosRequerimientos del dominio

Se derivan del dominio del sistema más que de las necesidades especificas del usuario.

Son importantes debido a que a menudo reflejan los fundamentos del dominio de la aplicación. Si estos no se satisfacen es imposible que el sistema trabaje de forma satisfactoria.

Estos se expresan utilizando un lenguaje especifico del dominio de la aplicación que a menudo es difícil de comprender. Ej.: operación para calcular desaceleración del tren, para un sistema de control de trenes.

Características de los requerimientos

Es importante señalar que los requerimientos pueden servir a tres propósitos:

Permitir que el desarrollador explique como ha entendido lo que el cliente pretende del sistema.

Indican a los diseñadores que funcionalidades y características va a tener el sistema resultante.

Los requerimientos indican al equipo de pruebas que demostraciones llevar a cabo para convencer al cliente de que el sistema que se le entrega es de hecho lo que había ordenado.

Características de los requerimientosLos requerimientos deben ser de alta calidad para la buena comprensión de clientes y desarrolladores.Con este fin debe comprobarse que los requerimientos posean las características que se desprenden de las siguientes preguntas:

¿los requerimientos son correctos?. Cliente y desarrollador deben revisarlos para asegurarse que no tienen errores.

¿los requerimientos son consistentes?. Es decir, ¿los requerimientos planteados son no conflictivos ni ambiguos?. Dos requerimientos son inconsistentes cuando es imposible satisfacerlos simultáneamente.

Características de los requerimientos ¿los requerimientos son completos?. El conjunto de requerimientos es completo si todos los estados posibles, cambios de estado, entradas, productos, restricciones están descritos en alguno de los requerimientos.

¿los requerimientos son realistas?.¿El sistema puede hacer realmente lo que el cliente esta pidiendo que haga?. Todos los requerimientos deben ser revisados para asegurarse que son posibles.

¿describe cada requerimiento algo que es necesario para el cliente?. Los requerimientos deben ser revisados para conservar sólo aquellos que inciden directamente en la resolución del problema del cliente.

¿los requerimientos son verificables?. Debemos preparar pruebas que demuestren que se han cumplido los requerimientos.

Características de los requerimientos

¿los requerimientos son rastreables?. ¿Se puede rastrear cada función del sistema hasta el conjunto de requerimientos que la establece?. ¿Resulta fácil encontrar el conjunto de requerimientos que coinciden a un aspecto especifico del sistema?.

Fuentes de Requerimientos

Requerimientos

Deseos y necesidad

De los interesados

Modelo del Dominio

Modelo de la situación actual

Requerimientos

Reutilizables

Tipo de Requerimientos recomendados

Documentos existentes

Organización y sistemas actuales

Plantilla de Requerimientos

Biblioteca de Reutilización

Proceso: Ingeniería de Requerimientos

Estudio de factibilidad

Obtención y Análisis de

Requerimientos

Especificación de

Requerimientos

Validación de

Requerimientos

Informe de

factibilidad

Actividades

Especificación de

Requerimientos

Documento de

Requerimientos

Modelo del Sistema

Artefactos

Proceso: Ingeniería de Requerimientos

Estudio de factibilidad

Obtención y Análisis de

Requerimientos

Especificación de

Requerimientos

Validación de

Requerimientos

Informe de

factibilidad

Actividades

Especificación de

Requerimientos

Documento de

Requerimientos

Modelo del Sistema

Artefactos

Proceso: Ingeniería de Requerimientos

Estudio de Factibilidad

La entrada de este es una descripción resumida del sistema y como se utiliza dentro de una organización.

El resultado del estudio es un informe que recomienda si es conveniente llevar a cabo la ingeniería de requerimientos y el proceso de desarrollo del sistema. Además permite proponer cambios al alcance, presupuesto, calendarización, etc.

Este es un estudio corto para resolver si es posible y conveniente construir el sistema con la tecnología existente, las restricciones de costo y tiempo, etc.

Proceso: Ingeniería de Requerimientos

Estudio de factibilidad

Obtención y Análisis de

Requerimientos

Especificación de

Requerimientos

Validación de

Requerimientos

Informe de

factibilidad

Actividades

Especificación de

Requerimientos

Documento de

Requerimientos

Modelo del Sistema

Artefactos

Proceso: Ingeniería de RequerimientosObtención y Análisis de requerimientos

Se trabaja en conjunto con los usuarios y los clientes.

Problemas Comunes: No saben lo que quieren del sistema , sólo en términos

generales, no conocen el costo de sus peticiones. Los requerimientos están en sus términos y con conocimientos

implícitos de su propio trabajo. Distintos usuarios tienen distintos requerimientos, se deben

encontrar todas las fuentes. Influyen factores políticos. La importancia de los requerimientos varia en el tiempo. Aparecen nuevos requerimientos.

Proceso: Ingeniería de RequerimientosObtención y Análisis de requerimientos

Proceso de Obtención y Análisis de requerimientos.

Comprensión del dominio

Recolección de Requerimientos Clasificación

Resolución deConflictosPriorizaciónVerificación

de Requerimientos

Proceso: Ingeniería de RequerimientosObtención y Análisis de requerimientos

Fases:1. Comprensión del Dominio: el analista debe desarrollar su

propia comprensión del dominio de la aplicación. Ej.: Si fuera un sistema para un supermercado este debe evaluar como funciona un supermercado.

2. Recolección de Requerimientos: éste es el proceso de interactuar con los clientes y usuarios para descubrir sus requerimientos . Acá se desarrolla la compresión del dominio.

3. Clasificación: considera la recolección no estructurada de requerimientos y los organiza en grupos coherentes.

Proceso: Ingeniería de RequerimientosObtención y Análisis de requerimientos

4.Resolución de conflictos: de forma inevitable, cuando existen muchos stakeholders involucrados, los requerimientos estarán en conflicto. Está actividad se refiere a resolver estos conflictos.5.Priorización: Descubrir la importancia de cada requerimiento. Es útil separar los requerimientos en tres categorías:

• Requerimientos que deben ser absolutamente satisfechos.• Requerimientos que son muy deseables pero no indispensables.• Requerimientos que son posibles, pero que podrían eliminarse.

6.Verificación de Requerimientos: Los requerimientos se verifican para descubrir si están completos, son consistentes y acorde con lo que realmente quieren los stakeholders.

No existe un enfoque perfecto ni universal aplicable a la obtención y análisis de requerimientos .

Proceso: Ingeniería de Requerimientos

Estudio de factibilidad

Obtención y Análisis de

Requerimientos

Especificación de

Requerimientos

Validación de

Requerimientos

Informe de

factibilidad

Actividades

Especificación de

Requerimientos

Documento de

Requerimientos

Modelo del Sistema

Artefactos

Proceso: Ingeniería de RequerimientosEspecificación de Requerimientos

Lenguaje Natural Comprensible para el Cliente/Usuario. Ambiguo (glosario). Poca legibilidad (plantilla, formateo del texto). Difícil de tratar (Verificar correctitud, consistencia, completitud).

Notaciones Especiales (más formales) Poca o ninguna ambigüedad. Facilita tratamiento. Necesidad de entrenamiento en la notación. Dificultades de comprensión por Cliente/Usuario

Proceso: Ingeniería de RequerimientosEspecificación de Requerimientos

Notaciones Especiales. Gráficas vs. Basadas en texto Estáticas vs. DinámicasDescripciones Estáticas.

• Se especifican entidades y sus atributos, los requerimientos se pueden ver como las relaciones entre las entidades.

• No describe como cambian las relaciones con el tiempo

Descripciones Dinámicas• Especifican estados y las transiciones entre estados en el tiempo.

Proceso: Ingeniería de Requerimientos

Estudio de factibilidad

Obtención y Análisis de

Requerimientos

Especificación de

Requerimientos

Validación de

Requerimientos

Informe de

factibilidad

Actividades

Especificación de

Requerimientos

Documento de

Requerimientos

Modelo del Sistema

Artefactos

Proceso: Ingeniería de RequerimientosValidación de Requerimientos

Proceso por el cual se determina si la especificación es consistente con las necesidades del cliente.Incluye verificar trazabilidad entre la especificación y el documento de requerimientos.Se trabaja con un bosquejo completo del documento a diferencia de la verificación del Análisis.Se realizan las siguientes verificaciones en el documento de requerimientos:

Validez: compromiso con el usuario, que valide que es lo que quiere. Consistencia: que no haya contradicciones. Realismo: que se puedan implementar (incluye: tecnología, presupuesto y

calendario). Verificabilidad: Diseñar conjunto de pruebas para demostrar que el sistema cumple

esos requerimientos.

Proceso: Ingeniería de RequerimientosValidación de Requerimientos

Verificación de Requerimientos no funcionales. Son difíciles de verificar. Se deben expresar de manera cuantitativa utilizando métricas que se puedan

probar de forma objetiva ( esto es IDEAL).

Propiedad MedidaRapidez Transacciones por seg.Tamaño KB.Fiabilidad Tiempo promedio entre fallas.Robustez Probabilidad de datos corruptos después de la falla.Portabilidad Número de sistemas. Facilidad de uso Tiempo de capacitación.

Para los usuarios es difícil especificarlos en forma cuantitativa.

Entre los participantes en el proceso de requerimiento pueden incluirse:

Supervisor del contrato: quienes sugieren hitos de control y cronogramas que restringen el desarrollo del sistema. Clientes y Usuarios: quienes deben comprender los requerimientos de modo que puedan estar seguros de que el sistema satisface sus necesidades. Gerentes de negocios: pueden comprender las probables consecuencias de construir y utilizar el sistema. Diseñadores: quienes utilizan los requerimientos como base para el desarrollo de una solución aceptable, que se implementara como un sistema basado en software. Verificadores: desarrollan datos de prueba y sesiones de prueba para asegurar que el sistema de software satisface cada uno de los requerimientos.

Proceso: Ingeniería de RequerimientosParticipantes en el proceso de requerimientos.

Proceso: Ingeniería de Requerimientos

Estudio de factibilidad

Obtención y Análisis de

Requerimientos

Especificación de

Requerimientos

Validación de

Requerimientos

Informe de

factibilidad

Actividades

Especificación de

Requerimientos

Documento de

Requerimientos

Modelo del Sistema

Artefactos

Proceso: Ingeniería de RequerimientosModelado del Sistema

Existen una gran cantidad de métodos para el modelamiento de sistemas, a continuación se nombran los más significativos:

Tablas de Decisión. Diagramas de transición de estados. Redes de Petri. Diagramas de Flujo de Datos. Diagramas de Casos de Uso.

Técnicas para describir un sistema entorno a estados y estímulos.

Proceso: Ingeniería de RequerimientosModelado del Sistema – Tablas de Decisión

Descripción dinámica.

Conjunto de condiciones posibles en un cierto instante o tiempo dado.

Estados donde se verifica una combinación determinada de las condiciones.

Acciones a tomar.

CondicionesAcciones

1 2 3 4 5Importe > 1000 F F V V VBuenos Antecedentes V F V V FYa operó antes - - V F -Autorizar Crédito X XAnalizar antecedentes X X X

EstadosF = Condición Falsa

V = Condición Verdadera

- = condición no importa

Proceso: Ingeniería de RequerimientosModelado del Sistema – Tablas de Decisión

La tabla de decisión representa acciones a ser tomadas cuando el sistema está en uno de los estados representados.

El número de estados es = 2^ nº de condiciones, lo que da como resultado tablas de decisión muy extensas.

Se puede verificar que si todo conjunto de posibles condiciones resulta en una acción, entonces la especificación está completa. También se puede analizar la consistencia de la tabla, y eliminar cualquier caso conflictivo.

Proceso: Ingeniería de RequerimientosModelado del Sistema – Tablas de Transición de Estados

Descripción dinámica.

Se interpreta el sistema de una forma similar, a un conjunto de estados donde el sistema reacciona a ciertos eventos posibles.

El conjunto de estados se denomina S.

Un estado inicial es, S0.

Un conjunto de eventos o condiciones, C.

Existe una función de transición de estados, F. F(Si,Cj) = Sk

Proceso: Ingeniería de RequerimientosModelado del Sistema – Tablas de Transición de Estados

Ejemplo de un diagrama de transición de estados para reserva de Hotel (Utilizando forma UML).

INICIO

Solicitud de plaza

ninguna

Solicitada

Confirmada En Lista de Espera

Ninguna plaza disponible

Poner en lista de espera

Plaza disponible

decrementar cuenta de plaza

Plaza disponible

decrementar cuenta de plaza

Cancelada

El cliente desiste

Retirar de la lista

El cliente cancela

Incrementar cuenta de plazas

Ocupada

El cliente ocupa

ninguna

Condición

Acciones

Proceso: Ingeniería de RequerimientosModelado del Sistema – Diagramas de Flujo de Datos (DFD)

Descripción dinámica Proviene de Metodología de Análisis y Diseño Estructurado

• fin de la década del 70.• Usados en versión original de OMT (Rumbaugh 91), no incorporados a UML.• Antes de los Casos de Uso era una de las formas más usadas para describir un

sistema. Elementos

• Proceso del sistema que recibe datos y genera otros.• Archivo de datos.• Flujo de Datos.• Entidad Externa al sistema a modelar (actor)

ProcesoDatos que entran

Archivo

Datos que salen

Proceso: Ingeniería de RequerimientosModelado del Sistema – Diagramas de Flujo de Datos (DFD)

Ejemplo:

Examen

Historia Clínica

Médico

Paciente

Experiencia yconocimiento

Síntomas Medicación y Diagnostico

Factura

Lista de exámenes yservicios brindados

Contabilidad

Registro Contable

Paciente

Proceso: Ingeniería de RequerimientosModelado del Sistema – Diagramas de Flujo de Datos (DFD)

Permite visualizar cómo fluye la información por el sistema.• Está asociado a una realización particular del sistema.

El diagrama no es suficiente para precisar el comportamiento:• por un flujo que entra a un proceso desde un archivo, ¿fluye un registro o

todo el archivo?.• No estipula sincronización, un flujo llega a una entidad externa y otro sale

¿Están relacionados? ¿Uno es respuesta del otro?. Se complementa con un diccionario de datos que describe:

• estructura de los flujos y otros detalles.• los procesos (lenguaje natural estructurado) con lo que el comportamiento

queda determinado. A menudo sistemas legados están documentados con DFD.

Proceso: Ingeniería de RequerimientosModelado del Sistema – Casos de Uso (UML)

Técnica para entender y describir requerimientos. Los casos de uso son requerimientos, describen requerimientos funcionales. Pone el acento en el uso del producto. Describen como el sistema debe comportarse desde el punto de vista del usuario. Casos de Uso como caja negra: Especifican que es lo que el sistema debe hacer sin especificar cómo debe hacerlo. Se describen mediante documentos de texto. Introducido por Ivar Jacobson (1992).

Proceso: Ingeniería de RequerimientosModelado del Sistema – Casos de Uso (UML)

Ejemplo:

Validar con PIN

Validar con Scaner de Retina

Validar Cliente

Retiro de Monedas

Retiro<<include>>

<<extend>>

Depósito

<<include>>Cliente

Transferencia

<<include>>

Actor:Entidad Externa que interactúa con el sistema (persona identificada por un rol o sistema externo).

Caso de Uso:Conjunto de escenarios posibles que puede encarar un actor (o varios) con el sistema para el logro de cierto objetivo.

Limite del Sistema

Caso de Uso Reutilizable <<include>>

Caso de Uso Escenario Variable <<extends>>

Generalización

Proceso: Ingeniería de RequerimientosModelado del Sistema – Elección de una Técnica

Ninguna técnica de especificación es completa. La elección de la técnica esta limitada por:

• Características del proyecto.• Preferencia de los desarrolladores.• Preferencias del cliente.

Por lo general se combinan varios enfoques, por ejemplo:• Una técnica para requerimientos funcionales.• Otra técnica para los requerimientos no funcionales.

Proceso: Ingeniería de RequerimientosTécnicas – Obtención y Análisis de Requerimientos

Estudio de factibilidad

Obtención y Análisis de

Requerimientos

Especificación de

Requerimientos

Validación de

Requerimientos

Informe de

factibilidad

Actividades

Especificación de

Requerimientos

Documento de

Requerimientos

Modelo del Sistema

Artefactos

Proceso: Ingeniería de RequerimientosTécnicas -Obtención y Análisis de requerimientos

Posibles conflictos:

Recur

sosTiempo

Alcance

CalidadBalancear

Necesidades

Expectativas

Necesidades

Expectativas

Tecno

logía Personas

Proceso

Restricciones

Proceso: Ingeniería de RequerimientosTécnicas -Obtención y Análisis de requerimientos

Técnicas :

Investigar antecedentes. Entrevistas individuales/grupales. Encuestas/Cuestionarios. Tormenta de ideas. Casos de Uso. Prototipado.

Proceso: Ingeniería de RequerimientosTécnicas -Obtención y Análisis de requerimientosInvestigar Antecedentes Estudio, muestreo, visitas,… Buena forma de comenzar un proyecto. Interna: Estructura de la organización, Políticas y procedimientos, Formularios e informes, Documentación de sistemas. Externa: Publicaciones de la industria y comercio, Encuentros profesionales, Visitas, Literatura y presentaciones de vendedores.

Ventajas Ahorra tiempo de otros. Prepara para otros enfoques. Puede llevarse a cabo fuera de la

organización.

DesventajasPerspectiva limitada.Desactualizado.Demasiado genérico.

Proceso: Ingeniería de RequerimientosTécnicas -Obtención y Análisis de requerimientosEntrevistas Individuales y Grupales

Usar para:• Entender el problema de negocio.• Entender el ambiente de operación.• Evitar omisión de requerimientos.• Mejorar las relaciones con el cliente.

Ventajas Orientación a las personas. Interactivo / Flexible. Rico.

DesventajasCostoso.Depende de las habilidades interpersonales.

Proceso: Ingeniería de RequerimientosTécnicas -Obtención y Análisis de requerimientosEncuesta / CuestionarioNo substituye la entrevista.Antes de usar el enfoque:

Determinar la información que se precisa. Desarrollar cuestionario. Probarlo con perfil típico. Analizar resultado de las pruebas.

Su principal uso es para validar asunciones y obtener datos estadísticos sobre preferencias.

Ventajas Conveniente para quien contesta. Respuestas anónimas.

DesventajasMenos Rico.Problemas por no Respuestas.Esfuerzo de desarrollo.

Proceso: Ingeniería de RequerimientosTécnicas -Obtención y Análisis de requerimientosTormenta de Ideas Objetivo: Lograr consenso sobre los requerimientos.

Ayuda a la participación de todos los involucrados.

Permite pensar en otras ideas.

Un secretario saca notas de todo lo discutido.

Reglas:• No se permite criticar ni debatir.• Dejar volar la imaginación.• Generar tantas ideas como sea posible.• Mutar y combinar ideas.

Proceso: Ingeniería de RequerimientosTécnicas -Obtención y Análisis de requerimientosCasos de Uso Formato simple y estructurado donde los usuarios y desarrolladores pueden trabajar juntos. No son de gran ayuda para identificar aspectos no funcionales. Mientras se definen los casos de uso, puede ser un buen momento para definir pantallas u otros objetos con los que el usuario interactúa. Pueden ser usados en el diseño y en el testing del sistema.

Usarlo Cuando el sistema está orientado a

la funcionalidad, con varios tipos de usuarios.

Cuando la implementación se va a hacer OO y con UML.

No son la mejor elección:Sistemas sin usuarios y con pocas interfaces.Sistemas dominados primariamente por requerimientos no funcionales y restricciones de diseño.

Implementación parcial, permite a los desarrolladores y usuarios:• Entender mejor los requerimientos.• Cuales son necesarios, deseables.• Acotar riesgos.

Prototipo desechable: El propósito es solo establecer que algo se puede hacer, luego se parte de cero en la construcción, quedando el conocimiento aprendido.

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

Aspectos para los que es frecuente construir prototipos:• Apariencia y percepción de la interfaz de usuario.• Arquitectura (riesgos técnológicos, tiempos de respuesta).• Otros aspectos riesgosos.

Proceso: Ingeniería de RequerimientosTécnicas -Obtención y Análisis de requerimientosPrototipado

Proceso: Ingeniería de RequerimientosTécnicas – Validación de Requerimientos.

Estudio de factibilidad

Obtención y Análisis de

Requerimientos

Especificación de

Requerimientos

Validación de

Requerimientos

Informe de

factibilidad

Actividades

Especificación de

Requerimientos

Documento de

Requerimientos

Modelo del Sistema

Artefactos

Proceso: Ingeniería de RequerimientosTécnicas – Validación de Requerimientos.

La validación incluye dos pasos:

Asegurar que cada especificación pueda ser rastreada hasta su requerimiento en el documento de definición.

Luego se chequea la definición para ver si cada requerimiento es rastreable hasta la especificación.

Es importante recordar, que la validación no es tan solo un rastreo de traza. Ya que, además, pretende garantizar que el sistema hará lo que los clientes y usuarios esperan. Validando que las metas e intenciones de los usuarios y clientes están satisfechas.

Una forma simple de validar los requerimientos es la realización de reuniones de revisión.

Proceso: Ingeniería de RequerimientosTécnicas – Validación de RequerimientosRevisiones de Requerimientos

Participan representantes del cliente: operadores, quienes realicen entradas, utilicen salidas, y sus gerentes. del equipo de desarrollo: analistas de requerimientos, diseñadores, encargados de

pruebas y gestión de configuración.

Incluye:• Revisar objetivos del sistema.• Evaluar alineamiento de requerimientos con los objetivos (necesidad).• Revisar el ambiente de operación y las interfaces con otros sistemas.• Funciones completas, restricciones realistas.• Evaluar riesgos.• Considerar:

o Pruebas del sistema.o Cambios en los requerimientos en el proyecto, su verificación y validación.

Medición de Requerimientos

La medición de requerimientos está enfoca a tres áreas: Producto, Proceso y Recursos.

Los productos de los requerimientos (definición y especificación) pueden ser evaluados en primer lugar considerando el número de requerimientos.

De manera similar se puede medir la cantidad de cambios introducidos a los requerimientos. Un gran número de cambios indica cierta inestabilidad o incertidumbre en la comprensión de lo que el sistema debe hacer o como comportarse.

También es bueno evaluar la incertidumbre por tipo de requerimiento. Esto permite seccionar.

Medición de Requerimientos

Debido a que los requerimientos son utilizados por los diseñadores y verificadores, pueden utilizarse medidas que reflejen cuando los requerimientos están preparados para derivar a ellos.

Existe un forma de evaluación utilizada para verificadores y diseñadores, donde califican los requerimientos en una escala de 1 a 5 para saber si estos están listos.

La escala es la siguiente:

1. Lo comprende por completo, ha diseñado (verificado) requerimiento similar antes y no debería tener problema.2. El requerimiento posee algún elemento que le resulta nuevo, pero no es radicalmente distinto de lo que ha diseñado (verificado) con éxito antes.

Medición de Requerimientos

3. Hay elementos nuevos que lo hacen muy diferente de los que ha diseñado (verificado) antes, pero los comprende y piensa que a partir de ellos puede desarrollar un buen diseño (prueba).4. Hay partes del requerimiento que no entiende bien y no está seguro de poder desarrollar un buen diseño (prueba).5. No comprende este requerimiento en absoluto y no puede desarrollar un diseño (prueba) para él.

Si un verificador o diseñador entrega un perfil con mayoría de 1 y 2 entonces el requerimiento esta en forma y puede pasar al equipo de diseño o verificación.

A

B

1 2 3 4 5

Diseñadores Verificadores

1 2 3 4 5

1 2 3 4 5 1 2 3 4 5

OK

• Los requisitos de un software suelen ser una combinación compleja de los requisitos de diferentes personas en diferentes niveles de una organización y del entorno en el cual operará el software.

• Es fundamental que un requisito sea verificable. • Otros atributos que les caracterizan son: Prioridad Identificador único. • Los requisitos deben ser lo más claros y no ambiguos que se pueda, y cuantificables (si es posible).

Características

• Posibles Problemas con los Requisitos:o No reflejan las necesidades reales del cliente o Son inconsistentes y/o incompletoso Es costoso realizar cambios sobre los requisitos una

vez que han sido acordadoso Puede haber malentendidos entre clientes,

analistas, ingenieros software,

Dificultades

Dificultades - Posibles Problemas con los Requisitos:

Dificultades Es frecuente que no esté clara la frontera entre Requisitos y

Diseño. En principio, los requisitos indican lo que el sistema debe hacer y

el diseño describe cómo lo hace. En la práctica, ambas etapas son inseparables porque:

o La arquitectura del sistema puede ser diseñada para estructurar los requisitos.

o El sistema interacciona con otros sistemas que generan requisitos de diseño del software.

o El uso de un diseño específico puede ser un requisito de dominio.

Principios de la ingeniería de requisitos

• Hacer que los requisitos alcancen un estado óptimo antes de

alcanzar la fase de diseño en el proyecto

• Lo buenos requisitos deben ser medibles, comprobables, sin

ambigüedades o contradicciones, etc.

¿Quién hace la Ingeniería de Requisitos?

• Los Ingenieros de Software (Ingenieros de Sistemas o Analistas de Sistemas) y los

interesados (gerentes, clientes, usuarios finales).

• El diseño y la construcción de un elegante programa de computadora que resuelva el

problema incorrecto no satisface las necesidades de nadie. Por lo tanto, es muy

importante entender lo que el cliente quiere antes de comenzar a diseñar y construir

un sistema basado en PC.

IMPORTANCIA DE LA INGENIERÍA DE REQUERIMIENTOS?

¿Qué debe hacer el ingeniero de Requisitos?Punto de inicio

Noción de existencia de un “problema” que debe ser resuelto, ej:

Insatisfacción con estado corriente del sistema/negocioOportunidad del negocioPotencial ahorro de tiempo, recursos, costos, etc.…

Un ingeniero de requisitos es un agente de cambio

El ingeniero de requisitos debe:Identificar el problema/oportunidad

¿Cual es el problema que se debe resolver? (Identificar los límites) ¿En donde se debe resolver (Comprender el contexto)¿De quien es el problema ? (Identificar los stakeholders)¿Por qué necesita ser resuelto? (Identificar los objetivos de los stakeholders)¿Cómo podría ayudar un S.S. ( Plantear escenarios)¿Cuando necesita resolverse? (Identificar restricciones de desarrollo)¿Que podría evitar que lo resolvamos? (Identificar riesgos y viabilidad)

Y hacerse experto del dominio

PASOS PARA HACER INGENIERÍA DE REQUERMIENTOS

Inicio

Obtención

Elaboración

NegociaciónEspecificación

Validación

Gestión

Inicio.- Se define al ámbito y la naturaleza del problema que debe resolverse

Obtención .- Ayuda al cliente a definir sus necesidades. QFD

Elaboración.- Se refinen y modifican los requisitos básicos

Negociación .- Se definen las prioridades, cuales aspectos son esenciales y en qué

momento se requieren

Especificación.- Puede ser un documento escrito, modelos gráficos, matemáticos,

etc.

Validación.- Examinar existencia, omisiones y ambigüedades

Gestión.- Identificar, controlar y rastrear los requisitos y los cambios de éstos en el

proyecto

Definir 10 requerimientos necesarios para el desarrollo del problema planteado.

Ejercicio

Los roles pueden clasificarse de la siguiente manera:

Personal involucrado

Usuario Líder

Personal de mantenimiento

Usuario finalAnalistas y programadores

Personal de pruebas

Administradores de

proyectos, diseñadores de base de datos, etc

Usuario Final. Es la persona que usará el sistema desarrollado. Será quien utilice, disponga y se encuentre familiarizado con los procesos que debe realizar el software; así también, es el que utiliza las interfaces y los manuales de usuario.

Usuario Líder. Es el individuo que comprende el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado.

Personal de Mantenimiento. Para proyectos que requieran un mantenimiento eventual, éstas personas son las responsables de la administración de cambios, de la implementación y resolución de anomalías. Su trabajo consiste en revisar y mejorar los procesos del producto finalizado.

Personal Involucrado

Analistas y programadores. Son los responsables del desarrollo del producto, en sí ellos interactúan directamente con el cliente.

Personal de pruebas. Se encarga de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes validan si los requerimientos satisfacen las necesidades del cliente.

Personal Involucrado

Mostrar una tabla con la cantidad de personal requerido para el desarrollo y solución del problema planteado.

Ejercicio

Tipo de personal Cantidad Justificación

A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades mostradas en la tabla anterior, podemos identificar y extraer cinco actividades principales que son:

Análisis del problema

Evaluación y negociación

Especificación

ValidaciónEvolución

ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS

• El objetivo de esta actividad es entender las verdaderas necesidades del negocio para el cual se hará el proyecto.

• Durante el análisis del problema, se realiza una serie de pasos para garantizar un acuerdo entre los involucrados, basados en los problemas reales del negocio, los pasos serian los siguientes:

• Comprender el problema que se está resolviendo• Construir un vocabulario común• Identificar a los afectados del sistema• Definir los límites y restricciones del sistema

1. ANÁLISIS DEL PROBLEMA

• Redactar el problema planteado.

• Elaborar el vocabulario común.

• Identificar los afectados del sistema.

• Definir los límites y restricciones del problema a solucionar.

PARA PROYECTO

Las principales actividades son:• Descubrir problemas potenciales.• Clasificar los requerimientos – (Prioridad de cada requerimiento

dependerá de las necesidades que tenga el negocio)Busca identificar la importancia que tiene un requerimiento en términos de implementación.

• Mandatario• Deseable (se necesitan pero no son indispensables)• Innecesario

Una vez hecha esta categorización de los requerimientos, puedo tomar como estrategia general el incluir los mandatorios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusión de un requerimiento, también debe analizarse su costo, complejidad, y una cantidad de otros factores.

2. EVALUACIÓN Y NEGOCIACIÓN DE REQUERIMIENTOS

Las principales actividades son:

• Evaluar factibilidades y riesgos• Factibilidades técnicas• Factibilidades operacionales• Factibilidades económicas

Factibilidades técnicas (¿pueden implementarse los requerimientos con la tecnología actual?);

Factibilidades operacionales (¿puede ser el sistema utilizado sin alterar el organigrama actual?); Factibilidades económicas (¿ha sido aprobado por los clientes el presupuesto?).

Incremento en la comunicación entre el equipo de desarrollo y los afectados. Para una comunicación efectiva, hay una serie de consideraciones a tener en cuenta:

Documentar todos los requerimientos a un nivel de detalle apropiado.

Mostrar todos los requerimientos a los involucrados en el sistema.

Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos.

Establecer las relaciones entre requerimientos que indiquen dependencias.

Negociar con flexibilidad para que exista un beneficio mutuo. Enfocarse en intereses y no en posiciones.

• Entregar documento en donde se enlisten los requerimientos del sistema planteando los puntos vistos anteriormente, dicho documento será la carta de presentación de los equipos.

• Exponer ante los compañeros los requerimientos fundamentales para llevar a buen término la solución del problema a plantear. (tiempo de exposición max. 10 minutos)

EJERCICIO.

• Es la actividad en que se genera el documento y contiene una descripción completa de las necesidades y funcionalidades del sistema, que será desarrollado; describe el alcance del sistema y la forma como hará sus funciones, definiendo los requerimientos.

• En la especificación se definen: • Todos los requerimientos de hardware• Todos los requerimientos de software• Diagramas• Modelos de sistemas y cualquier otra cosa que sirva de soporte y guía

para fases posteriores.

3. ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE.

Los clientes y usuarios utilizan la SRS para comparar si lo que se está proponiendo, coincide con las necesidades de la empresa.

Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse.

El personal de pruebas elaborará las pruebas funcionales y de sistemas en base a este documento.

Para el administrador del proyecto sirve como referencia y control de la evolución del sistema.

• Permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente, además revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes.

• La validación de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado

4. VALIDACIÓN DE LOS REQUISITOS

No debe confundirse la actividad de evaluación de requerimientos con la validación de requerimientos. La evaluación verifica las propiedades de cada requerimiento, mientras que la validación revisa el cumplimiento de las características de la especificación de requisitos.

Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se desean revisar. A continuación se presentan varios ejemplos:

• ¿Están incluidas todas las funciones requeridas por el cliente? (completa)• ¿Existen conflictos en los requerimientos? (consistencia)• ¿Tiene alguno de los requerimientos más de una interpretación? (no

ambigua)• ¿Está cada requerimiento claramente representado? (entendible)• ¿Pueden los requerimientos ser implementados con la tecnología y el

presupuesto disponible? (factible)• ¿Está la SRS escrita en un lenguaje apropiado? (clara)• ¿Existe facilidad para hacer cambios en los requerimientos? (modificable)• ¿Está claramente definido el origen de cada requisito? (rastreable)• ¿Pueden los requerimientos ser sometidos a medidas cuantitativas?

(verificable)

• Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas.

• Porque cambió el problema que se estaba resolviendo.• Porque los usuarios cambiaron su forma de pensar o sus

percepciones.• Porque cambió el ambiente del negocio.

5. EVOLUCIÓN DE LOS REQUERIMIENTOS

La actividad de evolución es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto.

Los requerimientos cambian por diferentes razones:

Las actividades del proceso incluyen :• Extracción de requerimientos• Análisis del problema• Especificación• Validación • Evolución