Requerimientos

Algoritmos y Computación Avanzada
Tutor: Eliezer Córdova
Ingeniería de Requerimientos
Estableciendo lo que el cliente
requiere de un Sistema de
Software.

Curva de Fallo del Software
• Todo el mundo exige que se realicen cambios sobre el Software
como respuesta a pequeños cambios del entorno.
• Además no es fácil comprender su comportamiento, según
Pressman:
– La curva de fallos del Hardware.
– La curva ideal de fallos del Software.
– La curva real de fallos del Software.

Tiempo
Indicedefallos
Defectos fabricación Estropeado
Obsolescencia
Curva de Fallo del Hardware

Indicedefallos
Defectos fabricación
Mismo nivel hasta obsoleto
Obsolescencia
Tiempo

Tiempo
Indicedefallos
Defectos fabricación
Curva ideal
Cambio Cambio Cambio
Curva
realObsolescencia

Etapas De Un Proyecto De Software
1. Planificación y/o Levantamiento de requerimientos
Productos que se obtienen de esta etapa:
• Requerimientos del sistema
• Especificaciones generales del sistema
• Costo y tiempos de ejecución del proyecto
• Recursos requeridos para el sistema
• Factibilidad del sistema
2. Análisis y diseño
Análisis y diseño
Productos generales que se obtienen de esta etapa:
• Modelos de casos de uso (reglas del negocio)
• Interfaces de entrada y salida del sistema
• Modelo relacional de la base de datos

Definición de Requisitos y Requerimientos
Los requisitos de un sistema son los aspectos que el sistema desarrollado
debe cumplir. Surgen de las necesidades del cliente, de las limitaciones
del entorno donde se va a implantar o de la propia gestión de la
información que debe realizar el sistema.

Características del Software

Tipos de Requerimientos
Los requisitos van a delimitar cómo quiere el cliente que se comporte el sistema,
que información tiene que manejar y cómo la debe procesar y presentar. Para
identificar todos estos aspectos se deben estudiar y analizar los requerimientos
funcionales y no funcionales:

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.

.
1.1 Requisitos de Actores
Son los que afectan a los diferentes actores del sistema, que van a
proporcionarle la información de entrada y van a recibir la información de
salida del sistema. Por ejemplo:
Usuarios Son los responsables de interactuar con el sistemaSon los responsables de interactuar con el sistema
Grupos
Permite realizar conjuntos de usuarios con
características comunes, para simplificar las reglas de
interacción entre los usuarios y el sistema
Permite realizar conjuntos de usuarios con
características comunes, para simplificar las reglas de
interacción entre los usuarios y el sistema
Perfiles
Permite agrupar todas las características que distinguen
a un usuario o grupo
Permite agrupar todas las características que distinguen
a un usuario o grupo
Papeles
(roles)
Permite asignar grupos de funcionalidades a los
usuarios y grupos, permitiendo diferenciar el
comportamiento de los usuarios con el sistema según la
actividad o proceso a realizar en el mismo
Permite asignar grupos de funcionalidades a los
usuarios y grupos, permitiendo diferenciar el
comportamiento de los usuarios con el sistema según la
actividad o proceso a realizar en el mismo
1. REQUERIMIENTOS FUNCIONALES

1.2 Requisitos de Interfaz
Refleja todos los requisitos que definen la forma de enviar la información a
procesar por los usuarios al sistema, y la forma de recibir la respuesta del
sistema por el usuario. Entre ellos podemos distinguir:
Medios de
interacción
Aplicación de escritorio, páginas Web,Aplicación de escritorio, páginas Web,
Pantallas formularios y demás elementos de la interfaz de usuarioformularios y demás elementos de la interfaz de usuario
Mensajes
intercambios y protocolos de comunicación,
fundamentales para describir las interacciones entre
sistemas
intercambios y protocolos de comunicación,
fundamentales para describir las interacciones entre
sistemas
CLAMB
Pantallas de gestión normalizadas: consultas, listados,
altas, modificaciones y bajas.
Pantallas de gestión normalizadas: consultas, listados,
altas, modificaciones y bajas.
Informes
documentos, archivos y datos en general generados por
el sistema.
documentos, archivos y datos en general generados por
el sistema.
1. REQUERIMIENTOS FUNCIONALES

2.1 Requisitos de Rendimiento
Se tiene en cuenta las métricas de rendimiento, pues suelen ser fácilmente medibles.
Entre ellos podemos sugerir los siguientes:
• Velocidad de las peticiones al sistema (número de peticiones que debe responder
en cierto tiempo)
• Tiempo medio de respuesta por tipo de petición, que sería el tiempo máximo (en
media) que debería tardar el sistema en contestar a una petición
• Velocidad en la comunicación con el sistema
• Velocidad en la gestión de la interfaz del usuario
2. REQUERIMIENTOS NO FUNCIONALES

2.3 Requisitos de Calidad
Aquí recogemos los requisitos que afectan a la gestión de la Calidad en el
desarrollo del proyecto. Entre ellos podemos destacar:
• Normativas y procedimientos de gestión del proyecto
• Normativas y procedimientos de desarrollo
• Normativas y procedimientos de documentación
• Normativas y Procedimientos de generación de entregables
• Normativas de calidad del Cliente
• Pruebas de Certificación de Calidad que deben superar los entregables.

2.4 Requisitos de Almacenamiento
Aquí se recogen todos los requisitos que especifican el cómo, dónde y
cuándo guardar los datos persistentes del sistema, así como la capacidad
del sistema de almacenamiento de los mismos, su seguridad, su fiabilidad,
su protección contra fallos o intento de acceso no autorizado y su política
de respaldo.

2.5 Requisitos de Seguridad
Aquí se recogen todos los requisitos relativos a la seguridad del sistema, como
pueden ser:
• Control de acceso al sistema y autenticación de usuarios.
• Políticas de usuarios y contraseñas, si las hubiere.
• Desactivación de usuarios.
• Control y auditoría de las acciones de los usuarios.
• Políticas de gestión de la seguridad y de los elementos y funcionalidades del
sistema.

2.5 Requisitos de Seguridad
• Métodos de agrupación de usuarios, y de permisos. Esquemas de administración y
almacenamiento de la seguridad.
• Gestión de los roles de los usuarios, si hubiese.
• Medidas de protección del sistema frente a ataques externos.
• Normativas y protocolos de seguridad que debe cumplir el sistema.
• Auditorías de seguridad y alarmas.

2.6 Requisitos de Escalabilidad
Aquí se recogen los requisitos de capacidad del sistema y cómo se debe
poder ampliar si es necesario. Si el sistema es utilizado por múltiples
usuarios simultáneos, debe disponer de un plan para redimensionar el
sistema al crecer el número de usuarios.

2.7 Requisitos Legales y Normativas
En este apartado se recogen los requisitos legales que debe cumplir el
sistema, es decir, toda la normativa legal que aplica al sistema, las
restricciones legales de su uso y las normativas de gestión de la
información confidencial. También se incluyen los requisitos de destrucción
de información confidencial al final del ciclo de vida de la misma.

Recogen todos los requisitos que debe cumplir el sistema,
independientemente de la funcionalidad que debe cubrir.
3.1 Requisitos de Arquitectura
Estos requisitos definen arquitectura y componentes del sistema, cuando es
un sistema creado a partir de varios, modúlalos.
3. REQUERIMIENTOS DEL SISTEMA

3.2 Requisitos de Software
Se recogen todos los requisitos de software que se aplicarán al sistema,
como pueden ser:
•Sistemas operativos de los diferentes módulos que forman el sistema,
incluyendo versiones y actualizaciones.
•Software adicional necesario en el sistema
•Requisitos de actualización del software de base del sistema

3.3 Requisitos de Hardware
Se recogen los requisitos de hardware de los componentes del sistema.
Entre ellos; tipos de servidores, configuración de los mismos, tipos de
unidades de disco y configuración, sistemas de backup, etc.

3.4 Requisitos de Comunicaciones
Aquí se recogen los requisitos para interconectar el sistema se definen los
parámetros de red requeridos, topología, tipos de enlace, anchos de banda,
etc.

3.5 Requisitos de Integración
Se recogen los requisitos de integración del sistema con otros sistemas
externos o del cliente. Se debe incluir los protocolos que se deben
soportar, los servicios que nos proporcionan o que debemos proporcionar,
las aplicaciones con las que debemos interactuar, etc.

3.6 Requisitos de Contingencia
Aquí enunciaremos los requisitos que debe cumplir nuestro sistema en caso
de contingencia, y que servirán de base para desarrollar el plan de
contingencia del sistema.

Riesgo, incertidumbre, perdida
Incertidumbre: Puede o no
ocurrir, no hay riesgos del 100%
de probabilidad.
Pérdida: Si el riesgo ocurre, hay
pérdidas.

Categorías
de riesgos
de software
1. Riesgos del proyecto:
2. Riesgos del producto:
3. Riesgos del negocio:
Amenazan al plan del proyecto; la
planificación temporal y los costos.
Ej: Pérdida de un diseñador
experimentado.
Amenazan la calidad y la
planificación temporal; la
implementación puede llegar a ser
difícil o imposible. Ej: Rendimiento
de un componente menor al
esperado.
Amenazan la viabilidad del
software a construir. Ej: Un
competidor introduzca un nuevo
producto.
Riesgo del Software

28
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

29
Marco del proceso de requerimientos
definicion
negociacion
especification
validaciondoc & admon

Características de los requerimientos
En principio los requerimientos deben ser
precisos, completos y consistentes.
Precisos
• Deben extraer con precisión 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 difícil producir un documento
con estas características.

Especificaciones 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 externo 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

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.

Razones de Inconsistencia
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.

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.
Estructura del Documento de Requerimientos

El Analista de Requerimientos
Analista de Requerimientos
Patrocinador del Proyecto Administrador del Proyecto
Desarrolladores
PruebasOtros 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
PruebasOtros 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.

Actividades:
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.

Actividades y responsabilidades:
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 Cliente

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).

El Usuario
Clasificación de los usuarios:
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.

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

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

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.

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.

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.
Resumen

Requerimientos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Requerimientos

Similar a Requerimientos (20)

Más de Eliezer Cordova

Más de Eliezer Cordova (20)

Último

Último (20)

Requerimientos