tema6
TRANSCRIPT
![Page 1: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/1.jpg)
Modelado del análisis de
requisitosTema 6
![Page 2: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/2.jpg)
Tema 6.1
![Page 3: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/3.jpg)
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.
![Page 4: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/4.jpg)
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.
![Page 5: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/5.jpg)
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
![Page 6: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/6.jpg)
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.
![Page 7: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/7.jpg)
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
![Page 8: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/8.jpg)
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
![Page 9: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/9.jpg)
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).
![Page 10: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/10.jpg)
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
![Page 11: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/11.jpg)
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.
![Page 12: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/12.jpg)
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
![Page 13: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/13.jpg)
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.
![Page 14: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/14.jpg)
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.
![Page 15: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/15.jpg)
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.
![Page 16: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/16.jpg)
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.
![Page 17: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/17.jpg)
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.
![Page 18: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/18.jpg)
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
![Page 19: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/19.jpg)
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.
![Page 20: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/20.jpg)
Tema 6.2
![Page 21: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/21.jpg)
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.
![Page 22: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/22.jpg)
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.
![Page 23: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/23.jpg)
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
![Page 24: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/24.jpg)
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).
![Page 25: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/25.jpg)
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.
![Page 26: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/26.jpg)
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.
![Page 27: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/27.jpg)
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
![Page 28: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/28.jpg)
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.
![Page 29: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/29.jpg)
4. Consistente
• Una ERS es consistente si ningún conjunto de
requisitos descritos en ella son contradictorios o
entran en conflicto.
![Page 30: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/30.jpg)
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).
![Page 31: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/31.jpg)
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).
![Page 32: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/32.jpg)
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)
![Page 33: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/33.jpg)
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
![Page 34: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/34.jpg)
![Page 35: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/35.jpg)
![Page 36: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/36.jpg)
![Page 37: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/37.jpg)
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)
![Page 38: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/38.jpg)
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.
![Page 39: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/39.jpg)
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.
![Page 40: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/40.jpg)
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.
![Page 41: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/41.jpg)
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
![Page 42: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/42.jpg)
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.
![Page 43: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/43.jpg)
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.)
![Page 44: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/44.jpg)
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.
![Page 45: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/45.jpg)
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
![Page 46: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/46.jpg)
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
![Page 47: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/47.jpg)
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.
![Page 48: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/48.jpg)
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.
![Page 49: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/49.jpg)
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.
![Page 50: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/50.jpg)
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.
![Page 51: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/51.jpg)
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.)
![Page 52: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/52.jpg)
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.)
![Page 53: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/53.jpg)
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.)
![Page 54: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/54.jpg)
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.
![Page 55: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/55.jpg)
• 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).
![Page 56: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/56.jpg)
3.6 Otros requisitos
• Otros requisitos que no se clasifiquen en las
secciones anteriores.
![Page 57: tema6](https://reader034.vdocuments.co/reader034/viewer/2022042815/5571f95449795991698f522d/html5/thumbnails/57.jpg)
Apéndices
• Formatos de entrada/salida de datos por
pantalla, listados,
• Resultados de análisis de costos
• Restricciones del lenguaje de programación