Recopilación de Requerimientos
Se divide en 7 conceptos:
-Concepción. ¿Cómo inicia un proyecto de software?
¿Existe un solo evento que se convierte en el catalizador de un nuevo sistema o
producto basado en computadora o la necesidad evoluciona en el tiempo? No hay
respuestas definitivas a estas preguntas. En ciertos casos, una conversación
casual es todo lo que se necesita para desencadenar un trabajo grande de
ingeniería de software. Pero en general, la mayor parte de proyectos comienzan
cuando se identifica una necesidad del negocio o se descubre un nuevo mercado o
servicio potencial.
-Indagación. En verdad que parece muy simple:
preguntar al cliente, a los usuarios y a otras personas cuáles son los
objetivos para el sistema o producto, qué es lo que va a lograrse, cómo se
ajusta el sistema o producto a las necesidades del negocio y, finalmente, cómo
va a usarse el sistema o producto en las operaciones cotidianas. Pero no es
simple: es muy difícil.
Se han identificado cierto
número de problemas que se encuentran cuando
Ocurre la indagación:
• Problemas de alcance.
• Problemas de entendimiento.
• Problemas de volatilidad.
-Elaboración. La
elaboración está motivada por la creación y mejora de escenarios de usuario que
describan cómo interactuará el usuario final (y otros actores) con el sistema.
Cada escenario de usuario se enuncia con sintaxis apropiada para extraer clases
de análisis, que son entidades del dominio del negocio visibles para el usuario
final.
-Negociación. No es raro que los clientes y usuarios
pidan más de lo que puede lograrse dado lo limitado de los recursos del
negocio. También es relativamente común que distintos clientes o usuarios
propongan requerimientos conflictivos con el argumento de que su versión es
“esencial para nuestras necesidades especiales”.
-Especificación. En el contexto de los sistemas basados
en computadora (y software), el término especificación tiene diferentes
significados para distintas personas. Una especificación puede ser un documento
escrito, un conjunto de modelos gráficos, un modelo matemático formal, un
conjunto de escenarios de uso, un prototipo o cualquier combinación de éstos.
-Validación. La calidad de los productos del
trabajo que se generan como consecuencia de la ingeniería de los requerimientos
se evalúa durante el paso de validación. La validación de los requerimientos analiza
la especificación a fin de garantizar que todos ellos han sido enunciados sin
ambigüedades; que se detectaron y corrigieron las inconsistencias, las
omisiones y los errores, y que los productos del trabajo se presentan conforme
a los estándares establecidos para el proceso, el proyecto y el producto.
-Administración de los
requerimientos. Los
requerimientos para sistemas basados en computadora cambian, y el deseo de
modificarlos persiste durante toda la vida del sistema. La administración de
los requerimientos es el conjunto de actividades que ayudan al equipo del
proyecto a identificar, controlar y dar seguimiento a los requerimientos y a
sus cambios en cualquier momento del desarrollo del proyecto.
Preguntas de Formulación
Antes de preocuparse por las preguntas de
formulación que debe hacer, debe identificar quién será el objetivo de las
preguntas. Necesitará identificar a las partes interesadas. Una parte
interesada puede definirse como "cualquier persona que se beneficia
directa o indirectamente del sistema que se está desarrollando" -Ian
Sommerville.
En el mejor de todos los mundos, una
persona será el centro de sus preguntas. Este individuo tendrá una experiencia
empresarial adecuada, un buen conocimiento técnico y la autoridad para negociar
las necesidades en términos de tiempo de entrega y recursos. Sin embargo, es
más probable que se ocupe de un número de diferentes partes interesadas, cada
una con un punto de vista diferente, a veces necesidades divergentes y
conocimientos técnicos y de negocios sustancialmente diferentes. En general,
las partes interesadas se basan en las siguientes categorías: gerentes de
negocios, gerentes de producto, personas de marketing, clientes internos y
externos, usuarios finales, consultores, ingenieros de productos, ingenieros de
Web y personal de soporte y mantenimiento.
Definición de las Categorías de Usuario
-Gerentes y altos ejecutivos. Son los que se les permite controlar,
controlar y, en general, gestionar los procesos institucionales. Son sistemas
de apoyo a las personas y equipos que tienen que estar pendientes si las
"cosas funcionan bien". Algunas características clásicas de estos
tipos de usuarios requieren que organicen y resuelvan las decisiones
semiestructuradas, realicen la gestión de riesgos bajo diversos escenarios y
lleven a cabo la planificación con un horizonte a la escala de meses, trimestre
o año.
-Operadores. Ellos son responsables de acceder a la
información crítica de negocios y tener la capacidad de distribuir dicha
información a las diferentes personas de la organización y los usuarios para
asegurar la toma de decisiones basadas en información precisa, confiable y
oportuna que puede afectar el desarrollo y el éxito del negocio.
Desarrollo de Casos de Uso
En ésta es posible identificar a los
actores principales, y a los secundarios cuando se sabe más del sistema. Los
actores principales interactúan para lograr la función requerida del sistema y
obtienen el beneficio previsto de éste. Trabajan con el software en forma
directa y con frecuencia. Los actores secundarios dan apoyo al sistema, de modo
que los primarios puedan hacer su trabajo.
Una vez identificados los actores, es
posible desarrollar casos de uso. Se sugieren varias preguntas que debe responder un caso de uso:
• ¿Quién es el actor principal y quién(es)
el(los) secundario(s)?
• ¿Cuáles son los objetivos de los
actores?
• ¿Qué precondiciones deben existir antes
de comenzar la historia?
• ¿Qué tareas o funciones principales son
realizadas por el actor?
• ¿Qué excepciones deben considerarse al
describir la historia?
• ¿Cuáles variaciones son posibles en la
interacción del actor?
• ¿Qué información del sistema adquiere,
produce o cambia el actor?
• ¿Tendrá que informar el actor al sistema
acerca de cambios en el ambiente externo?
• ¿Qué información desea obtener el actor
del sistema?
• ¿Quiere el actor ser informado sobre
cambios inesperados?
