Identifying Invisible Requirements

Hands up how many times this has happened to you. You work with a customer to elicit requirements for a system to replace a manual process. You analyse their processes, get copies of the documents they currently use, speak to all stakeholders you can identify, draw up activity diagrams, use case models (yes, even in agile), process flows, and more. You write criteria, and discuss the requirements with the development team. You’re confident in what you need to build, in the requirements you’ve been given, and that you’ve documented the requirements that represent the best possible way of meeting the customer’s need.

The developers code the system, it’s tested and you write a user guide. You gather the stakeholders together to show them the finished article, and they say;

So how would I do [insert something here that they’ve never mentioned needing to do before]?

You look at the developers. They shrug. The tester shakes her head. “You can’t do that, we didn’t know you needed to be able to.”

Does that sound familiar? I guarantee it’s happened to us all, several times. Missed requirements. Invisible requirements, as they were always there, but no-one ever noticed or mentioned them. 

The first thing to say is don’t kick yourself (unless it’s something really obvious that your goldfish could have picked out as a requirement, in which case kick yourself a little bit, then add it to the list of things to question in future), and don’t panic. If you’re working in an agile way, it’s rectifiable. You can add it to the backlog, plan it and have it built in to a future release.

But you don’t want this to happen regularly, do you? It’s inevitable that it will happen again, from time to time but there are things you can do to try and avoid it.

Work Shadowing

This is an invaluable experience, but its feasibility depends on the organisation you work for, and your relationship with your customer. It involves sitting with your end users whilst they perform their manual activities, and noting down absolutely everything that they do, asking them to narrate what they’re doing as they go. This way, any little ‘tweaks’ or things that they do which may be unique to their way of working (but important for them, to keep them efficient; think sorting tables of data, or filtering information down to the specifics they’re interested in) will be evident to you, and may elicit requirements around usability, or non-functional requirements, for example “I have to make this available to all our subscribers; there’s around 100,000 of them, who may all want to access this information at the same time.”

Mockups

Need an interface? Mock it up. Many people think that mock-ups or wireframes are purely to illustrate to the developers how a screen should look, but in my opinion, this is a byproduct of their true use. A good mockup shown to the right people, can drive conversation about how a screen might be used. What functionality do they need? Would a text input box be adequate? Do they need an auto-complete on the search functionality? Should a date field allow freetext or force them to use a date picker?

Imagine a screen showing tables of data. What our little scenario involved the end user viewing this screen and asking “so could I export that data into a spreadsheet so that I can manipulate it and run some calculations?” No, because you haven’t built in an export function, because you didn’t know they needed it. If you’d mocked it up, and ‘demonstrated’ it to them that way, they’d have asked that question earlier, and you’d have built it in.

Process Flows

This is probably a staple artefact for most analysts – certainly Business Analysts – but a good process flow is invaluable. Discuss the process, go away and model it as you understand it, then get together again, and look at what you’ve modelled. Is it correct? Have you accurately modelled what they said? Is there anything else they can add to the process as it is? Can you drill down into any of the processes and add more detail, break it down into individual steps? When made to think about their process in this way, quite often people will say “Oh, I also have to send a copy to [other department] for their records. I don’t know if you need to know that though.” Why, yes I do, thank you for that.

Early Visibility

You’ve sat with them while they work, modelled their processes, looked at concept-based mockups together and now the developers are coding. It’s due to be released in a fortnight and you’ve a demo booked in for the day before release.

Why wait until then? As soon as there’s anything you can show them, do so. Screenshot from the developer? Fine; it shows them what it will look like. Snippet of a video you’ve recorded of you navigating through the system test or UAT system? Great; it shows them how they’ll navigate the system and how intuitive (or not!) it is. It also gives them opportunity to review and specify terminology used throughout their new system, to reduce the number of tweaks needed after release.

Acceptance Criteria Review

Depending on your customer, end users, and their ability and willingness to feed into these sorts of things, asking them to review your acceptance criteria could be a valuable activity. If written in a sensible, user-scenario based way e.g. “Given that I am attempting to login to the system, When I enter a username and password combination incorrectly five times, Then my account is locked and I am unable to try a 6th time”, they should be able to comment on whether their requirements are being met. 

Talk to the Right People

Very often, your Product Owner isn’t your end user. It may be, for example the manager of the team who need to perform the activity you’re facilitating. But they’re not the one doing the activity themselves. They know the process, they know the requirements as far as what the overall need is, but they aren’t involved in the daily process itself. You need to speak to the people who are. They’re the ones with the small quirks and tweaks and minor requirements that could be thrown in right at the end. Involve everyone, and ensure to demo your system to everyone, whenever possible.

If All Else Fails…

Put it on the backlog. Delve into the requirements, document it, estimate it and put it on the backlog to be worked into the solution. Even if you’ve tried everything else, asked every question you can think of, and done your best, you will still have times where something has been missed. Don’t fret over it.