Ponder for a moment the impact of mints on your life. They provided an extra degree of confidence during some of life's most important moments from job interviews to first dates. Some people may even have a spouse and kids because a mint helped out in a crucial moment. In this week's column, Dion Johnson points out that the requirements improvement techniques called RequireMINTs can similarly impact the life of your software projects because like mints, they are small, refreshing, and effective.
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 | SUIT Elements | |||
| S | U | I | T | |
| 1. Assign Risks | x | |||
| 2. Add a Data Dictionary | x | x | x | |
| 3. Implement UML Modeling | x | x | x | x |
| 4. Introduce Formal/Semi-formal Peer Reviews | x | x | x | x |
| 5. Document to Avoid Reverse Engineering | x | x | x | x |
| 6. Introduce a Change Management Repository and Process | x | |||
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
About the author
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.
