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