La ingeniería de requisitos puede ser un proceso largo y
arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas
cambian el entorno y las relaciones entre la gente, así que es importante
identificar a todos los actores involucrados, considerar sus necesidades y
asegurar que entienden las implicaciones de los nuevos sistemas
Entrevistas
Estos son
empleados para reunir información proveniente de personas o de grupos
involucrados con el sistema.
Talleres
Se hacea para descubrir
implicaciones cruzadas desconocidas para las personas implicadas
individuales y que a menudo no se descubren en las entrevistas o quedan
incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden
descubrirse realizando en un ambiente controlado, talleres facilitados por un
analista del negocio, en donde las personas implicadas participan en
discusiones para descubrir requisitos, analizan sus detalles y las
implicaciones cruzadas.
Forma de contrato
En esta se puede hacer llenando formularios o contratos
indicando los requisitos.
Objetivos medibles
Los requisitos formulados por los usuarios se toman como
objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra
vez desde el punto de vista del sistema hasta determinar los objetivos críticos
del funcionamiento interno que luego darán forma a los comportamientos
apreciables por el usuarioPrototipos
Un prototipo es una pequeña muestra, de funcionalidad limitada,
de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión
de los usuarios y rectificar algunos aspectos antes de llegar al producto
terminado.
Casos de uso
Un caso de uso es una técnica para documentar
posibles requisitos, graficando la relación del sistema con los usuarios u
otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su
interacción con entidades externas, permite omitir dichos aspectos y determinar
los que realmente corresponden a las entidades externas. El objetivo de esta
práctica es mejorar la comunicación entre los usuarios y los desarrolladores,
mediante la prueba temprana de prototipos para minimizar cambios hacia el final
del proyecto y reducir los costes finales. Esta técnica se enfrenta a los
siguientes peligros potenciales.
- A
los directivos, una vez que ven un prototipo, les cuesta comprender que
queda mucho trabajo por hacer para completar el diseño final.
- Los
diseñadores tienden a reutilizar el código de los prototipos por temor a
“perder el tiempo” al comenzar otra vez.
- Los
prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no
proporcionan explícitamente cuáles son los requisitos.
- Los
diseñadores y los usuarios finales pueden centrarse demasiado en el diseño
de la interfaz de usuario y demasiado poco en producir un sistema que
sirva el proceso del negocio.
Los prototipos pueden ser: diagramas, aplicaciones
operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde
se espera que el software final tenga diseño gráfico, se realizan en una
variedad de documentos de diseño gráficos y a menudo elimina todo el color del
diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir
la confusión sobre la apariencia final de la aplicación.
Especificación de requisitos del software
Una especificación de requisitos del software es una
descripción completa del comportamiento del sistema a desarrollar. Incluye un
conjunto de casos de uso que describen todas las interacciones que se prevén
que los usuarios tendrán con el software. También contiene requisitos no
funcionales (o suplementarios). Los requisitos no funcionales son los
requisitos que imponen restricciones al diseño o funcionamiento del sistema
(tal como requisitos de funcionamiento, estándares de calidad, o requisitos del
diseño).
Las estrategias recomendadas para la especificación de los
requisitos del software están descritas por IEEE 830-1998. Este estándar
describe las estructuras posibles, contenido deseable, y calidades de una
especificación de requisitos del software.
Los requisitos se dividen en tres:
- Funcionales:
son los que el usuario necesita que efectúe el software. Ej: el sistema
debe emitir un comprobante al asentar la entrega de mercadería.
- No
funcionales: son los "recursos" para que trabaje el sistema de
información (redes, tecnología). Ej: el soporte de almacenamiento a usar
debe ser .MySQL
- Empresariales
u Organizacionales: son el marco contextual en el cual se implantará el
sistema para conseguir un objetivo macro. Ej: abaratar costos de
expedición.
Identificación de las personas involucradas
Debido a que los cambios que introduce un sistema nuevo tienden
a afectar a más de un tipo de usuario, los analistas de requisitos han de tomar
en consideración a todos los implicados para que se obtengan y depuren sus
requisitos de la forma más fidedigna posible. Entre las personas implicadas hay
que considerar:
- Organizaciones
que integran la organización del analista que está diseñando el sistema
- Organizaciones
o sistemas de respaldo
- Dirección
- Usuarios
Problemas
Relacionados con las personas involucradas
Las vías que pueden dificultar la determinación de los requisitos
son:
- Los
usuarios no tienen claro lo que desean
- Los
usuarios no se involucran en la elaboración de requisitos escritos
- Los
usuarios insisten en nuevos requisitos después de que el coste y la
programación se hayan fijado.
- La
comunicación con los usuarios es lenta
- Los
usuarios no participan en revisiones o son incapaces de hacerlo.
- Los
usuarios no comprenden los problemas técnicos
- Los
usuarios no entienden el proceso del desarrollo
Esto puede conducir a la situación donde las exigencias del
consumidor cambian, incluso cuando el desarrollo del producto ya está en
marcha.
Relacionados con los analistas
La correcta redacción de las Especificaciones de requisitos
del Software es imprescindible para el correcto desarrollo del proyecto. Por
ello, en su redacción hay que evitar:
- Uso
de terminología ambigua en la redacción de los documentos de requisitos
- Sobre
especificación de los requisitos
- Escritura
poco legible, voz pasiva, abuso de negaciones
- Uso
de verbos en condicional, expresiones subjetivas
- Ausencia
de términos y verbos del dominio de la aplicación
Relacionados con los desarrolladores
Los problemas posibles causados por los desarrolladores
durante análisis de requisitos son:
- El
personal técnico y los usuarios finales pueden tener diversos vocabularios
y pueden llegar a creer incorrectamente que están de acuerdo, no dándose
cuenta del desacuerdo hasta que se provee el producto final.
- Los
desarrolladores pueden intentar encajar el sistema en un modelo existente,
en vez de desarrollar un sistema adaptado a las necesidades del cliente.
- El
análisis de requisitos se puede realizar a menudo por los ingenieros o
programadores, en vez de personal con las habilidades de relación con la
gente y el conocimiento apropiados para entender las necesidades de un
cliente correctamente.
Soluciones aplicadas
Una solución aplicada en los problemas de comunicaciones ha
sido emplear a especialistas en análisis del negocio o del sistema.
Las técnicas introducidas en los años 90 tienden al uso de
prototipos, lenguaje unificado de modelado,
casos de uso, y el desarrollo agil del software.
Otros tipos de herramientas aplicadas para salvar las
diferencias entre los usuarios y las organizaciones de tecnología de la
información y que permiten la comprobación de las aplicaciones son:
- pizarras
electrónicas para bosquejar los algoritmos y para probar alternativas
- capacidad
de capturar la lógica del negocio y los datos necesarios
- capacidad
de generar los prototipos que imitan fielmente el producto final
- interactividad
- la
capacidad para agregar requisitos contextuales y otro comentarios
- capacidad
para que usuarios remotos y distribuidos operen con el prototipo
Por último, se requieren herramientas que permitan medir, de
forma objetiva, la calidad de una especificación de requisitos.
Fuente de informacion:
Elaborado: por Efrain Martinez Hernandez Semestre: 4to Modulo:1
