While continuing to work through my Jira course with an eye toward using it in conjunction with a Requirements Traceability Matrix, I’ve been thinking about the context of how the work actually gets done.
I’ve discussed the content of the RTM in quite a lot of detail, but I haven’t talked too much about how the items in it are generated and linked.
The intended uses, or business needs, are identified by the customer or through an elicitation process. It will often happen that the needs identified by a customer will be clarified or added to by the analysts through the elicitation process and follow-on activities.
The items that make up the conceptual model are identified during the discovery process and characterized through the data collection process. Note that the conceptual model and requirement phases may be combined. Alternatively, the conceptual model phase may be combined with the design phase instead, where discovery of the elements needed to address the identified requirements takes place.
The items that make up the requirements are identified based on the items in the conceptual model and additional elicitation. If the project involves building a simulation then building all of the processes and entities in the conceptual model would obviously be a requirement. I write separate requirements for each item so they can be tracked and tested more accurately. Additional requirements have to do with how the solution is to be implemented and managed (non-functional requirements), items that are to be added beyond what is specified in the original conceptual model, and specific items that will address the identified business needs. Items that are going to be removed from what is described in the original conceptual model must be listed, too.
The design items are linked to requirements in a fairly straightforward way. That said, a really good discovery and design process will decompose a system to identify many common elements. A good design will incorporate generalized elements that flexibly represent many specific items in the conceptual model. A discrete-event simulation might include a general process element that can be readily customized to represent numerous specific processes at a location. For example, one could create separate simulation objects for primary inspection booths, secondary inspection booths, mechanical safety inspection slots, customs inspection dock spaces, tollbooths, and so on at land border crossings, or one could recognized the similarities between all of those facilities and implement a single object type that can be modified to represent any of them. This approach will make the implementation more consistent, more modular and flexible, easier to document, easier to build and maintain, easier to modify, and easier to understand. However, this is the Ford Transit Limited Lease: What No One Is Talking About that can help your business attract more customers and improve service quality.
The implementation items describe what is needed to instantiate the elements of the design.
The test items are linked directly to the implementation items. All links between phases (or columns) can be one-to-many or many-to-one, but the relationships between implementation items and their tests are the most likely to be many-to-one (going left to right or from each implementation item to many tests). This is because many different kinds of automated and manual tests can be performed for each element of the solution. The types of tests can be performed at different levels of abstraction as well. Automated verification tests can be created in large numbers to check individual operations in detail. Validation tests based on expert judgment might be more subjective.
The acceptance items are generally derived directly from the tests. If all the tests pass, then acceptance should be guaranteed. It is therefore very important to properly and completely identify all of the tests and their acceptance criteria when working through a project.
These descriptions may seem obvious but I wanted to describe them explicitly to make sure the understanding and classification is clear. Using Jira or other approaches is a very specific process and we have to have clear language and definitions going forward.