Obviemos la opción habitual: no vale decir que lo escrito sobre una servilleta de bar mientras tomamos un café son las especificaciones del usuario; ni tampoco vale decir que lo que quiere el usuario es lo que cualquiera sabe ya. Ni responder con que no nos pagan por plantear problemas sino por encontrar soluciones.
Como hemos dicho anteriormente en este blog, existen muchos estándares de documentación (uno de los más reputados es el del IEEE Pierre Bourque and Robert Dupuis, ed (2004). Guide to the Software Engineering Body of Knowledge - 2004 Version. IEEE Computer Society. p. 2–1. ISBN 0-7695-2330-7. http://www.swebok.org). Como todo estándard, lo importante es interpretarlo correctamente; por ejemplo, no hay que tomarlo al pie de la letra sino interpretarlo. Esto no significa reducirlo a un documento vanal sino adecuarlo a nuestras necesidades.
En SoftAuction hemos incluido modelos de especificaciones; las hemos dividido en dos partes:
- Documento Público: permite dar una visión general de las necesidades de la aplicación. Este documento es visible para todos los usuarios con perfil Desarrollador de Software registrados en la plataforma, siendo la información disponible para realizar una primera puja a la baja sobre el proyecto. Incluye los siguientes apartados (obviando el capítulo 1, que es genérico):
- Perspectivas del proyecto: Es una descripción general del proyecto. Esta sección pone el proyecto en perspectiva con otros sistemas relacionados. Si el proyecto reemplaza un sistema existente este deberá ser referenciado y explicado.
- Capacidades generales: Esta sección describirá las principales capacidades y por qué son necesarias. Se explicará el proceso que realiza el software.
- Limitaciones generales: Se describirán todos los elementos que puedan limitar las opciones de los programadores.
- Características de los usuarios: Esta sección deberá describir las características generales de los usuarios afectados por los requerimientos específicos.
- Entorno operativo: Se describirá el entorno real en el que operará el software.
- Hipótesis y dependencias: Se describirán las hipótesis en las que están basados los requerimientos específicos.
- Documento Privado: permite dar una visión concreta de las necesidades de la aplicación. Este documento es visible sólo para tres usuarios ganadores de la primera puja; siendo la información disponible para realizar una segunda puja definitiva a la baja sobre el proyecto. Incluye los siguientes apartados (obviando el capítulo 1, que es genérico):
- Requisitos relativos a capacidades de la Aplicación: que tiene que hacer la aplicación.
- Requisitos relativos a limitaciones de la Aplicación: que limitaciones se imponen a la aplicación
Estos requisitos tienen una tipificación concreta y exhaustiva. Cuando finalice el proceso de desarrollo, serán la base para realizar las pruebas de usuario que permiten demostrar que se ha desarrollado lo que el usuario solicitaba. Lo que no esta especificado no puede exigirse.
Es decir, sobre modelos más exhaustivos, en SoftAuction proponemos un modelo suficientemente detallado sin caer en el extremismo. Pueden utilizarse otros modelos (¿gato blanco o gato negro? ¡que más da! mientras cace ratones...) pero no se permite no especificar. Y se revisa que las especificaciones sean adecuadas.
De esta forma, podemos confiar en que se sabe lo que se quiere y que se puede exigir lo que se ha pedido. Gana la empresa que necesita una aplicación de negocio para optimizar sus procesos y gana el desarrollador que realize un trabajo profesional.