Tarea 3: Identificar/revisar los objetivos del sistema

Objetivos

1. Identificar los objetivos que se esperan alcanzar mediante el sistema software a desarrollar.
2. Revisar, en el caso de que haya conflictos, los objetivos previamente identificados.

Descripción

A partir de la información obtenida en la tarea anterior, en esta tarea se deben identificar qué objetivos se esperan alcanzar una vez que el sistema software a desarrollar se encuentre en explotación o revisarlos en función de los conflictos identificados. Puede que los objetivos hayan sido proporcionados antes de comenzar el desarrollo.

Productos internos

1. No hay productos internos en esta tarea.

Productos entregables

1. Objetivos del sistema como parte del DRS.

Técnicas recomendadas

1. Análisis de factores críticos de éxito o alguna técnica similar de identificación de objetivos.
2. Plantilla para especificar los objetivos del sistema.

Tarea 2: Preparar y realizar las secciones de elicitación/negociación

Objetivos

1. Identificar a los usuarios participantes.
2. Conocer las necesidades de clientes y usuarios.
3. Resolver posibles conflictos.

Descripción

Teniendo en cuenta la información recopilada en la tarea anterior, en esta tarea se deben preparar y realizar las reuniones con los clientes y usuarios participantes con objeto de obtener sus necesidades y resolver posibles conflictos que se hayan detectado en iteraciones precias del proceso.

Esta tarea es especialmente crítica y ha de realizarse con especial cuidado, ya que generalmente el equipo de desarrollo no conoce los detalles específicos de la organización para la que se va a desarrollar el sistema y, por otra parte, los clientes y posibles usuarios no saben qué necesita saber el equipo de desarrollo para llevar a cabo su labor.

Productos internos

1. Notas tomadas durante las reuniones, transcripciones o actas de reuniones, formularios, grabaciones en cinta o vídeo de las reuniones o cualquier otra documentación que se considere oportuna.

Productos entregables

1. Participantes en el proyecto, en concreto, los usuarios participantes, como parte del DRS.
2. Objetivos, requisitos o conflictos que se hayan identificado claramente durante las sesiones de elicitación, como parte del DRS.

Técnicas recomendadas

1. Técnicas de elicitación de requerimientos, incluyendo las plantillas de objetivos, requisitos y conflictos.
2. Técnicas de negociación como ganar vs ganar.

Tarea 1: Obtener información sobre el dominio del problema y el sistema actual

Objetivos

1. Conocer el dominio del problema.
2. Conocer la situación actual.

Descripción

Antes de mantener las reuniones con los clientes y usuarios e identificar los requerimientos, es fundamental conocer el dominio del problema y los contextos organizacional y operacional, es decir, la situación actual.

Enfrentarse a un desarrollo sin conocer las características principales ni el vocabulario propio de su dominio suele provocar que el producto final no sea el esperado por clientes ni usuarios.

Por otro lado, mantener reuniones con clientes y usuarios sin conocer las características de su actividad hará que probablemente no se entiendan sus necesidades y que su confianza inicial hacia el desarrollo se vea deteriorada enormemente.

Esta tarea es opcional, ya que puede que no sea necesario realizarla si el equipo de desarrollo tiene experiencia en el dominio del problema y el sistema actual es conocido.

Productos internos

1. Información recopilada: libros, artículos, folletos comerciales, desarrollos previos sobre el mismo dominio, etc.
2. Modelos del sistema actual.

Productos entregables

1. Introducción, participantes en el proyecto, principalmente clientes y desarrolladores, y descripción del sistema actual como parte del DRS (Documento de Requerimientos del Sistema).

Técnicas recomendadas

1. Obtener información de fuentes externas al negocio del cliente: folletos, informes sobre el sector, publicaciones, consultas con expertos, etc.

   En el caso de que se trate de un dominio muy específico puede ser necesario recurrir a fuentes internas al propio negocio del cliente, en cuyo caso pueden utilizarse las técnicas auxiliares de elicitación de requerimientos como el estudio de documentación, observación in situ, cuestionarios, inmersión o aprendizaje, etc.

2. Modelado del sistema actual.

Documento de Requerimientos del Sistema

Las tareas recomendadas para obtener el Documento de Requerimientos del Sistema (DRS) son:

• Obtener información sobre el dominio del problema y el sistema actual.
• Preparar y realizar las reuniones de elicitación/negociación.
• Identificar/revisar los objetivos del sistema.
• Identificar/revisar los requerimientos de almacenamiento de información.
• Identificar/revisar los requerimientos funcionales.
• Identificar/revisar los requerimientos no funcionales
• Priorizar objetivos y requerimientos.

Dificultades para Definir los Requerimientos

• Los requerimientos no son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• Existen muchos tipos de requerimientos y diferentes niveles de detalle.
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.
• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.
• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

Prácticas Sugeridas para Escribir Requerimientos con Calidad

• Mantener sentencias y párrafos cortos. Utilizar voz activa. Utilizar gramática apropiada, ortografía y signos de puntuación. Utilizar términos consistentemente y definidos en un glosario o diccionario de datos.
• Ver si una sentencia de requerimiento está suficientemente bien definida, leída desde la perspectiva del desarrollador.
• Los autores de requerimientos a menudo batallan en encontrar el nivel correcto de granularidad. Evitar largos párrafos de relatos que contienen varios requerimientos. Una guía de granularidad útil es escribir requerimientos que sean probados individualmente. Si usted puede pensar un número pequeño de pruebas relacionadas para verificar la implementación correcta de un requerimiento, está escribiendo probablemente en el nivel correcto del detalle. Si imagina muchos tipos de pruebas diferentes, quizás varios requerimientos han sido agrupados y deben ser separados.
• Tenga cuidado con varios requerimientos que han sido agregados dentro de una simple sentencia. Conjunciones como "y" y "o" en un requerimiento sugiere que varios requerimientos han sido combinados. Nunca utilizar "y/o" en una sentencia de requerimiento.
• Escribir los requerimientos en un nivel consistente de detalles a lo largo del documento. He visto especificaciones de requerimientos que varían ampliamente en su alcance. Por ejemplo, "Un código de color válido será R por rojo" y "Un código de color válido será G por verde" se puede dividir como requerimientos separados, mientras que "El producto responderá a directivas de edición introducidas por voz" describe un subsistema completo, no un requerimiento funcional simple.
• Evitar declarar requerimientos redundantes. Mientras incluir el mismo requerimiento en varios lugares puede hacer al documento más fácil de leer, también hace el mantenimiento del documento más difícil. Las múltiples instancias del requerimiento todas tienen que ser actualizadas al mismo tiempo, no sea una inconsistencia influenciada.

Tener siempre los usuarios en mente.

No cabe duda de que esta aplicación tiene un éxito porque su desarrollo de centro en el usuario final

De modo que concluyo con lo siguiente: "En todo desarrollo de software, debemos tener al usuario siempre en mente".