Ingeniería de Requerimientos Judith Meles 1 Universidad Tecnológica Nacional Facultad Regional...

Ingeniería de RequerimientosIngeniería de Requerimientos Judith MelesJudith Meles 11

Universidad Tecnológica NacionalUniversidad Tecnológica NacionalFacultad Regional CórdobaFacultad Regional CórdobaCátedra de Análisis de SistemasCátedra de Análisis de Sistemas

Seminario de Actualización DocenteSeminario de Actualización Docente

Tema: Ingeniería de Requerimientos Tema: Ingeniería de Requerimientos

Disertante: Ing. Judith MelesDisertante: Ing. Judith Meles

Abril de 2001Abril de 2001


1) Lo que el usuario necesita

3) Lo que le transmitió al profesional

2) Lo que el usuario creecree necesitar

El Problema de los Requerimientos


4) Lo que el profesional entendió

6) Lo que al final resultó

5) Lo que se entregó al principio

El Problema de los Requerimientos


Introducción

La efectividad y flexibilidad de un sistema está

extrechamente relacionada a la correcta

comprensión de las necesidades de los clientes

y/o usuarios del sistema, hay un componente clave

en todo proceso de desarrollo , que juega un papel

central, llamado....

ESPECIFICACIÓN DE REQUERIMIENTOS


¿ Qué es un Requerimiento?(Definición IEEE-Std-610 - 1990)

Condición o capacidad que necesita el usuario para

resolver un problema o alcanzar un objetivo.

Condición o capacidad que debe satisfacer o

poseer un sistema o un componente de un sistema

para satisfacer un contrato, un standard, una

especificación u otro documento formalmente

impuesto.

Representación documentada de una condición o

capacidad como las expresadas anteriormente.


Requerimientos: Categorías

En general, caen en dos grandes categorías:

orientado al mercado

específico para un cliente


RequerimientosOrientados al Mercado

Bocetados e informales

Técnicas más de manufactura que de Ingeniería de Software

Especificación en forma de presentación comercial

“Cliente” no fácilmente identificable

Se basan en Consultores para aspectos deseables

Enfoque poco estructurado.


Requerimientos Específicos para un cliente

Voluminosos y más “formales”

Uso de técnicas de Ingeniería de Software

Largas especificaciones

Uso del conocimiento del dominio

Proyectos basados en personal propio

Método estructurado siguiendo un enfoque particular


Requerimientos: Una Perspectiva Organizacional

La contribución de los SI a las organizaciones

Automatizar reduciendo costos de proceso Informar a los tomadores de decisiones Transformar la organización

Prerequisitos Visión del negocio y la organización Alineación de los SI con la estrategia

corporativa

El desarrollo de los SI tiene que ver con: Necesidades de los involucrados Requerimientos del usuario y estrategia de

negocios


De la automatización de la rutina a los procesos críticos

La especificación de requerimientos debe atender a:

mejorar la gestión del cambio integrar visiones dentro de la empresa vincular la estrategia empresaria con los SI

ER como camino para gerenciar el cambio: comprensión conceptual del status actual definición del cambio implementación del cambio integración de esta nueva implementación


Requerimientos: Una Perspectiva del Software

Los errores en la definición de requerimientos resulta en un mantenimiento costo de los sistemas de software.

Surge la Ingeniería de Requerimientos como un sub-campo de la Ingeniería de Software


Importancia de los requerimientos

PremisaHacer un mejor trabajo definiendo y

especificando software no sólo vale la pena sino que tambien es posible y ventajoso en costo

Soporte:Cuanto más tarde en el ciclo de vida se detecta un error, más cuesta repararloMuchos errores permanecen latentes y no son detectados hasta bastante después de la etapa en que se cometieronLos errores de requerimientos son comúnmente: hechos, incorrectos, omisiones, inconsistencias y ambigüedadesLos errores en los requerimientos pueden detectarse


errores corregibles

errores nocorregibles

funcionescorrectas

erroresocultos

especificacióncorrecta

especificaciónincorrecta

diseñocorrecto

diseño basado en especificación

incorrecta

diseñoincorrecto

Especificación deRequerimientos

Diseño

Implementación

Testing

PROBLEMA REAL

programas basados en diseñoincorrecto

programascorrectos

errores de programación

programas basadosespecificación

incorrecta

Diseño correcto

Errores corregibles

Catarata de Errores de Mizuno


Impacto de los errores en la etapa de requerimientos

El software resultante puede no satisfacer a los usuarios

Las interpretaciones múltiples de los requerimientos pueden causar desacuerdos entre clientes y desarrolladores

Es imposible que a través del testeo el software satisfaga sus requerimientos

Puede gastarse tiempo y dinero construyendo el sistema erróneo


Evolución de Requerimientos

Comprensión Comprensión inicial del inicial del problemaproblema

Comprensión Comprensión inicial del inicial del problemaproblema

Cambios en la Cambios en la comprensión del comprensión del

problemaproblema

Cambios en la Cambios en la comprensión del comprensión del

problemaproblema

Requerimientos Requerimientos inicialesiniciales

Requerimientos Requerimientos inicialesiniciales

Requerimientos Requerimientos CambiadosCambiados

Requerimientos Requerimientos CambiadosCambiados

Tiempo Tiempo


Clases de Requerimientos

Requerimientos Durables: son relativamente estables, derivan de las actividades centrales del negocio, los cuales se relacionan directamente con el dominio del sistema.

Requerimientos Volátiles: son aquellos que tienen probabilidad de cambiar durante el desarrollo del sistema o después que el sistema se haya puesto en producción.


Clasificación de Requerimientos Volátiles

Mutables: los requerimientos cambian debido al entorno en el cual la organización opera.

Emergentes: surgen con la comprensión de los clientes del sistema, durante su desarrollo. El diseño puede relevar nuevos requerimientos.

Consecuentes: resultan de la introducción del sistema de computación, cambiando los procesos del negocio y abriendo nuevas formas de trabajo que generan nuevos requerimientos

De Compatibilidad: dependen de un sistema o proceso en particular dentro del negocio, si cambian, los requerimientos relacionados deberán cambiar.


Especificación de Requerimientos

La documentación de Requerimientos para la construcción de Software es la actividad que tradicionalmente se ha llamado Especificación de Requerimientos.

La Especificación de Requerimientos representa ambos: un modelo de lo que se necesita y una definición del problema bajo consideración.



Focaliza el proceso comunicacional en la comprensión a cerca del dominio, el negocio y el sistema propuesto.

Puede ser parte de un arreglo contractual.

Puede usarse para la evaluación del producto final, y tener unrol crucial en las pruebas de aceptación del sistema.

Razones para esforzarse en su desarrollo....



Una nueva visión para su desarrollo...

Especificación de

Requerimientos

Requerimientos Funcionales

Requerimientos Empresariales

Requerimientos No Funcionales

Evaluación


Requerimientos Funcionales

Relacionados con la descripción del comportamiento fundamental de los componentes del software.

Las funciones son especificacdas en términos de entradas, procesos y salidas.

Una vista dinámica podría considerar aspectos como el con trol, el tiempo de las funciones (de comienzo a fin) y su comportamiento en situaciones excepcionales.



Juegan un papel crucial en el diseño y desarrollo del sistema de información.

Pueden definirse como consideraciones o restricciones asociadas a un servicio del sistema.

Sueles llamerse también requerimientos de calidad o no comportamentales en contraste con los comportamentales.

Pueden ser tan críticos con los funcionales.


Dificultades asociadas a los Requerimientos No Funcionales

No hay reglas ni lineamientos para determinar cuando se obtuvo una solución óptima.

Tiene buenas y malas soluciones, no soluciones correctas e incorrectas

Problemas relacionados con requerimientos no funcionales pueden ser síntomas de problemas mayores.

Hay dos atributos que deben poseer: deben ser objetivos y testeables.


Requerimientos No Funcionales: Tipos

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements


Requerimientos del Producto

Requerimientos Organizacionales

Requerimientos Externos

Requerimientos Legales

Requerimientos de Estándares

Requerimientos de Entrega

Requerimientos de Entrega

Requerimientos de Usabilidad

Requerimientos de Seguridad

Requerimientos de Privacidad

Requerimientos De Espacio

Requerimientos De Performance

Requerimientos Eticos

Requerimientos de Portabilidad

Requerimientos Interoperatibidad

Requerimientos de Confiabilidad

Requerimientos de Eficiencia


Ingeniería de Requerimientos

“Es el proceso sistemático de desarrollar requerimientos a través de un proceso cooperativo e iterativo de analizar el problema, documentar las

observaciones resultantes en una variedad de formatos de representación

y chequear la precisión de la comprensión obtenida”


Características del proceso

Representación, aspecto social y aspecto cognitivo

De una formulación informal a una especificación formal

Proceso no determinístico y no lineal

Elicitar, especificar y validar requerimientos, no son actividades predominantemente técnicas

Típica actividad de resolución de problemas.


Aspectos principales de la Ingeniería de Requerimientos

Comprender el problema

Describir el problema

Acordar sobre la naturaleza del problema


Validación Especificación

Elicitación

RASTREABILIDAD HACIA DELANTE Y HACIA ATRASRASTREABILIDAD HACIA DELANTE Y HACIA ATRAS

Propuesta de la Ingeniería de Requerimientos


ElicitaciónElicitación Especificación

Especificación

ValidaciónValidación

UsuarioUsuario

Dominio del

Problema

Dominio del

Problema

Feedback del usuario

Requerimientos del usuario

Modelos a

validar por el usuario


Modelos de Requerimientos

Conocimiento

Necesidad de más conocimiento

Resultados de la validación

Conocimiento del dominio

Conocimiento del dominio

Interacción entre Procesos de la Ingeniería de Requerimientos


Productos entregables

Modelos ...

Del dominio del problema

De los requerimientos funcionales

De los requerimientos no funcionales


Elicitación: Propósito

Ganar conocimiento relevante del problema, para producir una especificación rigurosa del software necesario para resolver el problema.

Al final del proceso el analista podría ser un “experto” en el dominio del

problema.


Elicitación: Entradas

Fuentes del conocimiento del dominio:

• Expertos del dominio

• Literatura sobre el dominio

• Software existente en el dominio

• Software similar en otros dominios

• Standards nacionales e internacionales

• Otros “involucrados”


Elicitación: Actividades

Tareas a encarar por el analista:

• Identificar fuentes de conocimiento

• Adquirir el conocimiento

• Decidir sobre la relevancia de un conocimiento

• Comprender la significación del conocimiento y su impacto


Elicitación: Actividades

Técnicas más usadas :

Entrevistas Torbellino de Ideas Escenarios Reuso de conocimiento Análisis de Documentación Observación Análisis de Objetivo / Meta


Elicitación: Productos

Es un proceso de creación de modelos

El analista comienza con modelos

mentales con conocimiento dependiente del domino

Al avanzar, los modelos son más orientados al software

No se produce ningún modelo formal

Sucesión de modelos mentales del dominio del problema


Especificación: Propósito

Acuerdo usuarios-desarrolladores sobre el problema a resolver

Pauta para el desarrollo de un sistema de software


Especificación: Entradas

Conocimiento sobre el dominio del problema

Lo provee el proceso de elicitación


Especificación: Actividades

Análisis y asimilación del conocimiento de los requerimientos

Síntesis y organización del conocimiento en un modelo de requerimientos coherente y lógico


Especificación: Productos

Se producen una variedad de modelos:

modelos orientados al usuario, que especifican comportamiento, características no funcionales, etc.

modelos orientados al desarrollador, que especifican propiedades funcionales y no funcionales del software y restricciones


El Problema...

A partir del Modelo de requerimientos se puede establecer que no contiene definiciones contradictorias, pero...

Un modelo correcto de requerimientos no es necesariamente el modelo de requerimientos correcto.

No existen los REQUERIMIENTOS de los requerimientos

El peligro está en hacer el esfuerzo de analizar el problema erróneo.


Causas de los errores

Dificultades en la elicitación de los requerimientos del usuario.

Dificultad en establecer un esquema de comprensión común entre analista y usuario.


Validación: Propósito

Certifica la consistencia del modelo (de requerimientos) con las intensiones de clientes y usuarios

Ayuda a hacer el artefacto correcto

La necesidad aparece cuando se modifica el modelo actual

Se aplica también a los modelos intermedios


Validación: Entradas

Todo modelo está sujeto a validación,

por lo tanto cada modelo es input

El conocimiento sobre el dominio del problema debe ser validado

Algunas partes del modelo formal


Validación: Actividades

Interacción entre analistas, clientes del sistema y usuarios en el dominio del problema.

Similar a formular una nueva teoría científica y posteriormente testearla

Caracterizada por:

preparación del experimento

ejecución del experimento y análisis de los resultados


Validación: Técnicas

Prototipos

Animación

Enfoque de Sistemas Expertos


Prototipos

Proceso de construcción y evaluación de modelos de trabajo de un sistema para aprender de ciertos aspectos del sistema requerido y/o su solución potencial. Técnica común de la ingeniería.En Ingeniería de Software: es el paradigma de producir software tan rápido y económicamente como sea posible en alguna etapa del desarrollo.Un modelo es considerado un prototipo si:

es posible obtener información sobre el comportamiento y performance del sistema que se “prototipea”

construir el prototipo debería ser un proceso rápido


Tipos de prototipos

Prototipo de comportamiento, es un modelo en caja negra del sistema que muestra como responde a los estímulos. En un modelo funcionalPrototipo estructural, muestra como el sistema “prototipeado” cumplirá con este comportamiento. Es un modelo de caja de cristal que muestra la estructura interna y la organización del sistema. Modela los requerimientos no funcionales


Animación

Visión gráfica múltiple de un proceso en acción.Se representan gráficamente los principales objetos y se interactúa con ellos (tiempo real)En el contexto de desarrollo de IS es un enfoque que provee un ambiente visual para validar y ejecutar simbólicamente especificaciones conceptuales (en términos de modelos de entidades, reglas y procesos) de un IS.

“En el contexto de especificaciones conceptuales, visualización involucra la animación del comportamiento de un sistema y una interfase visual que refleja los resultados de eventos bajo la componente gráfica -cuando es apropiado la textual- de la especificación”


Animación: Características

Ventaja sobre prototipos: no impone decisiones de diseño muy tempranas

Provee una indicación de la dinámica del sistema mediante una recorrida

Permite determinar relaciones causales escondidas en la especificación


Enfoque de sistemas expertos

Algunas herramientas CASE reciben el calificativo de sistemas expertos por el conocimientos de algunos aspectos del proceso que ellos corporizan. Este puede ser:

conocimiento del método, conocimiento de cómo aplicar un método de RE

conocimiento del dominio, conocimiento sobre el dominio el cual se supone se modeló


Modos de acción de un Sistema Experto

Comportamiento de un sistema experto en RV

expertoexperto, lleva a cabo el proceso de validación,

asistenteasistente, asiste al analista en la validación

aprendizaprendiz, ejecutar las actividades de bajo nivel de la validación


Validación: Salidas

Modelo de requerimientos en línea con las expectativas de los usuarios

No significa que el modelo sea correcto

Compromiso entre lo deseado y lo posible y factible


ValidaciónInteracción con otros procesos

•LLa validación está presente en todos los procesos de la IR, la dispara:

nuevo conocimiento sobre el dominio del problema (elicitación)

formulación de un modelo de requerimientos (especificación)

La validación se requiere en las etapas de análisis y síntesis (pues debe chequearse la corrección de la información)


Verificabilidad de los Requerimientos

Los requerimientos deberían ser escritos de manera tal que puedan ser objetivamente verificables.

El problema con el requerimientos es el uso de términos vagos.

El ratio de errores debería ser cuantificado.


Medidas de los Requerimientos

PropiedadPropiedad MedidaMedida

VelocidadVelocidad • Transacciones / Segundo Procecesadas• Tiempo de Respuesta de Evento / Usuario• Tiempo de barrido de la pantalla

TamañoTamaño • K Bytes• Número de chips de RAM

Facilidad de UsoFacilidad de Uso • Tiempo de capacitación• Número de entornos de ayuda

ConfiabilidadConfiabilidad • Tiempo medio entre fallas• Probabilidad de indisponibilidad• Ratio de Ocurrencia de Fallas• Disponibilidad

RobustezRobustez • Tiempo de reinicio después de fallas• Porcentaje de Eventos que causan fallas• Probabilidad de corrupción de datos durante una falla.

PortabilidadPortabilidad • Número de Sistemas destino• Porcentaje de definiciones dependientes del destino


Propiedades Deseables para la Especificaicón de Requerimientos

Consistencia Interna

No ambigüedad

Consistencia Externa

Minimalidad

Completitud

Rastreabilidad


Indice del Standard de IEEE para la Especificación de Req. de

Software 1. Introducción

1.1. Propósito1.2. Alcance1.3. Definiciones, acrónimos y abreviaturas1.4. Referencias1.5. Overview

2. Descripción general2.1. Perspectiva del producto2.2. Funciones del producto2.3. Características del usuario2.4. Restricciones generales2.5. Supuestos y dependencias

3. Requerimientos específicosApéndices


1.Introducción

1.1. Propósito Delinear el propósito de la SRS y especificar a quién

se dirige

1.2. Alcance Identificar los productos de SW, explicar que hará y

que no hará cada uno, describir la aplicación1.3. Definiciones, acrónimos y abreviaturas Incluir las definiciones de los términos, acrónimos y

abreviaturas requeridas para interpretar la SRS. 1.4. Referencias Proveer una lista completa de todos los documentos

referenciados1.5. Overview Describir qué contiene el resto de la SRS y explicar

cómo está organizada la SRS


2.Descripción General

Describe los factores generales que afectan al producto y a los requerimientos, facilita su comprensión

2.1. Perspectiva del producto – Relación con otros productos o proyectos– Productos independientes– Componentes de un sistema o de un proyecto:– Hardware y equipamiento periférico– Diagrama de bloques– Restricciones de diseño

2.2. Funciones del producto– Resumen de las funciones que ejecutará el software.– Comprensibilidad– Diagrama de bloques– No establece requerimientos específicos,


2.Descripción General - II

2.3. Características del usuario– Características generales del usuario– Restricciones impuestas por los interactuantes– Requerimientos específicos o restricciones sobre la

solución

2.4. Restricciones generales– Límites al desarrollador– Requerimientos específicos o restricciones sobre la

solución

2.5. Supuestos y dependencias– Factores que afectan los requerimientos – Restricciones de diseño – Cambios quepueden afectar los requerimientos en la SRS.


Descripción General - III

2.4. Restricciones generalesLímites a las opciones para diseñar el sistema:

• Políticas regulatorias• Limitaciones de hardware• Interfases con otras aplicaciones• Operaciones paralelas• Funciones de auditoría• Funciones de control• Requerimientos de lenguajes de alto nivel• Protocolos de “signal handshake” (ej: XON/XOFF)• Criticalidad de la aplicación• Consideraciones de seguridad (Safety and Security)


3.Requerimientos específicos

El sector mayor y más importante de la SRS

Presentación y conceptualización del desarrollo de los requerimientos

El contexto de la ingeniería de requerimientos.


Requerimientos específicos - I

3.1. Requerimientos funcionales3.1.1. Requerimientos funcionales 1

3.1.1.1.Introducción3.1.1.2.Inputs3.1.1.3.Procesos3.1.1.4.Outputs

.....3.1.n. Requerimientos funcionales n

3.2. Requerimientos de interfase externa3.2.1. Interfases del usuario3.2.2. Interfases del hardware3.2.3. Interfases del software3.2.4. Interfases de comunicaciones

3.3. Requerimientos de performance3.4. Restricciones de diseño

3.4.1. Cumplimiento de standards3.4.2. Limitaciones de Hardware....


Requerimientos específicos - II

3.5. Atributos3.5.1. Disponibilidad3.5.2. Seguridad3.5.3. Mantenibilidad3.5.4. Transferibilidad/conversión...

3.6. Otros requerimientos3.6.1. Base de Datos3.6.2. Operaciones3.6.3. Adaptación del lugar


Bibliografía

Loucopoulos, P., Karakostas, V., System Requirements Engineering, McGraw-Hill, 1995, London.

Sommerville, Ian, Software Engineering 5Th Edition, Addison Wesley, 1995

Ingeniería de Requerimientos Judith Meles 1 Universidad Tecnológica Nacional Facultad Regional...

Documents

Transcript of Ingeniería de Requerimientos Judith Meles 1 Universidad Tecnológica Nacional Facultad Regional...