What techniques can identify missing requirements?

Question

I am working in a Scrum team developing methods and tools for use inside our organization, although our skillset tends more towards statistics and data science than traditional software development.

We have a general idea of the main requirements for the product we are currently developing and have already made progress on them, but we have a lingering feeling that we've missed something obvious. Are there any valuable techniques or frameworks for finding those gaps?

The users/customers/stakeholders will be the primary source of this information, and Sprint Review is a crucial opportunity for achieving this. But are there some ways to run the Sprint Review to better elicit the information from them, or things we can do outside of Sprint Review as well?

Answer 1

Software is never finished, merely abandoned.

Don't remember who said this first, but it's true. After you spend some time in the industry, you inevitably reach the same conclusion. And based on this, you can't say when the requirements are finished either. In fact, the only guarantee you have is that you are missing requirements.

And then the better question becomes "Which requirements are you missing?", because just identifying the lack of requirements isn't enough. For example, some requirements are essential, while others just represent a "nice to have" feature. If you think you are missing requirements, you better think of where you want to spend that time.

This is the problem with a predictive approach of developing software for example. You try at the beginning of the project to sit down and identify everything you need, put all of the details in, cover all the cases, and be afraid you've missed something. You sit down and think hard about everything, so that you don't miss anything.

But that doesn't work.

That's why we have things like Agile and an adaptive approach. Because you can't predict everything, and you can't write complete requirements for that, and you don't know what you are missing. Another reality of the industry is that users don't even know what they want. So even if you write (what you think are) complete requirements, they might be complete requirements for the wrong product. So you still need to sit down and think, but you think about what's the most important thing now, based on the information you actually know (not the one you try to predict), build something, experiment with it, and feed back the results of those experiments as lessons learned about what's still needed.

The only way you can get an idea of "complete requirements" is if you actually build the darn thing and then start using it, until you either abandon it because it serves all your needs for now, or you still need to add things to it (many times the development is abandoned, the software is used, people get frustrated with its limitations, they want a new version, which then gets built, the development gets abandoned, the software is used, people get frustrated with its limitations, they want a new version, and so on, and so on).

Using the software is the best way to determine if you truly have what you need. No matter how many discussions and conversations you have to elicit better information, seeing the thing and actually use it beats talking about it every time.

Answer 2

I'm not entirely sure if that is still "project management", but what has helped me in my developer role is to actually take a day and do the work that my program is supposed to improve.

This yields at least four good kinds of information:

• Sometimes, users of the old program are so set in their ways, that they just want the same. Just better. While actually a completely different approach to the problem altogether might be better. You will never find that out by talking to users of the old program.

• Sometimes, you as a programmer are frustrated by a step in their work process because you know it could be easily automated, while the users of the old program have just accepted it to a degree that they won't even mention it any more.

• Sometimes, when they explain their work to you, you notice that changes in their process and work routine could easily eliminate programs or part of programs they are asking you to write. I once scrapped a full feature of organizing and filing and assigning tasks by just asking why they don't just switch steps in their process around so they don't need this whole coordination software. Turns out they never thought about it.

• You get UX information. I once built a software that had a screen with two buttons, each of them as big as half the screen. It looked horrible. Like a four year old had accidentally clicked around in an UI builder. But it worked. For their purpose it was perfect. Because they were standing in a warehouse with thick gloves on and if they had a normal looking user interface, they would need to take the gloves off, click the tiny button, put the gloves back on and continue working. With the ridiculously huge buttons, they could move the mouse and hit them even with their thick gloves on and never needed to take them off. But that is not information you get when you sit around the requirements planning table with their foreman's boss who has not been on the floor a day in his life.

Are there ways to ponder about the requirements in theory around a table? Probably. You can invent personas and play through all their tasks with your software, but it will still be a theoretical construct brought to you by people most likely one or more steps away from actually doing the work and using the program. The only way to actually get a grip on it is doing it yourself.

So what can you do as a project manager? Well, resource planning is your job. Plan it so a few of your developers have the time to actually experience the thing they should improve.

Answer 3

Taking advantage of the fact that each need is related to other requirements in some way is the key to detecting missing requirements. It's nearly impossible to detect missing needs given a list of shall statements, but it's a lot easier if you give the requirements some structure that takes use of their relationship.

I've worked on enough projects to know that the statistics are most likely telling a true tale about how projects are scoped, defined, and delivered, but they aren't always providing a whole picture of the situation.

Here are some techniques I employ to uncover hidden requirements:

1. Requirements reviews and buy-in
2. Involve all potential stakeholders
3. Invest enough time

The great majority of missing requirements, in my opinion, are overlooked right at the start of the project. If no one on the project forces the business community to be clear about the problem that needs to be solved, or if a business sponsor refuses a Project Manager's standard "why" line of questioning, the entire team is adrift. You run the danger of pursuing rabbits down rabbit holes and uncovering a bunch of irrelevant requirements while ignoring the major, critical requirements that should be there in front of you.

Answer 4

No matter the development methods used or the industry or the product or service being delivered, you don't know what you don't know. This is why we manage risks, involve stakeholders, manage change, and establish open lines of two-way communication. These techniques will uncover requirements eventually and enable the requirements to be met, or requirements purposely excluded temporarily, by the time the customer accepts delivery. I suspect that in nearly every industry, develop or build method, nearly every product or service, the likelihood that 100% of the requirements are known during the collection phase is near zero. So trying to get there is futile. Having the capability to deal with emerging requirements when they are either discovered or formulated is the technique to deal with what we don't know we don't know.

Answer 5

As you are using SCRUM, and setting the stage for your whole company, you should be familiar with the Agile Manifesto, and from that flows the answer to your issue:

• "Individuals and interactions over processes and tools": in practice this means that the Refinement is the time and place where you identify requirements. During the Refinement, the team (including devs, product owner, and stake holders) defines or, well, refines the stories that will be worked on in later sprints. Hopefully the PO already has a good understanding of what the requirements are, but at that time the devs are really asked to dig deep and think along with everyone else to look for things that have not been thought about. You can have as many Refinement sessions per sprint as you want or need, it's part of the regular work. But avoid having too many well-refined stories in the backlog - that's just a sign that you're worrying too much about requirements.
• "Working software over comprehensive documentation": this means that it is very important to get a Minimum Viable Product out as quick as possible. The sprint nature of SCRUM lends itself well to it. Don't waste much time finding every single last requirement, but define the smallest possible subset of req's that make the software (or feature) usable in any fashion at all. Implement that. Hand it over to the testers or eventually the stakeholders, and proceed from there.
• "Customer collaboration over contract negotiation": this goes in the same direction. Draw the stakeholders into your development process by having them back in the next Refinement, so they can tell you what they need changed, or what the next requirement for that now existing MVP is. Again, make those next steps as small as humanly possibly, so it is certain that they can be implemented in a single sprint, and can be delivered with some benefit for the users. Don't treat a huge list of requirements like a contract with the stakeholders.
• "Responding to change over following a plan": This way, you are always in a position to, well, respond in changes to requirements. A big drawback of the old waterfall method was that you'd dream up requirements for months and years, and implement them over the span of more months and years, and by the day you were finished, you could throw everything away since it was obsolete...

Also, when you're at it, check out their 12 principles, which also contain plenty of inspiration to get you on the way.

Answer 6

There is a German company, Sophist who use Neuro-linguistic programming to find missing or ill-formulated requirements. Have a look at page 38 of this document for a flavour of their approach. The key idea is that there are certain forms of words, such as nominalizations, that hide complexity. They give an example on page 40 where a top level requirement, which appears simple, actually conceals at least 4 other requirements or constraints. Their methodology doesn't claim to find missing requirements, but it help you turn "unknown unknowns" into "known unknowns".

I attended a presentation some 15 year ago from one of the principals of Sophist, and she gave an example taken from the original requirements for an air traffic control system: any operator shall be able to initiate a backup at any time. Treating "any" and "all" as words that concealed hidden requirements, she was led to ask questions about the backup process. It turned out that a full backup involved 4 tapes drives, and there were only 6 drives on the system: "any" served as a marker that there were hidden constraints.