Saltar al contenido
Codifíca.me | Desarrollo web | Programación

Documentación de requisitos

24 junio, 2014
framworks javascript

Características generales de la documentación de requisitos

La documentación de requisitos debe ser correcta, sin ambigüedades, completa, consistente, ordenada, verificable y modificable en el caso de nuevos detalles que van surgiendo durante el desarrollo.
Podemos distinguir cuatro tipos de documentación, documentación agil, exhaustiva, formal y no formal.

Documentación Exhaustiva y agil

Para el tipo de documentación exhaustiva utilizaremos el estándar IEEE-830, que es un tipo de documentación muy completa.
Para el tipo de documentación agil no utilizaremos un estándar como el anterior, sino que se hará con apuntes rápidos o metodologías agiles.

Documentación en lenguaje no formal y formal

La documentación que generalmente se realiza utilizando nuestro idioma será documentación de tipo no formal. No obstante, si utilizamos un lenguaje como UML estaremos desarrollando documentación formal.

Documentación exhaustiva y no formal | IEEE-830

Estructura de la especificación de requisitos del estándar IEEE-830
Este tipo de documentación estaría compuesto de la siguiente estructura:
Introducción, objetivo, ámbito,alcance, definiciones, referencias, sinopsis.

Descripción general, descripción del producto, funciones, características de los usuarios, restricciones, requisitos aplazados.

Requisitos específicos, interfaces, funciones, requisitos lógicos , restricciones de diseño, cumplimiento de estandares

Documentación exhaustiva formal | OCL

Se utilizará algún lenguaje formal como puede ser UML, realizando los diagramas UML.
El estándar OCL está vinculado al lenguaje UML

Documentación ágil y no formal

Para realizar este tipo de documentación se suelen utilizar las historias de usuario, ya que nos permite realizar una documentación correcta, basándonos en las historias de usuario.

Las historias de usuario obtienen lo que el usuario requiere del software.

Están formadas, por una descripción corta que sirve para recordar que se quiere documentar ese requisito.

Una serie de conversaciones que sirven para definir y aclarar los detalles.

Y finalmente, unos criterios de aceptación que validarán que el requisito esté correctamente desarrollado.

Entradas relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Comentarios (4)

Interesante, si los jefes de desarrollo muchas veces tuviesen un poco de idea de cómo desarrollar un proyecto y de como gestionar los requisitos, los analistas y a su vez los programadores no tendrían que dar vueltas y vueltas para hacer un mismo código, perdiendo horas y horas y dinero y dinero.

Responder

Hola Webber,
Claro, una buena documentación y gestión de requisitos puede conseguir que el desarrollo sea mucho más efectivo.
Un saludo!

Responder

Bueno,
Yo creo que documentar las cosas es algo que se debería hacer en todos los desarrollos, pero es dificil decirle al cliente que por documentar las cosas bien hechas vamos a tardar x días más de trabajo con el incremento económico que eso supone.
Aunque más tarde el cliente tenga que pagar mucho más por modificar o implementar más cosas ya que no hay documentación sobre lo que se ha hecho.
Saludos

Responder

Hola,
Coincido en que si haces bien las cosas y bien documentadas al final tendrás las cosas bien hechas y podrás mantener el software de una manera más adecuada, pero esto supone un gasto inicial que muchas veces no están dispuestos a pagar las empresas, que luego tendrán que pagar porque les costará más mantener el software y tendrán que invertir más horas en desarrollar nuevas peticiones.

Un saludo

Responder