Análisis de

Requerimientos

SI903 Implementación de Sistemas

Análisis de Requerimientos

Da como resultado la especificación de las características operativas del

software, indica la interfaz de éste y otros elementos del sistema y establece
las restricciones que limitan al software.

El análisis de los requerimientos permite construir sobre los requerimientos

básicos establecidos durante las tareas de concepción, indagación y
negociación, que son parte de la ingeniería de los requerimientos
Análisis de
Requerimientos

• La atención se centra en qué,

no en cómo.
Ejemplos de preguntas

• ¿Qué interacción del usuario ocurre en una circunstancia particular?

• ¿Qué objetos manipula el sistema?
• ¿Qué funciones debe realizar el sistema?
• ¿Qué comportamientos tiene el sistema?¿Qué interfaces se definen?
• ¿Qué restricciones son aplicables?
Análisis de Requerimientos debe lograr:

• Describir lo que requiere el cliente

• Establecer una base para la creación de un diseño de software
• Definir un conjunto de requerimientos que puedan validarse una vez
construido el software.
 • Es un puente entre la descripción en
el nivel del sistema que se centra en
Análisis de éste en lo general o en la
funcionalidad del negocio que se logra
Requerimientos con la aplicación de software,
hardware, datos, personas y otros
elementos del sistema.
• Es importante observar que todos los
elementos del análisis de requerimientos
pueden rastrearse directamente hasta las
partes del del diseño.
• No siempre es posible la división clara entre
las tareas del análisis y las del diseño.
Análisis de
• Invariablemente, ocurre algo de diseño Requerimientos
como parte del análisis y algo de análisis se
lleva a cabo durante el diseño, y debe ser la
menor intersección posible y muy
controlada.
 Debe centrarse en los requerimientos que
sean visibles dentro del problema o dentro del
dominio del negocio. El nivel de abstracción
Reglas debe ser relativamente elevado.
prácticas para
el análisis Cada elemento del análisis de requerimientos
1/3 debe agregarse al entendimiento general de
los requerimientos del software y dar una
visión del dominio de la información, de la
función y del comportamiento del sistema
 Hay que retrasar las consideraciones de la
infraestructura y otros modelos no funcionales
Reglas hasta llegar a la etapa del diseño.

prácticas para
el análisis Debe minimizarse el acoplamiento a través del
sistema. Es importante representar las relaciones
2/3
entre las clases y funciones. Sin embargo, si el
nivel de “interconectividad” es extremadamente
alto, deben hacerse esfuerzos para reducirlo.
 Es seguro que el modelo de
requerimientos agrega valor para todos
los participantes. Cada actor tiene su
Reglas propio uso para el modelo.
prácticas para
el análisis Mantener el modelo tan sencillo como se
3/3 pueda. No genere diagramas adicionales
si no agregan nueva información. No
utilice notación compleja si basta una
sencilla lista.
Análisis de Dominio
Análisis de Requerimientos – SI903 Implementación de Sistemas
 Contexto:
• Si los requerimientos comunes
Análisis de pudieran reconocerse y aplicarse para
Dominio resolver
entonces
problemas
en
comunes,
Análisis de
Requerimientos sería más rápido.
Análisis de Dominio – ¿Qué es?

• Es la identificación, análisis y especificación de los

requerimientos comunes, a partir de un dominio de
aplicación específica, normalmente para usarlo
varias veces en múltiples proyectos dentro del
dominio de la aplicación.
Análisis de Dominio - Objetivo

• Encontrar o crear aquellos patrones de análisis que sean aplicables en

lo general, de modo que puedan volverse a usar varias veces.
La actividad: Análisis de Dominio

• Puede considerarse como una actividad sombrilla para el proceso de

hacer software.
• Significa que el análisis del dominio es una actividad de la ingeniería de
software que no está conectada con ningún proyecto de software.
Analista de Dominio

• Debe descubrir y definir patrones de análisis, clases de análisis e

información relacionada que pueda ser utilizada por mucha gente que
trabaje en aplicaciones similares, pero que no son necesariamente las
mismas.
Análisis de Dominio

• Las fuentes de conocimiento del dominio se mapean con el fin de

identificar los objetos que pueden reutilizarse a través del dominio.
Requerimientos no funcionales
Implementación de Sistemas SI903U
Requerimientos no funcionales

No se relacionan directamente con los servicios específicos que el sistema entrega a

sus usuarios.

Pueden relacionarse con propiedades emergentes del sistema, como fiabilidad,

tiempo de respuesta y uso de almacenamiento.

Pueden definir restricciones sobre la implementación del sistema.

 Como el rendimiento, la seguridad o la
Requerimientos disponibilidad, especifican o restringen por lo
no funcionales general características del sistema como un todo.

A menudo son más significativos que los

requerimientos funcionales individuales.

El fracaso para cubrir los requerimientos no

funcionales haría que todo el sistema fuera inútil.
Requerimientos no funcionales

Por lo general es más difícil relacionar

componentes con requerimientos no funcionales.
Tipos de Requerimientos no funcionales
Requerimientos de producto

• Especifican o restringen el comportamiento del software.

Requerimientos de la Organización

• Son requerimientos de sistemas amplios, derivados de políticas y

procedimientos en la organización del cliente y del desarrollador.
Requerimientos Externos

• Cubre todos los requerimientos derivados de factores externos al

sistema y su proceso de desarrollo.
Obtener requerimientos
Implementación de Sistemas SI903
Obtener requerimientos

• Es una actividad que se trabaja con clientes y usuarios finales.

Obtener
requerimientos
1. Descubrimiento de requerimientos

• Es el proceso de interactuar con los participantes del sistema para

descubrir sus requerimientos. También los requerimientos de dominio
de los participantes y la documentación se descubren durante esta
actividad.
2. Clasificación y organización de los
requerimientos
• Toma la compilación no estructurada de requerimientos, agrupa
requerimientos relacionados y los organiza en grupos coherentes.
• La forma más común de agrupar requerimientos es usar un modelo de
la arquitectura del sistema,
3. Priorización y Negociación de
Requerimientos
• Inevitablemente, cuando intervienen diversos participantes, los
requerimientos entrarán en conflicto.
• Esta actividad se preocupa por priorizar los requerimientos, así como
por encontrar y resolver conflictos de requerimientos mediante la
negociación.
4. Especificación de Requerimientos

• Los requerimientos se documentan y se registran, produciéndose

documentos de requerimientos.
Arquitectura y Diseño de un
Sistemas
Implementación de Sistemas SI903
Arquitectura de Sistemas

• Es el enlace crucial entre el diseño y la ingeniería de requerimientos, ya

que identifica los principales componentes estructurales en un sistema
y la relación entre ellos.
• Se describe la forma en que se organiza el sistema como un conjunto
de componentes en comunicación.
Arquitectura de Sistemas en dos niveles

1. La arquitectura en pequeño se interesa por la arquitectura de

programas individuales. En este nivel, uno se preocupa por la forma en
que el programa individual se separa en componentes.
Arquitectura de Sistemas en dos niveles

2. La arquitectura en grande se interesa por la arquitectura de sistemas

empresariales complejos que incluyen otros sistemas, programas y
componentes de programa. ales sistemas empresariales se distribuyen a
través de diferentes computadoras, que diferentes compañías
administran y poseen.