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 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.
|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.