Ingeniería de Software

Ingeniería de Requerimientos

Cristina Casimiro
casimc@sainc.com

2003 CC, Ing de Software, ITAM 1

Temario

Expectativas
Resolución de

Requerimientos conflictos

Ingeniería de
Restricciones
requerimientos
Validación

Terminología
Verificación

Premisas
Documentación

Técnicas

Dependencias

2003 CC, Ing de Software, ITAM 2

Expectativas

El cliente espera el triple  Expectativas
de un nuevo sistema
Funcionalidad

Nueva funcionalidad,

El nuevo sistema hace 1.5

Efectividad
más que el anterior

Eficiencia

Estrategia: Aplicar un
Interfaz de usuario
cuestionario de
Facil de aprender a usar
expectativas
Fácil de usar

La utilidad del producto
Facil de modificar
se mide de acuerdo al
Productividad

Facil de aislar los problemas
valor (percibido) para el

Mantenibilidad
usuario
Mejoras

El valor del producto
Soporte
depende de qué tan bien
Documentación
satisgafa las
Entrenamiento
necesidades del usuario.
2003 CC, Ing de Software, ITAM 3
Requerimientos

Todo empieza con una necesidad
 vaga e inarticulada

Se refina en un requerimiento
 el propósito que servirá el software
 qué hará para servir ese propósito
 desde la perspectiva del usuario

Se formaliza y completa en una
especificación

2003 CC, Ing de Software, ITAM 4

Ingeniería de Requerimientos

Generar una especificación completa y
correcta de las necesidades del usuario y
la forma en que se pueden cumplir

Generar la base de información necesaria
para apoyar la implementación del
producto, su aceptación en el campo y su
futura evolución

2003 CC, Ing de Software, ITAM 5

Ingeniería de Requerimientos (2)

Obtención de Requerimientos
 proceso divergente
acumulación de información
involucra muchos grupos de personas
emplea varias técnicas en paralelo

Análisis de Requerimientos
 proceso convergente
refina, agrupa y organiza la información
involucra un equipo integrado
usa técnicas sucesivas

2003 CC, Ing de Software, ITAM 6

Ingeniería de Requerimientos (3)

Revisión con cliente
 agrega información a la estructura básica
restricciones
prioridades
datos cuantitativos
criterios de validación

Documentación
 Especificación de requerimientos
 Acuerdo o especificación de trabajo

2003 CC, Ing de Software, ITAM 7

Consideraciones

Restricciones

reglas, estándares y limitaciones bajo las que operará el
sistema

limitan las elecciones posibles para cumplir el requerimiento

Prioridades

determinar el orden en que el desarrollo atacará los
requerimientos atendiendo a su importancia, urgencia y
dificultad.

Cuantificación

las necesidades del usuario son usualmente poco específicas y
cualitativas

la funcionalidad del software es específica y cuantitativa

se debe establecer los números exactos que deben cumplirse:
velocidad, frecuencia, tamaño, multiplicidad…

2003 CC, Ing de Software, ITAM 8

Consideraciones (2)

“Seguible”
 a través de la especificación, diseño e
implementación, determinar correspondencia
entre etapas

Tamaño y durabilidad
 en sistemas grandes, se piensa y actúa
diferente
herramientas y técnicas
documentación
reusabilidad

2003 CC, Ing de Software, ITAM 9

Consideraciones (3)

Riesgo

Alternativas
 ¿existe una solución disponible?

Participantes estratégicos
 personas a quienes afecta el software
 grave error: tomar requerimientos sólo del
“jefe”
 el cliente es quien paga, y a quien hay que
convencer del valor del producto

2003 CC, Ing de Software, ITAM 10

Participantes estratégicos

Sin acceso a ellos, no se podrán determinar los
verdaderos requerimientos

Para identificarlos, busca quien:

interactúa regularmente con el producto

cambia su forma de trabajar por el producto

crea entradas para el producto

emplea las salidas del producto

Comprender la estructura organizacional

Priorizar según el éxito del producto

Son más importantes si

son muchos

usan el sistema intensivamente

usan el sistema bajo stress

sus errores son más costosos
2003 CC, Ing de Software, ITAM 11
Ejemplo:

El sistema de contabilidad de la empresa
se diseñó en torno a la captura de datos
en una terminal de punto de venta
 Los usuarios eran los vendedores
 Sin embargo, los requerimientos fueron
dados por los contadores
 El producto fue un desastre

2003 CC, Ing de Software, ITAM 12

Dos tipos de requerimientos

¿Qué necesitan hacer los usuarios?
 Especificación funcional
 qué hacer
 información capturada, almacenada o desplegada
 entidades externas controladas o monitoreadas
 recursos usados o disponibles

¿Cómo desean hacerlo?
 Comportamiento (principio de operación)
 quién invoca qué funciones
 cómo se invocan las funciones
 cómo se lee o despliega la información
 cómo se comunica con otros sistemas

2003 CC, Ing de Software, ITAM 13

Problemas: Falta de expresión

Problema
 el usuario no puede explicar lo que hace
 tiende a recordar lo excepcional y olvidar lo rutinario
 hablan de lo que no funciona
 un usuario articulado puede crear un consenso falso

Ideas
 observar a los usuarios trabajando
 hacer que los usuarios registren lo que hacen y
cuánto tardan
 escenarios: llevar a los usuarios a través de
transacciones completas

2003 CC, Ing de Software, ITAM 14

Problemas (2): Terminología

Problema
 los usuarios tienen distinto vocabulario que los
desarrolladores
 usan el mismo término con distinto significado
 entienden los términos en el contexto de su trabajo

Ideas
 emplear un “experto” que entienda el uso
 construir un diccionario de términos clave y sus
definiciones
 pedir a varios usuarios que definan los términos y
buscar consenso

2003 CC, Ing de Software, ITAM 15

Problema (3): Premisas Ocultas

Problema
 no se habla de lo que “todos saben”
 el desarrollador puede no saberlo
 un sistema que no cumple una premisa
crítica fallará

Ideas
 observar
 pedir a usuarios que recorran los escenarios
y prueben que estén completos
 usar especificaciones formales

2003 CC, Ing de Software, ITAM 16

Problema (4): Soluciones
preconcebidas

Problema
 el usuario cree tener la respuesta a su problema
 puede ser, pero que no sea óptima
 tiene ideas incompletas, desactualizadas o falsas
acerca de la tecnología existente
 describe no el problema sino su idea de solución

Ideas
 brainstorming: explorar muchas ideas
 buscar las causas de los features pedidos
 describir la solución ideal, aún si es imposible
 mostrar algunos sistemas existentes

2003 CC, Ing de Software, ITAM 17

Técnicas de Obtención de
Requerimientos

Activas (los usuarios participan)

Pasivas (los usuarios son observados)

Muestreo (algunos participan)

Universales (todos participan)

Iterativas (hechas varias veces)

Definitivas (hechas una sola vez)

2003 CC, Ing de Software, ITAM 18

Técnicas Activas

Lluvia de ideas (muestra, definitiva)
 iniciar por consenso en objetivo general del sistema
 no discutir, criticar, cambiar o combinar sugerencias

Entrevistas (universal, iterativa)
 preparar tópicos, no preguntas
 instar a que digan lo que a ellos les importa más
 enfocar el impacto del sistema en su trabajo

Cuestionarios (universal, definitiva)
 todos con el mismo cuestionario, pero agrupados de
acuerdo a intereses
 enfocar expectativas de cambios y no cambios

2003 CC, Ing de Software, ITAM 19

Técnicas Pasivas

Monitoreo (iterativa)
 recolectar información sin interferencia
 da una imagen exacta del sistema usado

Observación (iterativa)
 similar, pero emplea un observador humano
 no puede ser muy detallada
 el observador debe conocer el sistema

Revisión de sistema previo o de actividades a
sistematizar (definitiva)
 el usuario dice qué hace y por qué
 útil para capturar manejo de errores y excepciones, y
para probar prototipos
2003 CC, Ing de Software, ITAM 20
Captura de Requerimientos

Especificaciones de sistemas actuales

FAST (Facilitated Application
Specification Technique)

FODA (Feature-Oriented Domain
Analysis, no confundir)

QFD (Quality Function Deployment)

Prototipos

UML

2003 CC, Ing de Software, ITAM 21

FAST (Facilitated Application
Specification Technique)

Se lleva a cabo en un sitio neutral

Se involucra tanto el cliente como los
desarrolladores

Reuniones guiadas con agenda

Reuniones llevadas por un facilitador

Todas las ideas se capturan

La meta es identificación del problema

2003 CC, Ing de Software, ITAM 22

Feature-Oriented Domain Analysis
(FODA)

Analizar aplicaciones existentes buscando
 características indispensables
 implementaciones alternativas
 funciones opcionales
 dependencias entre características

Crear diccionario del dominio
 establecer terminología
 explorar alternativas
 interactuar con usuarios poco comunicativos

2003 CC, Ing de Software, ITAM 23

QFD (Quality Function Deployment)

Comunicación
 relaciona a usuarios con desarrolladores

Ayuda en las decisiones
 expone requerimientos y features clave
 muestra conflictos entre requerimientos
 propone posibles features alternativas

Ayuda en la planeación
 captura y organiza requerimientos, restricciones,
prioridades e interdependencias
 provee medio para “traceability”

2003 CC, Ing de Software, ITAM 24

Prototipos

Por funcionalidad
 no-funcional
 funcionalidad falsa
 funcionalidad restringida

Objetivo
 captar y refinar requerimientos
 reducir riesgo técnico y de interface
 no es un adelanto en el desarrollo, es
desechable

2003 CC, Ing de Software, ITAM 25

 UML

Casos de uso
Modelo de objetos

2003 CC, Ing de Software, ITAM 26

Análisis de Dependencias

Identificación
 ¿es un requerimiento el refinamiento de otro?
 ¿si uno se quita, el otro tendría sentido?
 ¿es la relación recíproca?

Manejo
 agrupación por interdependencia
 ordenamiento según precedencia
 repriorizar por dependencias

2003 CC, Ing de Software, ITAM 27

Resolución de Conflictos

Remover requerimientos
 negociar quitar el de menor prioridad

Partición de grupos de usuarios
 puede ser posible un acuerdo

Partición del sistema
 diferentes configuraciones del sistema

Renegociar
 calcular probabilidad y costo del peor
escenario para decidir
2003 CC, Ing de Software, ITAM 28
Identificación de Restricciones

¿Algún usuario verá una diferencia por esto?

¿Podemos cumplir este requerimiento de
cualquier forma?

Plantear la restricción en positivo

Buscar restricciones globales
 se aplican a todo el producto
 se aplican por igual a todos los requerimientos

Buscar restricciones internas (organización),
externas (el mundo real) y de interface

Determinar si se puede cumplir el propósito de
la restricción con otra menor

2003 CC, Ing de Software, ITAM 29

Cuantificación

Para el sistema, es parte del requerimiento

Para cada componente, es parte del diseño

Pueden emplearse como pruebas de
aceptación

Deben considerarse los escenarios y
variaciones

Debe distinguirse valores pico de promedio

Deben establecerse tendencias a futuro

2003 CC, Ing de Software, ITAM 30

Revisión

Actividad técnica y política

La meta es un acuerdo
 informado
 “que se debe cumplir”

Se presenta la información y se escucha

Evitar desviaciones y conflictos

Buscar acuerdos en
 principios
 hechos
 implicaciones de los hechos

2003 CC, Ing de Software, ITAM 31

Validación

Para cada requerimiento
 al menos un usuario debe relacionarlo con sus
necesidades
 todos deben coincidir en que no perjudica sus
necesidades

Para cada información cuantificada
 todos los usuarios deben estar de acuerdo en que
las fórmulas son correctas y los números usados son
realistas

Proponer solución y dejar a los usuarios decidir

No informar de antemano de los conflictos
2003 CC, Ing de Software, ITAM 32
Verificación

Asegurarse de que un requerimiento se ha
cumplido

Criterio

establecer una forma específica de probar el requerimiento

este criterio debe ser acordado, o incluso propuesto, por el
cliente

concurrir en quién, cuándo y cómo lo probará

Resultados

éxito y usuario feliz

éxito y usuario insatisfecho

falla

2003 CC, Ing de Software, ITAM 33

Contenido de la Especificación de
Requerimientos

Descripción del sistema o proceso manual actual

Necesidades funcionales y no-funcionales

No funcionales

Interfaz con usuarios, procesos y sistemas

Restricciones de diseño, calidad, tiempo, transferencia de datos

Sistema propuesto

Uso

Objetos

Flujo

Datos

Matriz de seguimiento

2003 CC, Ing de Software, ITAM 34

Manejo de Requerimientos
 Los cambios no controlados en los requerimientos son la causa
principal de la mayoría de los retrasos y excesos de presupuestos
 ¿Por qué cambian los requerimientos?
 Complejos
 Difíciles
 Volátiles
 Novedosos
 Estrategias de defensa contra cambios a requerimientos
 Designar una persona como contacto primario con el cliente
 Usar técnicas para refinar requerimientos
 Presentar los requerimientos en formatos accesibles al cliente
 Hacer un “Acuerdo de trabajo” claro y firmarlo temprano
 Mantener un estricto control de configuración
 Dar transparencia al proceso de desarrollo

2003 CC, Ing de Software, ITAM 35

Bibliografía

Software Requirements

Objects, Functions and States

Alan M. Davis

Prentice Hall, 1993

Exploring Requirements Quality Before Design

Donald C. Gause, Gerald M. Weinberg

Dorset House Publishing, 1989

Requirements Analysis

Robert Firth

Software Engineering Institute, Carnegie Mellon University

2003 CC, Ing de Software, ITAM 36