RequireMINT 4: Introduce Formal/Semi-formal Peer Reviews
A typical review contains one or more of the following stages:

  • Planning: Review schedule is set
  • Overview: Reviewers are provided with an introduction to the work product
  • Preparation: Reviewers receive the product to review individually
  • Meeting: Reviewers meet to discuss possible defects
  • Rework: Product is revised based identified defects
  • Follow-up: Rework is verified

An incomplete scope is revealed through reviewers pointing out missing, incomplete, or unfeasible requirements. In addition, team members have an early opportunity to clear up any questions or perceived ambiguity, thereby increasing their understanding of the requirements. Identifying defects in the requirements phase reduces system instability by preventing massive requirement changes from reverberating throughout other areas of the SDLC. Traceability is improved by reviewers identifying the testability of a requirement prior to that requirement being finalized.

RequireMINT 5: Document to Avoid Reverse Engineering
The majority of the work that goes into software development often occurs after the initial development and deployment. This is when system maintenance is performed, which includes fixing production defects, adding new functionality, and changing existing functionality. Unfortunately, many of these deployed systems have incomplete or incorrect requirements, making it difficult to understand current system operations and how to properly make system updates. Reverse engineering requirements is the process of obtaining a sufficient level of information about a system based on how the system currently functions as opposed to how it is documented. This process is very time-consuming and often unreliable.

Requirements are often purposefully neglected to prevent feeling obligated to meet them. Instead of discarding requirements, assign them low priority ratings. Failing that, call them "requirements objectives"—non-binding requirements—and document them in an appendix.

Better documentation gives you a more completely defined set of requirements, which translates to a more complete scope. A more completely defined system is also a more understandable system, because there are fewer holes in the system definition. In addition, since the system has fewer holes, instability is reduced, and traceability increased.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.