ingenieria de requisitos - cotana.informatica.edu.bocotana.informatica.edu.bo/downloads/ingenieria...
TRANSCRIPT
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