In
Project Management, a
Work Breakdown Structure (commonly referred to as
WBS) is a tool intended to
communicate and
organize the
project scope.
It is produced through decomposition, by subdividing the major deliverables and tasks into smaller, more manageable components recursively, until the lowest level tasks are granular enough for the intended purposes.
A WBS could be created to provide a common vision on the division of responsibilities or effort sizing, as well as to state that items not listed in the WBS are outside of the scope of a project.
Each item in the WBS is usually assigned a unique ID, which are collectively known as code of accounts. The lowest level items are known as work packages. The work element descriptions together form a WBS dictionary.
A WBS can be presented both as a diagram, or as a simple list (see below), and is useful and common at the planning (and later) stages of a project.
An example (somewhat artificial* and high-level) of a WBS for a generic waterfalled software project, presented in a list format:
1. FooBar v1.00
1.1 Project Management
1.1.1 Planning
1.1.2 Meetings
1.1.3 Reports
1.2 Product Requirements
1.2.1 Software Requirements
1.2.1.1 Usage Scenarious
1.2.1.2 UML Use Cases
1.2.2 Documentation Requirements
1.3 Software Design
1.3.1 System Architecture
1.3.2 Software Architecture
1.3.3 Database Design
1.3.4 User Interface Design
1.3.5 Object Oriented Design
1.3.5.1 UML Class Diagrams
1.3.5.2 UML Activity Diagrams
1.4 Construction
1.4.1 Software
1.4.2 Documentation
1.5 Testing
1.5.1 System Testing
1.5.2 Acceptance Testing
1.6 Deployment
1.6.1 Installation
1.6.2 Handover to maintenance
* I'm sure there's stuff to nit-pick, but it should be sufficient for illustration. /Msg me and I'll gladly correct it.