requerimientos del software

Objetivos

Introducir los conceptos de usuario y requerimientos del sistema

Describir requerimientos funcionales y no funcionales

Explicar como los requerimientos del software se organizan en un documento de re

querimientos
Contenidos

Requerimientos funcionales y no funcionales

Requerimientos del usuario

Requerimientos del sistema

Especificación de la interfaz

Documento de requerimientos del sistema

Ingeniería de requerimientos

El proceso de establecer los servicios que el cliente requiere de un sistema las

restricciones bajo las cual funciona y se desarrolla
Los requerimientos por sí mismos son las descripciones de los servicios y restricc
iones del sistema que se generan durante el proceso de ingeniería de requerimiento
s
¿Qué es un requerimiento?

Puede variar desde una declaración abstracta de alto nivel de un servicio o de la

restricción de un sistema, hasta una especificación funcional matemática detallada.

Esto es inevitable ya que los requerimientos tienen doble función

Puede ser la base de un intento de contrato

Puede ser la base para el contrato en sí entonces debe ser definido con detalle
Ambas declaraciones deben ser llamadas requerimientos
Abstracción de los requerimientos
(Davis)

Si una compañía desea establecer un contrato para el desarrollo de un proyecto de so

ftware, debe definir sus necesidades de una forma suficientemente abstracta como
para establecer a partir de ella una solución. Los requerimientos deben redactars
e de tal forma que varios contratistas puedan licitar el contrato, ofreciendo, q
uizás, formas diferentes de cumplir las necesidades de los clientes en la organiza
ción. Una vez que el contrato se asigna, el contratista debe redactar una definición
de sistema para el cliente de forma que éste comprenda y pueda validar lo que hará
el software. Ambos documentos se denominan el el documento de requerimientos para
el sistema
Tipos de requerimiento

Requerimientos del usuario

Declaraciones en un lenguaje natural más diagramas de los servicios que el sistema

proporciona y sus restricciones operacionales.

Requerimientos del sistema

Un documento estructurado que establece descripciones detalladas de las funcione

s servicios y restricciones operacionales del sistema. Define lo que debería poner
se en práctica así que debe ser
parte de un contrato entre el cliente y el contratista.
Definiciones y especificaciones
Definición de requerimientos del usuario
1. El software debe proveer un medio para representar y acceder a archivos exter
nos creados por otras herramientas 1. .
Especificación de los requerimientos del sistema

1.1 Al usuario se le proveerá con los recursos para definir el tipo de archivos ex
ternos.
1.2 Cada tipo de archivo externo tendrá una herramienta asociada que será aplicada a
l archivo
1.31.3 Cada tipo de archivo externo se representará como un icono específico sobre l
a pantalla del usuario
1.4 Se proveerán recursos para que el usuario defina el icono que representa un ti
po de archivo externo.
1.5 Cuando un usuario selecciona un icono que representa un archivo externo, el
efecto de esa selección es aplicar la herramienta asociada con este tipo de archiv
o al archivo representado por el icono seleccionado
Lectores de requerimientos
Requerimientos del usuario
Requerimientos del sistema
Administradores de clientes
Usuarios finales del sistema
Ingenieros clientes
Administradores contratistas
Arquitectos del sistema
Usuarios finales del sistema
Ingenieros clientes
Arquitectos del sistema
Desarrolladores del software
Ingenieros clientes (quizás)
Arquitectos del sistema
Desarrolladores del software
Especificación del
diseño del software

Requerimientos funcionales y no funcionales

Requerimientos funcionales

Declaración de servicios que el sistema debería proporcionar,como debería reaccionar e

l sistema a determinadas entradas ycómo debería comportarse en situaciones particula
res.

Requerimientos no funcionales

Restricciones de los servicios o funciones ofrecidas por elsistema como restricc

iones de encendido, restricciones en el proceso de desarrollo, estándares, etc.

Requerimientos del dominio

Restricciones que provienen del dominio de aplicación delsistema y que reflejan la

s características del dominio.
Requerimientos funcionales

Describen la funcionalidad o los servicios del sistema

Depende del tipo de software, Los usuarios esperados y el tipo de sistema en que
elsoftware se va a usarse.

Los requerimientos del usuario funcional pueden ser declaraciones de muy alto ni
vel sobre lo que
el sistema debería hacer, pero los requerimientos funcionales del sistema deberían d
escribir los servicios del sistema con detalle.
El sistema LIBSYS

Un sistema de biblioteca que proporciona una cola interfaz a un número de bases de

datos de artículos en diferentes bibliotecas

Los usuarios pueden buscar, descargar e imprimir estos artículos para su estudio p
ersonal.

Ejemplos de requerimientos funcionales

El usuario debe ser capaz de buscar en el conjunto inicial de la base de datos o

seleccionar un subconjunto de ella.

El sistema debe proporcionar visores adecuados para que el usuario lea los docum
entos en el repositorio de documentos.

A cada orden se le debe asignar un único identificador (ORDER_ID) que el usuario d

ebe ser capaz de copiar en el área de almacenamiento permanente de la cuenta.

Imprecisión de requerimientos

Los problemas surgen cuando los requerimientos no se exponen detalladamente.

Los requerimientos ambiguos pueden ser interpretados de diferentes formas por pr

omotores y usuarios.

Considera el término visor apropiado

Intención del usuario Editor con un propósito especial para cada tipo de documento d
iferente
Interpretación del promotor -Proporciona un visor de texto que muestra los conteni
dos del documento.
Completitud y consistencia de los requerimientos

En principio, los requerimientos deberían ser tanto completos como consistentes

completos

Todos los servicios solicitados por el usuario deben estar definidos.

Consistentes

No debería haber conflictos o contradicciones en las descripciones de las facilida

des del sistema

En la práctica es imposible producir un documento de requerimientos completo y con

sistente.
Requerimientos no funcionales

Estos definen las propiedades y restricciones delsistema, p.Ej.: confiabilidad,

tiempo de respuesta y
requerimientos de almacenamiento. Las restricciones son la capacidad del mecanis
mo Entrada/Salida,representaciones del sistema, etc.

Los requerimientos también pueden ser especificados asignando sistemas CASE partic
ulares, programando un lenguaje o desarrollando un método.

Los requerimientos no funcionales pueden ser más críticos que los funcionales. Si es
tos no se cumplen, elsistema es inservible.

Clasificaciones no funcionales

Requerimientos del producto

Requerimientos que especifican que el producto entregado debe comportarse de una

manera determinada. P.Ej.: Velocidad de ejecución, confiabilidad, etc.

Requerimientos organizacionales

Requerimientos que son una consecuencia de las políticas yprocedimientos organizac

ionales. P.Ej.: estándares de proceso usados, requerimientos de implementación, etc.
Requerimientos externos

Los requerimientos que surgen de los factores que son externos al sistema y su
proceso de desarrollo. P.Ej.:
interoperabilidad, requerimientos legislativos, etc.
Requerimientos de usabilidad
Requerimientos de eficiencia
Requerimientos de fiabilidad
Requerimientos de portabilidad
Requerimientos de interoperabilidad
Requerimientos éticos
Requerimientos legislativos
Requerimientos de implementación
Requerimientos de estándares
Requerimientos de entrega
Requerimientos Requerimientos
Requerimientos del producto
Requerimientos organizacionales
Requerimientos externos
Requerimientos no funcionales
Tipos de requerimientos no funcionales

de espacio de privacidad de seguridad

de rendimiento

Ejemplos de requerimientos no funcionales

Requerimiento del producto

8.1 La interfaz del usuario para LIBSYS deberá ser implementada como HTML simple s
in marcos o applets java.

Requerimiento organizativo
9.3.2 El proceso de desarrollo del sistema y los documentos a entregar debe ajus
tarse al proceso y a los productos a entregar definidos en el XYZCo-SP-STAN-95

Requerimiento externo
7.6.5 El sistema no deberá revelar a sus operadores alguna información personal de l
os clientes excepto su nombre y su número de referencia
Metas y requerimientos

Puede ser muy difícil plantear los requerimientos no funcionales de forma precisa,
y puede ser muy difícil verificar los requerimientos imprecisos.

meta
Es una intención general del usuario como facilidad de uso.
Requerimiento verificable no funcional

Una instrucción que utiliza alguna medida que puede ser probada objetivamente
Las metas son útiles para los desarrolladores ya que transmiten las intenciones de
los usuarios del sistema.
Ejemplos

Metas del sistema

El sistema debería ser fácil de utilizar por controladores experimentados y debería es

tar organizado de forma que los errores de los usuarios estén minimizados.

Un requerimiento verificable no funcional

Los controladores experimentados deben ser capaces de utilizar todas las funcion
es del sistema después de un total de dos horas de formación.
Medidas de requerimientos

Propiedad
Medida
Velocidad
transacciones procesadas por segundo
Tiempo de respuesta al usuario y a eventos
Tiempo de actualización de la pantalla
Tamaño
M Bytes
Número de chipsde ROM
Facilidad de uso
Tiempo de formación
Número de marcos de ayuda
Confiabilidad
Tiempo medio entre fallos
Probabilidad de no disponibilidad
Tasa de ocurrencia de fallos
disponibilidad
Robustez
tiempo de reinicio después de fallo
Porcentaje de eventos que causan fallos
Probabilidad de corrupción de datos después de un fallo
Portabilidad
Porcentaje de declaraciones dependientes de objetivo
Número de sistemas objetivo
Interacción de los requerimientos

Conflictos entre diferentes requerimientos no funcionales son comunes en sistema

s complejos

Sistema de nave espacial

Para minimizar el peso, el número de chips separados en el sistema debería ser minim
izado.
Para minimizar el consumo de energía, se deberían usar chips de baja potencia.
No obstante, usar chips de baja potencia puede implicar tener que usar más chips. ¿C
uál es elrequerimiento más importante?
Requerimientos del dominio

Se derivan del dominio de la aplicación y describen características y rasgos del sis

tema que reflejan el dominio.

Los requerimientos del dominio son nuevos requerimientos funcionales, restriccio

nes de requerimientos existentes o bien definen cálculos específicos.

Si los requerimientos del dominio no se satisfacen, el sistema puede ser impract

icable.
Requerimientos del dominio del sistema de biblioteca

Deberá existir una interfaz del usuario estándar para todas las bases de datos, la c
ual tome como referencia el estándar Z39.50
Debido a las restricciones en los derechos de autor, algunos documentos deberán bo
rrarse inmediatamente después de su llegada. Dependiendo de los requerimientos del
usuario, estos documentos se imprimirán de forma local en el servidor del sistema
para ser distribuidos de forma manual al usuario o enviarse a la impresora de l
a red.
Sistema de protección de trenes

La deceleración del tren se calculará como:

Problemas de requerimientos del
dominio

comprensible

Los requerimientos se expresan en el lenguaje del dominio de la aplicación.

A menudo los ingenieros de software que desarrollan el sistema no entienden esto
.

implícito

Los especialistas del dominio comprenden el área tan bien que no piensan en hacer
los requerimientos
del dominio explícitos.
Requerimientos del usuario

Se debería describir los requerimientos funcionales y no funcionales de manera que

sean comprensibles por los usuarios del sistema que no tienen un conocimiento téc
nico detallado.

Los requerimientos del sistema se definen usando un lenguaje natural, tablas y d

iagramas,
ya que estos son entendidos por todos los usuarios.

Problemas con el lenguaje natural

Falta de claridad

La precisión es difícil de conseguir sin hacer que el documento sea difícil de leer.

Confusión de requerimientos

Los requerimientos funcionales y no funcionales tienden a estar mezclados.

Fusión de requerimientos

Varios requerimientos diferentes pueden expresarse juntos.

Requerimientos de LIBSYS

LIBSYS debe proporcionar un sistema de cuentas financieras que mantenga registro

s de todos los pagos hechos por los usuarios del sistema. Los administradores de
l sistema deben configurar este sistema para que los usuarios regulares reciban
tasas de descuento.

Requerimiento para editor de cuadrícula

2.6 Recursos de la cuadrícula

Para ayudar a la ubicación de entidades en un Diagrama, el usuario activará una cuad
rícula en centímetros o en pulgadas, mediante una opción en el panel de control. De fo
rma inicial, dicha cuadrícula estará desactivada. Esta cuadrícula se podrá activar o des
activar en cualquier momento durante la sesión de edición y puesta en pulgadas y cen
tímetros.
La opción de cuadrícula se proveerá en la vista de reducción de ajuste, pero el número de
líneas de la cuadrícula a mostrar se reducirá para evitar saturar el diagrama más pequeño
con líneas de cuadrícula.

Problemas de los requerimientos

Los requerimientos de la base de datos incluyen información conceptual detallada.

Describe el concepto de sistema de cuentas financieras que se va a incluir en LI

BSYS;
Sin embargo, también se incluye el detalle de que los administradores pueden confi
gurar este sistema Es innecesario a este nivel.
El requerimiento de cuadrículas mezcla tres clases diferentes de requerimientos.

Requerimiento funcional conceptual (se necesita una cuadrícula);

Requerimientos no funcionales (unidades de la cuadrícula)
Requerimiento de la interfaz del usuario no funcional (activación de la cuadrícula)
Presentación estructurada

2.6.1 Recursos de la cuadrícula

El editor deberá proporcionar un recurso para la cuadrícula donde una matriz de líneas
horizontales y verticales proporciona un fondo para la ventana del editor. Esta
cuadrícula deberá ser pasiva, donde la alineación de entidades es responsabilidad del
usuario.
Fundamento: Una cuadrícula ayuda al usuario a crear un diagrama ordenado con entid
ades bien espaciadas. Aunque en una cuadrícula activa pueda ser de utilidad que la
s entidades se ajusten a las líneas de la cuadrícula, la ubicación es imprecisa. El us
uario es la mejor persona para decidir dónde se deberían ubicar las entidades.
Guía para escribir requerimientos
Inventar un formato estándar y usarlo para todos los requerimientos.

Distinguir entre los requerimientos deseables y obligatorios.

Resaltar el texto para identificar partes importantes del requerimiento

Evitar el uso de lenguaje técnico de computación

Requerimientos del sistema

Si los comparamos con los requerimientos del usuario los requerimientos del sist
ema son especificaciones mas detalladas de las funciones, servicios y restriccio
nes del sistema.

Están dirigidos a ser la base del diseño del sistema.

Pueden estar incorporados en el contrato de un sistema

Los requerimientos del sistema pueden estar definidos o ilustrados usando los mo
delos de sistema
Requerimientos y diseño

En principio, los requerimientos deberían exponer lo que el sistema debería hacer y

el diseño debería describir como consigue esto.

En la práctica, los requerimientos y el diseño son inseparables

Una arquitectura de sistema debe estar diseñada para estructurar los requerimiento
s;
El sistema debe inter-operar con otros sistemas que generan requerimientos de di
seño;
El uso de un diseño específico puede ser un requerimiento del dominio.
Problemas con la especificación del LN (lenguaje natural)

ambigüedad

Los lectores y escritores del requerimiento deben interpretar las mimas palabras
de la misma forma. El LN es naturalmente ambiguo así que esto resulta muy difícil.

Demasiada flexibilidad

Lo mismo puede ser expresado de varias formas diferentes en la especificación.

Falta de modularización

Las estructuras del LN no son adecuadas para estructurar los requerimientos del
sistema.
Alternativas a la especificación del LN

Notación Descripción
Lenguaje natural estructurado
Este enfoque depende de la definición de formas estándar o plantillas para expresar
la especificación de requerimientos.
Lenguajes de descripción de diseño
Este enfoque utiliza un lenguaje similar a uno de programación, pero con característ
icas más abstractas, para especificar los requerimientos por medio de la definición
de un modelo operativo del sistema.
Notaciones gráficas
Lenguaje gráfico, complementado con anotaciones de texto. Uno de los primeros leng
uajes gráficos fue SADT. Ahora se utilizan descripciones de casos de uso y diagram
as de secuencia
Especificaciones matemáticas
Estas notaciones están basadas en conceptos matemáticos como las máquinas de estado fi
nito o los conjuntos. Estas especificaciones no ambiguas reducen las discusiones
entre el cliente y el contratista sobre la funcionalidad del sistema. No obstan
te, la mayoría de los clientes no entienden las especificaciones formales y se rehús
an a aceptarlas como un contrato del sistema.
Especificaciones del lenguaje estructurado

La libertad del redactor de los requerimientos está limitada por una plantilla pre
definida para los requerimientos

Todos los requerimientos están escritos de manera estándar.

La terminología que se usa en una descripción puede estar limitada.

La ventaja es que la mayoría de la expresividad del lenguaje natural se mantiene p

ero un grado de
uniformidad se impone en la especificación.

Especificaciones utilizando un formulario estándar

Definición de la función o entidad a especificar

Descripción de sus entradas y de dónde vienen

Descripción de sus salidas y hacia dónde van

Indicación de otras entidades requeridas

Pre y post condiciones (si procede)

Efectos secundarios o colaterales (si hubiera) de la función.

Especificaciones utilizando un formulario estándar

Función Calcular la dosis de insulina: nivel de azúcar seguro

Descripción Calcula la dosis de insulina para dispensarla cuando la medida actual
del nivel de azúcar
esté en una zona segura entre 3 y 7 unidades.
Entradas: Lectura actual de azúcar (r2), las dos lecturas previas (r0 y r1)
Fuente Lectura de azúcar del sensor. Otras lecturas de la memoria
Salidas CompDose (dosis calculada) La dosis de insulina que será dispensada
Destino Bucle de control principal
Acción: CompDose tiene valor cero si el nivel de azúcar es estable o está cayendo o si
el nivel se está
incrementando pero la tasa de incremento está decayendo. Si el nivel está incrementa
ndo y la tasa de
incremento se está incrementando, entonces la CompDose se calcula dividiendo la di
ferencia entre el
actual nivel de azúcar y el nivel previo entre cuatro y redondeando el resultado.
Si el resultado se
redondea a cero, entonces la CompDose se fija la mínima dosis que pueda ser libera
da.
Requerimientos Dos lecturas previas para que la tasa de cambio del nivel de azúcar
puedaser calculada.
Pre-condición La reserva de insulina contiene al menos el máximo permitido en una so
la dosis.
Post-condición r0 se reemplaza por r1 cuando r1 se reemplaza por r2
Efectos secundarios ninguno

Especificación tabular del calculo

Utilizada para complementar el lenguaje natural.

Particularmente útil cuando se tiene que definir un número de posibles acciones o ca

minos alternativos.
Especificación tabular

Modelos gráficos

Los modelos gráficos son más útiles cuando se necesita mostrar como cambian los estado
s o donde se necesita describir una secuencia de acciones

Se explican diferentes modelos gráficos en el capítulo 8.

Diagramas de secuencia

Éstos muestran la secuencia de eventos que tienen lugar durante cualquier interacc
ión de un usuario con el sistema.

Se leen de arriba hacia abajo para ver el orden de las acciones que tienen lugar
.

Retirada de dinero en un ATM

Validar tarjeta;
Gestionar petición;
Transacción completa.
Diagrama de secuencia de la retirada de un ATM

tarjeta
Número de tarjeta
Tarjeta OK
Petición de PIN
PIN
Menú opciones
<<excepción>>
Tarjeta inválida
Petición de retirada
Petición de cantidad
cantidad
Petición balance
Balance
<<excepción>>
Dinero insuficiente
Débito(cantidad)
Respuesta débito
tarjeta
Tarjeta extraída
dinero
Extracción dinero
recibo
Validar tarjeta
Gestionar petición
Transacción completa
ATM
Base de datos
Especificación de la interfaz

La mayoría de los sistemas deben operar con otros sistemas y las interfaces operan
tes deben ser
especificadas como parte de los requerimientos.
Se deben definir tres tipos de interfaz
Interfaces de procedimiento;
Estructuras de datos que se intercambian;
Representaciones de datos.
Notaciones formales que son una técnica efectiva para la especificación de la interf
az.
Descripción de la interfaz PDL
Documento de los requerimientos(SRS especificación de requerimientos de software)

El documento de requerimientos es la exposición oficial de lo que se pide a los de

sarrolladores delsistema.

Debería incluir tanto la definición de los requerimientos del usuario como la especi
ficación de los requerimientos del sistema.

NO es un documento de diseño. Debería fijar,hasta donde sea posible, LO QUE el siste

ma debería hacer en lugar de CÓMO debería hacerlo.
Usuarios de documento de requerimientos

Usan los requerimientos para desarrollar pruebas de validación para el sistema

Usan el documento de requerimientos para planificar una oferta para el sistema y
el
proceso de desarrollo del sistema
Usan los requerimientos para comprender para qué se desarrolla el sistema
Ingenieros probadores de sistemas administradores
Ingenieros de sistemas
Especifican requerimientos y leerlos para comprobar que cumplen sus necesidades.
Especifican
cambios para los requerimientos Clientes Del sistema
Usan requerimientos para ayudar a entender el sistema y la relación entre sus part
es
Ingenieros Mantenedores De sistemas
IEEE(Institute of Electrical and
Electronic Egineers)

Define una estructura genérica para un documento de requerimientos que debe ser in
iciado para cada sistema específico
Introducción.
Descripción general.
Requerimientos específicos.
Apéndices.
Índice.
Estructura de un documento de requerimientos

Prefacio

Introducción

Glosario

Definición de los requerimientos del usuario

Arquitectura del sistema

Especificación de los requerimientos del sistema

Modelos del sistema

Evolución del sistema

Apéndices

Índice
Puntos clave

Los requerimientos determinan lo que el sistema debería hacer y definen las restri
cciones en su funcionamiento e implementación.

Los requerimientos funcionales determinan los servicios que el sistema debería pro
porcionar

Los requerimientos no funcionales restringen el sistema que ha sido desarrollado

o el proceso de desarrollo.

Los requerimientos del usuario son declaraciones de alto nivel sobre lo que el s
istema debería hacer. Los requerimientos deberían estar escritos usando lenguaje nat
ural, tablas y diagramas.
Puntos clave

Los requerimientos del sistema están pensados para comunicar las funciones que el
sistema debería
proporcionar.

Un documento de requerimientos de software es una declaración acordada de los requ

erimientos del sistema.

El estándar de la IEEE es un punto de partida útil que define más estándares de requerim
ientos específicos detallados.
Procesos de ingeniería de
requerimientos
Objetivos
? Describir las principales actividades de la ingeniería de requerimientos y sus r
elaciones.
? Introducir técnicas para la obtención y análisis de los requerimientos.
? Describir la validación de los requerimientos y el papel de las revisiones de re
querimientos
? Discutir el papel de la administración de requerimientos como soporte de otros p
rocesos de ingeniería de requerimientos.
Estudios de factibilidad
? Un estudio de factibilidad decide si el sistema propuesto merece o no la pena.
? un estudio corto y orientado a resolver varias preguntas
si el sistema contribuye a los objetivos de la organización;
Si el sistema puede ser implementado utilizando la tecnología actual y dentro del
presupuesto;
Si el sistema puede integrarse con otros que ya se usan.
Factibilidad e implementación
? Basado en la valoración (lo que se necesita) de la recolección de información y reda
cción de un informe.
? Preguntas para las personas de la organización
¿cómo se las arreglaría la organización si no se llevase a cabo este sistema?
¿Cuáles son los problemas con los procesos actuales?
¿cómo ayudaría el nuevo sistema a resolverlos?
¿cuáles serían los problemas de integración?
¿se necesita nueva tecnología?¿qué capacidades?
¿A qué debe ayudar el sistema?
Obtención y análisis
? A veces llamado obtención de requerimientos o descubrimiento de requerimientos.
? Implica el trabajo de personal técnico con los clientes para informarse del domi
nio de la aplicación, los servicios que el sistema debería proporcionar y las restri
cciones operacionales del sistema.
? Debe implicar a los usuarios finales, administradores, ingenieros implicados e
n el mantenimiento, expertos del dominio, sindicatos, etc.
Todos estos son designados como stakeholders.
Problemas del análisis de requerimientos
? Los Stakeholders no saben lo que realmente quieren.
? Los Stakeholders expresan los requerimientos con sus propios términos
? Diferentes stakeholders pueden tener requerimientos conflictivos
? Factores políticos y organizacionales pueden influenciar los requerimientos del
sistema
? Los requerimientos cambian durante el proceso de análisis. Pueden surgir nuevos
Stakeholders y el entorno de negocios cambia.
Actividades del proceso
? Descubrimiento de los requerimientos
Interactuar con los stakeholders para descubrir sus requerimientos. También son de
scubiertos los requerimientos del dominio en esta etapa.
? Organización y clasificación de los requerimientos
Agrupa los requerimientos relacionados y los organiza en grupos coherentes
? Priorización y negociación
Priorizar los requerimientos y resolver los conflictos de los requerimientos.
? Documentación de los requerimientos
Los requerimientos se documentan y son introducidos en la siguiente ronda de la
espiral
Descubrimiento de requerimientos
El proceso de reunir información sobre los sistemas propuestos y los ya existentes
y destilar los requerimientos del sistema y del usuario de esta información
? Las fuentes de la información incluyen documentación, stakeholders del sistema y l
a especificación de sistemas similares.
Stakeholders de ATM
? Clientes de banco
? Representantes de otros bancos
? Administradores del banco
? Contadores de la sucursal bancaria
? Administradores de bases de datos
? Administradores de seguridad
? Departamento de marketing
? ingenieros de mantenimiento de hardware y
software
? Reguladores de banca
Stakeholders de ATM
? Clientes de banco
? Representantes de otros bancos
? Administradores del banco
? Contadores de la sucursal bancaria
? Administradores de bases de datos
? Administradores de seguridad
? Departamento de marketing
? ingenieros de mantenimiento de hardware y software
? Reguladores de banca
Tipos de puntos de vista
? Puntos de vista de los interactores
Las personas u otros sistemas que interactúan directamente con el sistema. En un A
TM, el cliente y la base de datos de las cuentas son los puntos de vista de los
interactores
? Puntos de vista indirectos
Los Stakeholders que no usan el sistema directamente pero que influyen en los re
querimientos. En un ATM el personal de administración y seguridad son los puntos d
e
vista indirectos
? Puntos de vista del dominio
Las características y restricciones del dominio que influyen en los requerimientos
. En un ATM, un ejemplo serían los estándares para las comunicaciones entre bancos.
Identificación de los puntos de
vista
? Identificar puntos de vista utilizando
Proveedores y receptores de los servicios del sistema;
Sistemas que interactúan directamente con el sistema
que está especificado;
Regulaciones y estándares;
Fuentes de negocios y requerimientos no funcionales
Ingenieros que tienen que desarrollar y mantener el sistema;
Marketing y otros puntos de vista del negocio.
Entrevistas
? En una entrevista formal o informal, el equipo de requisitos propone preguntas
a los stakeholders sobre el sistema que usan y el que va a desarrollarse.
? Hay dos tipos de entrevista
Entrevistas cerradas en las que se responde a un conjunto predefinido de pregunt
as
Entrevistas abiertas en las que no hay una agenda predefinida y una amplia varie
dad de temas se exploran con los stakeholders.
Entrevistas en la práctica
? Normalmente una mezcla de entrevistas abiertas y cerradas.
? Las entrevistas son buenas para obtener una comprensión global de los que los st
akeholders hacen y cómo interactuarán con el sistema.
? Las entrevistas no son buenas para entender los requerimientos del dominio
Los ingenieros de requerimientos no pueden entender la terminología específica del d
ominio
Algunos conocimientos del dominio son tan familiares que la gente encuentra difíci
l expresarse o piensan que no merece la pena expresarse.
Entrevistadores efectivos
? Los entrevistadores deberían tener una mente abierta,estar dispuestos a escuchar
a
los stakeholders y no deberían tener ideas preconcebidas sobre los requerimientos.
? Deberían provocar al entrevistado con cuestiones o proposiciones y no deberían esp
erar simplemente a que respondiesen a una pregunta como ¿qué quieres?
Escenarios
? Los escenarios son ejemplos de la vida real de cómo puede utilizarse el sistema.
? Deben incluir
Una descripción de la situación inicial.
Una descripción del flujo normal de acontecimientos
Una descripción de lo que puede salir mal;
Información sobre otras actividades simultáneas;
Una descripción del estado cuando finaliza el escenario.
Escenario (1) de LIBSYS
Suposición inicial: El usuario se ha registrado en el sistema LIBSYS y ha encontra
do el periódico que contiene la copia del artículo
Normal: El usuario selecciona el artículo para copiarlo. A él o a ella se les exige,
o bien proporcionar información de suscriptor del periódico o bien indicar cómo van a
pagar el artículo.
Los métodos de pago alternativos son la tarjeta de crédito o indicando el número de cu
enta de una organización.
Después se le pide al usuario que rellene un formulario copyright que mantiene det
alles de la transacción y después ellos mandan esto al sistema LIBSYS.
Se comprueba el formulario copyright y si es correcto se descarga la versión PDF
del artículo al área en funcionamiento de LIBSYS en el ordenador del usuario y el us
uario es informado de que está disponible.
Se le pide al usuario que seleccione una impresora y una copia del artículo se imp
rime. Si el artículo se ha impreso como imprimir solo éste se borra del sistema del us
uario una vez que éste ha confirmado que la impresión se ha completado.
Escenario (2) de LIBSYS
¿Qué puede salir mal?: El usuario puede equivocarse al rellenar el formulario copyri
ght. En este caso el formulario debe ser presentado de nuevo al usuario para que
lo corrija. Si al volver a enviar el formulario
sigue siendo incorrecto, entonces el la petición del artículo por parte del usuario
se rechaza.
El pago puede ser rechazado por el sistema. La petición del artículo por parte del u
suario es rechazada.
La descarga del artículo puede fallar. Reintentar hasta que no falle o el usuario
termine su sesión
Puede que no sea posible imprimir el artículo. Si el artículo no está etiquetado como i
mprimir solo ,
entonces se mantiene en el espacio de trabajo de LIBSYS. De lo contrario, el a
rtículo se borra y también la cuenta del usuario a la que se le atribuye el coste de
l artículo.
Otras actividades: Descargas simultáneas de otros artículos.
Estado del sistema en la conclusión: El usuario está registrado. La descarga del artíc
ulo ha sido borrada del espacio de trabajo de LIBSYS si ha sido etiquetada como i
mprimir solo .
Casos de uso
? Los casos de uso son una técnica basada en un escenario en UML que identifican a
los actores en una interacción y describen la interacción en sí.
? Un conjunto de casos de uso debería describir todas las posibles interacciones c
on el sistema
? Los diagramas de secuencia deben ser utilizados para añadir detalles a los casos
de uso mostrando la secuencia de procesamiento de eventos en el
sistema.
Factores sociales y organizacionales
? Los sistemas de software se usan en un contexto social y organizacional. Esto
puede influir o incluso dominar los requerimientos del sistema.
? Los factores sociales y organizacionales no son un solo punto de vista sino qu
e son influencias en todos los puntos de vista.
? Los buenos analistas deben ser sensibles a estos factores pero actualmente no
hay ningún modo sistemático de abordar su análisis.
Etnografía
? Un sociólogo pasa un tiempo considerable observando y analizando como trabajan v
erdaderamente las personas.
? Las personas no tienen que explicar o expresar su trabajo
? Deben observarse los factores sociales y organizacionales de importancia
? Los estudios de etnografía han mostrado que el trabajo es normalmente más rico y más
complejo de lo que sugieren los modelos de sistema simples.
Etnografía centrada
? Desarrollada en un proyecto estudiando el proceso de control del tráfico aéreo.
? Combina la etnografía con la creación de prototipos
? El desarrollo de prototipos desemboca en preguntas sin respuestas que se centr
an en el análisis etnográfico
? El problema con la etnografía es que estudia prácticas existentes que pueden tener
una base histórica que ya no es importante.
Alcance de la etnografía
? Los requerimientos que se derivan de la forma en la que las personas trabajan
en lugar de en la forma en que las definiciones del proceso sugieren que deberían
trabajar.
? Los requerimientos que se derivan de la cooperación y la conciencia de las activ
idades de otras personas.
Validación de requerimientos
? Se ocupa de demostrar que los requerimientos definen el sistema que el cliente
 realmente quiere.
? Los costes de los errores de requerimientos son altos así que la validación es muy
importante.
Arreglar un error de requerimientos después de la entrega puede costar unas 100 ve
ces el coste de arreglar un error de implementación.
Verificación de requerimientos
? Validez. ¿Proporciona el sistema las funciones que mejor sostienen las necesidad
es del cliente?
? Consistencia. ¿hay algún conflicto entre requerimientos?
? Completitud. ¿Se incluyen todas las funciones requeridas por el cliente?
? Realismo. ¿Pueden los requerimientos ser implementados, dotados de presupuesto y
tecnología disponibles?
? Verificabilidad. ¿Pueden comprobarse los requerimientos?
Técnicas de validación de requerimientos
? Revisión de requerimientos
Análisis sistemático de requerimientos Por un equipo de revisores
? Creación de prototipos
Utilizar un modelo ejecutable del sistema para comprobar los requerimientos.
? Generación de casos de prueba
Diseñar pruebas para poner a prueba los requerimientos
Revisión de requerimientos
? Deberían ser realizadas revisiones regulares mientras está siendo formulada la def
inición de los requerimientos
? Tanto el cliente como el contratista deberían estar involucrados en las revision
es.
? Las revisiones pueden ser formales (con documentos completos) o informales.
Las buenas comunicaciones entre los desarrolladores, el cliente y los usuarios p
uede resolver los problemas en una etapa temprana.
Los revisores también pueden comprobar:
? Verificabilidad. ¿Se puede probar el requerimiento de modo realista?
? Comprensibilidad. ¿Se comprende el requerimiento correctamente?
? Rastreabilidad . ¿El origen de los requerimientos está claramente establecido?
? Adaptabilidad. ¿Puede cambiarse el requerimiento sin que cause efectos a gran es
cala en otros requerimientos?
Administración de requerimientos
? La administración de requerimientos es el proceso de administración de los requeri
mientos que cambian durante el proceso de ingeniería de requerimientos y el desarr
ollo del sistema.
? Los requerimientos son inevitablemente incompletos e inconsistentes.
Nuevos requerimientos emergen durante el proceso ya que el negocio necesita camb
ios y se desarrolla una mejor comprensión del sistema;
Los diferentes puntos de vista tienen distintos requerimientos y éstos son frecuen
temente contradictorios
Cambio de requerimientos
? La prioridad de los requerimientos provenientes de diferentes puntos de vista
cambia durante el desarrollo
? Los clientes del sistema deben especificar los requerimientos desde una perspe
ctiva de negocios que choca con los requerimientos del usuario final.
? El entorno técnico y de negocios del sistema cambia durante su desarrollo.
Requerimientos duraderos y volátiles
? Requerimientos duraderos. Requerimientos relativamente estables que se deriva
n de la actividad principal de la organización del cliente.
P.Ej.: un hospital siempre tendrá doctores, enfermeras, etc. Puede derivar de los
modelos de dominio.
? Requerimientos volátiles. Requerimientos que cambian durante el desarrollo del s
istema o cuando éste está en funcionamiento. En un hospital, podrían ser los requerimi
entos resultantes de la política de asistencia sanitaria.
Clasificación de requerimientos volátiles
Tipo de requerimiento Descripción
Requerimientos mutantes: Requerimientos que cambian debido a los cambios en el
entorno en que opera la organización.
Por ejemplo, en los sistemas hospitalarios, la consolidación del cuidado del pacie
nte puede cambiar y requerir un tratamiento diferente de la información que se rec
opila.
Requerimientos emergentes: Requerimientos que emergen al incrementarse la compr
ensión del cliente en el desarrollo del sistema. El proceso de diseño puede revelar
requerimientos emergentes nuevos.
Requerimientos consecuentes: Requerimientos que son el resultado de la introduc
ción del sistema de cómputo.
Esta introducción puede cambiar los procesos de la organización y abrir nuevas forma
s de trabajar que generarán nuevos requerimientos del sistema.
Requerimientos de compatibilidad: Requerimientos que dependen de sistemas partic
ulares o procesos de negocios dentro de la organización. Cuando estos últimos cambia
n, los requerimientos de compatibilidad del sistema contratado o entregado puede
n cambiar.
Planificación de la gestión de requerimientos
? Durante la etapa de gestión de requerimientos, habrá que decidir sobre:
La identificación de requerimientos
Cómo se identifican individualmente los requerimientos;
Un proceso de administración de cambios
Es el proceso que sigue al análisis de cambio de requerimientos;
Políticas de rastreo
La cantidad de información sobre las relaciones de los requerimientos que se manti
ene.
Ayuda de herramientas CASE
La ayuda de herramientas que se requiere para apoyar la administración del cambio
de requerimientos.
Información de Rastreo
La rastreabilidad se ocupa de las relaciones entre requerimientos, sus fuentes y
el diseño del sistema.
? Rastreo de la fuente
Vínculos entre los requerimientos y los stakeholders que propusieron estos requeri
mientos y la razón de estos.
? Rastreo de requerimientos
Vínculos entre requerimientos dependientes;
? Rastreo del diseño
Vínculos entre los requerimientos con los módulos del diseño en los cuales son imple
mentados
Ayuda de herramientas CASE
Se precisan herramientas de ayuda para:
? Almacenamiento de requerimientos
Los requerimientos deben mantenerse en un almacén de datos seguro y administrado.
? Gestionar el cambio
El proceso de administración del cambio es un proceso de flujo de trabajo cuyas et
apas pueden ser definidas y el flujo de información entre estas etapas está parcialm
ente automatizado.
? Gestionar el rastreo
Recuperación automatizada de vínculos entre requerimientos.
Gestión del cambio de los requerimientos
? Debería aplicarse a todos los cambios propuestos en los requerimientos
? Etapas principales
Análisis del problema y especificación del cambio.
Discusión de los problemas de los requerimientos y propuesta de cambio;
Análisis del cambio y calculo coste. Valora los efectos del cambio en otros requer
imientos;
Implementación del cambio. Modificación del documento de requerimientos y otros doc
umentos para reflejar el cambio.
Puntos clave
? El proceso de ingeniería de requerimientos incluye un estudio de factibilidad, a
sí como la obtención, análisis, especificación y administración de requerimientos.
? La obtención y análisis de requerimientos es un proceso iterativo que incluye la c
omprensión del dominio, la recopilación de requerimientos y su clasificación, estructu
ración y validación.
? Los sistemas tienen múltiples stakeholders con diferentes requerimientos.
Puntos clave
? Factores sociales y organizacionales influencian los requerimientos del sistem
a.
? La validación de requerimientos se ocupa de la comprobación de validez, consistenc
ia, integridad, realismo y certidumbre.
? Los cambios en el negocio llevan inevitablemente a un cambio en los requerimie
ntos.
? La administración de requerimientos incluye la planificación y administración de cam
bios.