Especificación y

Análisis de Requisitos
Características de la ingeniería del
software (Van Vliet 1993)
• Construcción de programas grandes
• Controlar la complejidad
• Cooperación entre las personas implicadas
• Evolución del software
• Eficiencia en el desarrollo
• Soporte real a los usuarios

3. El proceso de desarrollo de software 2

Modelo de la Ingeniería del software
(Thayer 1988)

Ingeniería
del software
Desarrollo Gestión de Metricas Mantenimiento
de Software proyectos del software de software
Analisis Planificación Fiabilidad Corrección de Errores
Diseño Organización Usabilidad Modificaciones
Codificación Reclutamiento Flexibilidad
Pruebas Dirección Mantenibilidad
Control Reusabilidad
Etc.

3. El proceso de desarrollo de software 3

Técnicas básicas usadas en las
ingenierías
• Históricamente se han utilizado técnicas como:
• El modelado
• División del Producto
• División del Proceso
• En principio se deberían utilizar estas técnicas,
también en informática .

3. El proceso de desarrollo de software 4

Principales metodologías en el tiempo
Definición de 

Requerimientos

Análisis & Diseño Construcción/Pruebas

Inicialmente se usó
Implementación y 

el Modelo Test Unitarios
Tradicional de Tiempo
Cascada
 Integración y

test del sistema
1980
Operación y
mantención

Modelo Iterativo Incremental

1990 t

Iteración 1 Iteración 2 Iteración 3

R R R
A&D A&D A&D
C C C
P P P

Tiempo t
Elo329: Diseño y Programación Orientados
5
a Objetos
Qué es un Requerimiento?

• Es un aspecto del contenido o comportamiento del

producto, requerido o deseado por el cliente.
• Requerimientos funcionales. (Debe hacer)
• Requerimientos no-funcionales.(Debe tener)

• Una restricción es un requerimiento que afecta a

todo el producto.
Fases de la especificación y análisis de
requerimientos
• Blastoff o inicio
• Recolección de requerimientos
• Prototipos
• Verificación y validación
• Revisiones
• Post-Mortem
 Blastoff

Preparación para el inicio del proyecto
• Reunión entre los principales desarrolladores,
clientes y usuarios
• Del Blastoff se obtienen:
• El contexto
• Propósito del proyecto
• Lista de principales riesgos
• Estimación inicial del esfuerzo
• Decisión de seguir adelante o no
• Identificación clara de los interesados
• Compromiso con el proyecto
• Formación de equipos
 Blastoff (continuación)

• Determinar el propósito del producto:

1. Escribir en una frase el objetivo/propósito del
producto
2. Cuál es la ventaja/solución que ofrece?
3. Definir cómo medir el éxito.
Además:
4. Es realista / factible?
5. Lo desean todos los interesados (stakeholder)?
Propósito del producto:

• Todos los demás requerimientos son

verificados/validados en torno a su
contribución al propósito del producto.
• Qué ventaja o solución queremos que ofrezca
el producto?
• El producto tiene un criterio de validación
medible/verificable.
• La satisfacción es un factor en el valor del
producto.
Identificación de las personas
interesadas:

• Patrocinadores
• Clientes
• Usuarios
• Especialistas
• Ingeniero de requerimientos

Determinar el alcance:
• Dominios y Contexto

• Los dominios de interés son los que

influyen en el sistema que se esta por
estudiar
• El dominio de la aplicación simulará
hasta cierto punto a los dominios de
interés.
 (cont.)
• El contexto incluye todo lo que se debe saber
para construir el sistema.
• El producto es la parte del contexto sobre la cual
tenemos control para adaptar / cambiar
• Los sistemas adyacentes son las fuentes de
conocimiento sobre los dominios de información
• Los sistemas adyacentes tienen conexiones con el
contexto. Es importante entenderlos para
entender las características de las conexiones.
• El contexto contiene políticas de procesamiento y
datos almacenados
Estimar el costo costo/esfuerzo inicial

• Primera medición del tamaño del sistema:

• Número de sistemas adyacentes
• de dominios,
• entradas y
• salidas.
Estimar el costo costo/esfuerzo inicial

• Primera medición del tamaño del sistema:

• Número de sistemas adyacentes
• de dominios,
• entradas y
• salidas.
 Primer análisis de riesgos

• Identificar los riesgos más probables para el

proyecto
• Estimar el costo / impacto si el riesgo se vuelve
un problema
• Identificar las señales que indiquen que el riesgo
se está volviendo un problema
• La intención es balancear los beneficios con sus
riesgos
• Un riesgo no forzosamente es algo malo.
Evaluación y toma de decisión de seguir
adelante

• En base a lo anterior se analiza si:

• Los objetivos son viables y medibles?
• Son factibles?
• Son los riesgos demasiado altos?
• Es el costo de los objetivos razonable?
• Las personas implicadas están de acuerdo y
dispuestas?
• Se justifica el proyecto?

Hay razones para cancelarlo?
 Toma de Requerimientos
• Cual problema necesita ser resuelto? (identificar límites)
La técnica de • Donde está el problema? (el contexto o el dominio del
las 6 W: mismo)
What?
 • A Quienes involucra el problema? (identificar los actores)
Where?
 • Por qué necesita resolverse? (identificar las metas de los
Who?
 actores)
Why?
 • Como debería ayudar el soft? (tomar o colectar los
When?
 escenarios posibles)
How (Which)?
• Para cuando debe estar resuelto? (identificar limitaciones
¿Qué? de desarrollo)
¿Dónde? Quien • Qué debemos tener en cuenta para resolverlo? (identificar
?? Por qué ?? riesgos).
Cuando ??
Como cual)

• Adquirir suficiente conocimiento

• Convertirse en un experto del dominio del problema
Los cuatro mundos
Como el Como la máquina
sistema utiliza la representa
Mundo del
información inforamción sobre el
sobre el dominio sujeto dominio de
de la aplicación aplicación

Mundo del Interfases de Mundo del

uso usuario sistema

Justificar las
Mundo del Desiciones de
metas de
desarrollo
desarrollo diseño
Dificultades para la adquisición
• Criterios para definir el dominio del conocimiento
• El conocimiento puede estar distribuido a lo largo de muchos
recursos
• Generalmente no está descrito en forma explícita
• Puede existir conflicto entre diferentes fuentes
• Las metas pueden no ser las mismas entre distintas personas
• Las personas pueden tener diferentes criterios para entender un
problema
• Conocimiento tácito
• Las personas encuentran difícil decir que necesitan o complican
mucho la explicación
Dificultades para la adquisición
• Problemas en la comunicación
• La gente puede estar imposibilitada para decir lo
que realmente necesita
• Problemas políticos o de seguridad
• La gente puede no querer decir que es lo que
necesita
• Si digo algo luego quedo “pegado”
• “Si abro mi negocio y otro se entera pierdo”
Técnicas para toma de requerimientos
• Técnicas tradicionales
• Introspección
• Mirar hacia dentro del
problema
• Documentos existentes
• Análisis de datos
• Entrevistas
• Agenda abierta
• Estructuradas
• Cuestionarios
• Adquisición en grupos
• Grupos enfocados
• Brainstorming
• JAD/RAD
• Prototipación
• Aproximación basada en
representación
• Basada en objetivos
• Basada en escenarios
• Basadas en casos de uso
 Técnicas para toma de requerimientos

• Aproximación contextual • Aproximaciones cognitivas

(social)
• Técnicas etnográficas
• Observación de
participantes
• Etnometodología
• Análisis de discurso
• Análisis de conversación
• Análisis de presentación
• Diseño participatorio
• Análisis de tareas
• Análisis de protocolos
• Técnicas de adquisición de
conocimiento
• Ordenamiento de
tarjetas
• Grillas de repertorio
• Técnicas de escalado de
proximidad

Etnografía: ciencia que tiene por estudio y descripción de las razas o

pueblos, como también su lengua, sus creencias, artesanías, usos,
costumbres y formas de vida
 Aprendiz:
• El desarrollador se vuelve en el aprendiz de
usuario, aprende su trabajo por observación y
preguntando.
• La gente no siempre esta consciente de todas las
tareas que realiza

"Nadie describe mejor lo que hace y por qué lo
hace, que cuando lo esta
haciendo." [Beyer&Holtzblatt]
• El aprendiz demuestra lo aprendido haciéndolo
bajo la supervisión del usuario.
Aprendiz (continuación)

• El usuario generalmente no tiene

tiempo para entrevistas
• El aprendiz ve la misma tarea
repetidamente
• Captura de eventos en tiempo real
• Retroalimentación inmediata
• Establece una relación con los
usuarios y clientes
Cuestionarios
• Ventajas
• Puede obtener información
rápidamente de muchas personas
• Puede administrarse remotamente
• Puede obtener actitudes y
características de los actores
• Desventajas
• Puede obtener un contexto muy
pobre del problema
• No hay entrevistas con usuarios
• Qué mirar?
• Tendencias en la selección de
ejemplos
• Tendencias en la selección de
respuestas
• Ejemplos de tamaño chico (con
poca significancia estadística)
• Preguntas ambiguas (muchos que
no contestan la misma pregunta)
• El cuestionario debe ser testeado
Entrevistas
• Tipos • Difícil la comparación de
• Estructuradas respuestas
• Existe una agenda previa • Administrar las entrevistas
con temarios no es una tarea sencilla
• Libres
• Agenda abierta, no hay
• Que mirar?
temarios previos • Preguntas sin respuestas
• Conocimiento tácito
• Ventajas
• El contexto de discusión
• Ricas en adquisición de
información • Actitud de los entrevistados
respecto de los temas
• Desventajas abarcados
• Muchos datos cualitativos
difíciles de analizar
Técnicas de adquisición en
grupo
• Tipos
• JAD o RAD
• Desventajas
• Enfoque en grupo
• Puede crear grupos poco naturales y
• Brainstorming hacer sentir incómodos a los
• Ventajas participantes
• Interacción más natural entre • Peligro de llevar a una opinión de
la gente, mayor a una grupo que no sea real
entrevista formal • Pueden obtenerse respuestas
• Se puede medir la reacción superficiales a cuestiones técnicas
ante material de estímulo • Se requiere de un facilitador muy
• Presentaciones, maquetas, entrenado
etc. • Que mirar?
• Tendencias en los ejemplos
• Dominancia y submisión
Colección de “datos complejos”
• Identificar los grupos de estos
datos
• Hechos y figuras, información
financiera, etc.
• Reportes usados para toma de
decisiones,...
• Resultados obtenidos,
información de marketing,..
• Ejemplos
• Obtener datos representativos
del conjunto de la población de
elementos
• Ejemplos propuestos ! tomar
aquellos considerados más
relevantes
• Ejemplos aleatorios ! tomar cada
n casos
• Ej. Aleatorios por capas !
identificar capas del problema y
tomar un caso de cada uno
• Ej. Aleatorios por cluster !
generar subconjuntos relacionados
y tomar un ejemplo de él.
• Tamaño del ejemplo
• Balancear entre costo y relevancia
del ejemplo
Usando Casos de uso
• Dibujar los límites
• Identificar los actores fuera• Para cada caso de uso
de los límites del sistema • Escribirlo
que interactúan con él • Especificar reglas para elección
• Para cada factor del mismo y para interacturar con
• Identificar los posibles él
casos de uso • Considerar alternativas
• Establecer escenarios • Ver posibles superposiciones de
concretos para ilustrar casos de uso
cada caso de uso Template de caso de uso:
• Agrupar escenarios Nombre:

similares en casos de uso Resumen:

si son una variación Actores:

sobre un tema Precondiciones:

Descripciones:

Excepciones:

Postcondiciones:
Escenarios
• Definición
• Secuencia específica de
interacciones entre actores y
sistemas
• Tienden a ser cortos
• Puede sen
• Positivos (comportamiento
requerido)
• Negativos (interacción no
deseada)
• Pueden estar en modo
indicativo u optativo
• Ventajas
• Muy natural: se tratan de
usar de manera expontánea
• Los escenarios cortos son
muy buenos para ilustrar
interacciones específicas
• Desventajas
• Falta de estructuración: se
necesitan casos de uso o
modelo de tareas para
proveer una visión de alto
nivel.
Registro de
Requerimientos
 Registro de los requerimientos:
• Para manejar los requerimientos, estos deben
tener:
• Un número único de ID
• Tipo
• Descripción: una frase que describe la intención del
requerimiento.
• Propósito: Por qué se considera importante?
• Fuente: ¿Quién determinó este requerimiento?
• Dominio: área del sistema donde se encuentra el
requisito
Registro de los requerimientos (cont.)

• Criterio de evaluación: Prueba no-ambigua que indica

si una solución cumple este requerimiento
• Satisfacción del cliente: Grado de satisfacción si el
criterio se cumple exitosamente (1=no importa
mucho-5=muy satisfecho)
• Insatisfacción del cliente: Grado de insatisfacción si
el criterio no se cumple (1=no importa mucho-5=muy
molesto)
Registro de los requerimientos (cont.)

• Dependencias: requerimientos que usan la misma

información o que ocasionan cambios.
• Conflictos: requerimientos que están en conflicto
con este
• Materiales de apoyo: Indicación a las definiciones y
documentos que lo ilustran.
• Historia: Creación, cambios y eliminación

 Requerimientos Funcionales

• Describir una acción que debe realizar el producto

• No escribir soluciones

Cada evento/caso de uso tiene muchos requerimientos
funcionales
• Algunos son parte también de otros eventos
• Iniciar descomponiendo los casos de uso en pasos:
• serie de pasos para completar el trabajo de un caso de uso
• Acciones que puede reconocer el usuario
• Posiblemente una interacción entre usuario y máquina
• número limitado de pasos

El uso del formato ayuda para determinar qué tan completa está la
especificación de requerimientos.
Restricciones:

• Restricciones globales son las propiedades que aplican a todo el producto

• Esta parte de la especificación probablemente será escrita por la
administración del proyecto.
• Propósito del sistema
• El cliente para el producto
• Usuarios del producto
• Convenciones de nomenclatura y definiciones
• Hechos/datos relevantes
• Restricciones del proyecto
• Suposiciones
Restricciones (cont.)

• Para las convenciones de nomenclatura se sugiere el uso de los diccionarios

estándar nacionales/internacionales para la industria
• Buenos nombres son fácilmente distinguibles y no requieren muchas
explicación.
• Cada nombre deberá tener una definición.
• Deben definirse todas las abreviaturas, términos y siglas.
• Hechos / datos relevantes: Estan confomados por fuerzas, sistemas,
actividade del mundo externo que pueden tener efecto en el producto.
• Se identifican cambios que deben tomarse en consideración.
• Cambios probables en las fronteras del producto.
• Cambios tecnológicos, a otros productos, en la estructura organizacional, al
sistema legal, políticas, etc.
Restricciones del proyecto:

• Tecnológicas, de presupuesto, tiempo, etc. razones por

las que se restringe la manera en que se crea el
producto.
• Siempre indagar el por qué de estas restricciones y
anotar todas las restricciones y sus razones para el
producto.
 Requerimientos No-Funcionales

• Describen las propiedades o características que el producto debe

tener.
• Cada requerimiento funcional tiene asociados requerimientos no-
funcionales
• Algunos pueden afectar a nivel de eventos, otros a todo el
producto.
• Requerimientos no-funcionales:
• Apariencia y sensación: (Bosquejos)
• Usabilidad: Depende de la definición de los usuarios,
cuantificable por los criterios de evaluación.
• Performance: Requerimientos reales del performance,
velocidad, presición, disponibilidad, seguridad, nivel de
servicio, volúmenes de datos, etc.
• Operacional: Ambiente en el que el usuario operará el producto
y productos con los que colabora.
 Requerimientos no-funcionales
• Mantenibilidad: Tiempo esperado y tiempo permitido para
realizar cambios de mantenimiento, portabilidad.
• Seguridad: requerimientos para permitir el acceso, pruebas de
integridad para prevenir mal -uso no intencionado por usuarios
autorizados, auditorías para detectar mal-uso, recuperación
despues de un error, prueba de integridad después de un hecho
anormal. Considerar involucrar a un experto en seguridad.
• Políticas: Factores que podrían hacer al producto inaceptable
por razone políticas, este requerimiento puede no ser medible,
puede ser especificado como restricción.
• Aspectos legales: Examinar sistemas adyacentes, considerar sus
requerimientos y derechos legales, cite leyes relevantes al
producto, contar con el apoyo de abogados, restriccione
impuestas por estándares.
Definición de Requerimientos
Salidas de la Fase
Documento de Definición de Requerimientos.
1. Introducción
1.1 Propósito. Narrativa que describe el propósito del sistema a
desarrollar.
1.2 Alcance. Narrativa que establece el alcance del sistema a
desarrollar.
1.3. Contexto (Descripción general). Narrativa que describe a
grandes rasgos, el sistema a desarrollar.
1.4 Definiciones, acrónimos y abreviaciones. Listado de
acrónimos, con su significado.
1.5 Referencias. Se colocan las referencias de los documentos
utilizados para construir el URD.

44
Definición de Requerimientos
Salidas de la Fase
Documento de Definición de Requerimientos
2. Descripción General
2.3 Características de los Usuarios. Narrativa que establece
los diferentes tipos de usuarios que interactuarán con el
software, y las características de cada uno de ellos
(atribuciones, y limitaciones).
2.2 Perspectivas del Producto. Narrativa que establece que es
lo que se espera obtener con el producto de software en
desarrollo.
2.3 Ambiente Operacional. Narrativa que establece las
características del escenario de trabajo del software.

45
Definición de Requerimientos
Salidas de la Fase
Documento de Definición de Requerimientos.
2. Descripción General
2.4 Suposiciones y Dependencias. Narrativa que establece
(por escrito) todas aquellas suposiciones, que se han hecho
(con el consentimiento del cliente/usuario), sobre alguna
característica del software a desarrollar.
2.5 Restricciones Generales. Narrativa que establece cuáles
son las restricciones de funcionamiento del software. Por
ej. que funcione en Windows y UNIX, que funcione en el
actual ambiente operacional, etc.
2.6 Descripción del Modelo. Diagrama + explicación del
modelo de funcionamiento global actual. Se puede utilizar
DFD, diagramas de procesos, de transición de estados, etc.

46
Definición de Requerimientos
Salidas de la Fase
Documento de Definición de Requerimientos.
3. Requisitos del Sistema
3.1 Requisitos de Usuario. Listado de requisitos que representan la
necesidad del usuario/cliente.
3.1.1 Restricciones globales
3.1.2 Requerimientos Funcionales
3.1.3 Requerimientos No-Funcionales
3.1.4 Restricciones

47
Definición de pruebas
de requisitos
 Quality Gateway
• Evaluación de los requerimientos
• Para incluirlos en la especificación cada requerimiento debe pasar el
umbral de calidad.
• Sirve para prevenir la infiltración y la fuga de requerimientos.
• Para pasar debe :
• Tener un criterio de evaluación
• Tener una identificación única y referencias a los eventos y casos
de uso
• Ser relevante
• Ser viable
• Tener un valor para el cliente
• No ser adorno
• Estar completo
• Usar la tecnología correcta
• Los requerimientos rechazados se regresan al interesado
• Ser mantendrá una lista de requerimientos rechazados y la razón
Criterios de Validación

• Es una meta numérica que la solución debe cumplir.

• No se puede diseñar una solución a un requerimiento sin una
manera de saber si se ha logrado resolverlo o no.
• Para los requerimientos funcionales el criterio especifica cómo
establecer si cumple sus objetivos.
• Para los requerimientos no-funcionales cuantifican el
comportamiento resultante.

Tipo de requerimiento
10. Apariencia y sensación
11. Usabilidad
12. Performance
13. Operabilidad
14. Mantenibilidad
15. Seguridad
16. Requerimientos Políticas
17. Requerimientos legales
Métricas
Escalas de evaluación
Cumple con el estándar?
especificar quién/cómo probarlo
Tiempo requerido para aprender
Tiempo de entrenamiento
Realización de funciones en tiempo
planteado
Tiempo para completar la acción
Cuantificación del tiempo/facilidad de uso
Tiempo permitido
Esfuerzo requerido para portarlo
Cuantificar quién ha tenido acceso
Quién los acepta (no son cuantificables)
Opinión del abogado
 Prueba de los criterios

• Cumple con los objetivos y la intención del

producto?
• Provoca el comportamiento correcto?
• Puede ser probado?
• Las pruebas son eficientes (costo)?
• Es subjetivo el criterio?
• Esta definida la terminología?
• Es ambiguo?
Pruebas de Relevancia

• Se encuentra dentro del contexto del

proyecto?
• Cumple con las restrucciones globales y el plan
estratégico del producto?
• Es consistente con el producto?
Pruebas de viabilidad

• Los usuarios son capaces de usar el producto?

• Tenemos la habilidad tecnológica para construir
el producto?
• Se tienen los medios y el tiempo para ello?
• Es aceptable a todos los intersados?
• Se puede hacer de manera eficiente?
• Cuáles son las consecuencias del requerimiento?
Reutilización de Requerimientos
 Reutilización de Requerimientos

• Generalmente los sistemas no son completamente únicos

en todos sus componentes
• Hay oportunidad de reutilizar requerimientos
• Aunque puede ser difícil reconocer los componentes
reusables
• Con la ayuda de abstracción y el uso de patrones re
requerimientos es mas fácil
• Patrones: guías reusables que se pueden adaptar a
circunstancias específicas, se pueden abstraer de
cualquier tipo de sistema.
• Estos patrones se pueden basar en los casos de uso.
 Revisión de requerimientos
• Después de escribir la especificación de requerimientos se debe
realizar una revisión, para asegurar la calidad y completez de
la especificación
• Hasta este punto los requerimientos individuales ya pasaron el
punto de control de calidad (quality gateway).
• La revisión de la especificación busca requerimientos faltantes,
checa consistencia, conflictos y ambigüedad.
• Uso de un filtro de requerimientos (conjunto de reglas para
determinar si los requerimientos van conforme a la
especificación.
• Análisis de riesgos
• Determinar el esfuerzo contando function points por cada
evento/caso de uso
Revisión (cont.)

• Determinar el valor para el cliente (suma de los valores de

satisfacción del cliente)
• Mantener una base de datos de los requerimientos
rechazados
• Realizar un post-mortem al proceso de requerimientos

• El proceso de revisión es iterativo hasta que se resuelven

todas las inconsistencias, conflictos y ambigüedades.
Tipos de Requerimientos

• Restricciones globales
• Requerimientos Funcionales
• Requerimientos No-Funcionales
 Restricciones globales
• Afectan a todo el producto y son determinadas
por el usuario y los que administran el proyecto/
producto.
1. Propósito del sistema
2. El cliente
3. El usuario
4. Convenciones para la nomenclatura y las definiciones
5. Hechos relevantes
6. Restricciones del proyecto
7. Suposiciones
Requerimientos Funcionales

• Lo que el producto debe hacer

8. Alcance del sistema
9. Requerimientos Funcionales y de datos
 Requerimientos No-Funcionales

• Apoyan a las funciones, son las propiedades que

el producto debe tener.
10. Apariencia y sensación
11. Usabilidad
12. Performance
13. Operabilidad
14. Mantenibilidad
15. Seguridad
16. Requerimientos Políticas
17. Requerimientos legales