47
FUNDAMENTOS DEL FUNDAMENTOS DEL ANALISIS DE REQUISITOS ANALISIS DE REQUISITOS

Cap 6 Fundamentos Análisis Requisitos

Embed Size (px)

DESCRIPTION

Mantenimiento de sistemas de información

Citation preview

Page 1: Cap 6 Fundamentos Análisis Requisitos

FUNDAMENTOS DEL FUNDAMENTOS DEL ANALISIS DE REQUISITOSANALISIS DE REQUISITOS

Page 2: Cap 6 Fundamentos Análisis Requisitos

ANALISIS DE REQUISITOSANALISIS DE REQUISITOS

El análisis de requisitos es la tarea de la ingeniería del software que establece un puente entre la asignación del software a nivel de sistema y de diseño del software.

El análisis de requisitos facilita al ingeniero de sistemas la especificación de la función y del rendimiento del software, la descripción de la interfaz con otros elementos del sistema y el establecimiento de las restricciones de diseño que debe considerar el software. El análisis de requisitos permite al ingeniero de software refinar la asignación del software y construir modelos de los ámbitos del proceso de los datos y comportamiento.

Page 3: Cap 6 Fundamentos Análisis Requisitos

ANALISIS DE REQUISITOSANALISIS DE REQUISITOS

El análisis de requisitos proporciona al diseñador del software una representación de la información y de las funciones que se puede traducir en un diseño de datos, arquitectónico y procedimental.

Tareas de Análisis

En el análisis de los requisitos del software se pueden identificar cinco áreas de esfuerzo:

1.- Reconocimiento del problema,

2.- Evaluación y síntesis,

3.- modelización,

4.- Especificación y

5.- Revisión.

Page 4: Cap 6 Fundamentos Análisis Requisitos

RECONOCIMIENTO DEL PROBLEMARECONOCIMIENTO DEL PROBLEMA

Inicialmente, el analista estudia la especificación del sistema (si existe) y el plan del proyecto de software. Es importante llegar a comprender el software dentro del contexto del sistema y revisar el ámbito del software que se ha usado para generar las estimaciones en la planificación. El analista debe establecer contacto con el equipo técnico y de gestión del usuario/cliente y de la organización de desarrollo del software.El gestor del proyecto puede servir como coordinador para facilitar el establecimiento de los caminos de comunicación. El objetivo del analista es reconocer los elementos básicos del problema tal como lo percibe el usuario/cliente.

Page 5: Cap 6 Fundamentos Análisis Requisitos

EVALUACIÓN Y SÍNTESISEVALUACIÓN Y SÍNTESIS La evaluación del problema y la síntesis de la solución

es la siguiente área principal del esfuerzo del análisis. El análista debe evaluar el flujo y la estructura de la

información. Definir y elaborar todas las funciones del software. Entender el comportamiento del programa en el contexto

de los sucesos que afectan al sistema. Establecer las características de la interfaz del sistema Descubrir las restricciones del diseño. Cada una de estas tareas sirve para describir el problema

de forma que pueda sintetizarse un enfoque o situación global.

Page 6: Cap 6 Fundamentos Análisis Requisitos

EVALUACION Y SINTESISEVALUACION Y SINTESIS

Suponga el desarrollo un sistema de control de inventarios para un suministrador de respuestos para coches

El analista descubre que los problemas del sistema manual son (IDENTIFICACION DEL PROBLEMA):– Imposibilidad de obtener rápidamente el estado de un

componente– Tiempo medio de dos a tres días para la actualización del

archivo de targetas– Múltiples repeticiones de pedidos del mismo vendedor ya que

no hay forma de asociar a los vendedores con los componentes

Ahora el analista determina que información ba a producir el nuevo sistema y que datos se le suministraran

Page 7: Cap 6 Fundamentos Análisis Requisitos

EVALUACION Y SINTESISEVALUACION Y SINTESIS

– El cliente desea un informa diario que indique las piezas que sean tomado del inventario

– El cliente indica que los encargados de inventario registraran el número de identificación de cada pieza una vez que se retiran del inventario

Tras evaluar los problemas actuales y la información deseada, el analista comienza a sintetizar una o más soluciones– Un sistema basado en una terminal interactiva– Un sistema DBMS

El proceso de evaluación y síntesis continua hasta que el analista y el cliente estimen que se puede específicar el software de forma adecuada para los consiguientes pasos de desarrollo.

Page 8: Cap 6 Fundamentos Análisis Requisitos

EVALUACION Y SINTESISEVALUACION Y SINTESIS

A lo largo de la evaluación y síntesis de la solución, el analista se centra basicamente en el QUE y no en el COMO.– ¿ Que datos produce y consume el sistema ?– ¿ Que interfaces estan definidas ?– ¿ Que funciones debe realizar el sistema ?– ¿ Que restricciones se aplican ?

Durante la evaluación y la síntesis de la solución, el analista crea modelos del sistema en un esfuerzo por entender mejor el flujo de datos y de control, el procesamientofuncional, el comportamiento en operación y el contenido de la información.

El modelo servirá de pilar para el diseño del software y como base para la creación de una especificación del software.

Page 9: Cap 6 Fundamentos Análisis Requisitos

EVALUACION Y SINTESISEVALUACION Y SINTESIS

Anteriormente se explico que en esta etapa no es posible hacer una especificación detallada. El cliente puede no estar seguro de lo que precisamente quiere. El desarollador puede no estar seguro de que un enfoque concreto sea apropiado para realizar la función y comportamiento deseado.

Por esta y muchas razones, puede seguirse un método alternativo llamado construcción de prototipos, para el análisis de requisitos

Otra alternativa aunque al parecer inecesaria y poco lógica para un etapa tan temprana del proceso de ingeniería del software es el desarrollar un manual de usuario.

Page 10: Cap 6 Fundamentos Análisis Requisitos

EVALUACION Y SINTESISEVALUACION Y SINTESIS

El borrador del manual del usuario fuerza al analista a ponerse en el lugar del usuario del software.

El manual provoca la revisión del software por parte del usuario/cliente desde una perspectiva de ingeniería humana. Frecuentemente surge el siguiente comentario.– La idea es correcta, pero esta no es la forma en que pense que

se haria. El analista debe ser una persona muy completa y exhibir

los siguientes rasgos de carácter:– Habilidad para comprender conceptos abstractos,

reorganizarlos en divisiones lógicas y sintetizar soluciones– Habilidad para abstraer hechos importes de funtes con ruído– Habilidad para comprender entornos de usuarios clientes– Habilidad para aplicar elementos del sistema de hardware y/o

software a entornos de usuarios clientes.

Page 11: Cap 6 Fundamentos Análisis Requisitos

EL ANALISTAEL ANALISTA

– Habilidad para comunicarse bien de forma escrita y verbal– Habilidad para no parar en exceso en los detalles y perder de

vista el objetivo global del software

El analista debe descubrir los requisitos del software de una manera descendente, comprendiendo perfectamente las funciones principales, las interfaces y la información antes de especificar los niveles suficientes de detalle

Generalmente es responsable del desarrollo de una especificación de requisitos del software

El análisis de requisistos es una actividad de intensa comunicación. Siempre que existe comunicación, el ruido puede producir problemas tanto el analista como el cliente.

Page 12: Cap 6 Fundamentos Análisis Requisitos

AREAS DE PROBLEMASAREAS DE PROBLEMAS Las principales dificultades que pueden encontrarse

durante el análisis de requisitos estaran asociadas con:– La adquisisción de la información pertinente– El manejo de la complejidad del problema– La gestión de los cambios que pueden producirse durante y

déspues del análisis

Conforme crece el tamaño del problema, crece también la complejidad de la tarea de análisis cada nuevo elemento de información, nueva función, o nueva restricción puede afectar a los demas elementos del software.– ¿ Que información debe recogerse y como debe representarse ?– ¿ Quien suministra las distintas partes de la información ?– ¿ Que herramientas y técnicas estan disponibles para facilitar la

recolección de información ?– ¿ Puede un problema grande ser subdividido con efectividad ?

Page 13: Cap 6 Fundamentos Análisis Requisitos

AREAS DE PROBLEMASAREAS DE PROBLEMAS

Aunque el enfoque de la ingeniería del software para el análisis de requisitos no es una panacea, la aplicación de los principios fundamentales de análisis y de metódos sistematicos de análisis reducira considerablemente el impacto de estos problemas. La técnica de análisis más comunmente usada para cubrir el vacío de comunicación entre cliente y analista es dirigir una entrevista o una revisión preeliminar.

En las primeras entrevistas se suguiere que el analista comience con preguntas independientes del contexto –un conjunto de peguntas que lleven al conocimiento básico sobre el problema, sobre la gente que quiere una solución, sobre la naturaleza de la solución deseada y sobre la efectividad del propio primer encuentro.

Page 14: Cap 6 Fundamentos Análisis Requisitos

TECNICAS DE COMUNICACIONTECNICAS DE COMUNICACION

El primer conjunto de preguntas independientes del contexto se centran en el cliente, en los objetivos generales y en los beneficios– ¿ De quien ha surgido la petición de este trabajo ?– ¿ Quien va a utilizar la solución ?– ¿ Cuál será el beneficio económico de una solución

satisfactoria ?– ¿ Existe otro lugar donde puede encontrar la solución que

necesita ?

El siguiente conjunto de preguntas permite al analista conocer mejor el problema y al cliente expresar sus ideas sobre la solución: – ¿ Como definiria una buena salida generada por una solución

satisfactoria ?

Page 15: Cap 6 Fundamentos Análisis Requisitos

TECNICAS DE COMUNICACIONTECNICAS DE COMUNICACION

– ¿ Que problema resolvera esta solución ?– ¿ Puede mostrarme el entorno en el que se utilizara la solución?– ¿ Hay alguna limitación o aspecto especial de rendimiento que

vaya a la forma en que se enfoque la solución ?

El ultimo conjunto de preguntas se centra en la efectividad de la reunión (metapreguntas)– ¿ Son oficiales sus respuestas ?– ¿ Son relevantes mis preguntas para mis problemas ?– ¿ Estoy haciendo demasiadas preguntas ?– ¿ Hay alguen más que pueda proporcionar información

adicional ?– ¿ Hay algo más que deba preguntar ?

Estas preguntas ayudaran a romper el hielo y a iniciar la comunicación, que es esencial para un correcto análisis

Page 16: Cap 6 Fundamentos Análisis Requisitos

TECNICAS DE COMUNICACIONTECNICAS DE COMUNICACION

La sesión de preguntas y respuestas solo debe usarse en las primeras entrevistas y luego sustituirlas por un esquema de reunión que combine elementos de resolución de problemas, negociación y especificación.

Existe un enfoque orientado al equipo para la recopilación de requisitos llamado o denominado ´Técnicas para Facilitar la Especificación de la Aplicación (TFEA), que comprende la creación de un equipo mixto de clientes y personas encargadas del desarrollo que trabajan juntos para identificar el problema, proponer elementos de solución, evaluar diferentes enfoques y especificar un conjunto preeliminar de requisitos de la solución.

Page 17: Cap 6 Fundamentos Análisis Requisitos

TECNICAS DE COMUNICACIONTECNICAS DE COMUNICACION

Utilice las siguientes directrices básicas: – Se lleva acabo una reunión en un lugar neutral a la que asisten

tanto desarrolladores como cliente– Se establecen reglas para la preparación y participación– Se suguiere una agenda lo suficientemente formal para que

cubra todos los puntos importantes, pero lo suficientemente informal para estímular el flujo libre de ídeas

– Se acuerda la elección de un facilitador para controlar la reunión

– Se utiliza un mecanismo de definición (hojas de trabajos, diagramas, pizarras o tableros)

– El objetivo es identificar el problema, proponer elementos de una solución, evaluar los diferentes enfoques y especificar un conjunto preeliminar de requisitos de la solución en una átmosfera adecuada para alcanzar el objetivo.

Page 18: Cap 6 Fundamentos Análisis Requisitos

PRINCIPIOS DE ANALISISPRINCIPIOS DE ANALISIS

Los métodos de análisis estan relacionados por un conjunto de principios fundamentales:– Se debe representar y comprender el ámbito de información del

problema– Se deben desarrollar los modelos que representen la

información, función y el comportamiento del sistema– Se deben de subdividir los modelos (y el problema) de forma

que se descubran los detalles de una manera progresiva– El proceso de análisis debe ir de la información esencial hacia

el detalles de la implenetación Aplicando estos principios el analista enfoca el problema

sistematicamente:– El ámbito de información se examina para poder comprender

completamente la función– Los modelos se utilizan para poder comunicar la información

de forma compacta

Page 19: Cap 6 Fundamentos Análisis Requisitos

PRINCIPIOS DE ANALISISPRINCIPIOS DE ANALISIS

– La partición se aplica para reducir la complejidad– Los planteamientos esencial y de implementación del software

son necesarios para acomodar las lígaduras lógicas impuestas por los requisitos del procesamiento y la lígaduras físicas impuestas por otros elementos del sistema.

Dentro del ámbito de información del problema residen tanto los datos (números, caracteres, imágenes, etc) como el control (sucesos)

Un suceso representa algun aspecto de control de sistema, no es más que un dato booleano

El ámbito de información contiene tres planteamientos diferentes de los datos y del control ha medida que son procesados por un programa

Page 20: Cap 6 Fundamentos Análisis Requisitos

– El flujo de información .- representa la manera en la que los datos y el control cambian conforme se mueven atraves de un sistema. Las transformaciones que se aplican a los datos son funciones o subfunciones que un programa debe ejecutar. El control y los datos que se mueven entre dos transformaciones definen la interfaz de cada función.

– El contenido de la información.- Represnta los elementos de datos individuales que componen otros elementos mayores de información ([nombre de empleado, sueldo neto, sueldo bruto, deducciones,etc.] = nomina)

– La estructura de la información.- Representa la organización interna de los distintos elementos de datos y de control. ¿ Que estructura de datos es la ideal para representar la información (tablas n dimensionales, árboles, etc.)

PRINCIPIOS DE ANALISISPRINCIPIOS DE ANALISIS

Page 21: Cap 6 Fundamentos Análisis Requisitos

PRINCIPIOS DE ANALISIS: PRINCIPIOS DE ANALISIS: MODELIZACIONMODELIZACION

Creamos modelos para obtener un mejor entendimiento de la entidad a construir. Nuestro modelo debe ser capaz de modelizar la información que transforma el software, las funciones que permite que se tradusca la transformación y el comportamiento del sistema a medida que se produce la transformación

Los modelos se centran en lo que tiene que hacer el sistema y no en como lo tiene que hacer. En muchos casos, los modelos utilizan una notación grafica que representan la información, el proceso, el comportamiento del sistema y otras características, mediante iconos claros y fáciles de reconocer.

Page 22: Cap 6 Fundamentos Análisis Requisitos

PRINCIPIOS DE ANALISIS: PRINCIPIOS DE ANALISIS: MODELIZACIONMODELIZACION

Los modelos creados durante el análisis de requisitos desempeñan varios papeles importantes:– El modelo ayuda al analista ha entender la información, la

función y el comportamiento del sistema, haciendo por ello que la tarea de análisis de requisitos sea más fácil y más sistematica

– El modelo se convierte en el punto focal para la revisión, y por tanto, en la clave para la determinación de la integridad, la consistencia y la eficacia de la especificación

– El modelo se convierte en la base del diseño, proporcionando el diseñador una representación esencial del software que se puede “hacer corresponder” con un contexto de implementación.

Page 23: Cap 6 Fundamentos Análisis Requisitos

A menudo los problemas son demasiado grandes y complejos para que se puedan comprender como un todo.

Por esta razón, tendemos a partir (dividir) dichos problemas en partes que se pueden entender fácilmente y establecer interfaces entre las partes, de forma que se realice la función global.

En esencia, la partición descompone un problema en sus partes constituyentes.

Conceptualmente, se establece una representación jerárquica de la función o de la información y luego se descompone el elemento superior de la siguiente forma:

PRINCIPIOS DE ANALISIS: PARTICIONPRINCIPIOS DE ANALISIS: PARTICION

Page 24: Cap 6 Fundamentos Análisis Requisitos

– Exponiendo cada vez más detalles, al moverse verticalmente por la jerarquía

– Descomponiendo funcionalmente el problema, al movernos horizontalmente por la jerarquía.

PROBLEMA DEL HOGAR SEGURO

PRINCIPIOS DE ANALISIS: PARTICIONPRINCIPIOS DE ANALISIS: PARTICION

P artic ió n H orizon ta l S o ftware H og ar S eg u ro

C on fig u rac ió n d e l S is tem a M on ito rizac ió n d e S en sores In te racc ió n con e l U su ario

S oftware d e H og ar S eg u ro

Page 25: Cap 6 Fundamentos Análisis Requisitos

C o nfi gur ació n del s is tema

L ectur a del es tado del senso r Identifi cació n del tipo de suceso A ctivació n / desactivació n del senso r

R astr eo de suceso s de senso r

A ctivació n de la alr ma aud ib le M ar cado del númer o de teléfo no

A ctivació n de las funcio nes de alar ma

M o n ito r izació n de senso r es In ter acció n co n el usuar io

So ftw ar e H o gar Segur o

PRINCIPIOS DE ANALISIS: PARTICIONPRINCIPIOS DE ANALISIS: PARTICION

Page 26: Cap 6 Fundamentos Análisis Requisitos

El método de partición se puede aplicar al ámbito de la información y al ámbito del comportamiento del sistema.

El planteamiento esencial de los requisitos del software presenta las funciones que han de realizarse y la información que ha de procesarse, independientemente de los detalles de implementación.

Centrando la atención en la esencia del problema en las primeras etapas del análisis de requisitos, dejamos abiertas opciones de especificación de los detalles de implementación en etapas posteriores de la especifiación de requisitos y del diseño del software

PRINCIPIOS DE ANALISIS: PRINCIPIOS DE ANALISIS: PLANTEAMIENTO ESENCIALPLANTEAMIENTO ESENCIAL

Page 27: Cap 6 Fundamentos Análisis Requisitos

El planteamiento de implementación de los requisitos del software presenta la manifestación en el mundo real de las funciones de procesamiento y de las estructuras de información.

Se deben contemplar características generales como parte de la especificación de requisitos del software.

El analista debe reconocer las restricciones impuestas por los elementos predefinidos del sistema y considerar el punto de vista de implementación de la función y de la información, cuando dicho planteamiento sea apropiado.

PRINCIPIOS DE ANALISIS: PRINCIPIOS DE ANALISIS: PLANTEAMIENTO ESENCIALPLANTEAMIENTO ESENCIAL

Page 28: Cap 6 Fundamentos Análisis Requisitos

El modelo esencial es genérico en el sentido de que la realización de la función no está indicada explícitamente.

En algunos casos, se pueden aplicar los principios fundamentales de análisis y derivar una especificación del software en papel a partir de la cual se pueda desarrollar el diseño.

En otras ocasiones, se realiza una recolección de requisitos, se aplican los principios de análisis y se construye un modelo de software, denominado prototipo.

Este prototipo es valorado por el cliente y el desarrollador.

CONSTRUCCION DEL PROTOTIPO CONSTRUCCION DEL PROTOTIPO DEL SOFTWAREDEL SOFTWARE

Page 29: Cap 6 Fundamentos Análisis Requisitos

Por último, hay veces en las que se requiere la construcción de un prototipo al comienzo del análisis, debido a que el modelo es el único medio mediante el cual se pueden obtener los requisitos de forma efectiva. El modelo evolucionará hasta transformarse en el producto del software.

Todos los proyectos de ingenieria del software arrancan con una petición de un cliente. La petición puede venir dada como:– Una memoria qué describe el problema.– Un informe que define el conjunto de objetivos

comerciales o del producto.– Una petición de propuesta (PDP) formal de una

empresa o agencia exterior.

CONSTRUCCION DEL PROTOTIPO CONSTRUCCION DEL PROTOTIPO DEL SOFTWAREDEL SOFTWARE

Page 30: Cap 6 Fundamentos Análisis Requisitos

– Una especificación del sistema que asigna una función y un comportamiento al softwarecomo elemento de un sistema mayor.

Suponiendo que existe una petición de software de alguna de las formas anteriores, para construir un prototipo del software se aplican los siguientes pasos:

1. Evaluación de la petición de software para determinar si el software a desarrollar es un buen candidato para la construcción de un prototipo.

1. En general cualquier aplicación que cree una presentación visual dinámica, que interactúe mucho con el usuario o que demande algoritmos o procesos combinatorios que deban ser desarrollados de forma evolutiva, es candidata para ser construida como prototipo

CONSTRUCCION DEL PROTOTIPO CONSTRUCCION DEL PROTOTIPO DEL SOFTWAREDEL SOFTWARE

Page 31: Cap 6 Fundamentos Análisis Requisitos

2. Dado que el cliente deberá interactuar con el prototipo en pasos posteriores es esencial que se tenga en cuenta los recursos del cliente en la evaluación y el refinamiento del prototipo y que el cliente sea capaz de tomar decisiones sobre requisitos a tiempo.

2. Dado un proyecto candidato aceptable, el analista desarrolla una representación abreviada de los requisitos.

1. Antes de que pueda comenzar la construcción del prototipo, el analista debe representar los ámbitos de información, funcional y de comportamiento del problema y desarrollar un método razonable de descomposición.

3. Después de revisar el modelo de requisitos, se crea un conjunto abreviado de especificaciones de diseño para el prototipo.

1. Antes de comenzar la construcción del prototipo, se debe llevar cabo un diseño.

CONSTRUCCION DEL PROTOTIPO CONSTRUCCION DEL PROTOTIPO DEL SOFTWAREDEL SOFTWARE

Page 32: Cap 6 Fundamentos Análisis Requisitos

4. Creación del software del prototipo, prueba y refinamiento.

1. Lo ideal sería utilizar bloques constituyentes de software preexistentes para crear el prototipo rápidamente.

2. Para aplicaciones interactivas, a menudo se puede crear un prototipo en papel que describa la interacción hombre-máquinausando una serie de historietas. Cada hoja de la historieta contendrá una representación de una imagen de la pantalla junto con un texto que describa la interacción entre la máquina y el usuario.

3. El cliente revisará las historietas, obteniendo una perspectiva de usuario del funcionamiento del software. En muchos casos, el prototipo en papel no es un papel, sino una serie de pantallas interactivas generadas mediante una herramienta de creación de prototipos.

5. Una vez probado el prototip, presentación al cliente, para que “conduzca una prueba” de la aplicación y sugiera modificaciones.

CONSTRUCCION DEL PROTOTIPO CONSTRUCCION DEL PROTOTIPO DEL SOFTWAREDEL SOFTWARE

Page 33: Cap 6 Fundamentos Análisis Requisitos

1. Este paso es el foco del método de construcción de prototipos. Es aquí donde el cliente puede examinar una representación implementada de los requisitos del software y sugerir modificaciones que harán que el software satisfaga mejor las necesidades reales.

6. Repetición de los pasos 4 y 5 de forma iterativa, hasta que todos los requisitos queden formalizados o hasta que el prototipo evolucione en el sistema de producción.

El paradigama de construcción de prototipos puede seguir con uno de dos objetivos en mente:

1. El propósito de la construcción del prototipo es establecer un conjunto de requisitos formales que puedan luego ser traducidos en el producto de software mediante el uso de métodos y técnicas de ingeniería del software

2. El propósito de la construcción del prototipo es proporcionar una base continua que lleve a un desarrollo evolutivo del producto de software.

CONSTRUCCION DEL PROTOTIPO CONSTRUCCION DEL PROTOTIPO DEL SOFTWAREDEL SOFTWARE

Page 34: Cap 6 Fundamentos Análisis Requisitos

Para que la construcción de prototipos de software sea efectiva, el prototipo debe desarrollarse rápidamente, de forma que el cliente pueda comprobar los resultados y recomendar cambios.

Para realizar una construcción rápida del prototipo, existen tres clases genéricas de métodos y herramientas: técnicas de la cuarta generación, componentes de software reusables y especificación formal y entornos de construcción de prototipos.

Las técnicas de análisis pueden conducir a una especificación en papel o basada en computadora (desarrollada con herramientas CASE) que contengan descripciones gráficas y en lenguaje natural de los requisitos del software.

CONSTRUCCION DEL PROTOTIPO CONSTRUCCION DEL PROTOTIPO DEL SOFTWAREDEL SOFTWARE

Page 35: Cap 6 Fundamentos Análisis Requisitos

ESPECIFICACIONESPECIFICACION La construcción de prototipos lleva a una

especificación ejecutable, es decir, el prototipo sirve como una representación de los requisitos. Los lenguajes de especificación formal conducen a representaciones formales de los requisitos que pueden ser verificadas o analizadas.

Los requisitos se representan de forma que conduzcan finalmente a una correcta implementación del software.

Se proponen 8 principios para una buena especificación:

Page 36: Cap 6 Fundamentos Análisis Requisitos

1. Separar funcionalidad de implementaciónUna especificación, por definición, es una descripción de lo que se desea realizar, no de cómo se va a realizar

2. Se necesita un lenguaje de especificación de sistemas orientada al proceso

Debe emplearse una descripción orientada al proceso, en el cual la especificación de qué se consigue mediante la especificación de un modelo del comportamiento deseado en términos de respuestas funcionales a distintos estímulos del entormo.

Ha de describirse formalmente el proceso a automatizar y el entorno en el que existe.

ESPECIFICACIONESPECIFICACION

Page 37: Cap 6 Fundamentos Análisis Requisitos

3. Una especificación debe abarcar el sistema del cual el software es un componente.

Un sistema está compuesto de componentes que interactúan. Sólo dentro del contexto del sistema completo y de la interacción entre sus partes puede ser definido el comportamiento de un componente específico.

4. Una especificación debe abarcar el entorno en el que el sistema opera.

Similarmente, debe especifiacrse el entorno en el que opera el sistema y con el que interactúa. Tan solo supone reconocer que le propio entorno es un sistema compuesto de objetos, pasivos y activos, que interactúan, de los cuales el sistema especificado es un agente.

ESPECIFICACIONESPECIFICACION

Page 38: Cap 6 Fundamentos Análisis Requisitos

Los otros agentes, los cuales son por definición inalterables debido a que son parte del entorno, limitan el ámbito del diseño e implementación posteriores.

La especificación debe retratar con precisión el sistema y su entorno, tal como se percibe por su comunidad de usuarios, contantos detalles como sea necesario para las fases de diseño e implementación.

5. Una especificación de sistema debe ser un modelo cognitivo

La especificación de un sistema debe ser un modelo cognitivo en vez de un modelo de diseño o de implementación.

ESPECIFICACIONESPECIFICACION

Page 39: Cap 6 Fundamentos Análisis Requisitos

Debe describir un sistema tal y como es percibido por su comunidad de usuarios. Los objetos que manipula deben corresponderse con objetos reales de dicho ámbito; los agentes deben modelizar a los individuos, a las organizaciones y a los equipos de ese ámbito y a las acciones que ejecutan deben de modelizar lo que realmente ocurre en el ámbito.

6. Una especificación debe ser operativaEsto implica que la especificación, sin ser una especificación completa del cómo, pueda actuar como un generador de posibles comportamientos, entre los que debe estar la implementación propuesta.

ESPECIFICACIONESPECIFICACION

Page 40: Cap 6 Fundamentos Análisis Requisitos

7. La esepcificación del sistema debe ser tolerante a la incompletitud y ampliable.

Ninguna especificación puede ser totalmente completa. El entorno en el que existe es demasiado complejo para que lo sea.

8. Una especificación debe estar localizada y débilmente acoplada.

Los principios anteriores tratan la especificación como una entidad estática. Esto surge de la dinámica de la especificación. Debe reconocerse que, aunque el principal propósito de una especificación sea servir como base para el diseño y la implemntación de algún sistema, no es un objeto estático, sino uno dinámico que sufre considerables modificaciones.

ESPECIFICACIONESPECIFICACION

Page 41: Cap 6 Fundamentos Análisis Requisitos

El formato de representación y el contenido deben de ser adecuados al problema. – Las formas de representación contenidas en la

especificación, normalmente varían de acuerdo con el área de aplicación.

Se debe anidar la información contenida en una especificación.– Las representaciones deben revelar capas de

información, de forma que un lector pueda ir al nivel de detalle requerido. Los esquemas de numeración de párrafos y de diagramas deben indicar el nivel de detalle que presentan

ESPECIFICACIONESPECIFICACION

Page 42: Cap 6 Fundamentos Análisis Requisitos

Se debe restringir el número de diagramas y notaciones, y usarlos de forma consistente.– Una notación confusa o inconsistente, ya sea gráfica o

simbólica, degrada la comprensión y fomenta los errores.

Las representaciones deben ser revisables– El contenido de una especificación cambiará. En un

entorno ideal, estarán disponibles herramientas CASE para actualizar todas las representaciones que puedan ser afectadas por cada cambio.

ESPECIFICACIONESPECIFICACION

Page 43: Cap 6 Fundamentos Análisis Requisitos

ESPECIFICACION DE REQUISITOS ESPECIFICACION DE REQUISITOS DE SOFTWAREDE SOFTWARE

La especificación de los requisitos del software se produce como una culminación a la etapa de análisis.

La introducción describe los fines y los objetivos del software, describiéndolos en el contexto de un sistema basado en computadora.

La sección de descripción de la información proporciona una descripción detallada del problema que el software debe resolver. Estarán documentados el flujo y la estructura de la información. Se describe el hardware, el software y las interfaces humanas, para elementos externos del sistema y las funciones internas del software.

Page 44: Cap 6 Fundamentos Análisis Requisitos

La sección de descripción funcional proporciona una descripción de cada función requerida para resolver el problema. Para cada funcións se da una explicación del procesamiento, se establecen y justifican las restricciones de diseño, se establecen las características del comportamiento y se incluyen uno o más diagramas para representar gráficamente la estructura global del software y la interrelación entre sus funcionesy otros elementos del sistema.

La sección de criterios de validación actúa como una revisión implícita del resto de los requisitos.

La bibliografía contiene referencias a todos los documentos relacionados con el software. Documentación de ingenieria de software así como referencias técnicas, etc.

ESPECIFICACION DE REQUISITOS ESPECIFICACION DE REQUISITOS DE SOFTWAREDE SOFTWARE

Page 45: Cap 6 Fundamentos Análisis Requisitos

El apéndice contiene información que complementa la especificación. En los apéndices se presentan las tablas de datos, la descripción detallada de los algoritmos, los diagramas los gráficos y otro material.

En muchos casos la especificación de los requisitos del software puede acompañarse de un prototipo ejecutable, un manual del usuario preliminar, un prototipo en papel.

ESPECIFICACION DE REQUISITOS ESPECIFICACION DE REQUISITOS DE SOFTWAREDE SOFTWARE

I. Introducción

A. Referencia del sistema

B. Descripción general

C. Restricciones del proyecto de software

Page 46: Cap 6 Fundamentos Análisis Requisitos

I. Descripción de la informaciónA. Representación del flujo de la información

1. Flujo de datos

2. Flujo de control

B. Representación del contenido de la información

C. Descripción de la interfaz del sistema

II. Descripción funcionalA. Partición funcional

B. Descripción funcional1. Narrativa de procesamiento

2. Restricciones y limitaciones

3. Requisitos de rendimiento

4. Restricciones de diseño

5. Diagramas de soporte

ESPECIFICACION DE REQUISITOS ESPECIFICACION DE REQUISITOS DE SOFTWAREDE SOFTWARE

Page 47: Cap 6 Fundamentos Análisis Requisitos

C. Descripción del control1. Especificación del control2. Restricciones de diseño

IV. Descripción del comportamientoA. Estados del sistemaB. Sucesos y acciones

V. Criterios de validaciónA. Límites de rendimientoB. Clases de pruebasC. Respuesta esperada del softwareD. Consideraciones especiales

VI. BibliografíaVII. Apéndices

ESPECIFICACION DE REQUISITOS ESPECIFICACION DE REQUISITOS DE SOFTWAREDE SOFTWARE