Understanding the Problem
Knowing what requirements changes are necessary is easy if you pay attention to the elements of your project's Scope, Understanding, Instability, and Traceability (SUIT). Scope is the boundary line separating what is included in a system from what is excluded from the system. Improperly defined boundaries or a lack of prioritization can yield disarray throughout the software development lifecycle (SDLC). Ambiguous, unclear, and/or untestable requirements result in gaps in Understanding. If the system isn't adequately understood, it won't matter how well the boundaries are created and documented. Problems in scope and understanding often result in excessive requirements rework, causing changes to occur faster than they can be maintained, therefor causing Instability.

Problems due to instability are magnified by poor Traceability. Traceability is important for ensuring that all requirements are met and tested, and for doing an impact analysis on proposed system changes. Some small alterations that are easy to implement are all it takes to greatly improve your project's SUIT. These small alterations could bring a well-needed boost to the life of your project. And just like mints, these changes are small, refreshing, and effective.

RequireMINT 1: Assign Risks
Risk analysis resolves scope issues through prioritization. Developers will develop the highest-priority requirements first because it reduces the impact of a schedule reduction. Also, testers will be able to perform risk-based testing by prioritizing test case execution based on requirements risks.

Risks are composed of probability and severity: 

• Probability: the likelihood of an undesirable event occurring
• Severity: the impact of its occurrence

Probability may be ascertained by analyzing defects categorized by function from previous projects. Give those functional areas with high percentages a high-probability rating. Users or managers assign severity levels to these areas. Measurement is based upon the maintenance resources that will be required in the event of a failure, legal consequences, inconvenience, failed government standards, and potential loss of future business.RequireMINT 2: Add a Data Dictionary
A data dictionary lists each application data element and includes the following fields:

• ID: Identifier
• Name: Element name
• Definition: Brief description
• Type: Data type
• Format: Allowable number of characters and default values
• Condition: Special circumstances related to the display of the field

Requirements related to data entry fields are often neglected for fear of excess documentation and verbiage. The maintainable, tabular format of a data dictionary helps eliminate this fear, resulting in the omission of fewer requirements, thus reducing scope issues. The unambiguous nature of data dictionaries also contributes to improving the clarity (understanding) of requirements. Finally, traceability sees benefits from the granular nature of the requirements presented in a data dictionary.

RequireMINT 3: Implement UML Modeling
The Unified Modeling Language (UML) is a notation for creating diagrams that illustrate system behavior and design. To create these diagrams, you must first interview subject matter experts to gather information about work practices and expectations. In the event that subject matter experts aren't available, information may be obtained from existing project documentation. While the benefits are greater if done early in a software development effort, interviews are still beneficial even when conducted in later stages. Notes taken from the interview are used to provide information for the creation of UML diagrams.

Diagrams improve scope by pointing out holes in the system definition, while representing the system in an understandable manner. This more understandable system leads to reduced instability, because the most basic elements of the system documented by the model have fewer discrepancies. Models also improve traceability by providing a common ground for tracing to requirements, code, and test cases.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.RequireMINT 6: Introduce a Change Management Repository and Process
Change management is the process by which changes are suggested, approved, and tracked. Change management requires a repository for change requests and a process for using that repository. The repository may be a single table database (e.g., Microsoft Access) or a spreadsheet (e.g., Microsoft Excel), and should have the following fields:

• Request ID: Identifier
• Date Opened: Request creation date
• Description: Explanation
• Severity: Impact of requested change
• Status: Request status (new, in-progress, closed, rejected, etc.)
• Date Closed: Request completion date
•  Resolution: How the request was resolved

The process should describe who is allowed to enter change requests, how to assign severity levels, and who is responsible for approving the requests. In addition, criteria for approving requests should be described, along with how changes will be communicated throughout the project. A change management process allows for tracking and reduction of instability. Instability is tracked by totaling requirements changes, and is reduced by eliminating error-prone methods of requesting changes, such as word of mouth and email. Another advantage is that change management provides a historical explanation for each change, which reduces redundant questions about why a change was made and may also prevent a change from being improperly reversed.

It is easy to get caught up in a whirlwind of excuses for why something can't be done. In reality, many "impossible" things can be accomplished by making several small changes rather than one big one. By focusing less on instant perfection and more on steady improvement, the changes suggested can help any project alter its ill-fitting requirements process.

Editor's Note: This article is reprinted as a brief overview of its magazine counterpart. PowerPass members can read the entire article online at
www.stickyminds.com/s.asp?F=S8368_MAGAZINE_62

For all other members, check out the supplemental data to the magazine article on Better Software's StickyNotes at
www.stickyminds.com/BetterSoftware/magazine.asp?fn=bisns&ci=60