WBS (estructura de descomposición del trabajo) vs SRS (documento de especificación de requisitos de software)

"WBS debe contener el 100% del trabajo"... eso significa que debemos considerar todas las piezas de trabajo a realizar bajo el alcance de un proyecto en particular. Los elementos de la EDT se definen en términos de "resultados o resultados"... no todas las acciones/detalles necesarios para producir ese resultado (los detalles minuciosos formarían parte del documento SRS y Diseño de bajo nivel, etc.). Cómo determinar el nivel de avería se describe en http://en.wikipedia.org/wiki/Work_breakdown_structure

El propósito de WBS es definir y organizar el alcance del proyecto total para asignar responsabilidades, asignación de recursos, monitorear el proyecto y controlar el proyecto. Por lo tanto, solo tiene objetivos/entregables del proyecto. Pero en el caso de SRS, el propósito es abarcar todos los requisitos funcionales y no funcionales de todos los objetivos/entregables.

Para un proyecto de nivel pequeño/mediano, generalmente tenemos un documento WBS y varios documentos SRS. Para proyectos grandes hacemos lo mismo después de dividir los proyectos en Módulos.

Espero que esto ayude. Le invitamos con más preguntas específicas. Gracias.

A pesar de la respuesta de Praveen, que es buena, quiero abordar la WBS, la elaboración progresiva y la EVM. Si bien la EDT de cualquier proyecto dado en cualquier industria determinada debe contener el 100 % del producto/servicio que se entregará y, en los niveles inferiores, las acciones requeridas para producir el producto/servicio, no existe ningún requisito de que el 100 % de la EDT sea desarrollado y/o conocido antes de que comience el proyecto. En muchos casos y circunstancias, simplemente se desconoce lo que vendrá a continuación hasta que se realice algún trabajo, que puede incluir el desarrollo de requisitos de nivel inferior o documentos de especificaciones.

La identificación e iteración adicionales de la WBS a medida que se vuelve "más inteligente" son perfectamente aceptables.

La realización de EVM en este escenario también es perfectamente factible. A medida que el trabajo se elabora más, informa los valores de planificación que se utilizarán en la línea base y, bajo control, simplemente procesa un cambio en la línea base y sigue trabajando. En este escenario, puede esperar que el BAC (línea de base al finalizar) fluctúe mientras se produce la elaboración. Si bien esto es normal y se puede esperar, se convierte en un problema de comunicación con las partes interesadas.

EDITAR para responder Comentarios: Con EVM, SIEMPRE tienes esa opción porque, a pesar de la tonelada de incertidumbre con la que entregamos proyectos, el cambio es 100% seguro. Su capacidad de EVM debe ser capaz de manejar el cambio. De hecho, podría crear una "línea base" de presupuesto basada en estimaciones de costos aproximadas de orden de magnitud para el trabajo del cual no está seguro. Cuando obtenga más información, vuelva a estimar o refinar las etapas posteriores del trabajo y, conforme a su proceso de cambio aprobado, ajuste su presupuesto en consecuencia.

Cuando establece una nueva línea de base para el trabajo posterior, no debe sobrescribir el trabajo que ya comenzó, por lo que no estaría alterando una línea de base para el trabajo en curso o ya completado. Está reorganizando el trabajo futuro, en el que no se han acumulado varianzas y reales.

En los casos en los que desee, después de una aprobación formal, volver a establecer la base de un paquete de trabajo existente, existen métodos para hacerlo sin sobrescribir los valores reales y las variaciones acumuladas. Esto puede ser complejo pero, en pocas palabras, cerraría el paquete de trabajo existente y guardaría los datos reales y las variaciones y abriría un nuevo paquete de trabajo con el presupuesto. Hay mucho más que esto, pero es difícil ser muy detallado aquí.

Mark lo dirigió a MIL-STD-881 arriba. Comience allí. También hay otras fuentes que puede encontrar para obtener instrucciones muy detalladas.