project-management specifications specs

project management - Plantillas de especificaciones técnicas y funcionales



project-management specifications (8)

Comience de manera simple, y trabaje desde allí. Como esta es su primera experiencia trabajando con esto, use un documento de Word con viñetas. Escríbelo, vuelva a leerlo y proporcione suficientes detalles para que tenga sentido. Para las especificaciones técnicas, es posible que desee guiar al desarrollador hacia una solución, pero para las especificaciones funcionales, el "cómo" debería faltar por completo.

Así que, básicamente, estoy buscando buenas plantillas para escribir especificaciones técnicas y funcionales en un proyecto o solicitud de trabajo.

¿Que usas? ¿Qué tan profundo se obtiene al escribir las especificaciones? Cualquier consejo general adicional que pueda proporcionar será apreciado.

Mi compañía necesita esto mal. Trabajo para un contratista y en este momento no usamos estos documentos en absoluto.

EDITAR: He leído la nota de Joel sobre Especificación indolora , realmente me gustó, pero ¿hay alguna otra opinión? :)

Me gusta este, entre otros: ReadySet .

Él vende una versión pro también.

No es una plantilla, pero Joel ha escrito un par de artículos sobre cómo escribir una especificación funcional. Él también tiene una muestra aquí .

Puedes comprar plantillas de ieee y otros lugares, pero siempre he terminado haciendo las mías.

Para una especificación técnica, " Código Completo " de Steve McDonnell tiene una buena lista de verificación, puede extraer alguna información de eso. En mi último trabajo, acabo de hacer una plantilla de los encabezados de sus secciones, y la ajusté desde allí.

En cuanto a una especificación funcional, lo importante es definir todas las interfaces:

  1. IU (maquetas de pantalla)
  2. Interfaces de software (complementos, etc.)
  3. Interfaces de hardware (si corresponde)
  4. Interfaces de comunicaciones (servicios, correo electrónico, mensajes, etc.)

También debería haber una sección para reglas de negocios, cosas que son importantes desde el punto de vista funcional y que no están cubiertas en ninguna definición de interfaz.

Si desea comprar un libro, los Requisitos de software de Karl Wiegers tienen plantillas para algunos documentos como apéndice. Lamentablemente, estoy en el trabajo y ese libro en particular está en casa. Si alguien lo tiene a mano, es posible que puedan confirmarlo.

En consejos generales;

Estamos implementando un proceso de

1) Declaración de requisitos comerciales (BRS)

2) especificación funcional

3) especificación técnica

El BRS cubre cuáles son los problemas comerciales y cuáles son los requisitos en torno a soluciones, pruebas, seguridad, confiabilidad y entrega. Esto define lo que haría una solución exitosa.

La especificación funcional detalla lo que se necesita, cómo debería verse, qué tan largos deben ser los campos, etc.

Los detalles de la especificación técnica de donde provienen los datos, cualquier código complicado que pueda ser necesario considerar.

El cliente posee los requisitos. Los desarrolladores poseen las especificaciones técnicas, y la especificación funcional es un término medio. Las pruebas se realizan contra las especificaciones técnicas (por lo general, pruebas unitarias) y luego contra las especificaciones funcionales (generalmente pruebas del sistema) y luego contra los requisitos (UAT).

La parte importante de esto (y estamos luchando con) es que los desarrolladores aún tienen que cumplir con las especificaciones funcionales y los requisitos comerciales originales. En realidad, las especificaciones funcionales y tecnológicas están ahí para mayor claridad.

En resumen, mi consejo principal es primero averiguar el proceso que desea implementar. Luego busque el acuerdo de todas las partes involucradas en su proceso propuesto, luego trabaje en las plantillas para que quepan. Las plantillas en sí mismas son solo una pequeña parte del cambio que desea realizar.

Sugeriría echar un vistazo a la plantilla Volere de Roberston aquí . Son parte de Atlantic Systems Guild, junto con personas como Tom DeMarco y Timothy Lister de la fama de "Peopleware".

Como la plantilla está protegida por derechos de autor, no la reproduciré aquí, pero le daré algunos de los encabezados principales:

  1. El propósito del proyecto
  2. Los interesados
  3. Restricciones obligatorias
  4. Denominación de convenciones y terminología
  5. Hechos relevantes y suposiciones
  6. El alcance del trabajo
  7. Modelo de datos comerciales y diccionario de datos
  8. El alcance del producto
  9. Requerimientos funcionales
  10. Mira y siente los requisitos ...

Hay muchos más, pero esto debería darte una idea. La parte más interesante de la plantilla es el shell de requisitos que enumera los requisitos funcionales en un tipo de tarjeta de referencia. Otra vez con derechos de autor, pero realmente valioso.

Mire aquí en el capítulo 9.