Soluciones Sugeridas vs. Requisitos

Si un cliente describe una forma específica de interactuar con el sistema para llevar a cabo alguna acción, se trata de una solución sugerida, no un requisito.

Información Adicional: Requisitos del Proyecto

La información que no encaje en uno de los grupos anteriores puede representar un requisito del proyecto que no es de software, como puede ser un requisito de dar formación a los usuarios del nuevo sistema.

Roles y Responsabilidades en la Recopilación de Requisitos

Al principio de todo proyecto, el analista de requisitos se centra en entender el negocio para crear un producto que solvente las necesidades del mismo. Además, se debe llegar a un acuerdo sobre las condiciones que ha de tener el producto para que éste sea óptimo.

Importancia de la Comunicación

Los requisitos provienen de las personas. El analista de requisitos será el encargado de hablar con la gente, escuchar lo que dicen y entender lo que necesitan. Es decir, el encargado de llevar a cabo la búsqueda de requisitos será el analista de requisitos. Pero el analista no trabaja solo, sino que los usuarios y otros involucrados en el negocio colaborarán en la recogida de los mismos.

El analista es un traductor. Entiende lo que los usuarios y los involucrados en el negocio están diciendo sobre el trabajo y después traduce este conocimiento en requisitos para el producto.

Tareas del Analista de Requisitos

Las tareas asignadas al analista de requisitos son:

• Observar y aprender el trabajo que realizan los usuarios, y entenderlo desde su punto de vista. Para ello será necesario realizarles preguntas sobre lo que están haciendo y por qué lo están haciendo.
• Interpretar el trabajo. El usuario es el experto en el trabajo que lleva a cabo. Sin embargo, el analista debe filtrar la descripción para obtener la esencia real del trabajo.
• Inventar mejores maneras de hacer el trabajo. Una vez que el analista de requisitos captura la esencia, interpreta lo que el producto debe hacer para satisfacer esa parte del trabajo. Al mismo tiempo, y con la ayuda de los involucrados en el negocio, crea un producto para mejorar el trabajo.
• Registrar los resultados en la especificación de requisitos y en modelos de análisis.

Asegurar la Comprensión Compartida

El analista de requisitos debe asegurarse de que los involucrados en el negocio y él tienen el mismo entendimiento del producto y de que los involucrados en el negocio estén de acuerdo y entiendan que ese es el producto necesario.

Técnicas para la Búsqueda de Requisitos

Existen distintas técnicas para ayudar en la tarea de búsqueda de requisitos. No existe una única técnica que funcione en todas las situaciones. Es decir, otra de las tareas del analista de requisitos será seleccionar la técnica que mejor se ajuste a cada situación.

Involucrar a las Partes Interesadas

Durante esta actividad también deberá tener en cuenta a los involucrados en el negocio. Ellos son conscientes de ciertos requisitos pero no de todos. Existen ciertos requisitos que están tan arraigados a su trabajo, que se han olvidado de que existen.

La razón por la que existen requisitos de los que los involucrados en el negocio no son conscientes, es la falta de conocimiento acerca de ciertas tecnologías o porque nunca han visto su trabajo de la manera en que el analista de requisitos se lo mostrará.

Parte de la responsabilidad del analista de requisitos será sacar a la luz todos estos requisitos. Es importante tener claro que es más barato y efectivo descubrir y capturar todos los requisitos durante esta primera fase de búsqueda de requisitos. Aquellos requisitos que no sean descubiertos durante esta fase aparecerán cuando el usuario empiece a operar con el producto y, por lo tanto, será mucho más costoso hacer los cambios necesarios para acomodar los nuevos requisitos encontrados.

Buenas Prácticas en la Recopilación de Requisitos

Buenas prácticas: algunas buenas prácticas a tener en cuenta durante el proceso de recogida de requisitos:

1. Durante la obtención de requisitos se debe determinar si el alcance del producto está mal definido:
   • Si el alcance es muy grande, se recogen más requisitos de los que realmente se necesitan entregar y el proceso se puede alargar.
   • Si el alcance del proyecto es demasiado pequeño, los clientes presentarán necesidades claramente importantes que no estarán dentro del alcance actual establecido para el producto.
2. Se dice con frecuencia que los requisitos expresan lo que el sistema tiene que hacer, mientras que cómo se ha de implementar la solución es parte del diseño. La obtención de requisitos debería centrarse en el qué, pero hay un área dudosa entre el análisis y el diseño. Se pueden usar “cómos” hipotéticos para clarificar y refinar el entendimiento de lo que los usuarios necesitan.
3. Los modelos de análisis, escenarios y prototipos ayudan a hacer más tangibles los conceptos que se expresan durante el proceso de obtención de requisitos y proporcionan una forma de encontrar errores u omisiones.
4. El proceso de obtención de requisitos en el que están implicados demasiados participantes se pueden volver demasiado lentos. Pueden tener lugar discusiones extendidas de detalles innecesarios y puede ser difícil ponerse de acuerdo en cómo ha de funcionar cada caso de uso. Reducir el número de participantes a las personas que representan los roles principales del proyecto puede ayudar a acelerar el proceso.
5. En cambio, recoger información de demasiada poca gente puede ser también un problema. Puede conducir a pasar por alto requisitos que son importantes para algún tipo de usuario o a especificar requisitos que no representan las necesidades de la mayoría de los usuarios.

Técnicas de Recopilación de Requisitos

Técnicas de recogida de requisitos: Existen múltiples técnicas que pueden ayudar a la hora de recoger los requisitos de un producto. Algunas de ellas son bastante conocidas como por ejemplo: realizar entrevistas, reuniones, cuestionarios… y otras como la utilización de escenarios o prototipos, que quizás no son tan comunes.

Entrevistas

Entrevistas: Esta es una técnica simple y directa. Preguntas libres de contexto pueden ayudar a conseguir entrevistas libres. El objetivo es prevenir condicionar la respuesta del usuario a las preguntas. Entonces, puede ser apropiado buscar requisitos no descubiertos explorando soluciones. La convergencia en algunas necesidades comunes iniciará un repositorio de requisitos para usar durante el proyecto.

Se puede usar esta técnica para:

• Reunir información sobre un sistema existente.
• Determinar requisitos de un sistema nuevo.
• Clarificar especificaciones funcionales.
• Obtener información de entorno sobre la organización del cliente.
• Obtener realimentación respecto a la usabilidad.

Reuniones

Reuniones: se usan para comunicar y promover la solución de un problema en grupo. Esta técnica se puede usar para cualquier tipo de reunión, desde reuniones pequeñas de 2 o 3 participantes hasta reuniones a gran escala. Cuanto más grande sea, mayor deberá ser el nivel de formalidad. La efectividad de la reunión se puede evaluar mediante una encuesta a los participantes.

Formulario de Recogida de Observaciones

Formulario de recogida de observaciones: puede usarse para empezar a analizar un proceso de negocio reuniendo hechos que prueben una teoría u opinión y para empezar a detectar patrones en un proceso.

El formulario de recogida de observaciones más efectivo:

• Contiene información homogénea.
• Muestra datos de forma visual en un formato que revela patrones subyacentes.
• Es fácil de entender y de usar.

Cuestionarios y Encuestas

Cuestionarios y encuestas: Esta técnica se usa cuando la información proviene directamente de la gente, como actitudes, valores, hábitos o preferencias personales para:

• Determinar la funcionalidad de una aplicación existente.
• Para determinar el uso de una tecnología existente.

Usar cuestionarios por mail, de administración personal cuando:

• La gente está alejada geográficamente.
• Haya mucha gente para entrevistar.
• La información a reunir sea simple.
• El anonimato es importante.

Usar cuestionarios en entrevista cuando:

• Se requiera información en profundidad.
• Se quiere comprobar los distintos puntos de vista de las personas.
• Se requiere una tasa de respuesta mayor que la generada por cuestionarios vía mail.

Brainstorming

Brainstorming: o lluvia de ideas implica tanto la generación como la reducción de ideas. Las ideas más creativas e innovadoras resultan con frecuencia de la combinación de ideas aparentemente sin relación. Se pueden utilizar algunas técnicas de votación para priorizar las ideas creadas. Aunque se prefieren los brainstorming en vivo, en algunas situaciones puede ser viable el brainstorming basado en web.

Casos de Uso

Caso de uso: Los casos de uso identifican el quién, el qué y el cómo del comportamiento del sistema. Los casos de uso describen las interacciones entre el usuario y el sistema, centrándose en qué hace el sistema para el usuario. El modelo de caso de uso describe la totalidad del comportamiento del sistema.

Los pasos que hay que seguir para llevar a cabo un caso de uso serían:

1. Identificar actores: los actores son entidades externas que interactúan con el sistema. Identificar actores permite a los desarrolladores entender diferentes perspectivas del sistema. Los actores incluyen usuarios primarios del sistema, usuarios secundarios y sistemas hardware/software externos que interactúan con el sistema que se encuentra bajo desarrollo.
2. Identificar escenarios: un escenario es una descripción narrativa de lo que hacen y experimentan las personas cuando usan el sistema y las aplicaciones. Un escenario incluye tareas primarias del sistema, datos que crean los actores, almacenamientos, eliminaciones, modificaciones en el sistema, cambios externos de lo que el sistema necesita saber, cambios o eventos sobre los que el actor debe estar informado.