#57-Requirements vs. Expectations

This episode will examine the difference between Requirements and the Expectations that drive them, and suggest ways that we can better serve our organization by focusing on the latter.

Transcript

Requirements vs. Expectations

Product development should always be conducted with an eye toward delivering real value. Every action taken by the team should be aligned with the business value that drives requirements, and the prioritization of the portfolio.

However, simply capturing requirements can be misleading. It is also important to understand the expectations that drive the requirements in the first place, because in many cases that is where the real business value lies.

For example, imagine a requirement that says “there is a sensor in our warehouse. Every time that sensor detects a temperature above a certain maximum, an email should be generated to the building supervisor.”

Requirements are often stated this way, indicating the way the system should behave and therefore the way that the automation should be implemented. But sometimes it's important to know why this behavior is needed or, put another way, the expectation that it will satisfy. If we don't ask that question, then we may miss an opportunity to meet that expectation more fully. 

If we capture requirements in use cases, then we might be able to ascertain those expectations. A use case is, generally speaking, stated like this:

“As a building supervisor, I wish to be notified by email when the warehouse is excessively hot, so that I may take action to lower the temperature.”

The “so that I may” section of a use case often captures the expectation that drives the requirement. But use cases can be limiting too if they contain an excessive amount of implementation detail.

I prefer using acceptance tests because they are focused on systemic behavior, and in a future episode I will explain why that can be better if they are structured correctly, but here again that behavior often can be stated in such a way that is limiting on the team's creativity.

Put another way, if the desire of the building supervisor is to be able to address an overheating warehouse in some way, then there may be better ways than sending an email to that person. What if that person has gone home for the day? What if it's the middle of the night? What if the very fact that the warehouse is overheating disables the automation that sends the email? If we instead focus our understanding of the requirement on what outcome is needed, then we are free to brainstorm different ways to achieve that outcome, and some of them may be more advantageous to the stakeholders that we work for.

I would suggest, in fact, that part of the reason we were hired in the first place is to bring our expertise, our experience, and our creativity to the table in order to be able to deliver the maximum amount of value to the organization. But stakeholders often think they know what they want in a very specific way, and so the requirements can be stated from that context. We need to engage collaboratively in a way that teases out the actual expectations that drive the business value we are seeking to deliver.

There are many ways to engender such collaboration. I can only state my preferences here. I prefer that the team engage in the writing of acceptance tests in a very particular way, in the context of performing commonality-variability analysis.

I've spoken a lot about acceptance testing in this podcast, so you can peruse the archive for more details, and I will be writing about the structure of an acceptance test in an upcoming episode.

If you want to learn about commonality-variability analysis, check the transcript for a link to a free video.

CVA Video: 

https://www.projectmanagement.com/videos/872239/Commonality-Variability-Analysis