4. El Por Que?
Descripción del Problema
• Descubrir los procesos de Negocio para realizar análisis del dominio
del problema
Analisís del Problema
• Entender mejor el problema mas que inicar el diseño de la solución
para describrir los requerimientos del sistema.
5. Formalización del Problema
Modelado del Problema
Expresar mediante diagramas de datos, de procesos, de estados, de
interacción, de objetos, etc.
El tipo de modelo elegido depende de:
• La naturaleza del problema
• La experiencia del modelador
• La disponibilidad de herramientas
• Por decreto. El cliente impone una notación
6. Ingeniería de Requerimientos
Como escribir Requisitos
• La “mejor forma” de escribir requisitos no existe
• Lo más utilizado es el lenguaje natural
• Cada requisito expresado en una frases cortas
(“el sistema hará X ...”, “se facilitará Y ...”, etc.)
• Lenguaje natural complementado con diagramas y/o notaciones
formales
• La notación utilizada depende de quien lee o quien escribe los
requisitos
8. Documento Estandar IEEE 830
Introducción
• Propósito
• Alcance
• Definiciones
• Referencias
• Visión General
http://es.scribd.com/doc/54229526/FORMATO-IEEE-830
Descripción General
• Perspectiva del producto
• Funciones del producto
• Características del usuario
• Restricciones
• Suposiciones
Requisitos específicos
Apéndices
9. En conclusión
Independiente del formato utilizado, un documento de requisitos contiene:
Información acerca del problema
Propiedades y comportamiento del sistema
Restricciones de diseño y fabricación del producto
11. El Qué frente al Cómo
Relación Requisitos-Arquitectura
• La elección de una determinada arquitectura software debe tener
en cuenta los requisitos funcionales pero, sobre todo, los requisitos
no funcionales (atributos de calidad del software)
• No hay una regla definitiva para establecer, dados los requisitos, el
tipo de arquitectura
• Tan sólo hay una serie de heurísticas para, dados unos requisitos,
elegir la arquitectura
13. Clasificación de Requisitos
Criterios de agrupación
• En funcionales vs. No funcionales (Capacidades vs. Restricciones)
• Por prioridades
• Por coste implementación
• Por niveles (alto nivel, bajo nivel)
• Según su volatilidad/estabilidad
• Si son requisitos sobre el proceso o sobre el producto