Especificación y

Análisis de
Requerimientos
Dra. Ingrid Kirschning
Especificación y análisis de
requerimientos
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.
 REQUERIMIENTOS FUNCIONALES

Como se describen y clasifican los requerimientos funcionales

Los requisitos funcionales de un software se suelen registran en la 

matriz de trazabilidad de requerimientos y en la 
especificación de requerimientos de software, este último, documenta las
operaciones y actividades que el sistema debe poder desempeñar.

Entre los posibles requerimientos funcionales de un sistema, se incluyen: 


Descripciones de los datos a ser ingresados en el sistema.

Descripciones de las operaciones a ser realizadas por cada pantalla.

Descripción de los flujos de trabajo realizados por el sistema.

Descripción de los reportes del sistema y otras salidas.

Definición de quien puede ingresar datos en el sistema.

Como el sistema cumplirá los reglamentos y regulaciones de sector o generales que le
sean aplicables.
 EJEMPLOS REQUERIMIENTOS FUNCIONALES PROCESO O ÁREA DE NEGOCIO


El sistema enviará un correo electrónico cuando se registre alguna de las siguientes transacciones: pedido de venta
de cliente, despacho de mercancía al cliente, emisión de factura a cliente y registro de pago de cliente.

Se permitirá el registro de pedidos de compra con datos obligatorios incompletos, los cuales podrán completarse
posteriormente modificando el pedido. Antes de poder aprobarse los datos del pedido deben estar completos.

Al aprobar un pedido, la solicitud pasará al siguiente paso del flujo de trabajo (workflow) de aprobación configurado en
el sistema.

El sistema permitirá a los usuarios autorizados el ingresar planes y cronogramas de  proyecto.

El sistema permitirá aprobar, cambiar o actualizar planes y cronogramas de proyecto.

El sistema permitirá el envío automatizado de cartas de entrega de órdenes directamente al almacén.

A cada orden se le asignará un identificador único, que será utilizado para identificarla en todos los procesos
subsecuentes que se realicen sobre esta.

Al ingresar ordenes de entrega, toda orden de entrega estará asociada a un pedido de venta.

La facturación de pedidos de venta se realizara en lotes, por medio de una pantalla de pedidos pendientes de
facturación, la cual mostrará los pedidos no facturados. Una vez facturados los pedidos no se mostrarán en esta lista.

El sistema también permitirá el registro de facturas manuales no asociadas a pedidos, sin embargo, estas requerirán
autorización por parte del grupo de Gerentes antes de ser contabilizadas.

El proceso de compras en el sistema abarcará los siguientes pasos y transacciones: Ingreso de la requisición, emisión
de la solicitud de cotización y emisión de la orden de compra.

Los elementos de la solicitud de cotización serán los mismos de la requisición asociada, al igual que los de la orden
de compra. El sistema permitirá la emisión de solicitudes de cotización y órdenes de compra parciales.

La contabilización de transacciones de facturas de venta y facturas de compra podrá configurarse para realizarse de
forma automatizada a su registro, o manualmente en lotes (Proceso Batch).

El software debe poder emitir los siguientes estados financieros: Balance general, Estado de ganancias y pérdidas,
Estado de flujos de efectivo. Además, debe poder emitir un listado de mayor general y mayor analítico.

Los pedidos de compra que excedan los montos establecidos en el flujo de liberaciones de pedidos configurados,
deberán pasar por las aprobaciones establecidas en dicho flujo de aprobación.
 EJEMPLOS REQUERIMIENTOS FUNCIONALES DE INTERFAZ GRÁFICA


La solución validara automáticamente el cliente asociado a una orden con el sistema de gestión de
contactos.

El campo de monto acepta únicamente valores numéricos con dos decimales.

El campo fecha de transacción acepta únicamente fechas anteriores al día de hoy (día actual).

El campo nombre acepta caracteres alfabéticos únicamente.

El campo dirección acepta caracteres alfabéticos, numéricos y especiales.

El campo país consistirá en una lista de preselección. El país asociado a una dirección debe ser previamente
registrado en el sistema.

El campo estado, provincia o departamento consistirá en una lista de preselección. A los usuarios se les
presentará únicamente los estados asociados al país seleccionado previamente. El departamento o
provincia a seleccionar deberá ser registrado en la funcionalidad correspondiente.

El campo material de elemento de la pantalla de requisiciones de compra será una lista de preselección, que
mostrará únicamente los materiales registrados en el maestro de materiales.

El campo fecha contable acepta únicamente fechas que correspondan con periodos contables que estén
abiertos en el sistema.

La pantalla de registro de pago puede imprimir los datos en pantalla a la impresora.

Se mostrará el nombre, tamaño total, espacio disponible y formato de un pen drive o flash drive conectado al
puerto USB del computador.

Ejemplos de requerimientos funcionales legales o regulatorios


El sistema controlará el acceso y lo permitirá solamente a usuarios autorizados.


La base de datos será implementada con trazas de auditoría.

Las hojas de cálculo aseguraran los datos usando firmas electrónicas.

El sistema permitirá elaborar y emitir el reporte regulatorio XX, según los requerimientos establecidos en el
reglamento y ley aplicable.

Los libros de venta y de compras serán emitidos en el formato establecido por las autoridades tributarias de dicha
materia.



Ejemplos de requerimientos de seguridad


El sistema controlará el acceso y lo permitirá solamente a usuarios autorizados. Los usuarios deben ingresar al
sistema con un nombre de usuario y contraseña.

El sistema enviará una alerta al administrador del sistema cuando ocurra alguno de los siguientes eventos: Registro
de nueva cuenta, ingreso al sistema por parte del cliente, 2 o más intentos fallidos en el ingreso de la contraseña de
usuario y cambio de contraseña de usuario.

Los integrantes del grupo de usuarios de analistas pueden ingresar solicitudes pero no pueden aprobarlas o
borrarlas.

Los integrantes del grupo de usuarios de gerentes pueden ingresar y aprobar solicitudes, pero no pueden borrarlas.

Los integrantes del grupo de usuario de administradores no pueden ingresar o aprobar solicitudes, pero si pueden
borrarlas.

Cualquier intercambio de datos vía internet que realice el software se realizará por medio del protocolo encriptado
https.
Ejemplos de requerimientos no funcionales


En un primer nivel estos pueden clasificarse en requerimientos de producto, organizacionales y externos.

En un segundo nivel, los requerimientos de producto pueden clasificarse en requerimientos de usabilidad, eficiencia,
dependibilidad y seguridad. A su vez, los requerimientos organizacionales pueden clasificarse en requerimientos de
entorno, organizacionales y de desarrollo. Asimismo, los requerimientos externos pueden clasificarse en requerimientos
regulatorios, éticos y legislativos.

Ejemplos de requerimientos no funcionales de producto
Eficiencia

El sistema debe ser capaz de procesar N transacciones por segundo. Esto se medirá por medio de la herramienta
SoapUI aplicada al Software Testing de servicios web.

Toda funcionalidad del sistema y transacción de negocio debe responder al usuario en menos de 5 segundos.

El sistema debe ser capaz de operar adecuadamente con hasta 100.000 usuarios con sesiones concurrentes.

Los datos modificados en la base de datos deben ser actualizados para todos los usuarios que acceden en menos de 2
segundos.
Seguridad lógica y de datos

Los permisos de acceso al sistema podrán ser cambiados solamente por el administrador de acceso a datos.

El nuevo sistema debe desarrollarse aplicando patrones y recomendaciones de programación que incrementen la
seguridad de datos.

Todos los sistemas deben respaldarse cada 24 horas. Los respaldos deben ser almacenados en una localidad segura
ubicada en un edificio distinto al que reside el sistema.

Todas las comunicaciones externas entre servidores de datos, aplicación y cliente del sistema deben estar encriptadas
utilizando el algoritmo RSA.

Si se identifican ataques de seguridad o brecha del sistema, el mismo no continuará operando hasta ser desbloqueado
por un administrador de seguridad.
Ejemplos de requerimientos no funcionales


Seguridad industrial

El sistema no continuará operando si la temperatura externa es menor a 4 grados Celsius.



El sistema no continuará operando en caso de fuego. (Ej. Un ascensor).




Usabilidad

El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 4 horas.

La tasa de errores cometidos por el usuario deberá ser menor del 1% de las transacciones totales ejecutadas en el
sistema.

El sistema debe contar con manuales de usuario estructurados adecuadamente.

El sistema debe proporcionar mensajes de error que sean informativos y orientados a usuario final.

El sistema debe contar con un módulo de ayuda en línea.

La aplicación web debe poseer un diseño “Responsive” a fin de garantizar la adecuada visualización en múltiples
computadores personales, dispositivos tableta y teléfonos inteligentes.

El sistema debe poseer interfaces gráficas bien formadas.
 Qué es un Concepto?
Ciclo de vida “V”

Why? Concepto Verificación y Validación Pruebas acept.

What? Análisis Pruebas integ.

How? Diseño Pruebas unit.

Do! Código

Concepto : conocimiento general del proceso del negocio.

entrega: diag. de contexto, diag. de Entidad-Relación, Casos de Uso
Modelo de Procesos “Volere”
Fases de la especificación y análisis
de requerimientos

 Blastoff
 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 el 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.
Diagrama de contexto:


Por cada sistema adyacente se dibujan
interfases para identificar su relevancia en el
estudio.

Los sistemas adyacentes se derivan de los
dominios de interés que interactúan con el
dominio de aplicación.

Las interacciones deben ser comprensibles.
(graf)
 (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ísttcas de las conexiones.

El contexto contiene políticas de procesamiento y
datos almacenados
Estimado inicial de costo/esfuerzo


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?
Recolección de Requerimientos
 En esta etapa se deben
 Extraer los requerimientos de los
usuarios
 Descubrir el mayor número posible
de requerimientos
 Utilizar diferentes métodos para
los requerimientos conscientes,
inconscientes y los no-imaginados
Métodos para la recolección de requerimientos

 Aprendiz
 Escenciales
 Entrevistas
 Herramientas
 Mind Maps
 Brainstorming
 Particionamiento del contexto
 Identificación de eventos y Casos
de uso
 Uso de Video
 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
Requerimientos escenciales


Diferencia entre la implementación
actual y el requerimiento escencial

Estan presentes
independientemente de la
tecnología

Buscar al contenido de
información, no el medio.
Entrevistas


Ir a ellos para entrevistarlos en su
lugar de trabajo

Explicar la razón de la entrevista

Entrevistar primero al usuario más
experimentado

Preguntar, escuchar la respuesta y
retroalimentar lo entendido
Entrevistas (cont.)


Dibujar modelos, utilizar la
terminología del usuario

Guardar ejemplares de
documentos/artefactos

Agradecer al usuario su tiempo

Búsqueda de fallas potenciales: el
requerimiento es la falla
establecida de forma positiva.
 Brainstorming

El grupo de desarrolladores se reune para una
lluvia de ideas

Muchas ideas, ideas nuevas, toda idea es
buena

No deben evaluarse, debatir ni criticar

No limitarse por lo posible

Luego la lista de ideas es evaluada, ordenada
(votación)
-> 60 ideas locas pueden contener 5 ideas
geniales.
Particionamiento del contexto


El contexto se divide entre los
participantes en
unidades discretas (desde el punto
de vista del usuario)

Eventos distinguibles

Casos de uso
 Identificación de eventos y
Casos de uso


Los eventos se identifican por las
entradas y salidas del trabajo

Los eventos son:
 algo que sucede fuera del trabajo
y a lo que el trabajo debe
responder.
 Importante
 Reconocible.
 Casos de uso:


Porción de actividad: respuesta a un
estímulo externo o temporal

Colección única de procesos y datos para
cada evento/ caso de uso

La respuesta es contínua

Cada proceso se puede describir
 Casos de uso (cont.)


Cada evento/caso de uso tiene un número de
requerimientos funcionales y no-funcionales

Algunos requerimientos no-funcionales se
aplican a todo el evento

Utilícense los eventos como puntos de partida
para determinar los requerimientos,
observaciones y entrevistas.
 Uso de Video

Grabar en video a los participantes y
desarrolladores durante las sesiones de
brainstorming y talleres de casos de uso.

Grabar las entrevistas y observaciones en el
trabajo.

Grabar a los usuarios durante su trabajo (ellos
describen cómo lo realizan).

Registro detallado de las prácticas de los usuarios
Grabar cada evento/caso de uso.

Los videos son una ayuda en la búsqueda de
requerimientos.
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 usurio
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
 Otros temas importantes:

Puntos que salen eventualmente durante el
proyecto
18.Discusiones abiertas
19. Soluciones comerciales
20. Problemas nuevos
21. Tareas
22. Cutover
23. Documentación del usuario
24. Sala de espera
 Registro de los requerimientos:

Para manejar los requerimientos, estos deben
tener:
 Un número único de ID
 Tipo
 Lista de los eventos y casos de uso que lo
contienen.
 Descripción: una frase que describe la intención
del requerimiento.
 Propósito: Por qué se considera importante?
 Fuente: ¿Quién determinó este requerimiento
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 estan en
conflicto con este
 Materiales de apoyo: Indicación a las
definiciones y documentos que lo ilistran.
 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.
Requerimientos Funcionales

 Identificación de los requerimientos:El darles un número

único de identificación permite recuperarlos y relacionarlos
con mayor facilidad.
 Un requerimiento puede estar relacionado a varios eventos
 Requerimientos globales se relacionan a todos los eventos
 Utilizando los formatos para escribir requerimientos (pre-
definidos por la empresa), la información obtenida, las listas
de eventos y casos de uso conforman una vez terminadas
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.
 Verificación y Validación de Requerimientos


Prevenir la infiltración de requerimientos: los que entran
al producto depués del proceso de análisis de
requerimientos.

Prevenir la fuga de requerimientos: aquellos cuya fuente
se desconoce

Estos incrementan desmesuradamente el costo y el
tamaño del producto.

Se pueden usar métricas de función para controlar la
infiltración de requerimientos.

El número de function points puede ser una medida para
limitar el tamaño del desarrollo.
 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.
 Métricas
Tipo de requerimiento Escalas de evaluación
10. Apariencia y sensación Cumple con el estándar?
especificar quién/cómo probarlo
11. Usabilidad Tiempo requerido para aprender
Tiempo de entrenamiento
Realización de funciones en tiempo
planteado
12. Performance Tiempo para completar la acción
13. Operabilidad Cuantificación del tiempo/facilidad de uso
14. Mantenibilidad Tiempo permitido
Esfuerzo requerido para portarlo
15. Seguridad Cuantificar quién ha tenido acceso
16. Requerimientos Políticas Quién los acepta (no son cuantificables)
17. Requerimientos legales 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?
Prototipos y Modelado de Situaciones


Por qué usar prototipos?
 Algunos requerimientos no son obvios o no están
completos
 Algunos usuarios tienen dificultades para formular sus
deseos
 Algunos desarrolladores tienen dificultades para
entender los que se está pidiendo
 Darles a los usuarios la oportunidad de "usar" el
requerimiento
 Determinar la factibilidad o necesidad del requerimiento
 Permite encontrar mas requerimientos escondidos.
 Situaciones

 Prototipos son generales, situaciones son específicas

 Situaciones: relatos que ilustran acciones para un caso
especíifico
 Cada situación debe tratar un punto específico
 Trata un (o parte de uno) evento / caso de uso a la vez
 Esclarecen implicaciones de un requerimiento
 Ayudan a encontrar requerimientos faltantes
 Utilizar medios flexibles (texto, figuras, modelos)
Prototipos de baja fidelidad

 Baratos
 No requiere habilidades de programación
 Util medio de comunicación
 Identifica mercado y requerimientos de
usuario
 Genera ideas de funcionalidad
 Demostración general del funcionamiento del
producto
Construcción de un prototipo
de baja fidelidad


Se hace en una etapa temprana en el ciclo de
desarrollo

Restringir el prototipo a las tareas más
comunes

La meta es evaluar alternativas-no invierta
mucho ego

Enfoque de brocha ancha

Enfoque en aspectos del producto no del
prototipo
 Prototipos de alta fidelidad

Navegación y flujo

Interactivo

Demostración fiel del comportamiento

Provoca el surgimiento de requerimientos de usabilidad

Pretenden ser como el producto final

Completa funcionalidad de la interfaz

"La interfaz es el producto"

Exploración interactiva de las funciones del producto

Se realiza junto con una especificación escrita

Sin embargo es un prototipo desechable

No hay compromiso de entregar exactamente la misma
interfaz
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.
 Ejemplo:


Un patrón de requerimientos contiene el nombre del patrón, una
descripción del contexto, las razones o fuerzas que mandan este
requerimiento, la solución y una lista de patrones relacionados.
Esto se acompaña de un diagrama de contexto, especificación,
diagramas de los sub-patrones, modelos de datos y definiciones
de datos.

Para que los patrones se puedan reutilizar es necesario
abstraerlos.

Existen diversos niveles de abstracción.

Primero hay que encontrar el patrón:
 Buscando similitudes entre cosas aparentemente diferentes.

Usar: palabras clave, nombres de procesos y políticas, entradas
y salidas de procesos, eventos / casos de uso, topología,
nombres de flujo de datos, almacenamientos y sus contenidos.

Analizar el dominio (area de aplilcación) y encontrar
características generalizadas dentro del dominio, identificar y
especificar objetos y operaciones comunes, modelando el
dominio.
 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.
 Post-Mortem


El objetivo es aprender del proyecto.

Revisar la eficiencia de les técnicas de requerimientos
utilizadas

Qué aspectos deberían hacerse de manera diferente?

Usar un evaluador ?

Buscar los principales errores (sin buscar culpables)

Buscar los principales éxitos (sin premiar a nadie)

Escribir un reporte que se distribuye entre los miembros
del equipo y administración.
 Modelado de Requerimientos

Modelos de Contexto
 Diagrama de contexto: Punto de partida para todo modelado
 Representa al sistema y sus conexiones al mundo exterior.
 contienen: sistema, sistemas adyacentes y la
información que provee cada uno o los datos que flujen entre
el sistema y cada uno de los sistemas adyacentes.
 Cada proceso se escribe dentro de un círculo que recibe
datos, transfiere datos a otro proceso o sistema adyacente o
los almacena, su nombre refleja el proceso que realiza.
 Almacenes de datos se dibujan con dos líneas paralelas
horizontales.
 Por convención no se muestran flujos de 'tiempo'
 IDENTIFICACIÓN DE EVENTOS

A partir del diagrama de contexto se pueden
identificar los eventos.

Se listan junto con sus datos asociados.

En el diagrama de contexto nos enfocamos al
objetivo (scope) del sistema identificando los flujos
de datos alrededor de los límites del sistema.
 Pero es difícil obtener un diagrama de contexto 100%
completo desde el principio - sin embargo es un
comienzo-se encuentra lo relevante y lo escencial.
 Modelado de Datos

Confirma y ayuda a completar el diagrama de
contexto.

Se utilizó la descripción del negocio para construir el
contexto. También es la fuente de información para
identificar entidades y sus relaciones.

Para ello se toman en cuenta diferentes puntos de
vista (Viewpoints) ya que ayudan a distinguir
diferentes aspectos del negocio.
 Puntos de Vista

Punto de vista del estado actual : Analiza la
situación actual del proceso (necesario para entender
el negocio), documenta la realidad existente.

Punto de vista escencial: es la visión “perfecta” del
sistema, sólo muestra requerimientos y excluye todo
lo que existe actualmente sólo por la manera en que
se implementa el sistema.

Punto de vista de datos: Representado con el
modelo de datos, ignora los procesos y se concentra
en modelar la información escencial del sistema.
 Punto de vista de Datos (Data
Viewpoint)

El modelo de datos es una abstracción

Muestra la información almacenada por el sistema

Descarta procesos que usan la información y la
manera en que se implementa
 Se ven sólo los datos reales, no cómo se organizan
por conveniencia de cierto tipo de base de datos
 Modelos de Datos

También se conocen como los modelos entidad-relación

Entidades: Colección de atributos que describen algo, real o
abstracto, que es importante para el sistema.

La abstracción depende del punto de vista/dueño del sistema

Tienen un propósito definible

Tiene muchas instancias, un sólo identificador

Atributos: Datos acerca las entidades y relaciones
 Pertenecen a sólo una relación/entidad
 Tienen un valor
 No tienen un orden, pero las principales se escriben primero
 Se pueden derivar
 El mismo tipo de atributo en diferentes instancias de una
entidad no debería tener el mismo valor
 Modelos de Datos(cont.)


Relaciones: Asociaciones entre entidades
 Pueden tener atributos
 No tiene dirección
 Se nombran utilizando verbos hechos sustantivos

Cardinalidad: Muestran cuantas instancias de cada entidad pueden
participar en una instancia de relación.
cardinalidad
1 N
Cliente solicita Catálogo

entidad relación entidad

 Modelos de Datos(cont.)


Diccionario de datos: Todos los flijos de datos se
describen en el diccionario de datos, así como todas
las entidades.
 nombre_flujo_dato = *comentario* dato1+dato2+...
 nombre_entidad = nombre_registro + fecha_registro +
compañía_registradora
 opcionales (a)
 repeticiones {a}
 seleccionar uno [a | b ]
 *comentario*
 Diagramas de Flujo de Datos

Construir modelos funcionales (que funcionan)

Cada proceso debe recibir datos suficientes y
necesarios

El modelo excluye todo tipo de mecanismos

Sólo modela al sistema que contiene datos y
requerimientos funcionales.

Flujos de datos compuestos se unen con un signo ‘+’:
dato1 + dato2

Flujo de datos: representan el movimiento de datos de
un lugar a otro

Datos no pueden ir directamente de una base de
datos a un terminal o viceversa.
 Diagramas de Flujo de Datos

El diagrama del contexto se partiociona.

El mejor particionamiento es el que resulta en las
interfaces mas estrechas -> dónde hay sólo un
mínimo número de datos conectando al proceso con
otros.

Todas las burbujas y los flujos de datos deben tener
nombres representativos (evitar algo como D1, D2…)

Se numeran para su identificación -> no indican
secuencia de procesamiento.

Deben tener entrada y salida de datos

DFDs de sistemas complejos se dividen en niveles.
 Modelos de Eventos

Descomposición en eventos:
 Partir un problema grande en partes pequeñas
 Particiones naturales con mínimas conexiones a otras partes, con
fronteras claras y cuantificables y encontrando usuarios que son
expertos para esa parte.

Una respuesta de un evento es iniciado por un evento del exterior del
sistema o por el paso del tiempo.

Un sistema responde a eventos

El caso de uso es el alcance de la respuesta limitado por los sistemas
adyacentes y bases de datos: colección única de procesos y datos que
responden a cada evento

la respuesta es contínua (en tiempo)

cada proceso se puede describir

los datos se pueden definir por cada evento

luego se modelan:
 Modelos de Eventos(cont.)


Reglas para los eventos:
 El sistema puede identificar el flujo de datos accionador y sabe
cómo responder
 Eventos temporales se dan cuando es hora para que el sistema
haga algo, pero la hora de hacerlo puede ser determinada por un
sistema adyacente.
 El evento se puede reconocer como un evento del sistema
 La respuesta es única para dado flujo de datos accionador
 Un mismo sistema adyacente puede accionar diferentes eventos
 La respuesta es contínua y se detiene con la escritura de datos a
almacenamiento y el envío de las salidas a los sistemas
adyacentes
 Una entidad física puede ser un sistema adyacente para un evento
y parte de un proceso para otro evento.
 Modelos de Eventos (cont.)


Nomenclatura:
 para eventos externos: [nombre del sistema adyacente]
+razón por la cual envía el flujo de datos al sistema
 para eventos temporales: [Hora de producir]+ nombre del
flujo de datos o razón por la cual se envía el flujo de datos
al sistema adyacente

Cada evento se trata como un caso de uso

Cada evento es modelado

Cada evento es bien conocido por un usuario

Es conveniente numerar los eventos

Cada respuesta a estos eventos se modela también.