¿Cuál es el mejor formato de requisitos para las licitaciones?

Las grandes organizaciones a menudo subcontratan proyectos de software. Para ello, crean documentos de licitación, que son utilizados por las empresas de software para realizar una oferta.

Los documentos de licitación deben especificar los requisitos para que las empresas interesadas puedan estimar el esfuerzo necesario. ¿Cuál es el mejor formato para estos requisitos? Casos de uso, historias de usuarios, requisitos funcionales tradicionales, características de alto nivel.

Si escribe casos de uso detallados, necesitará mucho trabajo por adelantado y corre el riesgo de perder detalles que se cobrarán adicionalmente una vez que el contratista los encuentre.

Si escribe funciones de alto nivel, las estimaciones realizadas por las empresas de software no serán precisas y corre el riesgo de que la empresa subestime un proyecto de software complicado.

¿Cuáles son sus pensamientos y experiencias sobre este tema?

Gracias de antemano.

Respuestas (1)

Para una licitación, mirándola desde una perspectiva externa, vería una Lista de funciones completa como el centro. Representa su perspectiva de caja negra en el sistema. Se puede acompañar fácilmente (según sea necesario) de:

  • Un conjunto (potencialmente incompleto) de casos de uso que se refieren a funciones. Tienen un buen potencial de visualización y perspectiva y proporcionan indicaciones para el entorno del sistema y el uso previsto.
  • Un conjunto (potencialmente incompleto) de requisitos funcionales y no funcionales "más allá" (debajo) de la lista de características. Pueden especificar algunos detalles esenciales para el sistema.
  • Garabatos, bocetos, dibujos. Proporcionan información sobre la complejidad esperada de las interfaces de usuario, las dimensiones y similares.
  • Potencialmente todo lo anterior también para subsistemas donde sea necesario.
  • Una lista de normas y estándares relevantes
    • Los requisitos estándar de la organización para tal producto/servicio
    • Modelo de madurez requerido
    • Desarrollo requerido, ejecución, operación, enfoque de cooperación / detalles
    • Estándares de seguridad / seguridad / sociales / ambientales

La creación de estos documentos puede seguir las reglas generales de Gestión de requisitos. Si organiza y vincula los artefactos necesarios correctamente, la gestión de cambios y el análisis de impacto serán sencillos. (Si no vas a revelar todo lo que tienes para la licitación, no es malo que ya miraste un poco más).

Recomiendo enfáticamente no mezclar niveles de requisitos, granularidad y tipo. Aunque el proveedor tendría que arreglar esto, el mantenimiento del lado del cliente será propenso a errores.