Introducción al análisis de requisitos

Introducción al análisis de requisitos
Análisis de requisitos
En la fase de análisis se han de conseguir los siguientes objetivos:
· Identificar las necesidades del cliente, para lo que se efectúan reuniones y entrevistas entre
los miembros del equipo de análisis, el cliente y los usuarios finales. En cualquier caso hay que
tener en cuenta las restricciones económico-temporales impuestas por el cliente. Antes de
comenzar el análisis se ha de intentar conocer los productos existentes en el mercado por si
alguno fuese de utilidad. Con todos estos datos se realiza un documento conceptual del
sistema, que se modificará a medida que se definen los requisitos durante el análisis.
· Realizar un estudio de viabilidad económico, técnico y legal. Como hay limitaciones
económicas y temporales hay que estar muy seguro de que se podrá terminar el proyecto de
manera adecuada con el tiempo, dinero, personal, herramientas y técnicas disponibles. La
viabilidad legal pasa por conocer los elementos jurídicos relacionados con la informática y la
protección de datos, sobre todo las obligaciones definidas en los contratos y las
responsabilidades legales. Del estudio de viabilidad se desprende un documento que es
revisado por la dirección para valorar su continuidad o abandono, en el que se incluyen
alternativas referentes a costes y tiempos para el proyecto a desarrollar.
Conocidas las necesidades del cliente y la viabilidad del proyecto, si se decide seguir adelante
con él se han de asignar las funciones a desempeñar por el personal que interviene en el
desarrollo y se debe realizar una especificación de requisitos que sirva para el posterior
desarrollo del sistema.
Módulo de análisis de
requisitos
Los objetivos de este módulo son:
· Analizar y documentar las necesidades funcionales y de servicio del nuevo sistema. Se
dispondrá del catálogo de requisitos si se ha realizado la fase 0 o el plan de sistemas de
información.
· Identificar los requisitos y necesidades del nuevo sistema.
· Estudiarlas diferentes alternativas funcionales que permiten alcanzar una solución al sistema
propuesto, realizándose una valoración de sus diversos aspectos, los que se incluye el coste
económico de cada uno de ellos.
Como resultado de estas valoraciones se produce la selección de una alternativa más
apropiada, que será escogida para su posterior desarrollo por el cliente. Para alcanzar los
objetivos propuestos hemos de llevar a cabo las siguientes actividades
2.1. Actividad 1: Ámbito y alcance del proyecto
En esta actividad se describen los objetivos, el ámbito y las restricciones del sistema, se
identifican los participantes y su implicación en el proyecto. En esta actividad se deben
desarrollar las siguientes tareas:
Tarea 1: Definición del proyecto
Los objetivos para esta tarea son:
· Realizar una descripción general del proyecto, de los objetivos y de las restricciones.
· Identificar grupos, áreas y departamentos implicados en el proyecto. Hacer una planificación
inicial de la duración del mismo. Se pueden realizar cronogramas o gráficos, de barras o
circulares, para expresar los tiempos. Detallar la composición del equipo de trabajo necesario
para la realización del proyecto.
El producto a obtener es la descripción general del proyecto, en la que se ha de incluir:
· Objetivos principales.
· Departamentos, unidades o áreas afectadas.
· Planificación temporal inicial.
· Restricciones.
· Composición del equipo de trabajo.
Las técnicas necesarias son las entrevistas con los patrocinadores. A se va a explicar en qué
consisten las entrevistas y los cuestionarios.
· Entrevista
Se trata de una conversación dirigida a conocer determinados propósitos. Es importante crear
un clima de cordialidad para que el cliente se desenvuelva mejor y comunique con claridad lo
que piensa. Hay que estar atento a las opiniones del cliente. Dependiendo del tipo de
entrevistado y tiempo de reelaboración de la entrevista a posteriori, se pueden tomar notas o
grabarlas en audio o vídeo. En ambos caso debe pedir permiso al interlocutor. Se pueden
realizar videoconferencias para evitar desplazamientos del cliente y para rebajar los costes
del análisis.
Los puntos más importantes de una entrevista son:
- Lectura de antecedentes. Antes de la primera entrevista hay que conocer todo referente a la
empresa a la que se le va a implantar el sistema obteniendo d objetivos de fuentes externas,
que servirán para conocer la empresa con la que está tratando y así evitar tener que realizar
preguntas que puedan parecer trivial
Establecimiento de los objetivos. Los objetivos a conseguir con la entrevista han de estar
fijados de antemano, teniendo en cuenta las características del cargo que ejerce esa persona
dentro de la empresa. Por ejemplo, no se puede formular el mismo tipo de preguntas a un
operador que al responsable de marketing o a un director general.
Selección de los entrevistados. Comenzando por los directivos, que tienen una visión global
del sistema, se va descendiendo por la cadena de mando hasta los empleados o usuarios del
sistema que se va a implantar. Son los directivos o los responsables de equipo los que mejor
seleccionarán las personas que puedan ser entrevistadas.
Preparación del entrevistado. Para la realización de una entrevista hay que avisar o solicitar
fecha y hora con antelación. Unos días antes de que tenga lugar, se recuerda al cliente la
realización de la entrevista y se envía el guión o cuestionario previo con las materias a tratar
en la entrevista (también se puede realizar a través del correo electrónico).
Durante la entrevista hay que conseguir que las respuestas sean objetivas. Al término de la
entrevista se hace un breve resumen de la misma, a partir de las notas que se han tomado,
para asegurarnos que todo ha sido convenientemente explicado y comprendido. Por último,
antes de despedirnos, no hay que olvidar agradecer la atención que se nos ha dedicado.
Selección del tipo de preguntas. Habrá algunas preguntas abiertas, de temas generales,
incluso no referentes a la empresa, de forma que la entrevista resulte más cordial. También
se tendrán que formular otras preguntas cerradas referentes a hechos concretos y aspectos
del funcionamiento de la empresa relevantes para el diseño del sistema, evitando que se
olviden detalles. Hay tres modos de presentar ordenadas las preguntas en una entrevista:
1. Inductivo. A partir de preguntas cerradas, se van haciendo preguntas más abiertas y más
generales. Esto nos ayuda en aquellas entrevistas en las que el interlocutor no está a favor de
la implantación de un nuevo sistema.
2. Deductivo. A partir de preguntas abiertas y generales, se va concretando el tema.
3. Combinando los dos modos anteriores.
· Cuestionarios
Se utiliza cuando no es posible realizar entrevistas. El tratamiento que reciben los cuestionarios es similar al de las entrevistas. Se realizan preguntas de respuesta abierta y otras de
respuesta cerrada, de tipo Sí/No, con valoraciones puntuables de 0 a 10 o estimativas: muy
bueno, bueno, malo, etc. Las respuestas valorables tienen el inconveniente de introducir
elementos subjetivos en la información.
Tarea 2: Identificación de los usuarios participantes
Los objetivos son:
· Identificar a los responsables de cada una de las áreas o unidades implicadas, para lo cual se
realizará una descripción general del proyecto, de cada unidad afectada, del representante de
usuarios, del equipo de desarrollo, del área técnica, de los controles de calidad y del equipo
de desarrollo.
· Identificar a los principales usuarios implicados, para lo cual tendremos en cuenta aspectos
como el conocimiento de las funciones que se van a automatizar, la repercusión del nuevo
sistema sobre los usuarios y las implicaciones legales del nuevo sistema.
· De los participantes se han de anotar datos de interés como los siguientes: nombre y
apellidos, organización y área a la que pertenece, puesto que ocupa, teléfono de contacto,
disponibilidad horaria, localización de su puesto de trabajo, etc.
El producto a obtener es una lista o fichero de usuarios participantes, de responsables y del
personal técnico de las áreas afectadas.
Las técnicas necesarias son entrevistas y reuniones con los jefes de personal o responsables
de las distintas áreas afectadas. A continuación, se va a explicar cómo realiza ficheros de
datos referentes a los participantes y cómo organizar reuniones.
· Ficheros de datos de participantes
Tablas de datos. Es necesaria la confección de una tabla, en la que consta toda la información
disponible sobre los participantes en el proyecto. Los dato a incluir por cada uno de ellos son:
nombre y apellidos, lugar de trabajo (provincia, población, dirección, planta, despacho),
teléfonos de contacto con extensión fax y correo electrónico, disponibilidad horaria, área
funcional en la que trabaja departamento, sección, cargo que ocupa en la organización,
identificación de superior jerárquico, tareas que desempeña en la organización, nivel de
implicación en el proyecto, tareas que desempeña en el proyecto o información que puede
aportar.
Si se desea se puede crear una tabla de seguimiento en la que se almacenen datos de citas,
reuniones, entrevistas y correos electrónicos enviados.
Contactos (correo electrónico). Se puede ahorrar tiempo sise emplea el correo electrónico, email, evitando así el envío físico de papel. Esto nos permite crear fichas de contactos que se
distribuyen en grupos facilitando el envío masivo de comunicaciones.
Organigrama. Se puede confeccionar un organigrama de participantes en el proyecto de
forma jerárquica comenzando por el responsable del proyecto y continuado por los
responsables de áreas incluidos los usuarios para que resulte fácil identificar a cualquier
persona que participa en el desarrollo.
En la parte inferior del organigrama se sitúan los usuarios del sistema actual y aquellos que
han de recibir formación una vez termine el desarrollo del sistema. Por cada una de las
personas que aparecen en el organigrama se anota su identificación, área funcional asignada
y tareas a desarrollar en el análisis.
· Reuniones
Para la especificación de requisitos del sistema es conveniente realizar varias reuniones en las
que se intentará especificar algunos, tal vez todos, los requisitos del sistema. Se tienen que
llevar preparadas con un guión de trabajo
2.2. Actividad 2: Identificar y definir requisitos
Se planifican y realizan todas las entrevistas necesarias Son los usuarios identificados en la
actividad anterior para comprender de forma completa el diseñó de la aplicación. Las
entrevistas dentro de cada área se realizan Son los responsables, que aportará visión global, y
son los usuarios, que aportarán una visión detallada de cada o¿ específica dentro del área.
Esto permite, entre otras cosas, realizar una descripción del sistema actual, identificar los
problemas existentes y, por último, comenzar a elaborar los requisitos c nuevo sistema debe
satisfacer.
Se debe estudiar el funcionamiento actual del proceso que se va a autora para localizar faltas
y defectos, además de diseñar un catálogo de requisitos que lucieran a medida que se
progresa en el desarrollo del sistema. No hay que lo que los requisitos deben ser tangibles y
detallados y que sobre las medidas de magnitudes se establecen los controles de calidad.
Tarea 1: Planificación y realización de entrevistas
Los objetivos son:
· Confeccionar un calendario que permita planificar las entrevistas a realiza los responsables
de área y Son los usuarios incluyendo fecha, hora, lugar, duración prevista de la entrevista y
guión de la misma.
· Enviar con antelación suficiente el guión de la entrevista y los Cuestionarios previos a los
participantes para que puedan preparar y aportar la documentación relacionada con los
aspectos más importantes a tratar.
· Realizar la entrevista y obtener la documentación con los datos de interés
· Documentar los requisitos identificados con las prioridades que les otór los usuarios.
El producto que se va a obtener es el plan de entrevistas y el catálogo de requisitos del
sistema.
Especificación de requisitos
Hay dos tipos de requisitos: funcionales y no funcionales. Los funcionales describen el
comportamiento esperado del sistema, mientras que los no funcionales describen las
piedades del sistema.
Los requisitos no funcionales se pueden clasificar en restricciones, requisitos de
funcionamiento y manejo de excepciones. Las restricciones limitan las posibilidades de
trabajo. Los requisitos de funcionamiento se refieren a las especificaciones de di! por
ejemplo: a tiempos de respuesta ó a la ocupación de memoria, pero no al diseño ficheros. El
manejó de excepciones es todo aquello que tenga que ver con el cómo miento no deseado
del sistema. En el Cuadró 3.1 se muestran las características se espera que posea una
especificación. En el Cuadro 3.2 se caracterizan los principales defectos que aparecen en el
diseñó de especificaciones.
Catálogos de requisitos
Al término de la especificación de requisitos se elabora un catálogo de requisitos separando
las especificaciones funcionales de las no funcionales y estructurándolas de fe jerárquica en
cada grupo, desde las más abstractas hasta las más concretas.
El catálogo de requisitos es un documento que aporta información necesaria el desarrollo
adecuado del sistema. Las reglas de formación ya están explicadas, o que queda definir la
estructura del catálogo.
Cuadro 3.1. Características de una buena especificación de requisitos
Completa
Aunque puede haber omisiones, hay que intentar documentar todos los
requisitos para conseguir una especificación completa.
Consistente
No puede haber requisitos contradictorios. Si los hay, se seleccionan ambos y
se hacen verificar por el cliente para elegir el correcto o comprobar si falta
alguna condición en la especificación de uno de ellos.
Concisa y clara
Las especificaciones de requisitos han de escribirse con frases breves y sencillas
de entender.
No ambigua
No puede haber diferentes modos de entender la misma especificación por
distintas personas.
Verificable
Cada especificación ha de ser comprobada por el cliente para comprobar que
es correcta.
Cuadro 3.2. Principales defectos que aparecen en el diseño de especificaciones
Trivialidades
Son todos aquellos requisitos obvios, de los que no es necesario hacer una
descripción. Por ejemplo, el sistema funcionará bajo un determinado sistema
operativo (no podría ser de otra manera) y en un entorno amigable (nadie desea
trabajar en un entorno complicado y no intuitivo).
Ambigüedades
Hay que evitar que las frases tengan más de un sentido posible, para ello se utiliza el
lenguaje natural, haciendo que en cada una de ellas aparezca el sujeto de cada
verbo y no dando nada por entendido, a no ser que sea trivial.
Omisiones
Para evitar omisiones en especificaciones fundamentales hay que plantear
adecuadamente las entrevistas, las preguntas de los cuestionarios y estudiar la
documentación recibida.
Las directrices
No deben aparecer en una especificación de requisitos, aunque sí deben aparecer
las restricciones, los límites y los valores permitidos para cada especificación.
de diseño
e implantación,
lo que hay
que hacer
En el Cuadro 3.3 se muestran algunos ejemplos de requisitos.
Para imprimir el albarán, tres copias, han de estar ya elaborados y empaquetados
todos los componentes del kit (tarea a realizar de tipo funcional).
Los viernes, en administración, se imprime un listado de pedidos pendientes de
distribución que ya contienen albarán (tarea a realizar de tipo funcional).
Junto con el listado de pedidos pendientes de distribución se imprimen las etiquetas
de identificación de pedidos pendientes de distribución (funcional).
El listado se envía a distribución y las etiquetas a fabricación (funcional).
La fecha de nacimiento de un empleado no puede ser menor que la fecha actual
menos 16 años, según la ordenación laboral vigente (no funcional, restricción).
Cualquier salario ha de estar comprendido entre “x” Euros y “z” Euros (no funcional,
restricción).
Se pretende aprovechar un ordenador (no funcional, de software) que funciona bajo
Windows 98 (no funcional, de hardware).
Cualquier producto software que se emplee en el diseño de la aplicación ha de ser de
Microsoft, para asegurar una mayor compatibilidad entre ellos (no funcional, de
sistema).
Cuando se produzca un error se ha de terminar el programa o rutina que lo ha
generado. La línea en que se ha producido, el ordenador que ejecutaba la aplicación,
la identificación del usuario y las tablas de datos abiertas se almacenarán en un
registro de la tabla errores (no funcional, excepción).
Los distintos tipos de requisitos a incorporar en el catálogo son funcionales (la que ha
soportar el sistema) y no funcionales. Dentro de estas últimas se distinguen
- Restricciones (limitaciones impuestas por el cliente).
- De funcionamiento:
Del sistema (lenguajes, equipos, etc.)
Requisitos software.
Requisitos hardware.
- Manejo de excepciones (comportamiento no deseado del sistema).
Por cada una de las especificaciones se puede incluir, si se considera necesario, fecha de cada
especificación, quién la ha descrito, origen de la especificación: entrevista con...,
documento..., cuestionario... y si ha sido comprobada por el cliente.
La técnica necesaria es realizar entrevistas con los responsables y usuarios áreas funcionales o
departamentos afectados.
Tarea 2: Identificación de problemas y necesidades
Los objetivos son:
- Representar gráficamente el funcionamiento actual del sistema. Identificar los flujos de
información, las funciones que realiza.
- Identificar las entradas, salidas, los almacenamientos de información, las comunicaciones
con otras unidades.
- Identificar los objetivos que debe cubrir el sistema nuevo.
- Identificar los archivos y documentos que serán fuentes de información.
- Estimar los costes de explotación actual: tiempos de ordenador, operaciones tiempo de
usuario, mantenimiento y mejora de programas.
- Evaluar la información producida por el sistema actual, para detectar nuevos requisitos que
deba satisfacer el nuevo sistema.
El producto que se va a obtener es:
- Un modelo físico del sistema actual.
- Una lista de problemas y necesidades del sistema actual. Un catálogo de requisitos del
sistema con sus prioridades.
La técnica necesaria consiste en realizar entrevistas con los usuarios y con el personal técnico.
3.3. Actividad 3: Estudiar alternativas de construcción
En esta actividad se establecen las diferentes alternativas de construcción del sistema
teniendo en cuenta los requisitos identificados anteriormente. Una vez establecidas, se
comparan entre sí y se selecciona la más adecuada.
Algunas de las soluciones pueden exigir cambios en la organización o en las estructuras, por lo
que hay que evaluar su impacto, así como su viabilidad económica y realización dentro de los
plazos propuestos.
Tarea 1: Definición de alternativas
Los objetivos son:
— Plantear las diferentes alternativas de solución conjuntamente con los usuarios. Estas
deben ser consistentes con los requisitos identificados. Se siguen los siguientes pasos:
· Identificar los procesos manuales y automáticos.
· Determinar la naturaleza de los procesos automáticos (en lotes, interactivos, de consulta, de
lectura).
· Representar cada alternativa mediante un diagrama de flujo de datos hasta el nivel de
función.
· Estudiar opciones de automatizar procesos manuales junto con la reforma de los procesos
automáticos.
· Diferenciar claramente las distintas alternativas, describiendo todas ellas con el mismo nivel
de detalle.
— Estudiar aquellos productos que existen en el mercado que puedan considerarse como una
alternativa, incluyendo de cada uno la siguiente información:
· Cumplimiento de los requisitos.
· Estimación del esfuerzo de implantación.
· Coste del producto.
· Estándares.
· Entorno tecnológico.
Los productos que se van a obtener son:
— Descripción de alternativas, incluyendo:
· Modelo lógico de procesos, los diagramas de flujo de datos necesarios.
· Descripción de procesos manuales y automáticos, miniespecificaciones.
· Diferencias con las demás alternativas.
— Información de productos existentes en el mercado.
La técnica que se necesita emplear es el diagrama de flujo de datos.
Tarea 2: Selección de una alternativa
Los objetivos son:
— Identificar las ventajas y desventajas de cada alternativa obteniendo información sobre:
· Facilidad operativa.
· Complejidad técnica.
· Plazos requeridos para la implantación.
· Recursos necesarios.
— Para cada alternativa se deberá hacer un estudio de:
· Costes y tiempo estimado de desarrollo.
· Costes estimados de personal.
· Costes de tiempo de ordenador.
· Costes de equipos físicos adicionales.
· Costes de implantación.
— Detallar los beneficios de cada alternativa:
· Beneficios de usuario.
· Beneficios técnicos.
— Seleccionar la solución más adecuada teniendo en cuenta:
· Funcionalidad.
· Impacto en la organización: qué hay que modificar y cuáles son los tiempos de adaptación.
· Evaluación costes/ beneficios.
La decisión de selección de la alternativa será realizada por el Comité de Dirección del
Proyecto, asistido por el equipo del proyecto.
Los productos a obtener son:
— Descripción de cada alternativa.
— Descripción detallada de la alternativa seleccionada y motivos de su elección
Las técnicas que se necesitan son el análisis coste/beneficio y las entrevistas Comité de
Dirección.
· Análisis económico
La información esencial de un estudio de implantación de un sistema informático es el análisis
de costes/beneficios, es decir, la justificación económica para un sistema. Para que el análisis
de costes/beneficios sea eficaz hay que realizarlo antes del desarrollo del proyecto, durante el
mismo y a su término. Se puede dividir en dos tipos de análisis: de costes y de beneficios. La
comparación entre ellos permitirá tomar una decisión, sobre su viabilidad. En el análisis de
costes/beneficios intervienen factores difíciles de cuantificar, como el tamaño del proyecto,
los beneficios esperados, las mejoras en la calidad del diseño o la satisfacción del cliente.
Beneficios. Se agrupan en tres categorías:
· Beneficios derivados de la reducción de costes operativos. Puede suceder que intervenga
una menor cantidad de empleados o se produzcan menos errores. Dentro del entorno del
sistema a implantar se producirán beneficios derivados del incremento de la velocidad en
tareas de cálculo, impresión, búsquedas y almacenamiento de información, lográndose una
efectiva reducción de costes y mayor precisión.
· Beneficios operativos. Son los derivados de la reducción de tiempos de gestión y
planificación. A este nivel también se produce un mayor rendimiento en la capacidad de
análisis, de control de procesos y de gestión de recursos.
· Beneficios intangibles. Son difíciles de cuantificar y deseables por la empresa: mejora en la
calidad de los productos, mejora de su imagen, mejora en las relaciones con los clientes,
mejora en las comunicaciones entre áreas funcionales o de departamentos.
Costes (viabilidad económica). Los costes de un sistema de información para una empresa se
agrupan en cuatro categorías:
— Costes de elaboración: costes de consulta, de alquiler o compra de los equipos, de su
instalación, de modificación de equipos: aire acondicionado, costes de capital, de gestión y de
personal.
— Costes de puesta en marcha: costes del sistema operativo, costes de instalación de equipos
de comunicaciones, costes de personal de puesta en marcha, costes de interrupción del
trabajo del resto el personal.
— Costes relacionados con el proyecto: adquisición del software de programación,
modificaciones del software, costes de personal y gastos generales, costes de documentación
y formación del sistema y de su instalación. El coste por abandono de un proyecto en fases
tempranas de su desarrollo es menor que en sus etapas finales.
— Costes del proceso: mantenimiento del sistema, suministros, depreciación de hardware,
personal.
Documentación del análisis de
requisitos
Al conjunto de documentación asociada al módulo de análisis de requisitos del
sistema se le denomina documento de especificaciones de diseño. De acuerdo con las
especificaciones de Métrica, este documento está formado por los siguientes
elementos:
Portada (Nombre del proyecto, Nombre del autor y fecha de inicio)
1. Índice
2. Descripción del ámbito y alcance del proyecto.
3. Lista de usuarios participantes.
4. Descripción del sistema actual.
4.1. Modelo físico.
4.2. Lista de problemas y necesidades.
4.3. Diagramas de flujo de datos.
5. Catálogo de requisitos del sistema, definiendo las prioridades de cada uno de ellos.
5.1. Funcionales (tareas que ha de soportar el sistema).
5.2. No funcionales:
5.2.1. Restricciones.
5.2.2. De funcionamiento.
5.2.2.1. Del sistema (lenguajes, equipos, etc.).
5.2.2.2. Requisitos software.
5.2.2.3. Requisitos hardware.
5.2.3. Manejo de excepciones.
6. Análisis de alternativas.
6.1. Descripción de la alternativa 1.
6.2. Descripción de la alternativa 2.
6.3. ...
6.4. Descripción detallada de la alternativa seleccionada.
6.4.1. Modelo lógico de procesos.
6.4.2. Análisis coste-beneficio.
6.4.3. Diferencias significativas con las demás alternativas.
A los elementos anteriores se les puede añadir, en la medida que sea necesario, aquellos
definidos al ver el diseño de documentos: sumario, apéndices y, sobre todo, se han de
emplear las técnicas allí descritas.
Los documentos a entregar tendrán las siguientes especificaciones: tipo de letra Arial,
tamaño 12, interlineado 1.5, texto justificado, márgenes 2,5 cm. Se irán entregando por
apartados. Para cada parte indicaremos al final la fecha de inicio y la fecha final de
realización. Las páginas tienen que estar numeradas. En el encabezado y/o pie de página
debe aparecer nombre del proyecto y vuestro nombre como autor. Todos los documentos
tendrán nota y se tendrá en cuenta la presentación y especialmente el contenido.