The waterfall phases aim to define:
- What to do? - requirements catalogue (mapping to features; features could map to requested features)
- How to do? - high-level architecture and (if needed) detailed design
- Execute! - produce the code, unit tests and reverse engineer the detailed design (if possible)
- Validate! - validate the system against requirements (are we doing things right?)
- Accept! - prove that the system solves the customer problems (to the customer or a customer representative). Are we doing the right things? Deploy (transfer).
- Maintain! - keep the system up and running (and optionally evolve it - new features, changed features)
The core work products (outputs of applying QMS Engineering processes) are:
- SRS (Requirements Spec)
- SAS (Architecture Spec document - High Level Design; could include sections for ICD, DBS)
- SDD (Detailed design which could include a section for the DBS)
- The Code
- STS (and the STR, i.e. the test report)
- ATS (and the ATR)
In order to execute the project you'll also need plans (management documents, outputs of applying QMS Management or QMS Support processes) as well as present reports:
- PMP (Project Management Plan),
- CMP (Configuration Management Plan);
- CIL (identifies the review strategy for each item - and lists external CIs)
- QAP (Quality Assurance Plan)
- SVP (SVVP, and some similar docs could exist due to regulatory requirements)
- SPAR (SW Product Assurance Report - metrics per milestone)
- Milestone Reports
- Progress Reports (per milestone or per time period - e.g. monthly)
- etc.
PS. Remember that not all these documents need to be deliverables: A Deliverable requires extra peer review and formal customer acceptance (and all this takes you away precious time). Typically the project proposal identifies the minimum set of deliverables.
(@2016-10-13: rephrases, expanded acronyms)
