Normalmente participan en esta actividad de análisis cuando se debe cambiar la especificación de requisitos y cuando se debe recopilar información adicional. a) Los clientes y Usuarios b) Los clientes.
El análisis de requisitos: a) da lugar a un modelo del sistema que pretende ser completo y coherente . b) da lugar a un modelo del sistema que pretende ser correcto, completo, coherente e inequívoco.
validan, corrigen y aclaran la especificación de requisitos si se encuentran errores o
ambigüedades. a) Los desarrolladores b) Los analistas .
El objetivo es desarrollar los requisitos con el suficiente calidad y detalle de tal manera que los gerentes
pueden construir estimaciones realistas del proyecto y el personal técnico pueda proceder con el diseño, construcción y pruebas. a) El análisis de requisitos b) El análisis financiero.
Los requisitos obtenidos desde los interesados y articulados usando modelos de análisis necesitan ser
lo suficientemente claros y completos para posteriormente validar el proceso de: a) Requerimientos de software.
b) Requerimientos de Usuario.
.
El análisis de los requisitos es principalmente responsabilidad del analista, pero puede involucrar a los
actores clave, tales como:
a) usuarios, clientes y personal técnico quienes son necesarios para entender las necesidades del usuario.
b) clientes quienes son necesarios para entender las necesidades del usuario.
.
Es importante crear el modelo de requisitos porque le ayudará a:
a) Facilitar la comunicación entre personal técnico y empresarios. b) Descubrir requisitos faltantes, erróneos, ambiguos y contradictorios. c) Dificultar la comunicación entre personal técnico y empresarios. d) Descubrir requisitos faltantes, erróneos, ambiguos y contradictorios. e) Utilice los diferentes modos de pensamiento humano. f) Dejar pasar por alto requisitos faltantes, erróneos, ambiguos y contradictorios.
El ciclo de análisis de requisitos: a) Modelo de negocio, definir el alcance del proyecto, crear modelos al detalle de requisitos de usuario, priorizar los requisitos. b) Priorizar los requisitos, definir el alcance del proyecto, crear modelos al detalle de requisitos de usuario.
Para analizar los requisitos deberá: Modelo de negocio Crear modelos al detalle de requisitos de usuario Definir el alcance del proyecto Priorizar los requisitos.
Ayudan a identificar los requisitos que faltan, extraños e incoherentes. a) Los modelos de requisitos visuales. b) Los modelos de requisitos estructurales. .
Los modelos de requisitos visuales que se describen incluyen: Diagramas de flujo de datos
Diagramas de procesos
Mapas de dialogo
Tablas de decisión y árboles de decisión Tablas evento/respuesta
Árboles de características
Diagramas de casos de uso
Diagramas de actividad
Diagramas entidad-relación.
Relación del cliente con los componentes del modelo de análisis Verbo: Acciones, cosas que un usuario o un sistema puede hacer, o eventos que pueden tener lugar
Procesos
Sustantivo Personas, organizaciones, sistemas desoftware, elementos de datos, u objetos que existen
Entidades externas, almacenes de datos, o flujo de datos.
Condicional Declaración lógica condicional, como es Si/entonces.
Existen para almacenar y analizar datos, tales como: sistemas de minería de datos, generar consultas
e informes. a) Dominios estructurales b) Dominios dinámicos.
Manejan procesos de negocio y tareas tales como: operaciones de negocios y administración,
procesamiento de pedidos y gestión de inventario. a) Dominios transaccionales de negocio b) Dominios dinámicos .
Responden a los acontecimientos en constante cambio para almacenar datos y actuar en función
de su estado en un punto en el tiempo. Por ejemplo: los sistemas que gestionan el tráfico en la red, la
adjudicación, las operaciones de un dispositivo mecánico, y otras operaciones en tiempo real. a) Dominios dinámicos b) Dominios orientados al control.
Es muy adecuado los modelos “¿Cuándo?”. Por ejemplo: tablas de evento-respuesta y diagramas de estado. a) Dominios dinámicos b) Dominios orientados al control.
Evalúan las condiciones para tomar medidas o decisiones como la logística, la detección de fraudes,
la configuración del producto, y el diagnóstico. a) Dominios dinámicos b) Dominios orientados al control.
Modelos de requisitos basados en el enfoque del usuario ¿Quién? ¿Qué? ¿Cómo? ¿Por qué? ¿Cuándo? .
Se escoge el modelo de acuerdo a una pregunta de enfoque, que proporcione una potencial comprensión entre los requisitos y el desarrollo del modelo. a) ¿Quién? ¿Qué? ¿Cuándo? ¿Por qué? y ¿Cómo? b) ¿Cuándo? Y ¿Por qué?.
Es la herramienta básica del análisis estructurado y identifica los procesos de transformación de un sistema, las colecciones de datos o materiales físicos que manipula el sistema, y los datos o materiales entre procesos, almacenes y el mundo exterior. a) Diagrama de flujo de datos b) Diagrama de flujo .
Es la herramienta básica del análisis estructurado y identifica los procesos de transformación de un sistema, las colecciones de datos o materiales físicos que manipula el sistema, y los datos o materiales entre procesos, almacenes y el mundo exterior. a) Diagrama de flujo de datos b) Diagrama de flujo
.
El siguiente es un diagrama de: a) Diagrama de flujo de datos b) Diagrama de flujo .
Se usan más comúnmente para mostrar procesos de negocios, flujos de trabajo o interacciones entre el sistema y el usuario. Los mapas de estado Los mapas de proceso.
Ayudan a unir los requisitos funcionales que permiten a los usuarios realizar tareas específicas. También se pueden utilizar para realizar un análisis detallado para identificar los requisitos que soportan cada paso del proceso. Los mapas de estado Los mapas de proceso
.
El siguiente es un diagrama de: a) Los mapas de proceso b) Diagrama de flujo de datos.
El siguiente es un diagrama de: a) Diagrama de flujo de datos b) Diagrama de estado .
Son dos técnicas alternativas para representar lo que el sistema debe hacer cuando se aplican una lógica y decisiones complejas.
Las tablas de decisión y los árboles de decisión
Las tablas de evento y los árboles de evento.
Es una acción de un usuario humano que estimula un diálogo con el software, como cuando el usuario inicia un caso de uso. a) Evento de negocios b) Evento de señal.
Se registra cuando el sistema recibe una señal de control, lectura de datos interrupción desde un dispositivo de hardware externo u otro sistema de software, como cuando se cierra un interruptor.
a) Evento de negocios b) Evento de señal.
Se desencadena en el tiempo, como cuando el reloj de la computadora alcanza un tiempo especificado
o cuando una duración predeterminada ha pasado desde un evento anterior. Evento de señal Evento temporal.
Muestra cómo se entrelazan los diversos flujos en un caso de uso, o qué roles realizan ciertas acciones o para modelar el flujo de los procesos de negocio. Diagramas de actividad
Diagramas de casos de uso.
Muestra las relaciones entre actores externos al sistema y los casos de uso con los que interactúan. Diagramas de casos de uso
Diagrama de actividad.
Son afirmaciones verdaderas acerca del negocio, describen asociaciones o relaciones entre los términos del negocio.
Hechos Reglas de negocio .
Es una sentencia que restringe las acciones que el sistema o sus usuarios pueden realizar. Una restricción
Reglas de negocio .
Son aquellas posibilidades en las que desencadena una regla bajo determinadas condiciones. Acción facilitadora Restricciones .
Si la fecha de vencimiento del producto A en stock ha expirado, entonces notificar al personal encargado de bodega. Es un ejemplo de: Acción facilitadora Restricciones .
Consiste en la generación de nuevo conocimiento en base a unas reglas que cumplen con ciertas condiciones y permite crear un hecho nuevo a partir de otros hechos o cálculos. Acción facilitadora
Inferencias .
Se ejecutan usando fórmulas matemáticas o algoritmos. Inferencias
Cálculos
.
Cada elemento de línea en un pedido representa una combinación específica de químicos, grado,
tamaño del envase, y el número de contenedores. Hechos Reglas de negocio .
Si el pago no es recibido dentro de los 30 días calendario a partir de la fecha, entonces la cuenta
está en mora. Es un ejemplo de: Acción facilitadora Inferencias.
El siguiente es un diagrama de:
a) Mapa de dialogo
b) Diagrama de contexto .
Un solicitante de préstamo que es menor de 18 años de edad debe tener un padre o un
tutor legal como cosignatario en el préstamo. es un ejemplo de Acción facilitadora Restricciones .
Tipos de reglas de negocio: Hechos, Calculos, Inferencia. Restricciones, Acciones habilitadoras Todas las anteriores.
Tipos de requisito: Requisitos de negocio, Requisitos de usuario, Requisito funcional, Atributo de calidad. Atributo de calidad, Requisitos de usuario, Diagramas, Requisitos funcionales.
Ofrecer descuentos a los clientes leales es un ejemplo de: Politica de negocio Reglas de negocio.
Los clientes leales son aquellos que han realizado compras por mas de una vez al mes. Reglas de negocio Politica de negocio.
Incrementar las ventas en un 30%. Politica de negocio Objetivos de negocio.
El modelo que permite conocer quienes interactúan directamente con el sistema, es:
a. Tabla de actores
b. Glosario.
Cuando se requiere modelar el negocio, es necesario:
a. Establecer políticas de negocio
b. Combinar entre mapa de relaciones y/o mapa de procesos.
Cuando se desea adicionar detalle a los requerimientos de usuario, es conveniente desarrollar:
a. Casos de uso
b. Diagrama de contexto.
Un mapa de procesos permite mostrar:
a. El tipo de información y productos que se intercambian entre clientes externos
b. Una secuencia de pasos, entradas y salidas necesarias para manejar un proceso de negocio.
Son reglas que sirven para limitar las acciones que el sistema o los usuarios deben realizar. Se las
conoce como:
a. Restricciones
b. Hechos.
Cuando existe un caso de uso padre del cual uno o más casos de uso hijos heredan sus características
y especializan cierto comportamiento, se da una relación de:
a. Inclusión
b. Generalización.
La tabla de actores, permite
a. Identificar interesados
b. Identificar y clasificar a los usuarios del sistema en términos de sus funciones y
responsabilidades.
A los diagramas que muestran al sistema en su entorno, con las entidades externas que
proporcionan y reciben información o material desde y hacia el sistema, se los conoce como: b. Mapa de relación c. Diagramas de contexto.
Un ejemplo de política de negocio es: a. Incrementar la cantidad de estudiantes nuevos en un 15% en el próximo período b. Ofrecer descuentos a los estudiantes en su matrícula de acuerdo al período de tiempo en
que realice la matrícula.
Las reglas que se ejecutan usando fórmulas matemáticas o algorítmicas. Se las conoce como:
a. Hechos
b. Cálculos.
La comunicación clara y eficaz es el principio básico del:
Desarrollo de requisitos
Desarrollo de prototipos.
Los requisitos funcionales y no funcionales del producto a menudo se almacenan en la especificación de: Requisitos de software Requisitos de usuario.
Los requisitos se registran de: Forma organizada para que los interesados clave del proyecto puedan ayudar a revisar y asegurar están de acuerdo. Forma desorganizada para que los interesados clave del proyecto puedan ayudar a revisar y asegurar están de acuerdo.
Puede representar los requisitos de software de varias maneras, incluyendo: Lenguaje natural bien estructurado y cuidadosamente escrito.
Modelos visuales que ilustran procesos de transformación, estados del sistema y cambios entre
ellos, relaciones de datos, flujos lógicos, y similares.
Especificaciones formales que definen requisitos mediante el uso de lenguajes de especificación
matemáticamente precisos.
.
El documento que sirve como base para el diseño e implementación del sistema se lo conoce
como:
Carta de compromiso
Especificación de Requerimientos de Software
.
El responsable directo de la elaboración del documento “Especificación de Requerimientos de
Software” es el:
Analista
Usuario
.
Establece las funciones y capacidades que un sistema de software debe proporcionar, sus
características y las restricciones que debe respetar.
Especificación de Requisitos de Software
Numeración jerárquica
.
Ayuda a resolver el problema de las relaciones padre-hijo entre los requisitos.
Etiquetas de texto jerárquicas
Numeración jerárquica.
Las herramientas de gestión de requisitos comerciales asignan tal identificador cuando un usuario añade
un nuevo requisito a la base de datos de la herramienta. Número secuencial Numeración jerárquica
.
Si los requisitos funcionales aparecen en la sección 3.2 de su ERS, todos ellos tendrán etiquetas que comienzan con 3.2. Más dígitos que indican un requisito más detallado, de menor nivel, por lo que usted sabe que 3.2.4.3 es un requisito hijo de 3.2.4. Este método es simple, compacto y familiar.
Numeración jerárquica
Número secuencial
.
Están estructuradas, son significativas y no se ven afectadas añadiendo, eliminando o moviendo otros requisitos. Este método también es adecuado para etiquetar reglas de negocio si las mantiene manualmente, en lugar de hacerlo en un repositorio o herramienta de reglas de negocio dedicado.
Numeración jerárquica Etiquetas de texto jerárquicas.
Una de las fuentes para elaborar el documento de requisitos de usuario es:
Plantilla de requerimientos Visión del producto.
Al documento que actúa entre puente entre la definición del negocio y los requerimientos de
software, se lo conoce como: Requerimientos de usuario Visión del producto.
Uno de los lectores del documento de requerimientos de usuario es el: Patrocinador del proyecto
Programador
.
Un requisito esta completo si: Cada requisito debe contener toda la información necesaria para que el lector la entienda. Cada requisito describe con precisión una capacidad que satisfaga la necesidad de algún interesado y debe describir claramente la funcionalidad que se construirá.
Un requisito es correcto si:
Cada requisito describe con precisión una capacidad que satisfaga la necesidad de algún interesado y debe describir claramente la funcionalidad que se construirá. Cada requisito debe contener toda la información necesaria para que el lector la entienda.
Cada requisito debe describir una capacidad que proporcione al interesado el valor comercial por
anticipado, que diferencie el producto en el mercado o que se requiera para la conformidad con una
norma, política o norma externa. Estamos hablando de un requisito: Factible Necesario .
Priorizar los requisitos de negocio según cuáles son los más importantes para alcanzar el valor deseado. Estamos hablando de un requisito: Priorizado
No ambiguo
.
Los requisitos que son incompletos, inconsistentes, infalsificables o ambiguos: No pueden se requisitos verificables. Si pueden se requisitos verificables.
Si es posible implementar cada requisito dentro de las capacidades y limitaciones conocidas del sistema y su entorno operativo, así como dentro de las limitaciones de tiempo, presupuesto y personal del proyecto. Estamos hablando de un requisito: Factible
Necesario.
Son requisitos que no entran en conflicto con otros requisitos del mismo tipo o con requisitos de
negocio, de usuario o de sistema de nivel superior. Consistentes Completos .
Los dos objetivos importantes en la redacción de los requisitos son: Cualquiera que lea el requisito llega a la misma interpretación que cualquier otro lector. Cualquiera que lea el requisito llega a su propia conclusión indiferente de la de los demás. La interpretación de cada lector coincide con lo que el autor pretendía comunicar.
|
