ANÁLISIS DE REQUERIMIENTOS

DEFINICIÓN:

Requerimientos: Los requerimientos especifican qué es lo que el sistema debe hacer (sus funciones) y sus propiedades esenciales y deseables. La captura de los requerimientos tiene como objetivo principal la comprensión de lo que los clientes y los usuarios esperan que haga el sistema. Un requerimiento expresa el propósito del sistema sin considerar como se va a implantar. En otras palabras, los requerimientos identifican el qué del sistema, mientras que el diseño establece el cómo del sistema.

La captura y el análisis de los requerimientos del sistema es una de las fases más importantes para que el proyecto tenga éxito. Como regla de modo empírico, el costo de reparar un error se incrementa en un factor de diez de una fase de desarrollo a la siguiente, por lo tanto la preparación de una especificación adecuada de requerimientos reduce los costos y el riesgo general asociado con el desarrollo [Norris & Rigby, 1994].

Análisis de requerimientos: Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software. Es una tarea de ingeniería del software que permite especificar las características operacionales del software, indicar la interfaz del software con otros elementos del sistema y establecer las restricciones que debe cumplir el software.

MOLDEAMIENTO DEL NEGOCIO:

Modelo del Caso de Uso del Negocio:El modelo del negocio describe el negocio en términos de casos de usos del negocio, que corresponde a lo que generalmente se le llama procesos. Un proceso del negocio es el conjunto estructurado de las actividades que han sido diseñadas para producir un resultado específico para un cliente o el mercado. Debe haber un enfoque a la lógica del negocio de dicho proceso, desde la perspectiva del producto. El modelo de Casos de Uso del Negocio es un modelo que describe los procesos de un negocio (casos de uso del negocio) y su interacción con elementos externos (actores), tales como socios y clientes, es decir, describe las funciones que el negocio pretende realizar y su objetivo básico es describir cómo el negocio es utilizado por sus clientes y socios. 

Modelo de Objetos del Negocio:Un modelo de datos es una vista de datos analíticos que tiene una correspondencia de uno a uno con un modelo de objetos de negocio (MON) en IBM® Operational Decision Manager. Un MON especifica los elementos de negocio y el vocabulario utilizado para definir las reglas de negocio. El vocabulario permite a los usuarios crear reglas de negocios sin tener conocimientos de cómo se estructuran los datos a los que se refieren las reglas.

Una regla de negocio tiene el formato "si criterios entonces resultado". Por ejemplo, una decisión sobre si rechazar o no una aplicación de préstamo basándose en la capacidad de endeudamiento del aspirante corresponde a la siguiente regla de negocio:

Si la capacidad de endeudamiento del aspirante es menor

a 300 entonces rechace la aplicación.

El aspirante es la entidad de negocios en la que se basa esta regla. La capacidad de endeudamiento del aspirante es la entidad del atributo en el que se realza la decisión. El modelo de objetos de negocio debe incluir un elemento que represente al aspirante y, dicho elemento, debe incluir un atributo que corresponda a la capacidad de endeudamiento. El modelo también especifica el vocabulario utilizado para hacer referencia a los elementos del modelo en las reglas. En este caso el vocabulario incluye "capacidad de endeudamiento del aspirante".

Estructuralmente, el modelo de objetos de negocio es similar al modelo de objeto Java. Las entidades de negocios corresponden a una clase y pueden agruparse en paquetes. Las clases pueden anidarse en otras clases. Los atributos de la entidad corresponden a atributos de clase que tienen un tipo que indica el tipo de valores de datos permitidos para el atributo. Para la regla de ejemplo, el MON incluye una clase de aspirantes que tiene un atributo de capacidad de endeudamiento del tipo entero.

Los elementos del modelo de datos para una vista de datos analíticos corresponden a los elementos en el modelo de objetos de negocio. Una tabla de modelo de datos corresponde a una clase MON. Un campo en la tabla de modelo de datos corresponde a un atributo para la clase.

Figura 1. Relaciones entre un modelo de datos y el modelo de objetos de negocio

Figura 1ilustra las relaciones entre los elementos de modelos de datos y los elementos del modelo de objetos de negocio para un modelo de datos que incluye una tabla llamada Aspirante. Esa tabla corresponde a la clase MON que tiene el mismo nombre. La verbalización de la clase incluye el término aspirante para la clase. Los campos de la tabla de modelo de datos de ID, nombre y capacidad de endeudamiento corresponden a los atributos de la clase MON. Cada atributo de la clase proporciona una frase de verbalización con el formato {atributo} de {esto}. La variable {esto} se refiere al aspirante término padre en la verbalización.

Puede utilizar la correspondencia del modelo de datos y el MON para combinar los resultados desde distintos métodos analíticos. La salida de modelos predictivos que están basados en la visualización de datos analíticos pueden combinarse con reglas de negocio que se basan en un MON si los campos de modelo de datos coinciden con elementos MON. La interfaz de datos común permite que se integren indicadores desde modelos predictivos con los criterios de reglas de negocio.

Modelo de Dominio:

Un modelo de dominio en la resolución de problemas e ingeniería de software, es un modelo conceptual de todos los temas relacionados con un problema específico. En él se describen las distintas entidades, sus atributos, papeles y relaciones, además de las restricciones que rigen el dominio del problema.

El modelo de dominio se crea con el fin de representar el vocabulario y los conceptos clave del dominio del problema. El modelo de dominio también identifica las relaciones entre todas las entidades comprendidas en el ámbito del dominio del problema, y comúnmente identifica sus atributos. Un modelo de dominio que encapsula los métodos dentro de las entidades se asocia más bien con modelos orientados a objetos. El modelo de dominio proporciona una visión estructural del dominio que puede ser complementado con otros puntos de vista dinámicos, como el modelo de casos de uso.

EJEMPLO:

La empresa interactúa con distintos elementos externos, entre los que se identifican el cliente externo (persona o entidad que solicita la compra de productos a la empresa), el proveedor (persona o entidad que reabastece de productos a la empresa) y por último la empresa de transportes, que es una subcontrata encargada de servir los pedidos desde los distintos almacenes regionales a los clientes de la empresa.

Modelo de Casos de Uso del Negocio

Modelo de Objetos de Vender Productos

Modelo de Objetos de Seguimiento y Consulta de Productos

Modelo de Objetos de Reponer Stock

Modelo de Objetos de Modificar Catálogo

Modelo de Objetos de Realizar Entrega

Modelo del Dominio

RESUMEN:

La captura de los requerimientos tiene como objetivo principal la comprensión de lo que los clientes y los usuarios esperan que haga el sistema. Un requerimiento expresa el propósito del sistema sin considerar como se va a implantar. En otras palabras, los requerimientos identifican el qué del sistema, mientras que el diseño establece el cómo del sistema.
El modelo del negocio describe el negocio en términos de casos de usos del negocio, que corresponde a lo que generalmente se le llama procesos. Un proceso del negocio es el conjunto estructurado de las actividades que han sido diseñadas para producir un resultado específico para un cliente o el mercado.

SUMMARY:

Capturing requirements main objective understanding of what customers and users expect the system to do . A requirement expresses the purpose of the system regardless of how you will implement . In other words, identify the requirements which the system, while designing the system sets the how .
The business model describes the business in terms of business use cases , which corresponds to what is generally called processes. A business process is structured activities that are designed to produce a specific result for a client or the market as a whole.

RECOMENDACIONES:
Diseñar modelos de negocios transparente (fáciles de comprender). 
CONCLUSIONES:
Las CASE han sido creadas para la automatización de procesos de análisis, diseño e implementación,
brindándonos un sin número de componentes que hacen que los proyectos sean cada día más eficientes para los
usuarios finales.
APRECIACIÓN DEL EQUIPO:
La aplicación de las herramientas CASE corresponde el mejor método para el análisis y solución de situaciones empresariales complejas, ya que han venido a mejorar los aspectos claves en el desarrollo de los sistemas de negocios.

GLOSARIOS DE TÉRMINOS:
Requerimiento: petición de una cosa que se considera necesaria.
Esencial: que es lo mas importante y necesario.

LINKOGRAFIA:

http://www.cua.uam.mx/pdfs/conoce/libroselec/Notas_Analisis_Requerimiento.pdf

http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Model_Negocio.html
http://modeladodelsistema3.blogspot.pe/2012/03/republica-bolivariana-de-venezuela.html
https://es.wikipedia.org/wiki/Modelo_de_dominio

Presentación de diapositivas: SlideSha

Juan Julca Landacay.