7.12. Process: Evolutionary Requirements in Iterative Methods
As repeatedly stressed (as it's critical, yet too often ignored) in iterative methods, including the UP, these requirements are not fully analyzed and written near the start of the project. Rather, they evolve over a series of requirements workshops (for example), interspersed with early production-quality programming and testing. Feedback from early development refines the specifications.evolutionary requirements p. 25 As in the use case chapter, Table 7.1 summarizes a sample of artifacts and their possible timing in the UP. Usually, most requirements artifacts are started in inception and primarily developed during elaboration.
Discipline | Artifact | Incep. | Elab. | Const. | Trans. |
---|---|---|---|---|---|
Iteration | I1 | E1..En | C1..Cn | T1..T2 | |
Business Modeling | Domain Model | s | |||
Requirements | Use-Case Model | s | r | ||
Vision | s | r | |||
Supplementary Specification | s | r | |||
Glossary | s | r | |||
Business Rules | s | r | |||
Design | Design Model | s | r | ||
SW Architecture Document | s | ||||
Data Model | s | r |
Inception
Stakeholders need to decide if the project is worth serious investigation; that real investigation occurs during elaboration, not inception. During inception, the Vision summarizes the project idea in a form to help decision makers determine if it is worth continuing, and where to start.Since most requirements analysis occurs during elaboration, the Supplementary Specification should be only lightly developed during inception, highlighting noteworthy quality attributes that expose major risks and challenges (for example, the NextGen POS must have recoverability when external services fail).Input into these artifacts could be generated during an inception phase requirements workshop.
Elaboration
Through the elaboration iterations, the "vision" and the Vision are refined, based upon feedback from incrementally building parts of the system, adapting, and multiple requirements workshops held over several development iterations.Through ongoing requirements investigation and iterative development, the other requirements will become more clear and can be recorded in the Supplementary Specification.By the end of elaboration, it is feasible to have use cases, a Supplementary Specification, and a Vision that reasonably reflects the stabilized major features and other requirements to be completed for delivery. Nevertheless, the Supplementary Specification and Vision are not something to freeze and "sign off" on as a fixed specification; adaptationnot rigidityis a core value of iterative development and the UP.To clarify this "frozen sign off" comment: It is perfectly sensibleat the end of elaborationto form an agreement with stakeholders about what will be done in the remainder of the project, and to make commitments (perhaps contractual) regarding requirements and schedule. At some point (the end of elaboration, in the UP), we need a reliable idea of "what, how much, and when." In that sense, a formal agreement on the requirements is normal and expected. It is also necessary to have a change control process (one of the explicit best practices in the UP) for formally considered and approved requirements changes, rather than chaotic and uncontrolled change.But several points are implied by the "frozen sign off" comment:
- In iterative development and the UP it is understood that no matter how much due diligence is given to requirements specification, some change is inevitable, and should be acceptable. This change could be a late-breaking opportunistic improvement in the system that gives its owners a competitive advantage, or change due to improved insight.
- In iterative development, it is a core value to have continual engagement by the stakeholders to evaluate, provide feedback, and steer the project as they really want it. It does not benefit stakeholders to "wash their hands" of attentive engagement by signing off on a frozen set of requirements and waiting for the finished product, because they will seldom get what they really needed.
Construction
By construction, the major requirementsboth functional and otherwiseshould be stabilizednot finalized, but settled down to minor perturbation. Therefore, the Supplementary Specification and Vision are unlikely to experience much change in this phase.