RequireMINTS

[article]

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

Dion Johnson's picture Dion Johnson

As a senior test consultant and managing partner for DiJohn IC, Inc. and advisor to the Automated Testing Institute, Dion Johnson provides IT consulting services that focus on the overall system development lifecycle, with particular focus on the quality assurance, quality control, requirements analysis, and automated testing. He has presented at numerous SQE conferences and contributed to StickyMinds.com and Better Software magazine. In addition he is an editor for the Automated Software Testing magazine. Email Dion at dionjohnson@dijohn-ic.com or dionjohnson@automatedtestinginstitute.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!