Our App’s Requirements Matrix
In the last post, we took the Activities our app needs to support in order to run the event and identified Views [link] that the users would utilize as they execute those Activities. We’ve also previously identified data Entities and Relationships to support the Activities. Now, we need to put them all together to make sure we didn’t miss anything.
In my experience, a Requirements Traceability Matrix (RTM) is a crucial tool to ensure that every business requirement a software application needs to support is addressed. The idea is that all requirements are adequately supported and verified. RTM’s can be incredibly complex and detailed, depending on the size and scope of the project. Many include information regarding test scenarios, stakeholders, and risk.
Our Requirements Matrix (RM) will be much simpler. Since we are working from Activities, Views and data Entities, we can develop a simple matrix to make sure all of those elements are addressed.
We started our RM in the last post with the Activity/View map. Now, we’ll extend that map to produce our RM.
Let’s look at our first Activity, A1. Generate “Save the Date” letters for former sponsors and players, before the tournament. We identified one View, V1. Export contact data for the “Save the Date” mail-merge. Which data Entities do we need?
- E1. Person – has the name and address information for the letter.
- E2. Player – identifies the Person as a Player.
- E4. Sponsorship – identifies the Person as a Sponsor.
Continuing on, we flesh out our RM identifying the Entities needed to support each, Activity. We also assign each row in the matrix a Requirement Number for traceability purposes. Now our RM looks like this (click on the image for a larger view):
Next, we need to verify our RM. In the simplest of terms, verification means that for each Requirement, we’ve identified the Activity, Entities and Views that satisfy the Requirement. We verify there are no gaps, and no duplications.
Right away, we can see that in the Entity column, there are many cells that are duplicates of other cells. For example, the Entities for Requirements R2 and R3 are identical. Moving leftward across the matrix to the Views column, we see those cells are the same. Moving leftward again, we see these two Activities (full descriptions taken from this post):
- A2. Capture and track cash donations, before and after the tournament. We receive cash/check donations directly to the golf tournament. These donations are tax-deductible so we need to track them so that we can issue tax receipts.
- A3. Capture and track prize donations, before the tournament. We receive raffle and contest prize donations prior to the tournament. These donations are tax-deductible so we need to track them so that we can issue tax receipts.
Now, I admit I cheated a little bit. I was a data engineer for too many years not to realize that the only difference between a cash donation and a prize donation was the fact that one was cash and the other a physical object. I could have gone back to the Activities list and merged the two, but for purposes of illustrating RM verification, I chose instead to create a single Donation entity and include the Donation Type attribute:
Activities A2 and A3 are the same Activity, so we can update the RM by canceling Activity A3 and modifying Activity A2. In the updated RM below, we added a column called Entity Groups to identify duplicates and another column for Notes:
Repeating the exercise for the other duplicate Entity Groups, we verify that each activity is distinct. Our final RM is here:
Hurray! We’ve finished the Requirements phase of the Software Development Life Cycle. Next post, we’ll start on the Design phase.
First Post – Links to all Simple FileMaker posts can be found on this page.