Análisis de requerimientos (parte 2)

TÉCNICAS DE DETERMINACIÓN DE REQUERIMIENTOS

- Conversaciones, entrevistas, reuniones con el cliente. Podemos encontrarnos con los varios problemas:

• con la existencia de diferencias entre los usuarios, obtenemos puntos de vista muy diversos. La idea es la realización de todas las entrevistas posibles para poder contemplar todos esos puntos y analizar mejor.
• los usuarios no suelen tener experiencia o conocimiento del sistema.
• hacernos una idea del sistema, definiendo solo esta técnica, es complicado. Tendremos que utilizar técnicas alternativas para conseguir más información.

FASES ENTREVISTAS

1. Preparación. Determinamos las preguntas que van a hacerse (obtendremos un estudio sobre el dominio del problema), seleccionamos a un subconjunto de personas para obtener el mayor número de información posible, determinamos el objetivo y contenido de la misma y las planificamos.
   
2. Realización. Consta de 3 partes. En la apertura se deja claro al usuario cuál es el objetivo de la entrevista y se aclaran conceptos o notación específica que se vaya a utilizar durante la misma. En el desarrollo, máximo de 2 horas, hemos de mantener el control y dejar que el usuario se explique; hay que evitar monólogos por parte de los entrevistadores. Al final se debe hacer una recapitulación de la información dada por el usuario.
3. Análisis de las entrevistas, extraemos la información recogida por la mi

- Obtener requerimientos a partir de un Sistema de Información (sinónimo de sistema informático) desarrollado. Podemos utilizar esta técnica como complemento de la anterior ya que puede darnos mucha información más útil (en algunos casos que los usuarios no colaboran con datos concretos). Eso si, su problemática radica en sistemas complejos y en sistemas que nunca han existido.

- Obtener los requerimientos a partir del Sistema de Información mismo. Es necesario que los analistas conozcan lo que existe ya en la empresa donde vamos a poner el nuevo sistema. El problema de esta técnica es que tiene un coste elevado ya que se añade a esta fase un análisis de todo lo que ya hay y eso necesita tiempo y más personal que lo haga.

- Construcción de un prototipo. Definimos un prototipo con las características generales del sistema y vamos conociendo los requerimientos en función de las versiones. Es una técnica muy costosa.

- Casos de uso. Se identifican los requerimientos funcionales y no funcionales y se relacionan entre ellos. Nos preguntamos cuales son las funciones del sistema por cada actor (persona relacionada con el sistema).


¿QUÉ SE HACE EN EL ANÁLISIS DE REQUERIMIENTOS?

1. Comprensión del problema mediante la comprensión (valga la redundancia) del software dentro del contexto y la evaluación y síntesis del propio problema (definición de flujos, estructura y contenido de la información, funciones y entendimiento del comportamiento)
2. Modelización del sistema
3. Especificación del sistema mediante una representación formal y comprovación de que lo que ha recogido el analista es lo que realmente necesita el cliente.

Problemática
- Uno de los primeros conflictos con los que nos encontramos es en el momento de decidir que personas podrán darnos la información que necesitamos para plantear las necesidades del cliente. Nos encontramos con que un alto porcentaje de la gente que preguntamos no nos la da realmente.
- Es probable que para una misma función nos encontremos con diferente información de diferentes personas, por lo que se convierte en información inconsistente.
- Podemos encontrar problemas en el momento de integrar nuestro nuevo sistema por culpa del funcionamiento y rendimiento de otros elementos del sistema. Por ejemplo, puedo encontrarme con errores en el momento que decido conectarme a otro software para obtener datos.
- La percepción de los objetivos puede cambiar con el paso del tiempo.
- A medida que crece el tamaño del problema, crece la complejidad del análisis.
- El cliente no suele valorar la etapa de análisis.

Métodos de modelado
Cada método de análisis tiene una notación y un punto de vista propio, pero siempre se tiene que cumplir 3 reglas:

1. Partición. un sistema complejo solo puede entenderse si se divide en partes más pequeñas que se relacionan entre ellas; esto nos permite ver el problema en pequeñas partes y luego, de su relación, llegar a tener una visión general de él.
2. Abstracción. nos debe permitir ver el sistema en términos generales, sin tener en cuenta cómo generamos entradas y salidas del sistema.
3. Proyección. permite definir el problema teniendo en cuenta los diferentes puntos de vista.

Especificación de requerimientos
Es el resultado del análisis. Se trata de un documento que sirve de contrato entre el desarrollador y el cliente, y de base de trabajo para el diseñador.

- Explica qué hace el sistema, y no el cómo lo hace.
- Debe ser un documento comprensible para cualquier persona. Se precisa la explicación de los tecnicismos en el caso de que los haya.
- Los conceptos a explicar deben estar claros.
- La información debe estar completa, debe recoger todos los requerimientos y a su vez, estos deben de ser verificados por el cliente.
- No debe haber requisitos contradictorios.
- Debe ser un documento fácilmente modificable.
- Debe tener un índice.
- Deber poder ser usable durante el diseño y la implementación, y el mantenimiento del sistema.

- Un estándar de este documentos es el de ANSI/IEEE.

- Posteriormente el documento debe ser revisado y validado en dos niveles: macroscópico (especificación completa, consistente y precisa) y detallado (precisar temas concretos).