La sección de requisitos describe el
problema que se está solventando junto con la solución. Esta sección de la
documentación resulta interesante tanto para los usuarios como para los
implementadores; no debería contener detalles sobre la estrategia de
implementación en concreto. Las otras partes de la documentación del sistema no
serán de interés para los usuarios, únicamente para los implementadores, los
encargados del mantenimiento y demás personal.
- Visión general (hasta 1 página) Una explicación del objetivo del sistema y de la funcionalidad del mismo.
- Especificación revisada. Si le facilitaron especificaciones detalladas del comportamiento del sistema, es probable que encuentre que ciertas partes del mismo se encuentran infraespecificadas o son ambiguas. En esta sección debería aclarar tanto cualquier suposición que haya hecho sobre el significado de los requisitos, como cualquier extensión o modificación de los mismos.
- Funcionamiento (1/2 página). ¿Qué recursos necesita el sistema para una operación normal y qué espacio y tiempo se espera que consuma?
- Análisis del problema (2 - 10 páginas). Una descripción clara del problema subyacente. Esto incluye el modelo conceptual que hay detrás del diseño (y posiblemente la interfaz de usuario), si no se ha tratado ya. El análisis del problema generalmente incluye uno o másmodelos de objeto del problema, definiciones de sus conjuntos y relaciones y una discusión de asuntos complicados. Los objetos en los modelos de objeto del problema proceden del dominio del problema, no del código. Los modelos de objeto deberían incluir tanto diagramas como cualquier restricción textual fundamental, y deberían estar claramente expuestos para una correcta legibilidad. Esta parte también debería describir alternativas que hayan sido consideradas pero que se han rechazado, con razones, asuntos no resueltos o aspectos que no hayan sido totalmente aclarados y que vayan a solventarse más tarde.
Puede que los casos de uso le resulten útiles cuando escriba la especificación revisada y/o el manual de usuario. Un caso de uso es un objetivo específico y una lista de acciones que un usuario lleva a cabo para conseguir dicho objetivo. Un cliente puede, entre otras cosas, examinar la lista de acciones para decidir si la interfaz de usuario es aceptable. Si la colección de casos de uso abarca todos los objetivos deseados por el usuario, el cliente puede tener la seguridad de que el sistema cumplirá con su objetivo.
No hay comentarios:
Publicar un comentario