requisitos

1

Análisis de Requisitos del Sistema

• Identificación de Requisitos para el Software:Analista entrevista para obtener aspectos

generales del cliente:• ¿Quién está detrás de la solicitud de trabajo?• ¿Quién utilizará la solución?• ¿Cuál será el beneficio económico del éxito

de una solución?• ¿Hay alguna otra alternativa para la solución

que necesita?

1

2


• Entendimiento del problema• ¿Cómo caracterizaría un «buen» resultado ó

salida generados para una buena solución?• ¿A qué tipo de problema(s) va dirigida esta

solución?• ¿Puede mostrarme (o describirme) el entorno

en que se utilizará la solución?• ¿Hay aspectos o restricciones especiales del

rendimiento que afecten a la manera de enfocar la solución?

2

3


• Meta-preguntas (Preguntas sobre las preguntas)

• ¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas son «oficiales»?

• ¿Estoy preguntando demasiado?• ¿Hay alguien más que pueda proporcionar

información adicional?• ¿Hay algo más que debería preguntarle?

3

4


• Técnicas para Facilitar las especificaciones de una aplicación (TFEA):

• La reunión se celebra en un lugar neutral y acuden tanto los clientes como los desarrolladores.

• Se establecen normas de preparación y de participación.

• Se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes, pero lo suficientemente informal como para animar el libre flujo de ideas.

4

5


• Un «coordinador» (que puede ser un cliente, un desarrollador o un tercero) que controle la reunión.

• Se usa un «mecanismo de definición» (que puede ser hojas de trabajo, gráficos, carteles o pizarras).

• El objetivo es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución en una atmósfera que permita alcanzar el objetivo.

5

6


• Despliegue de la función de calidad (DFC)Traducción de las necesidades del cliente

a requisitos técnicos de software.• Identificación de 3 tipos de requisitos:

– Normales» Objetivos y metas de producto

– Esperados» Implícitos y fundamentales. A veces el cliente

no los declara.– Innovadores

» Características más allá de las expectativas del cliente, y que suelen ser muy satisfactorias. 6

7


• Casos de uso Respuestas que deben obtenerse de ellos:

• ¿Cuáles son las principales tareas o funciones que serán realizadas por el actor?

• ¿Cuál es el sistema de información que el actor adquiere, produce o cambia?

• ¿Qué actor informará al sistema de los cambios en el entorno externo?

• ¿Qué información necesita el actor sobre el sistema?

7

8


• Principios del análisisOperativos:

• Debe representarse y entenderse el dominio de información de un problema.

• Deben definirse las funciones que debe realizar el software.

• Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos).

• Deben dividirse los modelos que representan información, función y comportamiento de manera que se descubran los detalles por capas (o jerárquicamente)

8

9


• Principios del análisisOperativos:

• El proceso de análisis debería ir desde la información esencial hasta el detalle de la implementación.

9

10


• Principios del análisisDirectrices:

• Entender el problema antes de empezar 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 y la razón de cada requisito.• Usar múltiples planteamientos de requisitos.• Dar prioridad a los requisitos.• Trabajar-para eliminar la ambigüedad. 1

0

11


El dominio de la información:

• Agrupa elementos de datos u objetos que contienen números, texto, imágenes, audio, video o cualquier combinación de ellos.

11

12


Aplicaciones de Software =

Procesamiento de Datos

13


Los principios operativos exigen...

...un examen del dominio de la información y un:

MODELO DE DATOS:• Contenido de la información y relaciones• Flujo de la Información• Estructura de la Información

14


• Tipos de modelos a crear durante la etapa de Análisis de Requisitos:

• Modelos funcionales• Modelos de comportamiento

• Papel del Modelo de datos• Ayuda al analista a entender la información, el

comportamiento y las funciones del sistema• El modelo se convierte en un punto de

revisión ó “checkpoint” para determinar el avance realizado

• Se convierte en un fundamento de diseño del sistema, al proporcionar funciones esenciales.

15


• Partición (actividad de análisis):• Es la descomposición del problema en partes

constitutivas para su resolución.• Puede ser vertical u horizontal,

refiriéndose al orden jerárquico en que se resuelven los problemas.

• Verticalmente se exponen detalles del sistema

• Horizontalmente se “descomponen” etapas para revisión de detalles

15

16


• Visiones esenciales y de implementación

• Esencial: Presenta las funciones a conseguir y la información a procesar sin tener en cuenta los detalles de la implementación.

• Visión de Implementación: Introduce la manifestación en el mundo real de las funciones de procesamiento y las estructuras de información.

Sin embargo, la mayoría de los sistemas basados en computadora se especifican de manera que se acomode a ciertos detalles de implementación.16

17


• Principios básicos de especificación• Separar la funcionalidad de la implementación.• Desarrollar un modelo del comportamiento

deseado de un sistema que comprenda datos y las respuestas funcionales de un sistema a varios estímulos del entorno.

• Establecer el contexto en que opera el software especificando la manera en que otros componentes del sistema interactúan con él.

• Definir el entorno en que va a operar el sistema e indicar como «una colección de agentes altamente entrelazados reaccionan a estímulos del entorno (cambios de objetos) producidos por esos agentes» 1

7

18


• Principios básicos de especificación• Crear un modelo intuitivo en vez de un

diseño o modelo de implementación.• Reconocer que «la especificación debe ser

tolerante a un posible crecimiento si no es completa». Una especificación es siempre un modelo (una abstracción) de alguna situación real (o prevista) que normalmente suele ser compleja. De ahí que será incompleta y existirá a muchos niveles de detalle.

• Establecer el contenido y la estructura de una especificación de manera que acepte cambios.

18

19


• Representación• El formato de la representación y el

contenido deberían estar relacionados con el problema.

• La información contenida dentro de la especificación debería estar escalonada.

• Los diagramas y otras formas de notación deberían restringirse en número y ser consistentes en su empleo

• Las representaciones deben permitir revisiones.

19

20


Especificación de los requisitos de software• La Introducción establece las metas y

objetivos del software, describiéndolo en el contexto del sistema basado en computadora.

• La descripción de la información proporciona una detallada descripción del problema que el software va a resolver.

• En la descripción funcional se describen todas las funciones requeridas para solucionar el problema.

• Descripción del comportamiento examina la operativa del software como consecuencia de acontecimientos externos y características de control generadas internamente.

20

21


Especificación de los requisitos de software

• Criterios de validación actúa como una revisión implícita de todos los demás requisitos

• Finalmente, la especificación incluye una Bibliografía y un Apéndice.

• Puede incluir un prototipo funcional ó un Manual de Usuario preliminar, sirviendo para descubrir problemas en la interfaz hombre-máquina.

21

requisitos

Education