Getting requirements pulled together is tough. But you can’t get around it. Because without knowing what the customer actually wants you can’t plan your project:
The requirements determine the project cost. Also, they determine who you need to involve. And finally, requirements determine the timeline.
Having worked as a project manager for years, I’ve come up with a good strategy around understanding requirements. And in this article I’m sharing my process with you.
Heads-up: If you don’t have a good template for documenting requirements yet, check out my requirements specification template for Word (it has automatic numbering of requirements built in!).
The two goals of requirement analysis
We analyze requirements with two goals in mind:
- to make sure all requirements are taken up (an no requirement is missed)
- to get a thorough understanding of each requirement
If you are unsure how to go about getting the requirements from your client, always refer back to those goals, as they should determine your approach.
But before I take you through the actual process of requirements analysis, let’s talk about the biggest challenges you may face along the way.
I’ve identified four key issues. They not only make requirements analysis hard. They have the potential to completely tank your project. Now you’re asking yourself what these issues could be.
Beware of these challenges
I’ve identified four issues related to understanding requirements.
Challenge #1: Different backgrounds, different language
Project teams typically include people from a wide range of backgrounds: Engineers, marketing people, sales staff, IT specialists, people from legal — all working together. This is what makes project work so much fun, but the diversity can also cause trouble.
The issue is communication. People coming from different fields will have more difficulty understanding each other. Everybody uses their own jargon (terminology from a specific field) and also, some words will have a different meaning depending on the background.
Just look at these terms:
- process
- desktop
- assets
- lead
- cloud
Process is a generic term that — for a non-IT person — describes some sort of agreed procedure. For an IT person, a process is typically a software-supported mechanism to achieve a desired outcome.
When you hear the word desktop, what comes to your mind? Probably your computer screen. But not everybody will understand the same thing as you.
Asset is a finance term with a very specific meaning. Assets are items recorded in the balance sheet representing what a company owns. Asset can also have a general meaning — like advantage or benefit.
Lead is a term used in sales and marketing. It’s another word for potential customer.
Clouds can be found on the sky but they also have technical meaning in IT.
So you see, this is what makes communication between people from different backgrounds really hard.
And it also makes your requirements gathering really hard because (a) you won’t instantly understand what the client is talking about. And (b) you might assume you understood what the client meant, but in fact you got a wrong understanding.
This is why requirements analysis is a mine field … if you are not working with the same precision as a Swiss watch.
So, what can you do to avoid misunderstandings?
Clarify mercilessly.
“I didn’t understand <topic>. Can you please clarify?”
“If I understand correctly you want to have a process for this but you don’t necessarily need an automated solution, right?”
“So, you’re saying that …”
“Let me repeat what I understood…”
Challenge #2: Blinded by routine
Requirements are usually gathered by interviewing the client and asking specific questions to get a feel of how a process is carried out.
This works great most of the time (95%) when people are able to verbalize their steps and give a complete and consistent description of the process.
The problem is when people forget a part of the process for the simple reason that it has become routine and not something they consciously think of.
It’s like if you asked me: “What’s your PIN code for online banking?” I couldn’t tell. My fingers would know but it’s gone from conscious memory.
Here are more examples:
- Did you ever wonder why there’s always proper lighting in your office? It’s because the janitor regularly replaces broken light bulbs.
- Did you ever wonder why there are always clean dishes in the cupboard? Because a secretary puts used dishes in the dish washer and afterwards puts the clean dishes into the cupboard. You only become aware of that once dirty cups start piling up in the kitchen 🙂
- Do you know why your PC is always working fine? It’s because someone from IT takes care of software updates.
I’m sure you get the point. We easily ignore certain arrangements or processes that we are so used to because of routine. Especially when these services are provided by other departments like IT, finance or facility services.
How can you avoid gaps in your requirement analysis that are cause by routine-blindedness?
One possibility is observation. I’ll explain this method further down in the article.
Challenge #3: Rare items are often forgotten
When you discuss requirements with a client, your discussion will usually revolve around processes or things the client follows or uses on a frequent basis — the 80% of our time:
- the most used features of a software
- the rooms in a house where people spend 80% of their time
- the most-commonly purchased goods
What is often forgotten or left out in requirements discussions are the 20% or 10% of things.
For example: software features that are only used on a very rare basis. Just think of a tax audit report which you have to pull from your system in case you are being audited by the authorities. It’s not at the top of your head, right?
So, when you are moving to a new software solution you might forget to tell your software vendor about that report.
Challenge #4: Wants vs Needs
Not everything the client wants is actually something he needs.
In other words: It may not be in the client’s best interest to give him exactly what he’s asking for.
One anecdote that comes to my mind is when Henry Ford said: If I had asked people what they wanted, they would have said: faster horses.
We would not have cars if Henry Ford had relied on customer feedback.
So the lesson for you is:
Think beyond what the client asks you for. What is it he truly needs? What is the goal?
Then come up with ideas how you can solve the customer’s problem.
From high level to detail — the requirements gathering process
Now that we’ve talked about the challenges of gathering requirements, let’s talk about the actual process.
Collecting requirements is an iterative process which is done in several cycles. You start discussing the high-level requirements with the client:
What does the client want?
- What are his expectations?
- What does the client want to achieve with the project/product?
- What other solutions has the client tried before?
- Which ones worked and which ones didn’t work? Why have they not worked?
The way you carry out the initial, high-level requirement gathering is just in a number of casual meetings and by careful note taking.
Then you dig deeper into each requirement until you have a very clear understanding. To conduct a more in-depth analysis of each requirement, you typically use a more formal process for requirements gathering.
This can involve process flows, product prototypes, simulations and other methods for requirements analysis.
Here are my favorite methods for collecting requirements:
My best methods for understanding requirements
Method 1: Create a questionnaire
In my projects, I’d always send out a large questionnaire to the customer first. It covered all the questions we knew were important in order to figure out the project scope, effort and cost. The questionnaire was a Word document of several pages, containing very specific questions and directions. Here’s an example of a question (note: we were rolling out an ERP system):
- Question: Please list all the IT systems and applications you are currently using.
- Question: Describe your current purchasing process (include flow charts).
- Question: Are you selling goods to customers outside the US?
- Question: Add a screenshot of your invoice form.
Our questionnaire was a BEAST. It had 40 or 50 questions, and we gave the customer 4-6 weeks to complete it and send it back to us along with the additional pieces of information we requested, like document samples, Excel analyses and the like.
How did we know what questions to ask?
I sat down with every team member to collect the questions they needed an answer on, so that they were able to complete their work package.
Also, we added questions we knew were essential based on our experience from previous projects. We held a lessons learned workshop after every completed project in order to look back at what had worked and what didn’t go well. Our findings were used in upcoming projects.
Method 2: Visualize the client’s processes
Visualizing is a powerful way for understanding requirements. That’s because visual information is much easier to process for the brain than mental concepts.
You can ask the client to draw a process flowchart in case you want to understand a specific process. Or you can ask the client to give you samples of his favorite designs so you get an idea of your client’s design preferences.
All you need for visualizing requirements are a white board or a beamer, so that the whole group can take a look at it.
We used visualization extensively in our projects, and it proved to be super helpful especially when we talked about processes that were new for the project team.
Method 3: The requirements review meeting
Any high-level requirements gathering you do at the beginning of your project must be followed by an in-depth look at each requirements. I call this a detailed requirements review.
We go into a detailed requirements review typically after we’ve received the requirements questionnaire back from the customer (see above).
To give you an impression of what the discussion typically goes like:
Let’s assume we are rolling out a new IT system for the client. And we agreed to transfer old data to the new system so that the client can get started right away.
Looking further into the requirement to transfer data to the new system, we would ask questions like the following:
- How many data records do you have in total?
- Can you show us samples of your data?
- What format do you store your data in?
- Do you have a process / tool for extracting the data?
Then we wouldn’t just ask those questions, but we’d look at actual data that the customer provided us. And then we would dig deeper, with more specific questions. And so on 🙂
Method 4: Create a prototype
Put yourself in the shoes of your client: When you’re looking to buy an expensive product, it’s very hard to figure out all your needs when you’ve never used a similar product before.
This is true for many types of products:
- real estate
- furniture
- software
- a new service or process
Giving the customer a prototype not only allows him to get a “feel” for the product. It also helps to derive the desired features and requirements.
For instance, take a customer who intends to buy a new home. He might go to a site with fully assembled prefabricated homes. He can take a tour of the house, look through the windows, touch the walls and maybe even stay overnight to immerse himself into the house’s atmosphere. After seeing the prototype he’ll have a much better understanding how the home should be customized for his needs.
A prototype isn’t just useful for understanding the requirements for physical products. It can also be helpful when you are creating a virtual product like a software, or even a process.
Instead of starting right away with coding a software, you could give the client an Excel prototype of the desired solution. He can work with the Excel file for a couple of days and thereby really understand what additional features he wants or needs.
The great thing about this approach is that you significantly reduce the risk of your project because the chances of having missed a feature is much lower.
Method 5: Observe people at work
If you need to understand how a specific process is carried out, observing the responsible performing the job is the best option.
Observation is great for two reasons: You don’t interfere (too much) into people’s work because you are just observing from behind. The other benefit is that you don’t have to rely on people’s ability to recount their process steps. It’s easy to miss out on a step which the worker carries out on a routine, and which is done from a subconscious level.
Examples of processes to observe:
- Understand how warehouse workers pick and store goods
- Understand the pre-flight inspection process for aircraft
- Understand the steps of incoming mail being sorted
As you can probably tell, observation alone is not sufficient to get a thorough understanding of a process. You need to be able to ask questions, ideally during observation but definitely in a follow-up meeting: Why did you do X? I didn’t understand Y, can you please explain?
Make sure you carefully document your findings so you can refer to them later. Also I suggest you have the document reviewed and approved by the client. Just to make sure your findings are valid.
Qualifying requirements (don’t skip this)
If you have no rules or process in place to help you decide which requirement is really needed and which one is not, you might as well say good-bye to a successful project.
When you ask your client which of the features he wants for his machine, software or service, he will typically say: I WANT IT ALL, I WANT IT NOW. But normally you can’t implement all features right away, either for
That’s why you need a way to decide:
- which requirement is an absolute must
- which requirement is needed but not urgent
- which requirement is a nice-to-have
Use a ranking strategy like A=must, B=needed not urgent, C=nice to have and have all the requirements ranked by the customer.
My rules for collecting requirements
Here are my rules for analyzing requirements. Believe me, I’ve learned requirements analysis the hard way. If you follow these rules you will be in a much better position with your project.
Rule #1: Start as early as possible:
Getting to a clear understanding of the client’s needs is a longer process which takes several iterations. That’s why you should start discussing the requirements as early as possible — even if your project isn’t yet fully set up.
Rule #2: Get different perspectives on the same topic
If you ask ten people the question “What is the reason for seasons on earth?” (answer) you’ll probably get ten different answers. The same is true when you ask about requirements. You get 10 different versions of the story. The challenge for you is to figure out what aspects are true and which ones aren’t. In any case, I recommend you try to get feedback from a number of people, not just from the employee who’s been with the company for only 6 months.
Rule #3: Assign an ID to every requirement
It’s easy to get confused when you have to manage hundreds of requirements. Put every requirement into an Excel sheet and give it a unique number. This simplifies communication with the customer and the team and helps to avoid ambiguity or even misunderstandings.
If you are working in IT, you can define a test case for every requirement using a test case template.
Ask as many questions as you need
Your job is to get a 100% accurate understanding of your client’s needs. Don’t worry about asking too many questions. Ask as many as you can, even if you fear the customer thinks you’re a retard.
Get requirements signed off
Oh yes, very important! Once you have collected and documented all requirements, get the customer’s signature for approval.
Conclusion
There’s no way around a thorough requirements analysis. Don’t rush through the process and make sure every requirement is clear for you. In fact, you should be able to explain every requirement in your own words and why it is needed. That’s when you know you’ve done a good job!
