¿Qué le pedirías a una herramienta de modelado de requisitos?

Nuestro ecosistema software tiene cosas que mejorar, y ahí está lo bueno. Siempre hay ideas nuevas para mejorar el ecosistema y con ello refinar nuestra forma de trabajar. Hace algún tiempo publicábamos un simple plugin de TRAC que nos genera una página wiki con los requisitos que recogemos con la herramienta REM. Evidentemente era una primera aproximación que seguimos usando pero ha llegado el momento de avanzar, de ahí el título de esta entrada. A continuación algunas cosas que considero básicas para una herramienta de modelado de requisitos:

  1. Posibilidad de categorizar y etiquetar los requisitos.
  2. Posibilidad de reutilizar categorías y etiquetas entre proyectos.
  3. Reutilizar requisitos entre proyectos para evitar introducirlos múltiples veces
  4. Relacionar requisitos y definir en qué cosiste la relación (dependencia, ámbito, de interés, etc…)
  5. Representaciones gráficas (grafos) con los requisitos y sus relaciones
  6. Generación de artefactos documentales como entregables según perfiles
  7. Versionado de requisitos
  8. Posibilidad de que los requisitos tengan archivos adjuntos (documentos, audio y vídeo)
  9. Que para usarla sólo necesitemos un navegador web (y quizás ni conexión permanente si usamos algo como Google Gear)
  10. Que gestione correctamente una petición de cambio (quién la solicita, por qué, cómo, cuándo, etc.)

La lista se podría extender muchísimo. ¿Qué le pedirías tú?

6 thoughts on “¿Qué le pedirías a una herramienta de modelado de requisitos?

  1. Los requisitos que pones me parecen bien, pero la pregunta es: ¿tiene que hacerlo todo una sola herramienta?

    Y otra pregunta: ¿cómo encaja en tu proceso de desarrollo?

    La respuesta… quizás en el libro “Bridging the Communication Gap” de Gojko Adzic. La palabra Communication es clave aquí.

    Resumo el libro (y por tanto asume que hay pérdida de información):

    Al principio de cada iteración se reune el equipo (desarrolladores, probadores, analistas, diseñadores… y sobre todo los usuarios, expertos o dueños del producto, como se les quiera llamar a cada uno) en lo que el autor llama “taller de especificación”, donde se escriben y ACLARAN ejemplos de cada una de las funcionalidades a implementar en esa iteración. Estos ejemplos son los requisitos ejecutables que deberán ser satisfechos al final de la iteración, escritos en el lenguaje del negocio, que a partir de ese momento será compartido también por el resto del equipo.

    Y hasta ahí puedo leer… es que no he terminado aún de leer todo el libro… 🙂

  2. Hola José Manuel:

    Que sea una o varias herramientas es una cuestión de diseño, por ahora sólo estoy trabajando en el modelo conceptual y pensando en el diseño de interacción interesante.
    ¿En mi proceso? Pues espero que no sea intrusiva y que se adapte (dentro de unos límites) a distintas formas de trabajar.

    Gracias por la referencia. La pongo en la cola.

    Un saludo

  3. Que tal Manu?

    ¿Qué has pensado sobre la trazabilidad?

    Para mí, poder seguir la pista de los requisitos desde que se definen hasta su satisfacción, pasando por los productos y artefactos relacionados generados durante el proyecto es una característica muy muy deseable, tanto para control de calidad como para acelerar el posterior mantenimiento del producto.

    Un Saludo

  4. Hola Luis:

    Como ya comentaba en un comentario anterior, sobre la trazabilidad tengo que pensar mucho. Las soluciones que he visto por ahora no terminan de convencerme. Realmente, ¿Qué trazabilidad necesitamos? Entre requisitos y tareas que implementan dichos requisitos? Entre requisitos y otros requisitos para conocer el impacto que tienen los cambios? Resulta complicado atenderlo todo con “trazabilidad”.

    Un saludo

Leave a Reply

Your email address will not be published. Required fields are marked *