it-swarm-es.com

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

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

Para ser claros, estoy construyendo este gran componente de software con bastantes características y estas características se establecen en este software de seguimiento de errores.

24
patrick

Estoy bastante sorprendido de que nadie hasta ahora haya recomendado el uso de un wiki para el seguimiento de los requisitos.

Descubrí que es un sistema casi perfecto, porque:

  • Permite que las personas colaboren en los requisitos y hace que este aspecto sea muy visible;
  • Le permite mantener fácilmente los requisitos actualizados a medida que avanza el proyecto;
  • Puede ingresar y ver el historial en cualquier momento, en caso de una disputa de "eso no es lo que acordamos";
  • La mayoría de las wikis modernas tienen capacidades de formato decentes, por lo que se ve casi tan bien como un documento de Word;
  • Puede hacer un hipervínculo directamente desde sus requisitos a la documentación real;
  • Nunca tendrá que preocuparse de que la gente trabaje con copias diferentes u obsoletas;
  • Los requisitos pueden comenzar a tratarse como un proceso iterativo, al igual que el diseño/implementación;
  • Si los requisitos empiezan a ser muy grandes o complicados, es fácil dividirlos en páginas o 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, realmente es bastante sencillo en comparación con los documentos de Word anticuados o tratando de meterlo todo en un rastreador de errores.

18
Aaronaught

Siempre utilizo IEEE Std 830-1998 (Práctica recomendada de IEEE para 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 SRS final en sí mismo suele ser un solo documento de OpenOffice.org, pero generalmente hay muchas partes que lo componen, incluidas hojas de cálculo y diagramas.

Normalmente pongo todos estos documentos juntos en un repositorio que pongo en un sistema de control de revisiones , como SVN o CVS. Todos los demás analistas de negocios, diseñadores, desarrolladores, probadores, gerentes de proyectos y ¡clientes tienen acceso a este repositorio, por lo que pueden leerlo y editarlo.

Recuerde, el SRS es un documento vivo y en evolución. Continuará cambiando y creciendo durante 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. Entonces, un sistema de control de revisiones funciona muy bien para este propósito. ¡Buena suerte!

6
A. N. Other

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

Sin juzgar ningún método en particular:

  • si va a utilizar la cascada, necesita documentos bien estructurados, precisos y de varias páginas (no un párrafo que muchas personas suelen escribir como descripción de error). Estos documentos también son imposibles de redactar y mantener a un nivel decente de calidad si el personal de marketing/ventas (que origina los requisitos) no trabaja 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 de usuario, representada por una tarjeta de historia. La tarjeta en sí no es un requisito, solo un punto de partida de la conversación.

Una (breve) experiencia de uno de mis empleadores anteriores con el uso de un rastreador de errores para los requisitos fue que le dio a muchas personas una forma muy fácil de dejar de comunicarse por completo. La gente simplemente escribiría un deseo, lo arrojaría al 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
  • entra en conflicto con otros requisitos
  • lagunas en los requisitos
  • costos
  • cualquier consideración técnica
  • etc.
5
azheglov

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

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

2
HLGEM

Creo que los documentos "Word" son el camino equivocado para los requisitos, por las siguientes razones:

  1. No hay forma de "diferenciar" dos documentos para ver qué ha cambiado.
  2. La interfaz de usuario desalienta el uso de un estilo coherente en todo momento. Sí, se pueden usar estilos, pero la mayoría de las personas no se molestan debido a 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 "Word", pero Microsoft ha enterrado todo lo útil bajo toneladas de tonterías, por lo que nadie lo sabe realmente. Tarde o temprano, tu brillante, el nuevo "Word" no abrirá el documento.
  4. No funciona bien con otros formatos. Es decir, a menos que use Windows e IE, no tendrá suerte si alguien organizó los documentos de un proyecto en archivos HTML con enlaces a archivos en formato "Word". Haga clic en el enlace incorrecto y tendrá que sentarse durante un largo período de descarga e inicio de Word, interrumpiendo el flujo de pensamientos. Los hipervínculos de documentos de "Word" 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 reestructurado de Python o Markdown como alternativas.

2
Bruce Ediger

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 nota de "definición" y una nota de "notas" (ambos con texto enriquecido, con capacidad para incrustar capturas de pantalla, etc.). También hay otros campos, para proyecto, entregable, número de secuencia (para que puedan ordenarse 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 implementación, etc.

También hay un "Estado" - "Ingresado", ya que mientras diseñamos las funciones; "Aprobado", establecido una vez que se revisa un grupo de requisitos y se determina que está listo para implementarse; "Implementado", establecido por el programador una vez que cree que el requisito está cumplido, y "Validado" una vez que el técnico de QA está de acuerdo con el programador. (Si el técnico de control de calidad no está de acuerdo, puede volver a establecerlo en "Aprobado" para que el programador lo recupere). Los requisitos también pueden ser "Aplazados", "Rechazados" o "Cuestionados" (lo que significa que la Junta de Control de Cambios debe revisarlos .)

El truco para hacerlo bien es una granularidad razonable. A veces puede tener sentido tener requisitos de una oración (por ejemplo, "el problema descrito en el número 12345 está solucionado"), pero en general, los requisitos deben describir todos los aspectos importantes de una función completa (o una gran parte de una). Por ejemplo, una característica típica de "informe nuevo" tendrá un requisito para un formato de informe (cómo se ve la salida) y un requisito para el cuadro de diálogo de opciones (explicando los campos, validación, etc.). Incluso podría haber un tercero si hay un generador complejo que procesa los datos, en lugar de una simple consulta o algo así. Además, crearemos un requisito de "Ayuda" para el tema de ayuda correspondiente.

Hay enormes ventajas de mantener este material en los registros de la base de datos en lugar de un documento grande. Varios programadores pueden trabajar en requisitos al mismo tiempo. Los registros individuales están bloqueados, por lo que solo una persona puede editar a la vez, pero se pueden abrir y leer mientras otra persona está editando. Sin embargo, la mayor ventaja es que proporciona documentación fácil de buscar tanto de los requisitos como de 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. (Pruébelo con más de 6 años de documentos de Word).

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

1
SESummers

Usé una vez http://www.pivotaltracker.com/ pero en mi empresa actual estamos usando .doc como fuente de especificación principal y Lighthouse como lista de deseos de funciones combinadas y seguimiento de problemas. Para mí es difícil hacer que otras personas del equipo comiencen a usar otras herramientas cuando están tan acostumbrados a Word.

1
Julia K Szopa

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 personalmente uso Excel para el backlog y Trac para el backlog del sprint ( probablemente use una herramienta como esa herramienta).

Solo cuando es necesario, creo un documento de Word que describe la historia del usuario con más detalles y lo adjunto a la historia del usuario. Pero trato de evitar esto dividiendo la historia del usuario en historias más pequeñas.

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

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

Por supuesto, cada User Story se explica en detalle en la sesión de estimación y en la planificación del sprint, y siempre estoy disponible para más preguntas cuando el desarrollador decide trabajar en ella. Las retroalimentaciones frecuentes que utilizan la revisión de sprint evitan que los desarrolladores hagan algo diferente a lo solicitado por el propietario del producto.

1
user2567

Personalmente, en el pasado utilicé documentos de Word, pero resolví encontrar una herramienta en el futuro para administrar esto por mí ... especialmente con la capacidad de configurar errores según los requisitos, porque muchas veces, el error es en los requisitos, no en la desviación entre especificaciones e implementación.

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

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

EDITAR: una advertencia; dígale a su gerente que cambie el nombre del software de seguimiento de errores. De lo contrario, se supone que todo lo que contiene es un error. Tuve este problema político en mi último cliente, donde puse tareas en el rastreador de errores. No está bien.

1
John MacIntyre

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

Y en serio, pruebe la metodología Agile: predica un enfoque sensato común, simple, elegante, sensato, no jazzístico en todo lo que haga, de modo que cada miembro del equipo comprenda y aprecie el papel y el esfuerzo de todos los demás miembros.

¡Buena suerte!

0
karthiks