Al querer desarrollar cualquier sistema se necesita tener en cuenta los requerimientos que el sistema necesite y las técnicas que se necesitarán para poder obtener los requisitos, los requerimientos deben de pasar por un procedimiento de aprobación y dicho proceso consta de 3 partes:
1. Captura
2. Definición
3. Validación
Para la parte de la captura de requerimientos se tienen las siguientes técnicas:
Entrevistas. Las entrevistas le permiten al analista tomar conocimiento del problema y comprender los objetivos de la solución buscada.
Básicamente, la estructura de la entrevista abarca cuatro pasos: identificación de los entrevistados, preparación de la entrevista, realización de la entrevista y documentación de los resultados (protocolo de la entrevista).
La entrevista es la metodología principal a usar para la captura de requerimientos de mi proyecto, ya que obtendría información de primera mano y de la gente a la que está enfocada el proyecto.
Brainstorming (Tormenta de ideas). Consiste en la mera acumulación de ideas y/o información sin evaluar las mismas.
Como técnica de captura de requisitos es sencilla de usar y de aplicar, puesto que no requiere tanto trabajo en grupo como éste.
Además suele ofrecer una visión general de las necesidades del sistema, pero normalmente no sirve para obtener detalles concretos del mismo, por lo que suele aplicarse en los primeros encuentros.
Concept Mapping. Los concept maps (Pan, Zhu & Johnson, 2001) son grafos en los que los vértices representan conceptos y las aristas representan posibles relaciones entre dichos conceptos. Esta metodología parecía ser buena opción para el proyecto pero debido a que el proyecto puede tener ramificaciones muy amplias, entonces los concept maps se harían confusos y poco entendibles.
Sketches y Storyboards. La misma consiste en representar sobre papel en forma muy esquemática las diferentes interfaces al usuario (sketches). Estos sketches pueden ser agrupados y unidos por enlaces dando idea de la estructura de navegación (storyboard).
Esta metodología pareciera ser la ideal pero solo al principio del proyecto. Esto para irse dando una mejor idea de cómo se va a hacer cada parte de la interfaz con el usuario, luego seria innecesaria.
Casos de uso. Aunque inicialmente se desarrollaron como técnica para la definición de requisitos (Jacobson, 1995), algunos autores proponen casos de uso como técnica para la captura de requisitos (Pan, Zhu & Johnson, 2001 y Liu & Yu, 200). Los casos de uso permiten mostrar el contorno (actores) y el alcance (requisitos funcionales expresados como casos de uso) de un sistema.
Esta metodología seria apropiada para el proyecto, en especial en saber cómo sería la interacción del usuario con el sistema.
Cuestionarios y Checklists: Esta técnica requiere que el analista conozca el ámbito del problema en el que está trabajando. Consiste en redactar un documento con preguntas cuyas respuestas sean cortas y concretas, o incluso cerradas por unas cuantas opciones en el propio cuestionario (Checklist). Al parecer es muy similar a la entrevista, así que será innecesario ya que no se obtendría información nueva o relevante a la ya obtenida con la entrevista.
Comparación de terminología: Esta técnica es utilizada en forma complementaria a otras técnicas para obtener consenso respecto de la terminología a ser usada en el proyecto de desarrollo. Para ello es necesario identificar el uso de términos diferentes para los mismos conceptos (correspondencia), misma terminología para diferentes conceptos (conflictos) o cuando no hay concordancia exacta ni en el vocabulario ni en los conceptos (contraste) (Pan, Zhu & Johnson, 2001). Sin duda esta técnica es muy útil para evitar malentendidos, pero es muy probable que el usuario final no llegue a utilizar la terminología que yo necesitaré utilizar, así que bastaría con entender los tecnicismos manejados en el proyecto.
No hay comentarios:
Publicar un comentario