9

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?

2
  • Phrasing such as "What techniques can identify missing requirements?" contributes more to the problem than to any Answer. Consider asking these questions: What is the situation? Where are you now? What is to be achieved? Where would you like to be? How might that be achieved? What could get you there? What supplies or skills might be needed to achieve that? How might your guys combine and control their efforts? What requirements did that list miss? Feb 10 at 23:55
  • Isn't this what planning test cases is for? If the end users are aware and happy that the test cases cover off all the possible functionality, then that should flush anything out. If anything is missed because they failed to review these properly then that's on them. Feb 23 at 10:43

6 Answers 6

10

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.

2
  • 1
    This is definitely a good reminder of the entire point of Agile development, and thank you for pointing out the Kano model as well. I suppose that if a requirement never gets identified then in some sense it was never actually required?
    – ConMan
    Feb 10 at 23:27
  • 2
    @ConMan: I suppose that if a requirement never gets identified then in some sense it was never actually required? Yes, something like that. A requirement is something that first has to be a need, a sufficiently strong need for you to spend the time to elaborate it and turn it into a requirement. If you don't identify something, most likely the need for it wasn't so strong to begin with.
    – Bogdan
    Feb 11 at 20:54
20

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.

5
  • 2
    What does happen: 1. Users have asked for a feature in the past and were told it's impossible. And as a developer you don't see what's even remotely difficult about that feature. 2. (Related) Users think that a feature must be difficult and don't ask for it. Or they think it must be very easy and it is actually hard. So make clear they should ask for anything - some things might not be accepted after they estimate the value of a feature and you evaluate the cost, but if you don't ask, you definitely won't get.
    – gnasher729
    Feb 12 at 14:54
  • 2
    And 3. Users want to use the old methods and don't want to learn, so they come up with all kinds of useless and hard to fulfil requirements, to prevent new software from being built. If you don't catch that then you are in trouble.
    – gnasher729
    Feb 12 at 14:56
  • @gnasher729: I heard a great example of this in several talks by some ThoughtWorks guys. They were rebuilding some corporate system A, including a reporting feature. Very late in the development, a request came to match the report format of the old system exactly. Unfortunately, this would have meant a significant amount of work because … $REASON. When they more closely investigated this change request, they found that the ultimate reason was that data from A needed to be transferred to system B which was not part of the contract and had never been mentioned until then. It turns out that … Feb 12 at 16:30
  • 1
    … with the old system A, they were printing out the reports, carrying them down a flight of stairs to department B, and then typing them back in. And the change in the report's format, even though the new format was objectively better in any possible way, slowed down the B employees because the data they needed was in a slightly different place. They looked at system B, found that it had an API for importing data from XML, and wrote an XML exporter for A in the right format within hours. In the end, they not only saved a ton of extra development work, they also reduced the latency for syncing Feb 12 at 16:33
  • 1
    … A and B from a day to a few milliseconds, and removed useless, mindless, work from the B employees. Feb 12 at 16:34
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.

2
  • Thanks for the advice! It captures some of what I'm worried about - that we might have a common blind spot that is hard to identify just through standard iterative development. Points 2 and 3 are especially topical, since it's often hard to get some of the stakeholders engaged in the discussion until it's too late, and we struggle a little to work out how much time to invest in "working out what to do" versus "getting it done" when there might not be a lot of time available in total. Do you have any advice on managing either of those?
    – ConMan
    Feb 10 at 23:32
  • I use a product backlog to help mitigate this. A product backlog is a prioritized list of deliverables (such as new features) that should be deployed during the course of a project or product development in Agile development. It's a decision-making tool that assists you in estimating, refining, and prioritizing whatever you might wish to do in the future. I'm sure this will help you and your team. Feb 12 at 8:32
3

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.

1

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.