Resumen preparado por Miguel CotañaLa Paz, julio 20201

INGENIERIA DE REQUISITOS

2

ESTO DEBEMOS

CAMBIAR !!!

IR como base del éxito en el desarrollo de software

La comprensión de los requisitos de un

problema está entre las tareas más

difíciles que enfrenta el IS.

La IR ayuda a los IS a entender mejor el

problema.

Incluye el conjunto de tareas que

conducen a comprender cuál será el

impacto del software, qué es lo que el

cliente quiere y cómo interactuarán los

usuarios finales con el software.3

De acuerdo con la IEEE Std. 610.12-1990:

“Una condición o capacidad quedebe ser cumplida, o poseída por unsistema o componente de sistema,para satisfacer un contrato,estándar, especificación, u otrosdocumentos impuesto formalmente”

Qué es un Requisito ?

4

Propiedades de los buenos requisitos

5

Posibles: Cada requisito debe poderimplementarse dentro de las capacidades ylimitaciones conocidas del sistema y su entorno.El líder del proyecto deberá comprobar laviabilidad de los requisitos antes de comprobar eldocumento.

Necesarios: Un requisito es necesario si es algo:▪ Que el cliente realmente necesita;▪ Requerido para la conformidad con un

requisito;▪ Requerido para la conformidad con un

interfaz, externo o estándar.

6

Priorizados: Normalmente todos los requisitosde un producto de software no son igual deimportantes. Algunos resultan esenciales, yotros son deseables.

Cada requisito debe identificar estas diferencias:

▪ Los clientes tengan una consideración másadecuada de cada requisito;

▪ Que los desarrolladores tomen decisiones dediseño correctas y dediquen niveles deesfuerzo apropiado;

▪ Que el gestor del proyecto pueda establecerprioridades de ejecución.

7

Concreto: Un requisito es concreto si tiene unaúnica interpretación. Como mínimo esto requiereque cada característica del producto final sedescriba empleando un término único.

Ambigüedad

Puntoóptimo

Co

mp

ren

sió

n

Evitar la ambigüedad:▪Inspecciones formales delos documentos derequisitos.▪Escritura de casos deprueba▪Elaboración de casos deuso.▪Elaboración de diagramas.

8

Verificable: Un requisito es verificable sí, y sólosí a través de un proceso concreto y finito esposible comprobar si el software lo cumple. Engeneral los requisitos ambiguos no sonverificables.

Los requisitos no verificables incluyen sentenciascomo “que trabaje eficientemente”,”interfaz deusuario amigable”, “debe responderrápidamente”. Estos requisitos no son verificablesporque no es posible definir los términos“amigable”, “rápido”. La sentencia “el programano debe entrar nunca en un bucle infinito”tampoco es verificable porque un nivel depruebas absoluto es teóricamente imposible.

9

Ejemplo de requisito verificable:

“El tiempo de respuesta para la compra de unproducto, no debe superar los 2 segundos el 90%de las veces, y una transacción de compra de unproducto nunca debe tardar más de 5 segundos.”

Esta sentencia es verificable porque empleatérminos concretos y magnitudes medibles ycomprobables.

Si no es posible establecer un método paracomprobar si el software cumple con undeterminado requisito, el requisito debeeliminarse o revisarse.

10

Beneficios de los requisitos

▪Acuerdo entre desarrolladores, clientes yusuarios sobre el trabajo que debe realizarse:

Unos requisitos bien elaborados y validados conel cliente evitan descubrir al terminar elproyecto que el sistema no era lo que se pedía.

▪Acuerdo entre desarrolladores, clientes yusuarios sobre los criterios de validación:

Resulta muy difícil demostrar al cliente que elproducto desarrollado hace lo que el pidió si supetición no está documentada y validada por él

▪Base objetiva para la estimación de recursosSi los requisitos no comprenden necesidadesreales, las estimaciones no dejan de ser merasapuestas;

Ingeniería de Requisitos (IR):Consiste en un uso sistemático yrepetitivo de técnicas que abarcan lasactividades de desarrollo de software,con el fin de que estos cumplan con losobjetivos de negocio y sean de calidad.

Especificación de RequisitosSoftware (ERS): Documento formalde los requisitos del sistema.

Definición

11

Según el estándar IEEE-830 losrequisitos deben ser:

✓ Correctos;✓ Consistentes;✓ Completos;✓ Realistas;✓ Necesarios;✓ Verificables;✓ Rastreables.

Características de los requisitos

12

Niveles de detalle

13

El modelo FURPS+ establece cinco características como factores de

calidad que son los que le dan nombre:

Modelo FURPS+

Functional;

Usability;

Reliability;

Performance;

Supportability

El modelo FURPS incluye, además de los

factores de calidad y los atributos,

restricciones de diseño y requerimientos de

implementación, físicos y de interfaz.

14

Método VORD (Viewpoint-Oriented Requirement Definition)

Definición de requerimientos orientado a puntos de vista

VORD, está basado en puntos de vista que se enfocan en usuarios

involucrados en aspectos organizacionales. El modelo orientado a

puntos de vista es orientado a servicios. El sistema da servicios a los

puntos de vista y los puntos de vista pasan información de control y

parámetros asociados al sistema.

15

TIPOS DE REQUISITOS

FUNCIONALES

REQUISITO

RESTRICCIÓN

NO FUNCIONALES

DE INTERFAZ

REQUISITO

RESTRICCIÓN

REQUISITO

RESTRICCIÓN

▪Requisitos funcionales: mantener equilibrio (describen Qué debe hacer el sistema)

→ Definen el comportamiento del sistema.

→ Describen las tareas que el sistema debe realizar.

Ej: El usuario debe autenticarse ante el sistemamediante su fecha de nacimiento.

16

▪Requisitos no funcionales: Restricciones sobre lasfunciones o servicios ofrecidos por el sistema(atributos de calidad del sistema)

Deseables desde el punto de vista del usuario▪Tiempos de respuesta.▪Características de usabilidad.▪Facilidad de mantenimiento.

Ej:. El sistema debe realizar 20 transacciones porsegundo

17

Los requisitos no funcionales también se puedencategorizar en:

18

Otra clasificación categoriza a los requisitos en:▪ Requisitos de usuarioEj: El software debe proveer un medio derepresentar y acceder a los archivos externoscreados por otras herramientas.▪ Requisitos de sistemaEj: Cada tipo de archivo externo debe poder tenerasociada una herramienta externa para editarlo ymostrarlo.▪ Requisitos de softwareEj: Los íconos de los tipos de archivo se guardan enarchivos PNG.

Restricciones

19

Los requisitos, en su definición purista definen elQUÉ, y no el CÓMO; pero en el conjunto denecesidades que debe cubrir un sistema, no sólohay que tener en cuenta QUÉ cosas hay quehacer, sino también en ocasiones CÓMO debenhacerse.

La clasificación entre requisitos puros (QUÉ) yrestricciones (CÓMO) la debe considerar elanalista para que el equipo de trabajo sepa hastaqué punto determinados aspectos limitan susopciones de trabajo, y poder mantener así latrazabilidad con su origen (necesidad apuntadapor el usuario, normativa legal, limitacióntécnica, etc.)

20

El analista del sistema elige entre todas lasopciones tecnológicamente posibles aquellas quesegún su criterio profesional y las circunstanciasdel sistema, aportan mejor solución para laimplementación de los requisitos funcionales y nofuncionales.

La indicación por parte del cliente deinstrucciones como:

✓Debe emplearse base de datos Oracle.✓ Los procesos de desarrollo deben ser conformes aMétrica 3.

✓ El sistema final debe ejecutarse sobre la plataformalibre Linux.

✓Debe desarrollarse empleando Java.

La IR, debe adaptarse a las necesidades

del proceso, el proyecto, el producto y

las personas que realizan el trabajo.

Desde la perspectiva del proceso, la IR

es una acción de la IS que comienza

durante la actividad de comunicación y

continúa en la actividad de modelado.

Es esencial que el equipo de software

haga un esfuerzo real por entender el

problema antes de intentar resolverlo.

21

22

Habilidades comunicativas

La IR proporciona el mecanismo

apropiado para entender lo que el cliente

quiere. El proceso de la IR consiste en:

Tareas de la IR

23

OBTENCIÓN

Obtener información

ESPECIFICACIÓN

VERIFICACIÓN

&

VALIDACIÓN

GESTIÓN

Clasificarla, localizar

inconsistencias, dar

prioridades, pasar a

requisitos

Escribir los

requisitos

Comprobar que son

formalmente

correctos y lo que el

cliente quiere

Registrar cambios,

estudiar su impacto,

actualizar

documentación

Obtener información Registro y contrastaciónControlar las

modificaciones

INICIO ELABORACION

NEGOCIACION

En un escenario ideal, los clientes y los IS

trabajan juntos en el mismo equipo. Para

iniciar un proyecto software:

Identificación de los interesados. Son

aquellos que se benefician en forma

directa o indirecta del sistema en

desarrollo. Puede crearse una lista de

personas y a cada uno se le preguntará:

“¿Con quién más piensa que debería

conversar?

Inicio del proceso de la IR

24

Reconocimiento de varios puntos de

vista. Los requisitos que surjan pueden

ser inconsistentes y conflictivos. El IS debe

categorizar adecuadamente.

Trabajo con respecto a la colaboración

La colaboración no significa, que los

requisitos se definan por consenso.

Formulación de las primeras

preguntas. El conjunto de preguntas

libres de contexto se enfoca en el cliente,

metas generales y beneficios.25

Por ejemplo el IS podría preguntar:

¿Quién está detrás de la solicitud de

este trabajo?;

¿Quién usara la solución?;

¿Cuál será el beneficio económico de

una solución exitosa?;

¿Existe otra fuente para la solución

requerida?.

26

Dejar que el cliente exprese sus

percepciones, a través de las preguntas:

¿Cuáles problemas debería atacar

esta solución?;

¿Podría usted describir o mostrar el

ambiente de negocios en el que se

utilizará la solución?;

¿Los aspectos especiales del

desempeño o las restricciones

afectarán la forma en que se busque

la solución?.27

La serie final de preguntas:

¿Es usted la persona adecuada para

contestar esta pregunta? ¿sus

repuestas son “oficiales”?;

¿Mis preguntas son relevantes para su

problema?;

¿Estoy haciendo demasiadas

preguntas?;

¿Alguien más puede proporcionar

información adicional?;

¿Debería preguntar alguna otra cosa?.28

Se debe aplicar la recopilación conjunta de

requisitos. Algunas directrices son:

Las reuniones las dirige alguno de los

asistentes (IS o cliente);

Se establecen reglas para la preparación y la

participación;

Se sugiere una agenda formal;

Se utiliza un “mecanismo de definición”

(hojas de trabajo, foro virtual);

La meta es identificar el problema (proponer

soluciones, requisitos iniciales).

Obtención de requisitos

Recopilación conjunta

29

30

TÉCNICAS

ENTREVISTAS

ESCENARIOS

PROTOTIPOS

OBSERVACIÓN

Reuniones JAD, cuestionariosreuniones de grupo

entrevista, lluvia de ideas

Casos de uso, tarjetas CRCdiagramas de flujo, escenarios

Prototipos rápidosprototipos evolutivos

Introspecciónanálisis de protocolo

documentación, otros sistemas

Técnicas de obtención de requisitos

Conforme se recopilan los requisitos se

comienza a materializar una visión

general de las funciones del sistema. Sin

embargo, resulta difícil continuar,

mientras el equipo de software no

entienda la manera en que las distintas

clases de usuarios finales aplicarán esta

funciones.

Para lograrlo, se debe crear un conjunto

de escenarios (casos de uso)

Escenarios del usuario

31

Los productos de trabajo producidos

variarán de acuerdo con el tamaño del

sistema e incluye:

Un enunciado de necesidad y factibilidad;

Un enunciado limitado del ámbito del

sistema;

Una lista de clientes, usuarios que

participaron en la obtención de requisitos;

Una descripción del ambiente técnico;

Una lista de requisitos;

Un conjunto de escenarios de uso;

Prototipos para aclarar los requisitos.

Productos de trabajo de la obtención

32

La información conseguida con el cliente,

durante el inicio y la obtención se expande y

se refina.

La elaboración es una acción del modelado

del análisis y se compone de una serie de

tareas de modelado y refinamiento. Se

crean y se refinan escenarios del usuario,

para obtener objetos y clases con sus

respectivos atributos y operaciones.

33

Elaboración

Se debe conciliar conflictos por medio de un

proceso de negociación. Pedir a los clientes

que ordenen sus requisitos y después

discutan los conflictos relacionados con la

prioridad.

Se identifican y analizan los riesgos

asociados con cada requisito. Se hacen

estimaciones del esfuerzo requerido.

Mediante un enfoque iterativo, los requisitos

se eliminan, combinan o modifican, para

alcanzar cierto grado de satisfacción.34

Negociación

Los aspectos básicos que debe cubrir son:

▪Funcionalidad. Descripción de lo que el Sw. debe hacer.

▪ Interfaces externos. Cómo debe interactuar el softwarecon las personas, el sistema de hardware, o con otrossistemas (software y hardware).

▪Rendimiento. Indicación de la velocidad, disponibilidad,tiempos de respuesta, tiempos de recuperación, tiemposde determinadas funciones.

▪Atributos. Consideraciones de portabilidad, corrección,mantenibilidad, seguridad, etc.

▪Restricciones de diseño en la implementación.Indicación de las restricciones que puedan afectar por lanecesidad de sometimiento a estándares, lenguajes,políticas de integridad de bases de datos, límites derecursos disponibles para el desarrollo, sistema operativo.

35

Especificación de requisitos

Examina la especificación paraasegurar que todos los requisitos sehan establecido de manera precisa;que se han detectado lasinconsistencias, omisiones y errores yque estos han sido corregidos, y quelos productos de trabajo cumplen conlos estándares establecidos para elproceso, proyecto y producto.

36

Validación de requisitos

Una vez que se ha comprendido elproblema del usuario, se ha definido ydescrito el sistema que se deseaconstruir para solucionarlo, y detalladolos requisitos del software, comienza lafase de diseño y desarrollo.

Se puede considerar que la fase derequisitos ya ha terminado al generar losdocumentos de descripción del sistema ydescripción de requisitos del software.

37

Gestión de requisitos

Cuanto más complejo sea el sistema, ymás larga la agenda de desarrollo, habrámayor probabilidad de modificacionessobre los requisitos; y si no se gestionanconvenientemente deteriorarán, enmayor o menor medida, la planificación yla calidad del proyecto.

38

RequisitosDiseño Codificación

Integración/pruebas

La gestión de requisitos da continuidad a esta área durante todo el proyecto

La IR, es aquel conjunto de técnicas queayuda a los IS a entender mejor elproblema en el que trabajarán.

El AR, es aquel que genera laespecificación de característicasoperacionales de software; indica lainterfaz del software con otros elementosdel sistema, y establece las restriccionesque debe tener el software.

39

Ingeniería de Requisitos Vs. Análisis de Requisitos

Cliente con poco tiempo;

Cliente mentiroso;

Desarrolladores cómodos;

Mala relación con el cliente;

El cliente amenaza con acciones legales;

El proyecto ha cambiado mucho;

El cliente se tomo las cosas personales;

El proyecto se ha vuelto un desafió.40

Consecuencias de no aplicar la IR

Cliente abusador;

Cliente paranoico;

Desarrolladores temperamentales;

El cliente no nos dejó respirar: recibía de8 a 15 e-mail diarios y de 5 a 8 llamadasdiarias;

El cliente cambió de parecer muchasveces;

El cliente llamaba al celular a altas horasde la noche.

41