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