Analisis y especificacion de requerimientos

CAPITULO III
Análisis y Especificación de
Requisitos
Ingeniería de Software II
Prof. Sara Blach

¿QUÉ DEFINEN LOS REQUERIMIENTOS?
Lo que el sistema debe hacer:
 Las funciones que debe ejecutar.
 Los datos que debe capturar y almacenar.
 La información que debe producir

¿QUE DEFINEN LOS REQUERIMIENTOS?
Las interacciones usuarios-sistema y sistema-
sistema:
 La interfaz grafica usuario-sistema.
 La interfaz de la aplicación con otros sistemas.

Las restricciones bajo las cuales el sistema debe
operar:
 La plataforma de operación del sistema.
 La tecnología de información que debe utilizar el
sistema.

Los atributos de calidad que el sistema debe
satisfacer:
 Estándar ISO 9126
 Software Quality Model

¿POR QUÉ DETERMINAR REQUERIMIENTOS?
 El software esta integrado por muchos
componentes.
 El costo de cambiar requerimientos crece a medida
que avanza el proyecto. (Durante la fase de
diseño, durante la fase del diseño
detallado, durante la codificación, durante la prueba
de unidades, durante la validación, después que el
sistema ha sido implantado).

PROBLEMAS AL DETERMINAR
REQUERIMIENTOS
 El usuario o cliente no siempre sabe lo que quiere del
sistema:
 Al inicio del proyecto, no sabe que esperar del sistema.
 Los requerimientos suelen surgir a medida que el usuario se
familiariza con el sistema.

REQUERIMIENTOS
 El usuario no tiene tiempo para participar en el
proyecto:
 Evita participar en el proyecto.
 No esta consiente de la importancia de su participación.
 No ve el sistema como algo que le pertenece.

REQUERIMIENTOS
 Problemas de comunicación:
 El cliente o usuario no entiende el lenguaje informático
de los analistas.
 Los analistas no entienden el lenguaje del dominio de la
aplicación.

REQUERIMIENTOS
 Los requerimientos pueden interpretarse de
diferentes maneras:
 El analista entiende y especifica de manera diferente
los requerimientos del cliente.
 El diseñador interpreta de otra manera los requisitos
especificados por el analista.

REQUERIMIENTOS
 Requerimientos mal definidos:
 No reflejan las necesidades reales de los usuarios del
sistema.
 Son inconsistentes.
 Son incompletos.
 No son factibles.

SOLUCIÓN A LOS PROBLEMAS DE LOS
REQUERIMIENTOS
 Entender la naturaleza del software:
 Promueve cambios frecuentes en los requerimientos
.
 Entender el espacio del problema:
 Modelar el negocio antes de identificar y especificar
requerimientos.
 Utilizar un proceso de desarrollo bien definido y
probado.

 Utilizar practicas conocidas (mejores practicas):
 Incorporar al cliente en el desarrollo del sistema
(activamente).
 Modelar los requerimientos usando notaciones graficas
estandarizadas.
 Gestionar los requisitos.

 Emplear personal especializado:
 Analistas de negocios.
 Analistas de requerimientos.

ESPACIO PROBLEMA
ESPACIO SOLUCION

 Los métodos tradicionales de desarrollo de
software subestiman la importancia del problema y
su análisis:
 Se centran en la solución y sus requisitos.
 No alinean la solución al negocio.

 La separación de estos dos espacios es crucial en
toda ingeniería.
 Las necesidades ocurren en el espacio del
problema.
 Los requerimientos tienen lugar en el espacio de la
solución.

Es relevante definir claramente el dominio.
Dominio= Espacio del problema.

ESPACIO DEL PROBLEMA
MODELADO DEL NEGOCIO
NECESIDADES Y REQUERIMIENTOS

 Los requerimientos funcionales de un sistema
expresan necesidades de información:
 ¿Qué información requieren los usuarios para ejecutar
sus procesos de negocio?
 Que actividades de un proceso de negocio requieren
ser automatizados?
 Los requerimientos de una aplicación dependen de
los procesos de negocio que la aplicación soporta
(como y por que lo hace)
 Si los procesos de negocio no se conocen, la
identificación de necesidades y la especificación de
requerimientos no tienen fundamentación.

 Una buena practica de la IR es modelar los
procesos de negocio antes de definir sus
requisitos.
 Se puede hacer mediante la elaboración de un pequeño
modelo.
 El modelado del negocio (MN), es un proceso a
través del cual se representa el dominio de una
aplicación.
 El MN identifica y representa aspectos del
sistema, tales como:
 Objetivos de la organización.
 Procesos del negocio y sus actividades.
 Reglas del negocio.
 Objetos del negocio.
 Actores y sus organización.

 El producto del MN son los modelos de negocio.
 El modelo del negocio de una empresa es una
representación simplificada de la lógica de negocio
que describe lo que un negocio ofrece a sus
clientes, como llega a ellos, y como se relaciona
con ellos.
 El modelo de negocio es un documento compuesto
por un conjunto de submodelos.
 Cada submodelo describe uno o mas elementos
organizacionales.

 En ingeniería de requerimientos, el modelo del
negocio es usado para:
 Entender el proceso del negocio actual y establecer sus
problemas de información.
 Descubrir las necesidades que los usuarios tienen.
 Facilitar la definición y especificación de requerimientos
funcionales.
 Caracterizar el nuevo proceso de negocio.

ESPACIO DE LA SOLUCION:
INGENIERIA DE
REQUERIMIENTOS

INGENIERÍA DE REQUERIMIENTOS
Definición:
Es una sub-disciplina de la Ingeniería de
Software, encargada de los requerimientos para
automatizar sistemas.
Estudia:
• Los problemas de los requerimientos.
• Las soluciones que pueden contribuir a resolver estos
problemas.

Se encarga de establecer:
Principios, modelos, métodos, mejores
practicas, técnicas y herramientas que contribuyan
a mejorar la definición y especificación de los
requerimientos.
Conduce a:
• Encontrar y definir las necesidades que tienen los
interesados de la aplicación.
• Transformar la definición de necesidades en una
descripción completa y precisa de
requerimientos, denominada Especificación de
Requerimientos de Software (ERS).

ELEMENTOS DE LA IR
El Producto
El Proceso
El Equipo
¿Qué se hace?
¿Cómo hacerlo?
¿Quiénes lo hacen?
Documento de
Especificación de
Requerimientos (DER)
Llenado del Documento
de Especificación de
Requerimientos (DER)
Conjunto de interesados
o actores debidamente
organizados

REFLEXION
“La brecha entre la teoría y la práctica no es tan
larga en teoría como lo es en la práctica”.
Anónimo

Analisis y especificacion de requerimientos

Más contenido relacionado

La actualidad más candente (20)

Similar a Analisis y especificacion de requerimientos (20)

Último (20)

Analisis y especificacion de requerimientos