1.

ELEMENTOS:
2. Indagación Problemas: a) De alcance b) De entendimientos c) De volatilidad 3) Elaboración 4) Negociación 5) Especificación Formato ERS. 3) 7) Administración de los requerimientos (identificar, controlar y dar seguimiento)
Formato ERS IEEE 830 OTRA PROPUESTA ERS Validación (Revisión técnica) ejemplo 1 ejemplo2

1

• IDENTIFICACIÓN DE LOS PARTICIPANTES
• RECONOCER LOS MÚLTIPLES PUNTOS DE VISTA • TRABAJAR HACIA LA COLABORACIÓN ( uso de puntos de prioridad)

2 3

Recabación de los requerimientos en forma colaborativa

Despliegue de la función de calidad

Escenarios de uso

Indagación de los productos de trabajo

Entrevista Cuestionario Muestreo Observación Investigación MÉTODOS INTERACTIVOS MÉTODOS NO INSTRUSIVOS .

..Quién es el actor principal y quién(es) el secuandario? 2.Qué información del sistemas adquiere.Qué excepciones deben considerarse al describir la historia? 6..Tendrá que informar el actor de cambios al sistema en el ambiente externo? 9.Cuáles variaciones son posibles en la del actor 7.Cuáles son los objetivos de los actores? 3....Quiere el actor se informado sobre cambios inesperados? . produce o cambia el actor? 8..Qué precondiciones deben de existir antes de comenzar la historia? 4...PREGUNTAS QUE DEBE RESPONDER UN CASO DE USO: 1..Qué tareas o funciones principales son realizadas por el actor? 5.Qué información desea obtener el actor del sistema? 10.

1) Elementos del modelo de requerimientos • Basados en el escenario • De datos • Orientados a clases • De comportamiento • Orientados al flujo • Modelos de datos • Prototipos y Basados en el diccionario de datos 2) Patrones de Análisis 3) Modelos de para webapps .

.a) Identificación de los participantes claves b) Determinación de las condiciones “ganar” de los participantes c) Negociación de las condiciones “ganar-ganar” para todos.

. ¿es realmente necesario o representa una característica agregada que tal vez no sea esencial para el objetivo del sistema? 4. ¿refleja de manera apropiada la información..¿Se ha “particionado” el modelo de requerimientos en forma que exponga información cada vez más detallada sobre el sistema? 11..El requerimiento...¿Hay requerimientos en conflicto con otros? 7.. ¿puede someterse a prueba? 9.Es coherente cada requerimiento con los objetivos generales del sistema o del producto? 2.¿Cada requerimiento es asequible en el ambiente técnico que albergará el sistema o producto? 8.Cada requerimiento está acotado y no es ambiguo? 5.Se han especificado todos los requerimientos en el nivel apropiado de abstracción? Es. la función y el comportamiento del sistema que se va a construir? 10..Una vez implementado cada requerimiento.¿Tiene atribución cada requerimiento? Es. decir ¿algunos de ellos tienen un nivel de detalle técnico que resulta inapropiado en esta etapa? 3.PREGUNTAS DE VALIDACIÓN DEL MODELO: 1... decir ¿hay una fuente (por lo general una individual y específica) clara para cada requerimiento? 6..El modelo de requerimientos..¿Se ha usado el patrón de requerimientos para simplificar el modelo de éstos? ¿Se han validado todos los patrones de manera apropiada? ¿Son consistentes todos los patrones con los requerimientos del cliente? .

II. MODELADO DE LOS REQUERIMIENTOS 1. Análisis de Requerimientos MODELADO DE REQUERIMIENTOS Requerimientos Análisis .

C) Definir un conjunto de requerimientos que puedan validarse una vez construido el software.2. . Objetivos y Filosofía General A) Describir lo que requiere el cliente. B) Establecer una base para la creación de un diseño de software.

Relación entre la descripción y el diseño Descripción del sistema Modelo del análisis El modelo de requerimientos como puente entre la descripción del sistema y el modelo del diseño Modelo del diseño .

2. Reglas prácticas del análisis El nivel de abstracción debe ser relativamente elevado Cada requerimiento debe dar una visión del dominio de la información. de la función y del comportamiento del sistema Retrasar las consideraciones de infraestructura y otros modelos no funcionales Debe minimizarse el acoplamiento a través del sistema Asegurar que el modelo de requerimientos agrega valor a todos los participantes Mantener el modelo tan sencillo como se pueda .

[Firesmith 1993] OBJETIVO • Identificar elementos comunes para la solución de problemas. que sean útiles en todas las aplicaciones de un dominio . a partir de un dominio de aplicación específica.3. Análisis del dominio Es la identificación . análisis y especificación de los requerimientos comunes. normalmente para usarlo varias veces en múltiples proyectos dentro del dominio de la aplicación.

Entradas y salidas para el análisis del dominio Bibliografía técnica Taxonomías de clase Fuentes de conocimi ento del dominio Aplicaciones existentes Encuestas a clientes Consejo de expertos Requerimientos actuales y futuros Análisis del dominio Estándares de reutilización Modelos funcionales Lenguajes del dominio Modelo de análisis del dominio .

Enfoques del modelado de requerimientos Análisis orientado a objetos •Modelos basados en el escenario : •Casos de usos •Historias de usuarios •Modelos de clase: •Diagramas de clase •Diagramas de colaboración Análisis orientado a objetos REQUERIMIENTOS DEL SOFTWARE Análisis orientado a objetos •Modelos de comportamiento: •Diagramas de estado •Diagramas de secuencia •Modelos de flujo: •DFD •Modelos de datos Análisis estructurado .4.

Modelado Orientado al Flujo PUNTO DE VISTA: ENTRADA REPRESENTACIONES: PROCESO SALIDA Entidades Externas (Productores y Consumidores de los datos) Objetos de Datos Transformaciones o Procesos .

Lineamientos: • El nivel 0 del diagrama debe mostrar el sistema como una sola burbuja • Debe anotarse con cuidado las entradas y salidas principales • La mejora debe comenzar por aislar procesos candidatos. para representarse en el siguiente nivel. objetos de datos y almacenamiento de éstos. • Todas las flechas y burbujas deben etiquetarse con nombres significativos • De un nivel a otro debe mantenerse la continuidad del flujo de información • Debe mejorarse una burbuja a la vez .

hasta que cada burbuja realice una función simple. Alarma .DFD en el nivel de contexto (0): • Ejemplo para la función de seguridad de “Casa Segura”: Panel de control Comandos y datos del usuario Información en pantalla Pantalla del panel de control Software de CasaSegura Sensores Estado del sensor Tipo de alarma Alarma Tonos del número telefónico Este diagrama debe expandirse a un siguiente nivel manteniendo la continuidad del flujo de la información.

hasta que cada burbuja tenga “un solo pensamiento” . . . .¿Cómo expandir un DFD? ANÁLISIS GRAMÁTICAL Los sustantivos son: ° Entidades externas (cuadros) Los verbos son los procesos (burbujas) ° Datos u objetos de control (flechas) ° Almacenamiento de datos (líneas dobles) .

Otro modelado para aplicaciones conducidas por “eventos” Un evento o aspecto de control se implementa como un valor booleano una lista discreta de condiciones MODELADO DEL FLUJO DE CONTROL 1) Especificación del control (CSPEC): ° Diagrama de estado (UML) ° Tabla de activación del programa (TAP) 2) Especificación del proceso (PSPEC): ° Texto narrativo ° Diagrama de actividades (UML) .

Reiniciar Entrar/fijar Estadodel Sistema en “inactivo” Interruptor de iniciar/detener. “Listo” Entrar/mostrar en la pantalla el mensaje 2. “Activada” Entrar/mostrar en la pantalla el mensaje 2. “DispararSensor” Entrar/fijar EstadodePantalla en ParpadearRápido Hacer:SonarAlarma SensorDisparo/ ComienzaCronómetro OprimirTecla/ManipularTecla Hacer:NotificaraResponsablesdeAlarma SensorDisparo/ ReiniciarCronómetro . “Iniciando sistema” Entrar/mostrar en la pantalla el mensaje 2. “Por favor espere” Entrar/fijar EstadodePantalla en ParpadearDespacio Hacer: activar diagnóstico Entrar/mostrar en la pantalla el mensaje 1.Ejemplo: Diagrama de estado para la función de seguridad de CasaSegura. encendido Ocioso Sistema bien Reiniciar Entrar/fijar Estadodel Sistema en “inactivo” Entrar/mostrar en la pantalla el mensaje 1. “” Entrar/fijar en la pantalla EstadodePantalla Hacer:VigilaryControlarelSistema FalsaAlarma Entrar/fijar Estadodel Sistema en “VigilaryAlarma” Entrar/mostrar en la pantalla el mensaje 1. “ALARMA” TiempoTerminado Entrar/mostrar en la pantalla el mensaje 2. “” Entrar/fijar en la pantalla EstadodePantalla OprimirTecla/ManipularTecla Apagar/Interruptor Apagado Activar FallaDetectada/mostrar en la pantalla el mensaje 2 “contacte al proveedor Desactivar password Desactivar password ActivarAlarma VigilanciadelEstadodelSistema Entrar/fijar Estadodel Sistema en “vigilancia” Entrar/mostrar en la pantalla el mensaje 1.

eventos de entrada evento del sensor bandera de parpadeo Interruptor de iniciar o detener estado de la acción en pantalla terminado en marcha tiempo terminado salida señal de alarma actividad del proceso vigilar y controlar el sistema activar o desactivar el sistema mostrar mensajes y estado interactuar con el usuario 0 0 0 0 1 0 0 0 1 1 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 1 1 1 1 0 0 0 0 0 1 0 0 0 1 1 1 0 1 0 1 0 1 1 .Ejemplo: Tabla de activación del proceso (TAP) para la función de seguridad de CasaSegura.

Pasos: 1) Evaluar todos los casos de uso para entender por completo la secuencia de interacción dentro del sistema 2) Identificar los eventos que conducen la secuencia de interacción dentro del sistema a)Identificar los eventos (siempre que el sistema y un actor intercambian información) b)Identificar un actor por cada evento c)Anotar la información que se intercambia d)Enlistarse cualesquiera restricciones condiciones o e)Asignar los objetos involucrados (son los responsables de la generación de eventos) 3) Crear una secuencia por cada caso de uso 4) Construir un diagrama de estado para el sistema 1)El estado de cada clase cuando el sistema ejecuta su función 2)El estado del sistema según se observa desde el exterior cuando realiza su función 5) Revisar el modelo de comportamiento para verificar la exactitud y consistencia .Modelo de Comportamiento • Indica la forma en la que responderá el software a eventos o estímulos externos.

El estado de cada clase tiene características: PASIVAS: ACTIVAS: El estado actual del objeto conforme pasa por una transformación o procesamiento continuos Através de ventos externos El estado actual de los atributos de un objeto Através de una función de tiempo Diagramas de estado para clases Diagramas de secuencia .

Jerarquías de objetos 4..Análisis Estructurado vs..Diagramas de flujo de datos 1. que permiten: a) Revisiones sobre los diagramas UML b) Proveen vínculos para producir el diseño y generar código UML 5..Diagramas de estado (especificación de control CSPEC) c) Construye una base de datos 6.Diagramas UML..-Diccionario de datos 2. Análisis generalizado en UML Estructurado 1.Diagramas E-R 3...Diagramas de actividades para administrar y evaluar (especificación de proceso PSPEC) modelos UML .

Patrones para el Modelado de Requerimientos 1) Se descubre el patrón 4) Se busca y selecciona para reutilizarse Son un mecanismo para capturar conocimiento del dominio. en forma que permita que vuelva a aplicarse cuando se encuentre un problema nuevo Nombre del patrón 2) Se documenta (PAS) Objetivo Motivación Restricciones Patrón de Análisis Semántico Aplicabilidad Estructura (Diagrama de clases) Comportamiento (Diagrama de secuencia) 3) Se guardan en un depósito Participantes Colaboradores Consecuencias .

Modelado de Requerimientos para WEBAPPS Entradas (Actividad de Comunicación) Participantes Medida de dependencia entre el éxito de la organización y de la webapp Número de participantes Tamaño y complejidad Salidas (Modelos) De contenido (árbol de datos) Categorías de usuario De interacción Contexto del negocio FACTORES Funcional (diagrama de actividades) Metas definidas de información Metas definidas de aplicación Requerimientos generales de webapps Escenarios de uso De navegación Grado en el que ha trabajado junto el equipo Tamaño de equipo De configuración (ambiente y estructura) Descripciones en lenguaje natural .

Árbol de datos • Ejemplo: para CasaSeguraAsegurada.com Descripción de mercadotecnia Número de parte Nombre de la parte Fotografía Descripción técnica Esquema Video Precio al mayoreo Componente Tipo de parte Descripción Precio Precio al menudeo .

ERS MEDIOS PARA LA EVALUACIÓN DE LA CALIDAD DEL SOFTWARE(una vez construido) MODELADO DE LOS REQUERIMIENTOS .Concluimos……….

Estimación de Costos y Tiempos Costos Tiempos Ejemplo .

Sign up to vote on this title
UsefulNot useful