This is post one of five that shares learning and insight gained during a recent consulting experience.
I started work with a new team that was struggling to understand a small set of requirements. They said they wanted a set of use cases to help them understand the requirements so that they could survey the COTS on the market and identify the best fit. I knew they would probably need more than that, but I just smiled and nodded.
I knew I needed to get a good base knowledge of the problem space before I could create use cases, so I conducted some preliminary reading to educate myself in the business domain, project intent and project history.
Then, I constructed a set of questions to seek clarification and interviewed the original requirement author to educate myself further in the details of the project and the requirements that needed clarification.
I began drawing current state (as-is) diagrams and future state (to-be) diagrams.
I identified scenarios, a primary workflow, and applicable business rules.
I confirmed my understanding with the requirement owner and adjusted my notes.
Then I started articulating user stories, but after six lines, I quickly realized that user stories were not scalable and would not serve the purpose. I know that many BAs like user stories and that the scrum approach to application development espouses user stories, but I am not a fan of them, because I find that they generate too much text that clouds the real logic of the capabilities, business rules, workflows, and permissions etc.
So I began creating a capability matrix;
| Modified Capability matrix |
Role 1 |
Role … |
Role N |
| Capability 1 |
Y |
|
|
| Capability … |
|
Y |
Y |
| Capability N |
|
|
Y |
Again, I realized that I needed greater refinement than the traditional capability matrix would provide.
I discovered that not all capabilities are required. Some are essential. Some are optional.
So I looked in my BA toolkit and surveyed the ranking tools that could be used to provide greater granularity in priority. I settled on the MoSCoW technique (Must, Should, Could, Won’t). I like the MoSCoW technique because it is simple, yet effective, and is easy for everyone to understand.
I merged the concepts of MoSCoW ranking and the capability matrix to make a table that looked like this:
| Modified Capability matrix |
Role 1 |
Role … |
Role N |
| MUST |
|
|
|
| Capability M1 |
Y |
|
|
| Capability M… |
|
Y |
Y |
| Capability MN |
|
|
Y |
| SHOULD |
|
|
|
| Capability S1 |
|
Y |
Y |
| Capability S… |
|
Y |
Y |
| Capability SN |
|
|
Y |
| COULD |
|
|
|
| Capability C1 |
Y |
|
|
| Capability C… |
|
Y |
Y |
| Capability CN |
Y |
|
|
Thus, the top requirements, the MUST requirements, are absolutely essential and any solution that does not have them will not be considered. The middle requirements, the SHOULD requirements, are not essential but are valuable to the client and will be appreciated. The bottom requirements, the COULD requirements, are nice to have.
Put another way, the MUST requirements are mandatory and form the basis of the acceptance criteria, while the SHOULD and COULD requirements can be used in a scoring function to evaluate the relative score/rank of the potential solutions. The scoring function would place more weight on the SHOULD requirements than the COULD requirements.
Would the matrix have had the same meaning if I used the terms Essential, Appreciated, and Nice to Have? Yes.
Will I change the terms if the client doesn’t like the term? Yes.
The terms MUST, SHOULD, and COULD are well understood by CBAP® professionals, but may not be understood by business stakeholders reviewing the document. In this case, I’d rather not be a stickler on theory. I believe it is more important to create a requirements document that is understood by its audience than get stuck on terminology.
Is this a standard tool? No.
Will you see this when you go to google? No… though I did see a reference to using MoSCoW to prioritize user stories.
Is this the first time I have used a hybrid of BA techniques to explain a concept? No.
As a professional, I believe that it is my responsibility to leverage the tools of the profession and the knowledge I have gained through years of experience to resolve the issues and questions of my client. If I need to create a hybrid model or variation of a standard tool in order to address their requirements, I will do so.
Stay tuned for more about the use cases that I created in post two.
This is post one of five that shares learning and insight gained during a recent consulting experience.
I started work with a new team that was struggling to understand a small set of requirements. They said they wanted a set of use cases to help them understand the requirements so that they could survey the COTS on the market and identify the best fit. I knew they would probably need more than that, but I just smiled and nodded.
I knew I needed to get a good base knowledge of the problem space before I could create use cases, so I conducted some preliminary reading to educate myself in the business domain, project intent and project history.
Then, I constructed a set of questions to seek clarification and interviewed the original requirement author to educate myself further in the details of the project and the requirements that needed clarification.
I began drawing current state (as-is) diagrams and future state (to-be) diagrams.
I identified scenarios, a primary workflow, and applicable business rules.
I confirmed my understanding with the requirement owner and adjusted my notes.
Then I started articulating user stories, but after six lines, I quickly realized that user stories were not scalable and would not serve the purpose. I know that many BAs like user stories and that the scrum approach to application development espouses user stories, but I am not a fan of them, because I find that they generate too much text that clouds the real logic of the capabilities, business rules, workflows, and permissions etc.
So I began creating a capability matrix;