Introduccion a la ing requerimientos

Sommerville, Mejia-Alvarez Introduccion a los Requerimientos Diapositiva 1
Ingeniería de Requerimientos
Estableciendo lo que el cliente
requiere de un Sistema de
Software.

Objetivos
 Introducción a la Noción de Ingeniería de
Requerimientos.
 Explicación de los diferentes niveles de detalle de
requerimientos que se necesiten.
 Describir como deben ser organizados los
documentos de un Sistema de Requerimientos.
 Describir la validación del Proceso de
Requerimientos.
 Explicar porque los Requerimientos se involucran
durante el tiempo de vida de un sistema.

Tópicos
 El Proceso de Ingeniería de Requerimientos
 Los Documentos de Requerimientos de software
 Validación de Requerimientos
 Evolución de Requerimientos

Requerimientos
 Que funcionalidad se le pide a este sistema ?
Interfase Hombre-Maquina
Pantalla ° Teclado
Sistemas de Control y
Conteo de Billetes
Sistema de
Comunicaciones
Lector de
Tarjeta de Crédito
Sistema de
Control del
Cajero Automático
•Cliente
•Representante
del Banco
•Personal de
Mantenimiento
Base de Datos
Del Banco
Sistema de
Comunicaciones
del Banco
Análisis
de Riesgos

 El proceso de establecer los servicios que el cliente
requiere de un sistema y los limites bajo los cuales opera
y se desarrolla.
 Las malas o ineficientes prácticas de la Ingeniería de
Requerimientos llevan invariablemente al fracaso del
desarrollo del software, y pueden ser más costosas,
dependiendo de que tan tarde estas son descubiertas en el
proceso de desarrollo.
 Es necesaria una disciplina en el desarrollo de software y
en particular en el proceso de Ingeniería de
Requerimientos a fin de evitar que el desarrollo de
software falle o que sufra de costos excesivos.

 El éxito de un sistema de software se mide de acuerdo al grado con
que este y su proyecto de desarrollo cumplen con el objetivo para el
cual fueron requeridos.
 El problema del desarrollo de los sistemas de software es que los
requerimientos son inherentemente dinámicos.
• Los cambios ocurren constantemente y esto se de debe ase deben a:
Estos cambios por mejoras,
• cambios por errores descubiertos, cambios por adopción de nuevas
tecnologías,
• cambios por mejoras en la comprensión del sistema, entre otros.
 El proceso de Ingeniería de Requerimientos debe ser preciso y
flexible a la vez.
• Preciso por que debe incluir todos los requerimientos del cliente y del
ambiente donde este estará operando.
• Flexible, ya que los requerimientos están sujetos a constantes cambios.

¿Qué es un Requerimiento?
 Puede variar desde unos estatutos abstractos en
alto nivel de un servicio o unas restricciones del
sistema hasta una especificación funcional
matemática detallada.
 Los Requerimientos pueden servir como una
función dual
• Puede ser la base para la declaración de un contrato, por lo
tanto, deber estar abierto a interpretación.
• Puede ser la base para el contrato en sí, por lo tanto, debe ser
definido en detalle.
• Ambas declaraciones serán llamadas Requerimientos.

 Un requerimiento de software define las funciones,
capacidades o atributos de cualquier sistema de software.
 También representan:
• Factores de calidad del sistema que permitirán evaluar su
utilidad a un cliente o usuario.
• Los datos de entrada al proceso de desarrollo de software y
representan lo que se requiere implementar.
• Una descripción de cómo el sistema deberá comportarse,
describe información del dominio de la aplicación, describe
restricciones de la operación del sistema y especifica atributos ó
propiedades del sistema.
• Un problema por resolver.

 No se deben incluir aspectos de diseño, que especifiquen
como deben implementarse tales requerimientos, ni
detalles de planeación del proyecto o de las pruebas.
 Es importante separar lo que se requiere (que se detalla
con los requerimientos) de como se requiere que el
sistema sea diseñado (que se detalla en la etapa del
diseño).
 Todo software tiene requerimientos que lo definen y
quizás la parte más difícil de la construcción del software
es la decisión de que es lo que se debe construir

 Los Requerimientos pueden ser Funcionales o
No-Funcionales
• Los Requerimientos funcionales describen servicios o funciones
• Los Requerimientos No-funcionales son un límite en el sistema
o en el proceso de desarrollo.
 Requerimientos de Dominio
• Requerimientos que se obtienen de el dominio de la
aplicacion del sistema y que reflejan sus
caracteristicas.

11
Ingenieria de Requerimientos: Pasos
principales
1. Entender el problema: definicion
2. Describir el problema: especificacion
3. Verificar la naturaleza del problema: validacion
4. Ponerse de acuerdo en los limites del problema:
negociacion
Este es un proceso iterativo

12
Marco del proceso de requerimientos
definicion
negociacion
especification
validacion
doc & admon

Caracteristicas de los requerimientos
 En principio los requerimientos deben ser
precisos, completos y consistentes.
 Precisos
• Deben extraer con precision lo que se desea del sistema
 Completos
• Deben incluir todas las descripciones y componentes requeridos
 Consistente
• No debe haber conflictos o contradicciones en las descripciones
de los requerimientos
 En la practica es dificil producir un documento
con estas caracteristicas.

Sommerville , Mejia-Alvarez Introduccion a los Requerimientos Diapositiva 14
Requerimientos
Definición/Especificación
 Definición de Requerimientos
• Una declaración en un Lenguaje Natural incluye los diagramas
de los servicios del sistema y sus límites operacionales. Escrito
para clientes.
 Especificación de Requerimientos
• Un documento estructurado con descripción o detalle de los
servicios del sistema. Escrito como un contrato entre el cliente y
el contratista.
 Especificación de Software
• Descripción detallada de software, la cual, puede servir como
una base para diseño o implementación. Escrito para
desarrolladodres.

Definiciones y Especificaciones
Definición de Requerimientos
1. El Software proporciona significado de representación y acceso a
archivos externos creados por otras herramientas.
Especificación de Requerimientos
1.1 El usuario debe proporcionar facilidades para definir el tipo de archivos externos.
1.2 Cada tipo de archivo externo puede tener una herramienta asociada. La cual, será
aplicada para el archivo.
1.3 Cada tipo de archivo externo será representado como un icono específico mostrado al
usuario.
1.4 Las facilidades proporcionadas para la representación del icono en un tipo de archivo
externo será definido por el usuario.
1.5 Cuando un usuario selecciona una representación de icono de un archivo externo, el
efecto de la selección es aplicar las herramientas asociadas con el tipo de archivo ex-
terno al archivo representado por la selección del icono.

Lectores de Requerimientos
Gerencia de Cliente
Usuarios Finales del Sistema
Ingenieros de Clientes
Gerencia de Contratistas
Arquitectos del Sistema
Definición de
Requerimientos
Especificacion de
Requerimientos
Usuarios Finales del Sistema
Ingenieros de Cliente
Desarrolladores de Software
Especificación de
Software
Ingenieros de Clientes
Desarrolladores de Software

Problemas
 Los sistemas de software grandes siempre
presentan problemas.
 Problemas que son tan complejos que puede ser
que nunca se comprendan completamente y
donde los desarrolladores van comprendiendo el
sistema durante su desarrollo.
 Por lo tanto, los requerimientos son normalmente
incompletos e inconsistentes.

Razones de Inconsistencia
 Los sistemas de software grandes deben permitir una
mejora en la situación actual de la empresa. Es difícil
anticipar los efectos que el sistema tendrá en la
organización.
 Usuarios diferentes tienen requerimientos y prioridades
diferentes. Hay constantemente cambios en los
requerimientos.
 Los usuarios finales del sistema y la organización que
paga por el sistema tienen requerimientos diferentes.
 El prototipado es requerido para clarificar requerimientos

Proceso de Ingeniería de
Requerimientos
 Estudio de Factibilidad
• Encontrar si las necesidades de los usuarios son satisfechas dada
la tecnología y el presupuesto disponible?
 Análisis de Requerimientos
• Detallar que es lo que los usuarios requieren del sistema.
 Definición de Requerimientos
• Definir los requerimientos en una forma comprensible para el
cliente.
 Especificación de Requerimientos
• Define los requerimientos en detalle.

El Proceso de Ingeniería de
Requerimientos
Estudio de
Factibilidad
Análisis de
Requerimientos
Definición de
Requerimientos
Especificación
de Requerimientos
Reporte de
Factibilidad
Modelos del
Sistema
Documento de
Requerimientos
Definición de
Requerimientos
Especificación de
Requerimientos

Documento de Requerimientos
 Es la declaración oficial de lo que es requerido
para que el sistema sea desarrollado.
 Incluye la definición y especificación de
requerimientos.
 No es un documento de diseño. Tanto como sea
posible, es un conjunto de lo que es el sistema y
no de como lo hará.

Requerimientos del Documento
 Especificación del comportamiento externa del
sistema.
 Especificar las restricciones de la implementación.
 Fácil de cambiar.
 Sirve como una herramienta de referencia para el
mantenimiento.
 Registro del ciclo de vida del sistema, con el fin de
predecir cambios.
 Caracteriza respuestas a eventos inesperados.

Estructura del Documento de Requerimientos
 Introducción.
• Describe la necesidad de crear el sistema y cuales son sus
objetivos de negocio.
 Glosario.
• Define los términos técnicos usados.
 Modelos del Sistema.
• Define los modelos mediante los cuales se muestran los
componentes del sistema y las relaciones entre ellos.
 Definición de Requerimientos Funcionales.
• Define los servicios que serán proporcionados.

Estructura del Documento de Requerimientos
 Definición de Requerimientos No-funcionales.
• Definir las restricciones del sistema y el proceso de desarrollo.
 Evolución del Sistema.
• Definir las suposiciones fundamentales en las cuales el sistema se basa
y los cambios que preveen.
 Especificación de Requerimientos.
• Especificación detallada de los requerimientos funcionales del sistema.
 Apéndices.
• Descripción de la plataforma de Hardware del Sistema.
• Requerimientos de la base de Datos (quizá como un modelo Entidad
Relacion)
 Indice.

El Analista de Requerimientos
Analista de Requerimientos
Patrocinador del Proyecto Administrador del Proyecto
Desarrolladores
Pruebas
Otros interesados
en el sistema
Cliente y
Usuarios
requerimientos
del negocio
requerimientos
del cliente/usuario
restricciones y
requerimientos
requerimientos funcionales
y no-funcionales
y no-funcionales
Factibilidad,
Tiempos y costos
Analista de Requerimientos
Patrocinador del Proyecto Administrador del Proyecto
Desarrolladores
Pruebas
Otros interesados
en el sistema
Cliente y
Usuarios
requerimientos
del negocio
requerimientos
del cliente/usuario
restricciones y
requerimientos
y no-funcionales
y no-funcionales
Factibilidad,
Tiempos y costos

Actividades:
 Definir los objetivos del proyecto y los beneficios al negocio.
 Identificar el problema a resolver y obtener los requerimientos.
 Identificar a los involucrados en el desarrollo del proyecto así
como a las clases de clientes y usuarios.
 Identificar el ambiente del dominio a desarrollar y estar
preparado para desarrollar el sistema requerido.
 Administrar los requerimientos utilizando un proceso y un plan
de requerimientos.
 Modelar los requerimientos.
 Realizar control de cambios en los requerimientos.

Habilidades:
 Capacidad de comunicación.
 Capacidad de análisis y observación.
 Capacidad de organización.
 Analizar los riesgos del desarrollo del software.

El Cliente
Actividades y responsabilidades:
 Educar al analista de requerimientos acerca del negocio y sus
objetivos.
 Ser claro y preciso acerca del problema que se quiere resolver.
 Colaborar con el analista en la definición de los requerimientos.
 Revisar los documentos de requerimientos y el avance del proyecto.
 Comunicar a los analistas sobre cambios en los requerimientos.
 Plantear costos y tiempos esperados de desarrollo y estar abierto a
discutir cambios en los costos y tiempos de entrega.
 Estar siempre dispuesto a reunirse con los desarrolladores para
discutir distintos aspectos del proyecto.
 Respetar los procesos que implementarán los desarrolladores para
implementar el producto.

El Usuario
Clasificación de los usuarios:
 La frecuencia con la que usan el sistema.
 Las funciones que usan del sistema y su frecuencia.
 La experiencia en el dominio de la aplicación y su experiencia con
otros sistemas similares.
 El tipo de uso que le dan al sistema (operación, administración,
mantenimiento, supervisión).
 Las tareas que desempeñan en soporte de los procesos de la
organización.
 Sus privilegios de acceso o niveles de seguridad (tales como usuario
invitado, administrador o usuario de nivel interno).
 Tipo de usuarios necesarios para operar el sistema (persona, grupo de
personas, robot, u otra computadora).

Problemas asociados al proceso
 Problemas de alcance, en los cuales se describen
el ámbito y los límites de operación del software.
En esta categoría algunos de los problemas
podrían ser, que el ambiente del sistema no esta
bien delimitado, o que no exista información
suficiente del flujo de información de la
organización.

 Problemas de comprensión de lo que se quiere construir, con
los clientes, usuarios y con los grupos de desarrolladores. En
esta categoría podrían aparecer distintos problemas:
• Los clientes y usuarios no entienden completamente todo lo que
requieren o no cuentan con toda la información que de soporte a sus
necesidades.
• Los clientes y usuarios tienen poco conocimiento de las capacidades y
limitaciones de los sistemas de cómputo.
• Los analistas de requerimientos tienen poco conocimiento del
dominio de la aplicación.
• Los usuarios y los analistas hablan distintos lenguajes técnicos.
• Existen distintas perspectivas de cómo debe construirse el software,
entre el cliente y los desarrolladores.

 Problemas de volatilidad debidos a los
continuos cambios en los requerimientos. En esta
categoría se trata de resolver los problemas que
existen cuando los requerimientos deben cambiar
razones tecnológicas, por errores, o por mejoras.
 Problemas de conflictos entre requerimientos.

Validación de Requerimientos
 Demostración de que los requerimientos que
definen el sistema son lo que el cliente realmente
quiere.
 Los costos de errores en los requerimientos son
altos, por lo cual, la validación es muy
importante.
• Fijar un error de requerimiento después del desarrollo puede
resultar en un costo 100 veces mayor que fijar un error en la
implementación.
 El Prototipado es una técnica importante en la
validación de requerimientos.

Chequeo de Requerimientos
 Validez. Provee al sistema las funciones que
mejor soportan las necesidades del cliente?
 Consistencia. Existen conflictos en los
requerimientos?
 Completitud. Están incluidas todas las funciones
requeridas por el cliente?
 Realismo. Pueden los requerimientos ser
implementados con la tecnología y el presupuesto
disponible?

Revisión de Requerimientos
 Revisiones frecuentes deben llevarse a cabo
mientras la definición de requerimientos está
siendo hecha.
 Tanto el cliente como el staff de contratistas
deben estar involucrados en la revisión.
 La revisión pueden ser formales (con los
documentos completos) o informales. Una buena
comunicación entre desarrolladores, clientes y
usuarios puede resolver problemas en las
primeras etapas.

Chequeo de la Revisión
 Verificabilidad. Pueden hacerse pruebas de los
requerimientos ?
 Entendibilidad. Se comprenden los
requerimientos?
 Busqueda (trace). El origen de los
requerimientos esta claramente establecido?
 Adaptabilidad. Puede el requerimiento ser
cambiado sin causar un gran impacto en otros
requerimientos?

Chequeo de Consistencia
Automatizado
Requerimientos en un
Lenguaje Formal
Proceso de
Requerimientos
Base de Datos
de Requerimientos
Reporte de los problemas
de Requerimientos
Análisis de
Requerimientos

Cambios en el Documento de Requerimientos
 El documento de requerimientos debe ser
organizado, de tal forma que los cambios en los
requerimientos puedan ser hechos sin tener que
re-escribir demasiado.
 Las referencias externas deben ser minimizadas y
las secciones del documento deben ser tan
modulares como sea posible.
 Los cambios son mas fáciles cuando se trata de
un documento electrónico. Sin embargo, la falta
de estándares para documentos electrónicos lo
hace difícil.

Evolución de Requerimientos
 Los requerimientos siempre evolucionan cuando
existe una mejor comprension de las necesidades
del usuario y cuando los objetivos de la
organización cambian.
 Es escencial planear posibles cambios en los
requerimientos cuando el sistema sea
desarrollado y utilizado.

Evolución de Requerimientos
Comprensión Inicial
del Problema
Comprensión de los
Cambios del Problema
Requerimientos
Iniciales
Cambios en los
Requerimientos
Tiempo

Evolución Controlada
Documento VI de
Requerimientos
Implementación V1
del Sistema
Implementación V2
del Sistema
Documento V1
de Requerimientos
Documento V2
De Requerimientos
Implementación
V1 del Sistema
Implementación
V2 del Sistema
Cambio en los
Requerimientos
Cambio en los
Requerimientos
Inconsistencia de los
Requerimientos y del
Sistema
Consistencia de los
Requerimientos y del
Sistema

Clases de Requerimientos
Requerimientos de acuerdo a su audiencia:
 Los Requerimientos del Cliente.
 Los Requerimientos del Sistema.
 Especificación del Diseño del software.

Requerimientos de acuerdo a su característica:
 Requerimientos funcionales.
 Requerimientos no funcionales.

Requerimientos de acuerdo a su característica:
 Requerimientos de dominio. Los requerimientos de
dominio son requerimientos que provienen del dominio
de aplicación del sistema y reflejan las características de
este dominio.
 Requerimientos de Datos. Los requerimientos de datos
definen las estructuras de datos requeridas en el sistema.
 Requerimiento de Interfaz. Definen las características y
parámetros de la comunicación del sistema a desarrollar
con otros sistemas dentro de la empresa, o incluso de los
subsistemas.

Requerimientos no funcionales
Performance
requirements
Space
requirements
Usability
requirements
Efficiency
requirements
Reliability
requirements
Portability
requirements
Interoperability
requirements
Ethical
requirements
Legislative
requirements
Implementation
requirements
Standards
requirements
Delivery
requirements
Safety
requirements
Privacy
requirements
Product
requirements
Organizational
requirements
External
requirements
Non-functional
requirements

 Requerimientos Perdurables. Requerimientos estables
derivados de las actividades de la organización del
cliente. Por ejemplo, un hospital siempre tendrá doctores,
enfermeras, etc. Puede ser derivado de modelos de
dominio.
 Requerimientos Volátiles. Los requerimientos cambian
durante el desarrollo o cuando el sistema está en uso. En
un hospital, los requerimientos se derivan de las políticas
salud-cuidados.

Clasificación de Requerimientos
 Requerimientos Cambiantes.
• Los requerimientos que cambian por el ambiente del sistema.
 Requerimientos Emergentes.
• Requerimientos que surgen como una comprensión del
desarrollo del sistema.
 Requerimientos de Consecuencias.
• Requerimientos que resultan de la introducción del sistema
computacional.
 Requerimientos de Compatibilidad.
• Requerimientos que dependen de otros sistemas o de otros
procesos de la organización.

Medidas en los requerimientos no funcionales
Propiedad Medida
Velocidad Transacciones por segundo
Tiempo de respuesta a eventos
Tamaño Numero de líneas de código
Numero de Bytes de Memoria disponible
Facilidad de uso Tiempo de entrenamiento
Numero de ayudas
Confiabilidad Errores permitidos por unidad de tiempo
Media de tiempo por fallo
Disponibilidad en tiempo
Robustes Tiempo para restablecer despues de fallo.
Porcentaje de fallos que causan caida del
sistema.
Portabilidad Facilidad de transportar a otro S.O o
lenguaje.

Ratreo de Requerimientos
 EL rastreo de los requerimientos trata con las relaciones
entre los requerimientos, sus fuentes y el diseño del
sistema.
 Rastreo de la fuente
• Liga los requerimientos con los clientes o desarrolladores que
propusieron este requerimiento.
 Rastreo de requerimientos.
• Liga los requerimientos dependientes entre si.
 Rastreo del diseño.
• Liga los requerimientos al diseño.

La matriz de rastreo
Req.
id
1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2
1.1 U R
1.2 U R U
1.3 R R
2.1 R U U
2.2 U
2.3 R U
3.1 R
3.2 R

Herramientas de Soporte Case
 Almacenamiento de Requirimientos
• Los requerimientos deben de organizarse y guardarse en un
lugar seguro y en donde estos puedan organizarse.
 Manejo de Cambios
• El proceso de cambios en un proceso de flujo de datos cuyas
etapas pueden definirse asi como el flujo de informacion entre
estas etapas.
 Manejo del Rastreo
• Obtencion automatizada de las ligas que generan los
requerimientos.
 Pre-Requisite Pro. Herramienta de Soporte CASE

Factores sociales y organizacionales
 Los sistemas de software se usan dentro de un
contexto social y organizacional. Estos pueden
influir o dominar los requerimientos del sistema.
 Los factores sociales y organizacionales tienen
influencia en todos los puntos de vista.
 Los analistas deben ser sencibles a estos factores
aunque no exista una forma sistematica de
enfrentarlos.

Ejemplo
 Considere un sistema que permite a los administradores
accesar informacion sin consultar con los operadores del
sistema.
• Estatus de la Administracion. Los adminstradores consideran
que ellos son demasiado importantes como para tener que usar
un teclado de computadora. Esto podria limitar el tipo de
interfaz hombre-maquina a diseñar.
• Responsabilidades de la administracion. Los administradores
podrian no tener tiempo para aprender a usar el sistema.
• Resistencia organizacional. Los administradores podrian no dar
informacion completa o incluso dar informacion erronea para
que el sistema falle.

Etnografia
 Un cientifico gasta una cantidad de tiempo considerable
observando y analizando como trabaja la gente.
 La gente no tiene que explicar o articular su trabajo.
 Se observan los factores de mas importancia sociales y
organizacionales.
 Es importante observar como trabaja la gente para
producir mejores diseños.

Requerimientos
 Ya sabemos que funcionalidad se le pide a este
sistema ?
Interfase Hombre-Maquina
Pantalla ° Teclado
Sistemas de Control y
Conteo de Billetes
Sistema de
Comunicaciones
Lector de
Tarjeta de Crédito
Sistema de
Control del
Cajero Automático
•Cliente
•Representante
del Banco
•Personal de
Mantenimiento
Base de Datos
Del Banco
Sistema de
Comunicaciones
del Banco
Análisis
de Riesgos

Resumen
 Es muy difícil formular una especificación de
requerimientos completa y consistente.
 Una definición de requerimientos, una
especificación de requerimientos y una
especificación de Software son una manera de
especificar el Software para diferentes tipos de
lectores.
 El Documento de Requerimientos es una
descripción para clientes y desarrolladores.

Resumen
 Los errores en los requerimientos son usualmente
muy caros de corregir una vez desarrollado el
sistema.
 La revisión debe involucrar al cliente y al staff de
contratistas para validar los requerimientos del
sistema.
 El establecer requerimientos está relacionado con
las actividades del cliente para el Software.
 Los requerimientos volátiles dependen del
contexto en que se use el sistema.

Introduccion a la ing requerimientos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Introduccion a la ing requerimientos

Similar a Introduccion a la ing requerimientos (20)

Último

Último (20)

Introduccion a la ing requerimientos