2. Interactive prototypes.
These can include mock-ups and proofs of concept implementing a slice of the product, wireframes for custom user interface or website design to understand how users will interact with it, and evolutionary prototypes that provide an architectural foundation for the product
3. Software Requirements Specification (SRS).
This document, used as the basis for coding, is created to record in detail all functional and non-functional requirements. Its purpose is to outline all possible behaviors of the system under various conditions, data requirements, requirements for external interfaces, including user interfaces, and the systems’ desired quality attributes like performance, security, and usability. It may incorporate visual product models (context diagrams or environment maps) to provide a more clear perspective or analysis models (data flow diagrams, feature trees, state-transition diagrams, etc.)
4. Architecture design
, built on the basis of the product’s functionality, quality attributes, and constraints
5. Scope baseline
that consists of a scope statement, WBS (work breakdown structure or a hierarchical decomposition of the total work to be done to create the deliverables), and WBS dictionary
6. Project schedule
created based on the scope baseline, activity duration estimates, resource requirements, resource calendars, and the risk register
7. Project budget estimates
, driven by the scope baseline, activity cost estimates, project schedule, and risk register
This upfront effort to discover and engineer the product’s requirements is truly massive and hard, so it’s critical to find a vendor with enough experience and capabilities to handle it properly (you can drop us a line
if you choose to go waterfall).
There’s one more thing to remember. While giving you the most predictability possible, the whole plan created in waterfall mode will still rely on many underlying assumptions. As a famous quote goes, planning is still guessing. And as godfathers of software development best practices ruthlessly add, “you’re never going to get perfect requirements.”
The truth is, business requirements may change, either because of evolving priorities or because business people just haven’t thought through in detail what they actually need. Your developers may stumble across unforeseen technical challenges weeks or even months after the start of the project. Also, integration, security, or quality problems (if any) can be uncovered only in testing, which is not possible in waterfall until a stable product has been built.
This brings us to the next alternative where such risks are mitigated.