ANALISIS Y DISEÑO DE SISTEMAS

Semana 03
Del 24 al 28 de abril
Ingeniería de Requerimientos
Ing. Juan Carlos Hernández Saona

jhernandez@iestplurin.edu.pe
 • Introducción
• Importancia de los requerimientos
• Ciclo de vida de requerimientos
• Propiedades de los requerimientos
• Errores de requerimientos
Contenido
• Clasificaciones de requerimientos
• Documentación de requerimientos
• Trazabilidad de requerimientos
• Gestión de requerimientos
• Conclusiones
La realidad de los
Requerimientos

3
 • Conjunto de actividades involucradas
en el descubrimiento, documentación
y mantenimiento de los
requerimientos para un producto
determinado – según Ortas 1997
Introducción • El proceso de recopilar, analizar y
verificar las necesidades del cliente
para un sistema, es llamado Ingeniería
de Requerimientos. La meta es
entregar una especificación de
requerimientos de software correcta y
completa
 • La Ingeniería de requerimientos
comprende todas las tareas
relacionadas con la determinación de
las necesidades o de las condiciones a
satisfacer para un software nuevo o
modificado, tomando en cuenta los
Introducción diversos requerimientos de los
usuarios, que pueden entrar en
conflicto entre ellos. Puede ser
conocida también como "Análisis de
requerimientos", "especificación de
requerimientos", etcétera
 ¿Qué es un Requerimiento?
• Una condición o capacidad necesaria
para un usuario para resolver un
problema o alcanzar un objetivo
• Una condición o capacidad que debe
estar presente en un sistema o
Introducción componentes de un sistema para
satisfacer un contrato, estándar,
especificación u otro documento
formal
• Una representación documentada de
una condición o capacidad como en (1)
o (2)
 “La parte más difícil de construir un
sistema es precisamente saber qué
construir. Ninguna otra parte del trabajo
conceptual es tan difícil como establecer
los requerimientos técnicos detallados,
incluyendo todas las interfaces con
gente, máquinas y otros sistemas.
Importancia de los Ninguna otra parte del trabajo afecta
tanto el sistema si es hecha mal. Ninguna
requerimientos es tan difícil de corregir más adelante...
Entonces, la tarea más importante que el
ingeniero de software hace para el
cliente es la extracción iterativa y el
refinamiento de los requerimientos del
producto.”
Frederick P. Brooks 1987
 • Los requerimientos se deben descubrir
antes de empezar a construir un
producto y puede ser algo que el
Importancia de los producto debe hacer o una cualidad
que el producto debe tener
requerimientos
• Si no se tienen los requerimientos
correctos, no se puede diseñar o
construir el producto correcto
 Estrategia y
Demanda Gestión del Portafolio y Proyectos
Operacional

Definición y Gestión de Requerimientos

Análisis

Priorización, Verificación,
Riesgo, Estimación

Modelo General
Elicitación Especificación Validación
Requerimientos detallados,
Técnicas, Interesados, Escenarios de modelos de negocio, Priorización, Verificación,
Glosarios, Límites del sistema Modelosde casos de uso, Prototipos Riesgo, Estimación

Gestión de Requerimientos

Almacenamiento, Trazabilidad, Medición y Auditoría, Estado, Documentación, Seguridad

9
Flujo General

10
Modelo en
Cascada

11
Ciclo del Análisis
de
requerimientos

12
 • Existen diferentes métodos para la
extracción de los requerimientos.
Algunos son:
• Entrevistas con el cliente y con los
Extracción de futuros usuarios
Requerimientos • Encuestas
• Documentos entregados por los
clientes
• Prototipación
• Sistemas antiguos
 • Es importante tener en cuenta que en
muchos casos el cliente no sabe al
inicio del proyecto cuales son sus
Extracción de requerimientos.
Requerimientos • En este sentido es más un proceso de
definición y descubrimiento de
requerimientos junto al cliente que
una extracción de algo existente
Un Poco de
Humor

15
 • Publicar previamente una agenda y seguirla
• Incluir a las personas apropiadas
• Si no se invita a una reunión a un
actor importante para los temas
tocados, tenderá luego a asistir a
todas las reuniones para no perder
nada
• Si se invita alguien que en la práctica
Entrevistas y reuniones no tiene relación con el tema de la
reunión, puede distorsionar la reunión
y no asistir a reuniones posteriores
• Manejar las personas que no pertenecen a
la reunión
• No agendar reuniones justo antes de la hora
de almuerzo
• Procurar se respeten los horarios de inicio y
término de las entrevistas y reuniones
 Llevar tarjetas de presentación y presentarse al inicio de la entrevista si no lo ha hecho
anteriormente con algún participante

Recordar y confirmar la asistencia de los participantes claves a la reunión unos minutos

antes de la hora de inicio

Establecer previamente una política de interrupciones

Prohibir ataques personales y descalificaciones

Reducir la presión si la atmósfera de la reunión se complica, pero considerando que de

algunos conflictos pueden surgir conclusiones importantes para el proyecto

Entrevistas y reuniones
 • Al hacer una pregunta, escuchar la
respuesta, entonces describir nuestro
entendimiento
• Usar la terminología y artefactos del
usuario
• En los minutos finales, revisar los
puntos tocados en la entrevista o
reunión para detectar detalles que
Entrevistas y necesitan aclaración “en caliente”
reuniones • Al termino, agradecer a los usuarios
por su tiempo y hacerle saber por que
fue valiosa su participación
• Luego, confeccionar una minuta
incluyendo los compromisos
resultantes y enviarla a los
participantes para su visto bueno
 Técnica
• Entrevistas y Cuestionarios

Ventajas
• Se obtiene una gran cantidad de información
correcta del usuario
• Pueden usarse para obtener un pantallazo del
dominio del problema
Análisis comparativo • Son flexibles
• Pueden combinarse con otras técnicas
de algunas técnicas
Desventajas
• La información obtenida al principio puede ser
redundante o incompleta
• Si el volumen de información manejado es
alto, requiere mucha organización de parte del
analista, así como la habilidad para tratar y
comprender el comportamiento de todos los
involucrados

19
 Técnica
• Lluvia de Ideas

Ventajas
• Los diferentes puntos de vista y las
confusiones en cuanto a terminología,
Análisis comparativo son aclaradas por expertos
de algunas técnicas • Ayuda a desarrollar ideas unificadas
basadas en la experiencia de un
experto

Desventajas
• Es necesaria una buena
compenetración del grupo participante

20
 Técnica
• Prototipos

Ventajas
• Ayudan a validar y desarrollar nuevos
requerimientos
• Permite comprender aquellos
requerimientos que no estén muy claros y
Análisis comparativo que sean de alta volatilidad
de algunas técnicas
Desventajas
• El cliente puede llegar a pensar que el
prototipo es una versión del software que
será desarrollado
• A menudo, el desarrollador hace
compromisos de implementación con el
objetivo de acelerar la puesta en
funcionamiento del prototipo

21
 • Se procesa la información obtenida
Análisis de • Se analizan inconsistencias que
puedan existir
requerimientos
• Se analiza si la información obtenida
es suficiente para la etapa de diseño
 • Los diferentes tipos de documentos
son: User Requeriment Specification
(URS), Alternatives and Impacts
Document (AID), Software
Requirements Specification (SRS),
Prototipos
Documentación de
• Es importante que los documentos
Requerimientos estén completos
• Estos documentos no solo sirven para
saber qué hay que hacer sino para
tener un respaldo validado por el
cliente de lo que posteriormente se
construye
 • Proceso manual que involucra a varios
lectores
Revisión de los
• IQA: revisión interna del proyecto
requerimientos
• EQA: revisión externa del proyecto
pero interna a la empresa
 • El equipo “conduce” al cliente a través
de los requerimientos para confirmar
Validación de si es lo que realmente quiere
Requerimientos • Es muy importante que el cliente
valide los documentos generados
El proceso de lectura consiste en leer la secuencia de
letras de cada palabra y luego ir armando la frase con
cada una de las palabras identificadas

Según un etsduio de una uivennrsdiad ignlsea no

ipmotra el odren en el que las ltears etsen ersciats, la
uicna csoa ipormnte es que la pmrirea y la utlima ltera Proceso de
esten ecsritas en la psiocion cocrrtea. El rsteo peuden
estar taotlmntee mal y aun prodas lerelo sin pobrleams.
Etso es pquore no lemeos cada ltera en si msima, pero si
lectura
la paalbra cmoo un todo.

¿No te parcee aglo icrneible?

¿Por qué los Proyectos de Software son exitosos?

13,0%: 7,2%:
9,6%: Quality
15,9%: 13,9%: clara 8,2%: equipo
apropiad 7,7%: Systems
involucra soporte definición expectati compete &
o hitos no
a administr de vas nte de Software
planeami extensos
usuarios ación requerimi realistas profesion · 1997
entos ento ales
 • 13,1%: requerimientos incompletos
• 12,4%: falta de requerimientos
• 10,6%: falta de recursos
• 9,9%: expectativas no realistas

¿Por qué los Proyectos • 8,7%: cambio de

requerimientos/especificaciones
de Software fallan?
• 8,1%: falta de planeamiento
• 7,5%: no se especifico el tiempo
adecuado

Quality Systems & Software · 1997

 100%
100%

90%

80%

70%
Costos Costo relativo 60%
relativos en la 60%

corrección de 50%

errores de 40%

requerimient 30%

os 20%
20%

10% 7%
0,15% 0,5%
0%
Requerimientos Diseño Codificación Test de desarrollo Test de Operación
aceptación
Fase en la que se identifica el error

45
Errores de
requerimi
entos
 • El 48% de los defectos observados en
proyectos de software de mediana
escala son “atribuidos a especificaciones
funcionales o requerimientos
incorrectos o mal interpretados” (Basili y
Perricone · 1984)
• El 79,6% de los defectos de las interfaces
y el 20,4% de los defectos de
Errores de implementación se deben a
requerimientos requerimientos omitidos o incompletos
(Perry y Stieg · 1993)
• El 44,1% de todos los defectos de los
sistemas se producen en la etapa de
especificación (Computer Weekly Report
· 1994)
• La tecnología es un problema mayor solo
en un 7% de los proyectos
 • “Los requerimientos, especialmente
expresados en una especificación (o a
menudo no expresados porque no
existe especificación), son la mayor
fuente de los costosos bugs. El rango
va desde un pequeño porcentaje
hasta más del 50% dependiendo de la
aplicación y el ambiente. Lo que más
Errores de duele es que estos defectos son los
requerimientos que más temprano invaden el sistema
y también son los últimos en salir. No
es raro que un requerimiento
defectuoso pase todos los tests de
desarrollo, el beta-test, y el uso inicial
en producción, sólo para ser
descubierto después de que se ha
instalado en centenares de sitios”
(Beizer · 1990)
 • Los requerimientos se pueden dividir
en “Requerimientos Funcionales” y
“Requerimientos No Funcionales”
• Los requerimientos funcionales son
los requerimientos que especifican las
entradas (estímulos) al sistema, las
salidas (respuestas) del sistema y la
relación entre las entradas y las
Requerimientos Funcionales y salidas
No Funcionales • Los requerimientos no funcionales
tienen que ver con características o
restricciones que de una u otra forma
puedan limitar el sistema, como por
ejemplo, el rendimiento (en tiempo y
espacio), interfaces de usuario,
confiabilidad, mantenimiento,
seguridad, portabilidad, estándares,
etc.
 • Para calcular el interés de depósito
fijo anual, se hace por un período de 3
años al 14%
Requerimientos Funcionales • Los datos requeridos de los clientes
Ejemplos son: nombre, apellido, CI y teléfono
• Para poder ingresar un cliente,
primero hay que tener ingresada la
empresa en la cual trabaja
 Performante
• Número de dígitos de precisión en un
cálculo numérico
• Tiempo máximo de respuesta en una
transacción
• Tiempo de respuesta y finalización de
tareas en un sistema de tiempo real
Requerimientos No Funcionales
Ejemplos
Ambiente
• Que el sistema corra bajo un
determinado sistema operativo
• Usar un determinado lenguaje de
programación
Seguridad
• El alta y baja de libro puede ser
realizado solo por el jefe de librería
 Usabilidad
• Los futuros usuarios deben poder
utilizar el sistema después de un
entrenamiento de 2 semanas
• El ingreso de pedidos de clientes
típico (15 ítems) no puede llevar más
de 1 minuto
Requerimientos No Funcionales
Confiablidad
Ejemplos
• Probabilidad de falla bajo demanda
(POFOD)
• Tasa de ocurrencia de fallas (ROCOF)
• Tiempo medio entre fallas (MTTF)
• Disponibilidad
 • Tipos de satisfacción en el cliente o usuario:
• Requerimientos Normales
• Respuestas del usuario a preguntas específicas
• La satisfacción / insatisfacción es proporcional a su
presencia / ausencia en el sistema
• La satisfacción es lineal y bi-direccional
• Requerimientos Esperados
• Tan básicos que es posible que el usuario no los mencione
• Su presencia en el sistema seguramente cumpla con las
expectativas del cliente pero no aumenta la satisfacción
Otros criterios de clasificación • Su ausencia es muy insatisfactoria
de requerimientos • Requerimientos Extra
• Van mas allá de las expectativas de los clientes
• No son extraídos de los clientes
• Alta satisfacción de los clientes cuando estos
requerimientos resultan exitosos
• Su ausencia no insatisface porque no son esperados

• Tipos de servicio

• Categorías de usuario
 • Los requerimientos extra se están
transformando cada vez mas en
Tendencia a través requerimientos normales
de los años • Algunos requerimientos normales se
transforman en esperados
Clasificación por tipos de servicio

Requerimientos Requerimientos Requerimientos Requerimientos

asociados a asociados a asociados a asociados a
funcionalidad presentación performance administración

La manera o
Necesidades de Criticidad del Controles en el
forma de
información del tiempo de la procesamiento de
presentar la
usuario información la información
información

Aspectos del
Uso optimo de los Clima
procesamiento de
recursos organizacional
la información
URS · User Requirements AID · Alternatives and SRS · Software Prototipos
Specification Impacts Document Requirements Specification • El prototipado es una técnica de
• Documento inicial que describe • Las diferentes soluciones • Documento genérico de
construcción parcial del sistema
cual es la funcionalidad del alternativas y su impacto en la especificación de • En un comienzo, su objetivo era
negocio requerida y los organización o dominio del requerimientos. que los clientes, usuarios y
problemas existentes desde la cliente es definido en el AID desarrolladores pudieran
• Contiene una descripción global
perspectiva del usuario. aprender más sobre un problema
• Su principal propósito es servir del sistema completo o la solución del problema
• El URS documenta los objetivos como un registro de que • Puede estar mas o menos
que se suponen deben ser • Entonces, la única y principal
distintas alternativas se detallado según los datos
logrados y los requerimientos generaron durante el análisis y se obtenidos al momento función del desarrollo de un
asociados para alcanzarlos. definió un ranking de acuerdo a prototipo era establecer los
• Tiene que estar escrito de forma requerimientos
• Contenido: Introducción, su impacto que sea comprensible por el
Descripción general, • Es una manera muy fácil de
• Puede ser o no entregado al usuario, ya que deberá validarlo
Requerimientos, Plan de IT, cliente representar la navegabilidad y
• Contenido: Introduction,
Apéndices presentación del sistema
• Contenido: Introducción, Purpose, Scope, Definitions,
Soluciones alternativas, acronyms and abbreviations,
Impactos, Solución elegida References, Overview, Product
perspective (System Interface,
User Interface, Hardware,
Interface, Software Interface,
Communication Interface,
Memory Constraints, Operations,
Site Adaptation requirements),
Product functions, User
characteristics, Constraints,
Assumptions and dependencies,
Prioritizing of the requirements,
Specific requirements (External
interfaces, Functions,
Performance requirements,
Logical database requirements,
Design constraints, Software
system attributes, Organizing the
specific requirements, Additional
comments)

Documentos de requerimientos
 • La Ingeniería de Requerimientos es primordial
en el proceso productivo ya que se enfoca en
la producción, siendo su tarea la generación
de especificaciones correctas que describan
con claridad, sin ambigüedades y en forma
compacta las necesidades del cliente,
minimizando los problemas relacionados con
la gestión de dichos requerimientos.
Principales • Los requerimientos son importantes debido a
conclusiones que son la base de todo desarrollo de
software. Obtener requerimientos de calidad
demuestra que el trabajo realizado culminará
con éxito, esto se debe a dos factores:
• La utilización adecuada de las técnicas
de captura de requerimientos con los
clientes.
• La experiencia de los analistas del
proyecto.