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 entrevis­tas 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 limitacio­nes 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 alternati­va 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 mar­keting 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 pue­dan 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 conveniente­mente 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 pre­sentar 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 cues­tionarios 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 inconve­niente 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 implica­ció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, e-mail, 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 identi­ficació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
de diseño
e implantación,
lo que hay
que hacer
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.
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 identifi­cació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 Win­dows 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.