tema6

Modelado del análisis de

requisitosTema 6

Tema 6.1

Análisis

• El término análisis, aplicado a sistemas,

significa descomponerlo en sus partes en sus

componentes para estudiar cada uno de ellos

tanto como un ente aislado como en interacción

con el resto.

Especificación de requisitos

• Cuando hablamos de una fase del ciclo de vida,

el análisis consiste en producir un documento

de especificación de requisitos que describa lo

que el futuro sistema debe hacer, pero no cómo

debe hacerlo.

Definición según la IEEE estándar 610

• El análisis de requisitos es el proceso del

estudio de las necesidades de los usuarios para

llegar a una definición de los requisitos del

sistema, de hardware o de software, así como el

estudio y refinamiento de esos requisitos

Requisito

• Condición o capacidad que necesita el usuario

para resolver un problema o conseguir un

objetivo determinado. Por ejemplo, poder listar

todos los clientes que tienen pagos pendientes.

• También se refiere a las condiciones que debe

cumplir o poseer un sistema o uno de sus

componentes para satisfacer un contrato, una

norma o una especificación.

Definición de requisitos como trabajo

conjunto• La definición de requisitos es un trabajo

conjunto de:

▫ Suministradores

▫ Desarrolladores del software (a través de los

analistas)

▫ Clientes

▫ Usuarios

Fases del análisis de requisitos según

el estándar IEEE 10741. Definir los requisitos del software

2. Definir los requisitos de las interfaces

3. Integrar los requisitos y asignarles prioridades

Fase 1. Definir los requisitos del

software• Tarea iterativa para crear una definición o

especificación preliminar de los requisitos que

debe cumplir el software a partir mediante la

información obtenida mediante las técnicas de

recolección de datos. (Entrevistas, JAD,

prototipado).

Fase 2. Definir los requisitos de las

interfaces• También es necesario definir las propiedades

que se deben satisfacer para obtener una

interacción eficaz con otros elementos del

sistema como el usuario, el hardware u otras

aplicaciones de software.

• Debe definirse no sólo cómo va a fluir la

información entre el software y el usuario, sino

también, cómo el usuario lo va a utilizar

Fase 3. Integrar los requisitos en un

documento de especificación y

asignarles prioridades

• Aprobación de los requisitos por parte del

usuario.

• Asignarles prioridades en función de su

importancia o los beneficios que puede aportar

su cumplimiento.

• Una vez verificados y validados, los requisitos

se deben integrar en un documento definitivo, la

ERS, que constituye el objetivo a cumplir en el

proyecto de desarrollo.

Actividades que se realizan en la fase

de análisis de requisitosA. Extracción o determinación de requisitos

B. Análisis de requisitos

C. Especificación de requisitos

D. Validación de requisitos

A. Extracción o determinación de

requisitos• Proceso mediante el cual los clientes o los

futuros usuarios del software descubren,

revelan, articulan y comprenden los requisitos

que desean.

B. Análisis de requisitos

• El proceso de razonamiento sobre los requisitos

obtenidos en la etapa anterior, detectando y

resolviendo posibles inconsistencias o

conflictos, coordinando los requisitos

relacionados entre sí, etc.

C. Especificación de requisitos

• Proceso de redacción o registro de los

requisitos. Para este proceso se puede recurrir

al lenguaje natural, lenguajes formales, modelos

gráficos, etc.

D. Validación de los requisitos

• Proceso de confirmación por parte de los

usuarios o del cliente, de que los requisitos

especificados son válidos, consistentes,

completos, etc.

Realización de las actividades

• La realización de estas tareas no es secuencial,

hay distintas iteraciones entre ellas.

• Además, se apoyan de distintas técnicas.

Técnicas para cada actividad

A. Extracción o determinación de requisitos

▫ Técnicas de recolección de información

(Observación, cuestionarios, entrevistas, etc.)

B. Análisis de requisitos

▫ Técnicas gráficas: Diagramas de flujo de datos

DFD

▫ Métodos completos: Análisis estructurado

Técnicas para cada actividad (cont.)

C. Especificación de requisitos

▫ Las mismas que para el análisis

D. Validación de requisitos

▫ Listas de comprobación de distintos aspectos

de las especificaciones que suelen usarse como

técnicas de revisión.

Tema 6.2

Términos

• Especificación.- Documento que define de

forma completa, precisa y verificable, los

requisitos, el diseño, el comportamiento u otras

características de un sistema o componente de

un sistema.

• Software.- Conjunto de programas,

procedimientos y documentación asociada a la

operación de un sistema informático.

ERS

• Se puede definir como la documentación de los

requisitos esenciales (funciones, rendimiento,

diseño, restricciones y atributos del software y

de sus interfaces externas.

Características fundamentales de una

ERS• Debe incluir información veraz, es decir,

coherente con las necesidades reales del

usuario que se desean satisfacer.

• Debe comunicar dicha información de forma

eficaz, es decir, de tal manera que se pueda

comprender perfectamente

Características fundamentales de una

ERS (cont.)• La especificación debe describir lo que hay que

desarrollar, no el cómo, cuándo, etc. Esto

implica:

• Describir correctamente todos los requisitos del

software.

• No describir ningún detalle del diseño del

software, de su verificación o de la dirección del

proyecto; excepto las restricciones impuestas al

diseño (Ej. limitación del hardware disponible).

Características de una ERS

1. No ambigua

2. Completa

3. Fácil de verificar

4. Consistente

5. Fácil de modificar

6. Facilidad para identificar el origen y las

consecuencias de cada requisito

7. Facilidad de utilización durante la fase de

explotación y de mantenimiento.

1. No ambigua

• que no se preste a distintas interpretaciones.

Si al especificar la característica de un

requisito, se usa un término que puede tener

distintos significados, se usará un glosario

para definir su significado.

2. Completa

• Incluye todos los requisitos significativos (de funcionalidad, ejecución, diseño, calidad, etc.)

• Define respuestas del software a todos los posibles datos de entrada y en todas las posibles situaciones (tanto para entradas válidas, como para no válidas).

• Se puede apegar a un estándar. Si esto es así, y alguna de las secciones del estándar para ERS no se usa, se agregará de todas formas la sección explicando su no aplicación.

• Todas las figuras, tablas y diagramas están etiquetadas y referenciadas. Así como todos los términos y unidades de medida

3. Fácil de verificar

• Una ERS es fácil de verificar si cualquier requisito al que se haga referencia se puede verificar fácilmente, es decir, si existente algún procedimiento para que una máquina o persona compruebe que existe dicho requisito.

• Ejemplo: El sistema debe permitir la búsqueda de propiedades de acuerdo a los siguientes rubros: Por ubicación, por tipo de propiedad, por costo, etc. Y el software realmente deberá realizar dichas búsquedas.

4. Consistente

• Una ERS es consistente si ningún conjunto de

requisitos descritos en ella son contradictorios o

entran en conflicto.

Tipos de conflicto:

• Dos o más requisitos describen el mismo objeto

real, pero utilizan distintos términos para designarlo.

• Las características especificadas de objetos reales

pueden estar en conflicto. (Un requisito dice que el

estatus deberá estar en alta y otro que en baja).

• Puede haber un conflicto lógico o temporal entre

dos acciones determinadas. (Un requisito dice que

dos valores deben sumarse y otro dice que deben

multiplicarse).

5. Fácil de modificar

• Una ERS es fácil de modificar si su estructura y

estilo permiten que cualquier cambio necesario

se pueda realizar fácil, completa y

consitsentemente.

• Tendrá una organización coherente y manejable

(tabla de contenidos, índice, referencias

cruzadas).

• No será redundante (que el mismo requisito no

aparezca más de una vez).

6. Facilidad para identificar el origen y

las consecuencias de cada requisito• Debe haber referencias entre los requisitos

• Tipos de referencias

• Referencias hacia atrás (documentos previos al

desarrollo)

• Referencias hacia adelante (a los documentos

originados a partir de la ERS, cada requisito

puede tener un número de referencia que ayude

a identificarlo de forma única en otros

documentos)

7. Facilidad de utilización durante la

fase de explotación y mantenimiento• La ERS debe tener en cuenta las necesidades

de mantenimiento, incluyendo la sustitución

eventual del software

1. Introducción

• 1.1 Objetivo.- Define el propósito del documento ERS y a quien va dirigido

• 1.2 Ámbito▫ Nombre del futuro sistema

▫ Se explica lo que el sistema hará y lo que no hará

▫ Se describen beneficios, objetivos y metas que se espera alcanzar con el futuro sistema.

▫ Se referencian documentos de nivel superior (Si existiera un documento global de un sistema más complejo)

1. Introducción

• 1.3 Definiciones, siglas y abreviaturas.- Se definen

los utilizados en el documento. (Ej. ERS, SGBD,

BD, DFD, etc.)

• 1.4 Referencias.- Lista completa de todos los

documentos referenciados en la ERS. (Ej.

Propuesta del proyecto, plan del proyecto, público

objetivo y beneficios, glosario de términos)

• 1.5 Visión global.- Describe brevemente los

contenidos y la organización del resto del

documento.

2. Descripción general

• Describe todos los factores que afectan al

producto y a sus requisitos.

• No se describen los requisitos sino su contexto.

Esto permite describir con detalle los requisitos

en la sección 3.

2. Descripción general (cont.)

• 2.1 Perspectiva del producto.- Relacionar el futuro sistema (producto de software) con otros productos (si los hubiera). Si el producto es independiente de otros, también se debe especificar aquí. Si la ERS define un producto que es parte de un sistema mayor, aquí se relacionarán los requisitos del sistema mayor con la funcionalidad del producto descrito en la ERS y se explicarán las interfaces entre el sistema mayor y el descrito en la ERS.

2. Descripción general (cont.)

• 2.2 Funciones del producto.- Resumen a

grandes rasgos de las funciones del sistema.

(Ej. el sistema soportará el mantenimiento del

catálogo de propiedades, propietarios y clientes,

mostrará las propiedades por distintas

características, etc.). Se debe presentar de

forma organizada

2. Descripción general (cont.)

• 2.3 Características del usuario.- Descripción de las características generales de los usuarios del producto, incluyendo nivel educacional, experiencia técnica, etc.

• 2.4 Limitaciones generales.- Limitaciones sobre los desarrolladores del producto: Políticas de la empresa, hardware, interfaces con otras aplicaciones, operaciones paralelas, funciones de auditoría, funciones de control, lenguajes de programación, aspectos de seguridad, etc.

2. Descripción general (cont.)

• 2.5 Supuestos y dependencias .- Describe

factores, que si cambian, pueden afectar los

requisitos. (Ej. Se puede presuponer que el

sistema correrá sobre cierto sistema operativo,

si este cambia, puede afectar los requisitos del

sistema en cuanto a aspectos técnicos.)

3. Requisitos específicos

• Esta sección explica los requisitos a tal detalle

que permita a los desarrolladores diseñar un

sistema que satisfaga dichos requisitos y

planear las pruebas para verificar si el sistema

satisface o no los requisitos.

• Los requisitos que se especifican aquí, deben

describir comportamientos externos que puedan

ser percibidos por los usuarios y operadores del

sistema.

3. Requisitos específicos (cont.)

• Esta sección es la más larga e importante de la ERS y se recomienda que cumpla con los siguientes principios.

1. El documento debe ser legible para personas de distintas formaciones e intereses.

2. Referenciar documentos relevantes que tengan influencia sobre los requisitos. (manuales de procedimientos, reglamentos, políticas, estándares, etc.

3. Identificar cada requisito mediante algún código o sistema de numeración adecuado

3.1Requisitos funcionales

• Esta subsección quizá es la más larga del

documento. Debe especificar todas las

funciones o acciones que deberá llevar a cabo

el software.

• Ej. El sistema deberá permitir altas, bajas,

cambios y consultas de los distintos propietarios

que desean vender o rentar una propiedad

3.1 Requisitos funcionales

• Se pueden organizar de la siguiente manera:

• Requisitos por tipos de usuario.- Cada usuario tiene distintas actividades, por lo cual se especificarán los requisitos que tengan mayor relación con las tareas de cada tipo de usuario.

• Por objetos.- Se refiere a entidades del mundo real. Para cada objeto se detallarán sus atributos y sus funciones. Ej. Objeto propiedades, atributos: m2, ubicación, habitaciones, precio venta, etc.

3.1 Requisitos funcionales

• Jerarquía funcional.- para esta clasificación se identificarán distintas funciones del sistema y se detallarán entradas, procesos y salidas. Ej. Función de cálculo de gastos por propiedad. ▫ Entradas. Datos de propiedades y medios de

publicidad, costos de cada medio, periodos de publicidad, etc.

▫ Procesos. Suma de todos los gastos relacionados con una propiedad en un periodo determinado.

▫ Salida. Listado de todos los gastos e importe total de gastos por cada propiedad en un periodo determinado.

3.2 Requisitos de interfaz externa

• Se refieren básicamente a las entradas y

salidas del sistema.

• En el caso del análisis estructurado, se pueden

identificar fácilmente con sólo fijarse en los

flujos que entran y salen del sistema en un

diagrama de contexto.

3.2 Requisitos de interfaz

externa(cont.)• Las entradas se pueden obtener por teclado,

sensores, archivos, bases de datos, etc.

• En el caso de las salidas se pueden especificar

formatos de pantallas, reportes en papel,

archivos, bases de datos, etc.

3.2 Requisitos de interfaz

externa(cont.)• La definición de interfaces de entrada / salida (E/S),

tiene como objetivo establecer el modo en el que el sistema va a interactuar con el exterior del sistema.

• Es conveniente organizar las interfaces por:▫ Interfaces de usuario (Ej. pantallas de entrada de datos, de

salida, reportes, etc.)

▫ Interfaces de hardware (Ej. Sensores, lectores de código de barras, etc.)

▫ Interfaces de software (Ej. si es un sistema de contabilidad, recibirá entradas del sistema de ventas, de compras, etc.)

▫ Interfaces de comunicaciones (Ej. Si el sistema recibirá datos a través de extranet, Internet, línea telefónica, circuito cerrado de televisión, etc.)

3.3 Requisitos de ejecución

• Requisitos relacionados con la carga que se

espera tenga el sistema. Ej. Número de

terminales, número de usuarios concurrentes,

número de transacciones por segundo.

• También requisitos de datos, como la cantidad

de registros a almacenar en la base de datos.

(decenas, cientos, miles, etc.)

3.4 Restricciones de diseño

• Restricciones impuestas por estándares,

• Limitaciones del hardware (imágenes de baja

resolución, cantidad de colores, de imágenes,

etc.)

3.5 Atributos de calidad

• Detallar los atributos de calidad:

• Fiabilidad.- Que el sistema mantenga y genere

datos congruentes, verídicos, etc.

• Mantenibilidad .- Facilidad de que el software

pueda recibir mantenimiento debido a la

documentación interna y externa generada,

organización del código, etc.

• Portabilidad .- Que el software pueda instalarse

en otras plataformas sin requerir cambios o

modificaciones drásticos.

• Seguridad .- Especificar qué tipo de usuarios

están autorizados, cuáles no para realizar

ciertas tareas y cómo se van a implementar los

mecanismos de seguridad (Ej. usuario y

contraseña).

3.6 Otros requisitos

• Otros requisitos que no se clasifiquen en las

secciones anteriores.

Apéndices

• Formatos de entrada/salida de datos por

pantalla, listados,

• Resultados de análisis de costos

• Restricciones del lenguaje de programación