ANALISIS DE REQUERIMIENTOS DE SOFTWARE

1
ANALISIS DEREQUERIMIENTOS DE SOFTWARE

• UNIDAD 5
• Jesús Martínez San Germán

2
Contenido

• Análisis de Requerimientos de Software
• 5.1 Fase Preliminar
• 5.2 Fase de Análisis
• 5.3 Principios de Análisis
• 5.4 Modelo de Análisis
• 5.5 Técnicas de Especificación
• 5.6 Especificación de Requerimientos de Software

3
5.1 Fase Preliminar
4
Análisis de las áreas de negocio

• define grupos de funciones y datos de negocio
  naturalmente cohesivos (Martin)
• lleva a cabo algunas de las mismas actividades
  que el ISP, pero en un alcance más restringido en
  las áreas de negocio individuales
• identifica sistemas de información existentes
  (viejos) / determina la compatibilidad con el
  modelo del nuevo ISP
• define sistemas que son problemáticos
• defne sistemas que son incompatibles con el nuevo
  modelo de información
• comienza a establecer las prioridades de
  reingeniería

5
El proceso BAA
admin.
manufactura
QC
distrib.
ventas
cont
ing.
Diagram. Descomp. Procesos
Matrices v.g., matriz entidad/ proceso
Modelo de Flujo de Procesos IDEF0/3
Modelo de Datos E/R
6
Ingeniería de Producto
El producto completo
Análisis de sistema
(Vista Panorámica)
características
Ingeniería de
software
hardware
componentes
(Vista de Dominio)
Requerimiento de procesamiento
Modelo
funciones
comportamiento
datos
Análisis y Diseño
(Vista de Elemento)
componentes
Ingeniería
de programa
Software
Construcción
e
Integración
(vista detallada)
7
Ingeniería deRequerimientos

• Licitación determinar qué requiere el usuario
• Análisis y negociación entender las relaciones
  entre varios requerimientos de clientes y
  conformar esas relaciones para lograr un
  resultado exitoso
• Especificación de requerimientos construir un
  modelo de requerimientos tangible

8
Ingeniería de Requerimientos

• Modelado del Sistema construir una
  representación de requerimientos que serán la
  base para la correctividad, completitud y
  consistencia.
• Validación revisar el modelo
• Administración identificar, controlar y dar
  seguimiento a los requerimientos y los cambios
  que serán aplicados a estos

9
Plantilla de Arquitectura de Producto
procesamiento de la interfaz del usuario
procesamiento
procesamiento
funciones de
de la entrada
de la salida
proceso y control
mantenimiento y auto-prueba
10
Diagrama de Flujo de la Arquitectura
interfaz
del operador
subsistema
requerimientos del operador
consultas, reportes y despliegues
de la interfaz
del operador
requerimientos de adquisición de código de barras
status de control de activación
reportes ordenados
datos de temporización/localización
proccesamiento y control CLSS
requerimientos
de reportes
subsistema
controlador
número de
subsistema
de control
Subsistema
parte
de activacón
lector de
de activación
decodificador
código de barras
código de barras
datos código de
localización
comandos de activacion
code barras crudos
binaria
código de barras
subsistema
de acceso
reportes CLSS
a base de datos
subsistema
velocidad
de formateo
clave
subsistema
de línea
de reportes
de adquisición
de datos sensados
registros ordenados
controlador de
comunicaciones
BCR status
shunt status
subsistema
status de sensor
entrada de pulsos
de diagnóticos
datos de
reporte formateados
status de comunicaciones
interfaz de
status del lector
adquisición de datos
interfaz de salida
de código de barras
interfaz de diagnóstico
11
5.2 Fase de Análisis
12
Cuáles son los problemas reales?
el cliente tiene una idea muy vaga de lo que se
requiere.
el desarrollador decide avanzar con la idea
vaga
con el supuesto de que iremos encontrando los
detalles conforme avanzamos
el cliente continua cambiando los requerimientos
el desarrollador es afectado por estos cambios,
cometiendo errores en las especificaciones y
desarrollo

y así continúa...
13
Análisis de Requerimientos de Software

• identificar al cliente y el trabajo así como
  negociar los requerimientos de nivel-producto
• construir un modelo de análisis
• enfocarse en los datos
• definir la función
• representar el comportamiento
• prototipar áreas de incertidumbre
• desarrollar una especificación que guiará el
  diseño
• conducir revisiones técnicas formales

14
Reunir requerimientos
Facilitated Application Specification Techniques
Técnicas de Especificación de Aplicaciones
Grupo de
Grupo del
Ingeniería
Cliente
de Softare
15
Guías FAST

• los participantes deben asistir a la reunión
  completa
• todos los participantes son iguales
• la preparación es tan importante como la reunión
• todos los documentos pre-reunión deben ser vistos
  como propuestos
• la ubicaciones de las reuniones fuera de sitio
  son preferibles
• establecer y mantener una agenda
• no enfrascarse en detalles técnicos

J. Wood D. Silver
16
Distribución de la Función de Calidad

• La Distribución de la Función determina el
  valor (como lo percibe el cliente) de cada
  función requerida en el sistema
• La Distribución de Información identifica objetos
  de datos y eventos
• Distribución de Tareas examina el comportamiento
  del sistema
• Análisis del valor determina la prioridad
  relativa de los requerimientos

17
Casos de Uso

• Una colección de escenarios que describe el
  hilo o situación de uso del sistema
• Cada escenario es descrito desde el punto de
  vista de un actor una persona o dispositivo
  que ineractúa con el software de alguna manera
• Cada escenario contesta las siguientes preguntas
• cuáles son las principales tareas o funciones
  llevadas a cabo por el actor?
• qué sistemas de información el actor adquiere,
  produce o cambia
• el actor informará al sistema acerca de cambios
  del entorno?
• qué información el actor requiere del sistema?
• el usuario desea ser informado acerca de cambios
  no esperados?

18
5.3 Principios de Análisis
19
El proceso de Análisis
constuir un prototipo
Licitación de Requerimientos
Desarrollar Especificación
el problema
Revisión
crear modelos de análisis
20
Principio de Análisis IModelar el Dominio de los
Datos

• definir los objetos de datos
• describir atributos de los datos
• establecer relaciones de los datos

21
Principio de Análisis IIModelar la Función

• identificar funciones que transforman los objetos
  de datos
• indicar el flujo de datos del sistema
• representar los productores y consumidores de los
  datos

22
Principio de Análisis IIIModelar el
Comportamiento

• indicar los diferentes estados del sistema
• especificar eventos que provocan que el sistema
  cambie de estado

23
Principio de Análisis IVParticionar los modelos

• refinar cada modelo para representar niveles más
  bajos de abstracción
• refinar objetos de datos
• crear una jerarquía funcional
• representar el comportamiento a diferentes
  niveles de detalle

24
Principio de Análisis VEsencia

• comenzar enfocándose en la esencia del problema
  sin descuidar los detalles de implantación

25
Principios de Davis

• Entender el problema antes de comenzar a crear el
  modelo de análisis.
• Desarrollar prototipos que permitan al usuario
  entender cómo será la interacción hombre-máquina.
• Registrar el origen de y la razón de cada
  requerimiento.
• Utilizar múltiples vistas de los requerimientos.
• Priorizar los requerimientos.
• Trabajar para eliminar la ambigüedad.

26
5.4. Modelo de Análisis
27
El Modelo de Análisis
Modelos de Datos
Modelo Funcional
Modelo de Comportamiento
28
Modelo de AnálisisDónde comenzar?

• Establecer una Sentencia o Declaración de Alcance
  a partir de
• el documento de trabajo FAST
• un conjunto de casos de uso
• la sentencia de alcance debe ser analizada para
  extraer datos, funciones y comportamiento de la
  información del dominio

29
Declaración del Alcance

• una descripción breve (relativa) del sistema a
  ser desarrollado
• indica los datos que son entrada y salida, así
  como la funcionalidad básica
• indica el procesamiento condicional (a alto
  nivel)
• implica ciertas restricciones y limitaciones

30
Identificar objetos y operaciones

• definir objetos mediane subrayar todos los
  sustantivos den la declaración de alcance
• productores/consumidores de los datos
• establecer dónde los datos serán almacenados
• elementos de datos compuestos
• definir operaciones mediante subrayar doble
  todos los verbos activos
• procesos relavantes a a aplicación
• transformaciones de los datos
• considerar otros servicios que serán requeridos
  por los objetos

31
Modelado de Datos y Diagramación Entidad
Relación (E-R)
32
Qué es el Modelado de Datos?

• examinar los objetos de datos independientemente
  del procesamiento
• enfoca la atención en el dominio de los datos
• crea un modelo a nivel de abstracción del cliente
• indica cómo los datos se relacionan entre sí

33
Qué es un Objeto de Datos?
Objeto
algo que es descrito por el conjunto
de atributos (elementos de datos) y serán
manipulados dentro del software (sistema)
cada
instancia
de un objeto (v.g., un libro)
puede ser identificado únicamente (v.g. ISBN)

cada uno desempeña un rol necesario en el sistema
v.g., el sistema no puede funcionar sin
acceso a las instancias del objeto
cada uno es descrito por atributos que son

elementos de datos por sí mismos
34
Objetos típicos
entidades externas (impresora, usuario, sensor)
cosas
(v.g, reportes, despliegues, señales)
ocurrencias o eventos (e.g., interruptor, alarma)
roles
(v.g., administrador, ingeniero, vendedor)
(v.g., división, equipo)
unidades organizacionales
lugares
(v.g., piso de manufactura)
estructura (v.g., registro de empleado)


35
Objetos de Datos y Atributos
Un objeto de datos contiene un conjunto de
atributos que actúan como un aspecto, cualidad,
característica, o descriptor del objeto
objeto automóvil atributos fabricante
modelo carrocería precio código de opc.
36
Qué es una relación?
relación
indica conexionismo
un hecho que debe ser recordado
por el sistema y no puede ser computado o
derivado mecánicamente

• pueden existir varias instancias de una relación
• los objets pueden ser relacionados de diferentes
  formas

37
Notación ERD
Una forma común
(0, m)
objeto
objeto
relación
1
2
(1, 1)
atributos
Otra forma común
relación
objeto
objeto
1
2
(1, 1)
(0, m)
38
Construcción de un ERD

• Nivel 1modelar todos los objetos de datos
  (entidades) y sus conexiones a otros
• Nivel 2modelar todas las entidades y sus
  relaciones
• Nivel 3modelar todas las entidades, relaciones,
  y los atributos que proveen mayor profundidad

39
Ejemplo de un ERD
requerim. de serv.
Cliente
lugares
(1,1)
(1,m)
(1,1)
tareas estándar
(1,n)
orden trabajo
genera
(1,1)
(1,1)
(1,1)
(1,w)
tareas
seleccionado de
consiste de
(1,w)
(1,i)
materiales
lista
40
Creación delModelo de Flujo
41
Modelo de Flujo
Cada sistema basado en computadora es una
transformación de información
sistema basado computadora
entrada
salida
42
Notación del Modelo de Flujo
entidad externa
proceso
flujo de datos
almacenamiento de datos
43
Entidad Externa
Un productor o consumidor de información
Ejemplos una persona, un dispositivo, un sensor
Otro ejemplo un sistema basado en computadora
Los datos deben siempre originarse en algún lado
y deben siempre enviarse a otro
44
Proceso
Un transformador de datos (cambia una entrada por
una salida)
Ejemplos impuestos calculados, calcular
áreas, formatear un reporte, desplegar un gráfico
Los datos deben siempre ser pocesados de alguna
manera para llevar a cabo una función
45
Flujo de Datos
Los flujos de datos a través de un
sistema, comienzan con una entrada y deben ser
transformados a una salida.
base
calcular el área de un triángulo
área
altura
46
Almacenamiento de Datos
Los datos son frecuentemente almacenados para un
uso posterior
sensor
sensor, tipo, ubicación, intevalo
revisión de los datos del sensor
reporte requrido
tipo, ubicación, intervalo
sensor
datos del sensor
47
Diagramación del Flujo de DatosGuías

• todos los íconos deben ser etiquetados con
  nombres significativos
• el DFD evoluciona a través del úmero de niveles
  de detalle
• siembre comienzan con un diagrama de contexto
  (siempre llamado nivel 0)
• muestran las entidades externas a nivel 0
• los flujos de datos simpre están etiquetados
• no se representa la lógica procedural

48
Construcción de un DFDI

• revisar un ERD para aislar los objetos de
• datos y revisar gramaticalmente para determinar
  operaciones
• determinar las entidades externas (productores y
  consumidores de datos)
• crear el nivel 0 del DFD

49
Ejemplo de un Nivel 0 del DFD
requerimiento de procesamiento
usuario
señal de video requerida
procesador de video digital
monitor
fuente de video
Señal de video NTSC
50
Construcción de un DFDII

• escribir una narrativa describiendo la
  transformación
• revisar para determinar las transformaciones del
  siguiente nivel
• balancear el flujo para mantener la continuidad
  del flujo de datos
• desarrollar el Nivel 1 del DFD
• utilizar una expansión 15 (aprox.)

51
Jerarquía del Flujo de Datos
a
b
P
x
y
nivel 0
c
p2
a
f
p1
b
p4
d
5
g
p3
e
nivel 1
52
Notas del Modelado de Flujo

• cada burbuja es refinada hasta que haga una sola
  cosa
• la tasa de expansión decrece conforme avanza el
  número de niveles
• casi todos los sistemas requieren entre 3 y 7
  niveles para un adecuado modelo de flujo
• un simple elemento de flujo de datos (flecha)
  puede ser expandido como se incrementan los
  niveles (el diccionario de datos provee
  información)

53
DFD Un vistazo
modelo de análisis
Se mapea en
mdelo de diseño
54
Modelado del Comportamiento yEspecificación
delProceso
55
Modelado del Comportamiento
eventos
comportamiento
Mundo real
Aplicación
56
Los Estados de un Sistema

• estadoun conjunto de circunstancias observable
  que caracterican el comportamiento de un sistema
  en un momento dado
• transición de estadoel movimiento de un estado a
  otro
• eventouna ocurrencia que provoca que el sistema
  exhiba alguna forma de comportamiento predecible
• acciónproceso que ocurre como la consecuencia de
  hacer una transición

57
Modelo de Comportamiento

• hacer una lista de estados diferentes de un
  sistema (cómo se debe comportar el sistema)
• indicar cómo el sistema hace una transición de un
  estado a otro (cómo el sistema cambia de
  estado?)
• indica eventos
• indica acciones
• dibujar un diagrama de transición de estados

58
Notación del Diagrama de Transición de Estados
estado
evento que causa una transición
acción que ocurre
nuevo estado
59
Diagrama de transición de estados
llenar y comenzar
leer
invocar la admón. copiado
comandos
del operador
lleno
invocar lectura-op-entrada
hacer copias
invocar lectura-op-entrada
hacer copias
recargar papel
vacío
invocar recarga de papel
atorado
invocar diagnósticos
no atorado
invocar lectura-op-entrada
estado problema
60
El Modelo de Control
el diagrama de flujo de control es superpuesto
en el DFD
y muestra los eventos que controlan los procesos
denotados en
el DFD
flujos de control eventos y elementos decontrol
son
denotados por líneas punteadas
una barra vertical implica una entrada o salida
desde unl
especificación de control control spec (CSPEC)
una
especificación separada que describe cómo el
contro es
manejada.
una flecha punteada llegando a una barra vertical
es una
entrada al CSPEC
una flecha punteada saliendo de un proceso
implica un
condición de datos.
una flecha punteada llegando a un proceso implica
un
lectura de entrada de control directamente por el
proceso
los flujos de control fisicamente
activan/desactivan los
procesos esto se realiza vía los SPEC
61
5.5 Técnicas de Especificación
62
Especificación de ControlControl Specification
(CSPEC)
El CSPEC puede ser
diagrama de transición de estados
(spec secuencial)
tabla de transición de estados
spec combinacional
tabla de decisión
tablas de activación
63
Guías para la construcción de un CSPEC
listar todos los sensores que son leídos por el
software
listar todas las condiciones de interrupción
listar todos los switches que son accionados
por el operador
listar todas las condiciones de datos
recordar la revisión sustantivo-verbo que es
aplicada a la declaración del alcance del
software, revisar todos los elementos de
control como sea posible en las
entradas/salidas CSPEC
describir el comportamiento de un sistema al
identificar sus estados identificar como cada
estado es alcanzado y define las transiciones
entre estados.
enfocarse en las posibles omisiones... un error
muy común al especificar el control, v.g.,
preguntar hay alguna otra manera de obtener
este estado o salir de él?
64
Especificación del ProcesoProcess Specification
(PSPEC)
burbuja
PSPEC
narrativa

pseudocódigo (PDL)
ecuaciones

tablas

diagramas y/o gráficas

65
Una nota de diseño
PSPEC
uno o más componentes
en el diseño del software
66
Crear Mini-Specs
Software
Specification
67
Métodos para Análisisen Tiempo Real

• cada quien introduce su propia notación, pero
• proponer una forma de representar el control y
  separarlo de sus datos
• proveer unmecanismo de especificación de eventos,
  y procesamiento distribuido
• comenzar el nivel de análisis y trabajo para
  derivar asignaciones al procesador, tareas y
  arquitecturas de programa.

68
Métodos de Análisis y DiseñoTiempo Real

• Gomaa, H., Software Design Methods for
  Concurrent and Real-Time Systems, Addison-Wesley,
  1995.
• Harel, D. et al, "STATEMATE A Working
  Environment for the Development of Complex
  Reactive Systems, IEEE Trans. Software
  Engineering, vol. 16, no. 3, abril, 1990, pp.
  403-414.
• Hatley, D.J. and I.A. Pirbhai, Strategies for
  Real-Time System Specification, Dorset House,
  1987.
• Selic, B., G. Gullekson, and P. Ward, Real-Time
  Object-Oriented Modeling, Wiley, 1994.
• Shumate, K. and M. Keller,, Software
  Specification and DesignA Disciplined Approach
  For Real-Time Systems, Wiley 1992.
• Ward, P.T. and S.J. Mellor, Structured
  Development for Real-Time Systems, 3 volúmenes,
  Yourdon Press, 1985, 1986.

69
El Diccionario de Datos
una gramática cuasi-formal para describir el
contenido
de los datos que el software procesará y creara

una notación para describir los datos de control y
los valores de los datos de control que pueden
ser tomados

un repositorio que también contiene información
donde se usa/ como se usa

una notación que puede ser representada
manualmente,
pero es mejor desarrollado utilizando
herramientas CASE
70
Construir un Diccionario de Datos
Nombre
el nombre primario del elemento de datos compuesto


Alias
otros nombres para el elemento de datos


Donde se usa
transformaciones de datos (procesos) que

utilizan el elemento dedatos compuesto


Como se usa
el rol del elemento de datos (entrada,salida,

almacenamiento temporal, etc.


Descripción
una notación que represente contenido




Formato
información específica acerca d los tipos de
datos, valores predeterminados (si se conocen)
71
Notación del DD
Notación
Signficado





se compone de



y



o




n

n repeticiones de


( ... )
datos opcionales


... texto ...
delimita un comentario
72
Ejemplo de Diccionario de Datos
sistema
núm. teléfono
salida del sistema
integrado
de telefonía
de oficina
Construir el diccionario de requerimientos
Nombre
número de teléfono


Alias
número de telefono, número


Dónde/Cómo
ler-número-teléfono(entrada)
se usa
desplegar-número-teléfono(entrada)

analizar-llamadas-larga-dist(entrdas)


Descripción
num_teléfono. local extension
num_salida 0

num_salida 9 código_serv número_local

código_serv 211 411 611 911

número_local ( ( 0 ) cód_área )
núm_local

cód_área 3 designadores numéricos

datos alfanuméricos
Formato
73
5.5 Especificación de requerimientos de
Software
74
Escribir una Especificación de Software
Cada quien conoce qué tiene que hacer hasta que
alguien lo escribe!
75
Guías de una Especificación
Utilizar un formato prehecho que provea un
detalle creciente

Utilizar una notación gráfica consistente
términos textuales consistentemente (no usar
sinónimos)

Asegurar de describir todos los acrónimos

Asegurar incluir una tabla de contenido,
idealmente
incluir un índice y/o glosario.

Escribir en un lenguaje sencillo y un estilo
no ambiguo.

Ponerse en lugar del usuario soy capaz de
enten- der si no estoy familiarizado con el
sistema?
76
Guías de Especificación
Vigilar los conectores persuasivos, preguntar
porqué. claves ciertamente, entonces,
claramente, obviamente, esto significa
que... Vigilar los términos vagos claves
algunos, a veces, frecuentemente, usualmente,
orginaramente, casi... Cuando se dan listas,
pero no están completas, asegurarse que todos los
elementos son entendidos claves etc., y así
sucesivamente, entre otras, tal
como... Asegurarse que los rangos establecidos
no contienen criterios establecidos. valores
válidos de 10 a 100, entero, real,
hexadecimal... Asegurarse que los verbos vagos
tales como manejados, rechazados,
procesados... Vigilar las declaraciones en "voz
pasiva" v.g. los parámetros son inicializados.
por quién? Vigilar los sujetos tácitos. v.g.
el módulo de E/S comunicado con el módulo de
datos de validación y su bandera de control es
establecido quién control la bandera?
77
Guías de Especificación
Cuando un término es definido explícitamente en
un lugar, intentar substituir la definición en
otras ocurrencias Cuando una estructura está
descrita en palabras, hacer un dibujo. Cuando
una estructura está descrita en un dibujo,
intentar redibujarlo para enfatizar diferentes
elementos de la estructura Cuando una ecuación
simbólica es usada, tratar de expresar su
significado en palabras. Cuando un cálculo es
especificado, trabajar por lo menos
2 ejemplos Revisar las sentencias que implican
certeza, entonces preguntar por claves de prueba
(simpre, todos, ninguno, nunca) Buscar detrás de
sentencias de certeza - asegurarse que las
restricciones y limitaciones son realistas
78
Especificación de requerimientos de Software
Tabla de contenido  Lista de figuras  Lista de
tablas 1.           Introducción  1.1       
Propósito del sistema 1.2        Alcance del
sistema 1.3        Definiciones, acronismos y
abreviaturas 1.4        Referencias 2.          De
scripción general del sistema 2.1       Contexto
del sistema (Perspectivas del producto) 2.2      
Capacidades principales del sistema (Funciones
del Producto) 2.3       Restricciones
principales del sistema 2.4       Tipos de
usuarios 2.5       Suposiciones y
dependencias 3.         Requerimientos
específicos 3.1       Requerimientos funcionales
3.1.1        Requerimiento funcional n
(n 1,2,3,........) 3.1.1.1     
Propósito 3.1.1.2      Alcance
3.1.1.3      Entradas 3.1.1.4     
Procedimiento 3.1.1.5     
Salidas  3.2      Requerimientos de interfaces
externas 3.2.1        Interfaces del
usuario 3.2.2        Interfaces del
hardware 3.2.3        Interfaces del
software 3.2.4        Interfaces de
comunicación 3.3       Requerimientos del
rendimiento del sistema 3.4       Otros
requerimientos