Embed Size (px)
DESCRIPTION
Analisis y especificacion de requerimientos de software
Citation preview
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.
¿QUE DEFINEN LOS REQUERIMIENTOS?
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.
¿QUE DEFINEN LOS REQUERIMIENTOS?
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.
PROBLEMAS AL DETERMINAR 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.
PROBLEMAS AL DETERMINAR 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.
PROBLEMAS AL DETERMINAR 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.
PROBLEMAS AL DETERMINAR 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 PROBLEMAESPACIO 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 PROBLEMAMODELADO DEL NEGOCIONECESIDADES 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
