¿Cuál es la forma correcta de crear documentos de requisitos?

Question

En este momento, mi supervisor está creando documentación / especificaciones de requisitos para mí utilizando el software Bugtracking. Esto me parece una idea terrible, todos los requisitos están en estos pequeños boletos y tengo que hacer clic en esta forma web tonta para obtener los requisitos. ¿Qué es una solución de software sana para los requisitos / especificaciones de software?

Para ser claros, estoy construyendo este gran componente de software con bastantes características y estas características se están estableciendo en este software de tracking.

Answer 1

Me sorprende bastante que nadie haya recomendado el uso de un wiki para requisitos de seguimiento.

He encontrado que es un sistema casi perfecto, porque:

• Permite a las personas colaborar en los requisitos y hace que este aspecto sea muy visible;
• Le permite mantener fácilmente los requisitos a medida que avanza el proyecto;
• Puede entrar y ver la historia en cualquier momento, en caso de una disputa "no es lo que acordamos";
• La mayoría de los wikis modernos tienen capacidades de formato decentes, por lo que se ve casi tan bien como un doctor de palabras;
• Puede hipervínculo directamente de sus requisitos a la documentación real;
• Nunca tienes que preocuparte por las personas que trabajan en copias diferentes/obsoletas;
• Los requisitos pueden comenzar a ser tratados como un proceso iterativo, al igual que el diseño/implementación;
• Si los requisitos comienzan a ser realmente grandes/complicados, es fácil dividirlos en páginas/temas.
• La mayoría de los wikis aceptan HTML, por lo que si realmente necesita un formato avanzado, probablemente pueda usar una herramienta como Windows Live Writer.

Dada la opción, casi siempre elijo el método wiki en estos días, es realmente bastante indoloro en comparación con los documentos de palabras anticuados o tratando de meterlo todo en un rastreador de errores.

Answer 2

Siempre uso IEEE STD 830-1998 (práctica recomendada por IEEE para las especificaciones de requisitos de software) como plantilla para mi documento SRS. Ver http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html

El documento final del SRS en sí suele ser un solo documento OpenOffice.org, pero generalmente hay muchas partes constituyentes que se dedican a él, incluidas hojas de cálculo y diagramas.

Por lo general, junto todos estos documentos en un repositorio que pongo en un sistema de control de revisión, como SVN o CVS. Todos los demás analistas de negocios, diseñadores, desarrolladores, probadores, gerentes de proyectos y clientela Tenga acceso a este repositorio, para que puedan leerlo y hacer ediciones.

Recuerde, el SRS es un documento vivo y en evolución. Continuará cambiando y creciendo por algún tiempo. No solo es importante que todas las partes interesadas tengan acceso al SRS, sino que también es importante tener un historial completo de los cambios y la capacidad de revertir estos cambios también, si es necesario. Por lo tanto, un sistema de control de revisión funciona muy bien para este propósito. ¡Buena suerte!

Answer 3

El uso del rastreador de errores para la gestión de requisitos tiene un tendencia a ocultar la falta de colaboración y comunicación dentro de la empresa.

Sin emitir un juicio sobre ningún método en particular:

• Si va a usar la cascada, necesita documentos bien estructurados, precisos y de varias páginas (ni un párrafo que muchas personas suelen escribir como descripción de error). Estos documentos también son imposibles de escribir y mantener en un nivel decente de calidad si el marketing/vendedores (que originan los requisitos) no funcionan bien junto con el personal de ingeniería.
• Si va a utilizar uno de los métodos ágiles, entonces una unidad de requisitos es una historia del usuario, representada por una tarjeta de cuentos. La tarjeta en sí no es un requisito, solo un punto de partida de la conversación.

Una experiencia (breve) de uno de mis empleadores anteriores con el uso de un rastreador de errores para los requisitos fue que dio a muchas personas como una manera muy fácil de dejar de comunicarse por completo. La gente simplemente escribiría un deseo, lo arrojaría en el rastreador de errores y asumiría que eventualmente se haría realidad.

Por supuesto que lo hicieron sin tener en cuenta:

• sus propias calificaciones
• su participación en el proyecto
• conflictos con otros requisitos
• brechas en los requisitos
• costo
• Cualquier consideración técnica
• etc.

Answer 4

Creo que los documentos de "palabra" son la forma incorrecta de los requisitos, por las siguientes razones:

1. No hay forma de "diferir" dos documentos para ver qué ha cambiado.
2. La interfaz de usuario desalienta el uso de un estilo consistente en todo momento. Sí, se puede hacer estilos, pero la mayoría de las personas no pueden ser molestadas por la dificultad.
3. El formato del documento está esencialmente oculto. Claro, hay una especificación para los archivos OLE, que supongo que son los documentos de "palabra", pero Microsoft ha enterrado todo útil bajo toneladas de glatificación, por lo que nadie lo sabe realmente. Tarde o temprano, su nueva y brillante "palabra" no abrirá el documento.
4. No juega bien con otros formatos. Es decir, a menos que use Windows e IE, no tiene suerte si alguien organizó los documentos de un proyecto en archivos HTML con enlaces a archivos de formato "Word". Haga clic en el enlace incorrecto y debe sentarse a través de un largo período de descarga y palabra de arranque, interrumpiendo el flujo de pensamiento. Los hipervínculos de los documentos de "palabra" a otros pueden o no funcionar.
5. "Word" es básicamente para escribir documentos destinados a aparecer en papel. Un objetivo admirable, pero que lo hace menos útil para la visualización en línea.

No tengo una sugerencia alternativa con la que tenga experiencia, pero he pensado en el texto o markdown reestructurado de Python como alternativas.

Answer 5

Generalmente usamos Word, pero en realidad cómo los crea en el software es menos importante que cómo recopila los datos para crearlos y si la persona que recopila la información sabe lo suficiente como para saber cuándo un requisito es demasiado complicado y será mucho más costoso que Un requisito más simple aún no agrega ningún valor real a nadie (como cuando desee que los números de identificación siempre se asignen en orden sin omitirse) o cuándo entrará en conflicto con un requisito existente u otra característica planificada. A menudo, los usuarios reales nunca se habla y hay muchas sorpresas cuando sus gerentes no sabían algo que tenía que hacerse absolutamente y no está en la nueva versión del software.

También podemos usar varios archivos PDF, Excel o Visio también. Todos ellos para el proyecto se recopilan y editan de SharePoint, por lo que podemos ver versiones anteriores si es necesario.

Answer 6

Mantengo una cartera de productos (una por proyecto o producto) que contiene Historias de usuarios. Se pueden almacenar en un software de seguimiento de errores como el que usa. Yo personnaly uso Sobresalir para el atraso y Trac Para la cartera de sprint (probablemente use una herramienta como esa herramienta).

Cuando solo es necesario, creo un Documento de Word que describen la historia del usuario con más detalles y la adjuntan a la historia del usuario. Pero trato de evitar esto dividiendo la historia del usuario en una más pequeña.

Las historias de los usuarios pequeños son más fáciles de administrar (incluida la estimación)

Me gusta el documento de Word porque me permite poner enlaces, formatos de textos, poner tablas, capturas de pantalla y más, y todos pueden leerlo.

Por supuesto, cada historia del usuario se explica en detalle en la sesión de estimación y la planificación de sprint, y siempre estoy disponible para más preguntas cuando el desarrollador decide trabajar en ello. Los comentarios frecuentes utilizando la revisión de Sprint evitan que los desarrolladores hagan algo de manera diferente a lo solicitado por el propietario del producto.

Answer 7

Personalmente, en el pasado he usado documentos de Word, pero he resuelto encontrar una herramienta en el futuro para administrar esto para mí ... especialmente con la capacidad de establecer errores en los requisitos, porque gran parte del tiempo, el error es En los requisitos, no la desviación entre especificaciones e implementación.

Nunca se me ocurrió usar una herramienta de seguimiento de errores, pero tiene mucho sentido.

Por curiosidad, ¿qué es lo que no te gusta?

Editar: una advertencia; Dígale a su gerente que renombra el software de seguimiento de errores. De lo contrario, se supone que todo en él es un error. Tuve este problema político en mi último cliente, donde puse tareas en el rastreador de errores. No es bueno.

Answer 8

Escribí una base de datos de requisitos hace 6 o 7 años para manejar esto. Cada registro de requisitos tiene una descripción breve, una memorando de "definición" y una nota de "notas" (ambas textos ricos, con capacidad para incrustar capturas de pantalla, etc.). También hay otros campos, para el número de proyectos, entregables, el número de secuencia (por lo que se pueden ordenar lógicamente), caso de uso/característica con la que esté relacionado, estimación de tiempo, un campo para la persona que lo maneja, si alguien lo ha seleccionado para la implementación, etc.

También hay un "estado" - "ingresado", porque mientras diseñamos las características; "Aprobado", establecido una vez que se revise un grupo de requisitos y se determina que está listo para implementar; "Implementado", establecido por el programador una vez que piensan que el requisito se realiza, y "validado" una vez que la tecnología de control de calidad está de acuerdo con el programador. (Si la tecnología de control de calidad no está de acuerdo, puede configurarlo en "aprobado" para que el programador lo recupere). Los requisitos también pueden ser "diferidos", "rechazados" o "cuestionado" (lo que significa que la placa de control de cambios debe mirarlo .)

El truco para hacer esto bien es una granularidad razonable. A veces puede tener sentido tener los requisitos de una oración (por ejemplo, "el problema descrito en el problema 12345 es arreglado"), pero en general, los requisitos deben describir todos los aspectos importantes de una característica completa (o una gran parte de una). Por ejemplo, una característica típica de "nuevo informe" tendrá un requisito para un formato de informe (cómo se ve la salida), y un requisito para el diálogo de opciones (explicando los campos, validación, etc.), incluso podría haber un tercio si Hay un generador complejo que abarca los datos, en lugar de solo una consulta fácil o algo así. Además, crearemos un requisito de "ayuda" para el tema de ayuda correspondiente.

Hay grandes ventajas de mantener estas cosas en los registros de la base de datos en lugar de un gran documento. Múltiples programadores pueden estar trabajando en los requisitos al mismo tiempo. Los registros individuales están bloqueados para que solo una persona pueda editar a la vez, pero se pueden abrir y leer mientras alguien más está editando. Sin embargo, la mayor ventaja es que proporciona una documentación fácil de buscar tanto de cuáles eran los requisitos como notas sobre cómo se implementaron. Tenemos más de 25,000 requisitos allí ahora, y podemos encontrar fácilmente todos los requisitos con palabras específicas en todos los campos, o la definición, o notas, o lo que sea, en menos de 10 segundos. (Intente con documentos de palabras más de 6 años).

Puedo ver por qué la gente podría decir que es una mala idea hacer requisitos en un "rastreador de errores", pero supongo que es porque las herramientas apestan, no porque mantener los requisitos en una base de datos de búsqueda es una mala idea.

Answer 9

Yo usé una vez http://www.pivotaltracker.com/ Pero en mi compañía actual estamos utilizando .DOC como fuente de especificación central y faro como la lista de deseos de características combinadas y el seguimiento de problemas. Para mí es difícil hacer que otras personas en el equipo comiencen a usar cualquier otra herramienta cuando estén tan acostumbradas a la palabra.

Answer 10

Si puede seguir la metodología ágil, los siguientes enlaces pueden guiarlo para elegir una buena herramienta de gestión de proyectos ágiles:

• Herramientas de gestión de proyectos ágiles
• Comparación de diferentes herramientas de gestión de proyectos ágiles

Y en serio, pruebe la metodología ágil: predica un enfoque sensible simple, elegante, sin sentido, no juzgado, común en lo que haga, de modo que cada miembro del equipo comprenda y aprecie el papel y el esfuerzo de cualquier otro miembro.

¡Buena suerte!