Want good requirements? Focus on these 2 things

Want good requirements? Focus on these 2 things

Why is the important part of a project is also the part that no one ever wants to do? Getting requirements down on paper is the first step towards success. But while so many people know this, it still happens all the time. Here are some of the most common reasons I hear for why no one write down the requirements:

• “We didn’t have time we had to start asap to make the deadline.”
• “There was no budget available for a resource do the requirements.”
• “The goals of the project were not clear at the beginning so we didn’t bother.”
• “The client wasn’t available to talk to us about what they wanted.”
• “We’re an agile team so we don’t need requirements.”

If any of the above this sounds familiar this is for you.

What is a ‘requirement’?

A requirement describes how something must work to meet the objectives of the end-user.

Why do you need them?

If you want a project to succeed you’d best have your requirements clearly defined and available for your team. If you’re a one or two person team it’s completely possible that you didn’t have any written requirements. However, with more complex projects and larger teams, not having a set of requirements to work with increases risk significantly.

Why are they useful?

Requirements are what should guide the project team on what they should be building vs what they think they should be building. Requirements help remove a lot of the guesswork that has to happen when things aren’t clear. We know that it’s impossible to reduce uncertainty completely. By defining requirements you’re putting your team and project in a much better position to succeed.
Having requirements is also the most effective way to get everyone on the team on the same page. Especially where you have cross-functional teams made up for roles from designers to developers who may not all be working out of the same office.

How do you write a good requirement?

There are many resources out there that will tell you the best way to document requirements. I recommend that you search these out for yourself so that you can find something that works the best for you.

For our purposes here and for those who may be new the the requirements process, I’ve condensed the process down to just two key steps. Now let’s get to these and some examples.

Requirements for good requirements

Requirement Rule #1: An effective requirement must be clear

Seems simple enough right?  Don’t be fooled! Really ‘being clear’ with your written requirements will require you to cut through a lot of ambiguity. If there’s any room for interpretation (or misinterpretation), it’s guaranteed to happen if your requirements are absolutely clear.

You might be familiar with this cartoon below. If you’re a PM or have ever been part of a project team, you might be laughing (or crying!).

Ok, now let’s get to some examples.

Let’s use the example of a simple website redesign and development project. You have a customer who you’re redesigning their existing website for. Their current website is a static site so the new site will have an updated visual design as well as a Content Management System (CMS) so they can edit and update the content themselves.

Website Redesign Requirement #1

“The customer should be able to update website content.”

 

At first glance this makes total sense but there are a few things about this statement that makes it not as clear as it could be. We can ask a few questions to try gain more clarity:

1. Who is the ‘customer’ referring to in this case?

• Is it someone you’re building this website for and the person who will be administering it?
• It referring to the end-user customer, aka the users/visitors of the website?
• If the customer is referring to one administrator this is much different from multiple
• customers who need site editing abilities in some capacity.

2. What does ‘should be able to’ mean?

• In an ideal world one ‘should be able to’ something but alas, summer Fridays are here and the whole team had to head out for beers. It’s always best to use the word ‘must’ when documenting requirements so it’s very clear to all stakeholders that something is required, not just a ‘nice to have’.

3. What content needs to be updateable?

• Does ‘content’ refer to site text and images? Are there any other content types that the Administrator (the customer) will need to update? (eg. videos, products etc.)
• Must all content be updatable or specifically page content via a WYSIWYG editor.

Based on these questions we just went through, we can update this requirement to this:

“The website Administrator must have the ability to edit/update and delete website content that includes content page text, images and embedded video links.”

Let’s do another one.

Website Redesign Requirement #2

“The website needs to integrate with Twitter.”

Even if you’re not so familiar with Twitter the first question you might ask is ‘integrate how?’. The word ‘integration’ is thrown around a lot these days and can mean a lot of different things. So in this example let’s see what questions we can ask to try and clarify further:

1. What the specifics on the Twitter account?

• Is there a specific Twitter account the customer is using?
• What is the Twitter handle for that account? (This might seem like a basic question but it’s possible the customer does not actually have a Twitter account)

2. What exactly is meant by ‘integration’?

• There are several ways to integrate twitter with a website, which type of integration is being required?

If we say that for this example that the customer would like their twitter feed to appear on the website, we would update this requirement as follows:

“Website will integrate customer’s Twitter account (@custhandle) to display the latest Tweets ordered from newest to oldest on the website’s homepage using Twitter’s ‘user timeline’ feature. Implementation documentation is available in Twitter’s developer documentation.”

 

Once you think you’ve done your best ensure your requirements are as clear as possible, you can move onto the second step.

Requirements Rule #2: An effective requirements must be verifiable

Once you think you have a list of requirements that are clear, you can move onto step two.  The second step here is reviewing your requirements to make sure they are verifiable.

What exactly does that mean? If a requirement is an explanation of how something is supposed to work, there needs to be a way to test to see that it does work as intended. This is why things get confusing later if a requirement wasn’t clear to begin with.

So in step two, we want to document clear steps on how we test whether or not a requirement has been completed to spec and checked off as ‘verified’.
Let’s try this using the first example from earlier.

“Website administrator must have the ability to edit/update and delete website content that includes content page text, images and embedded video links.”

 

In order to verify if the requirement works to its specification, we could use these steps to help us verify if it works or not.

1. Administrator log into the administrator dashboard of website.

2. Administrator navigate to an editable content page (e.g. ‘About us) then:

(a) edit some page text then save changes

(b) edit a page image then save changes

3. Refresh edit page and confirm that changes have been saved.

If all three steps can be completed without interruptions, you can say that the requirement has been implemented correctly.

 
Let’s do the same with the second requirement example.

“Website will integrate customer’s Twitter account (@custhandle) to display the latest Tweets ordered from newest to oldest on the website’s homepage using Twitter’s ‘user timeline’ feature. Implementation documentation is available in Twitter’s developer documentation.”

 

In order to verify if the requirement works to its specification, we could test it as follows:

1. Navigate to website homepage.
2. Scroll to section displaying Twitter integration.
3. Confirm that the latest Tweets from the account (@custhandle) are displaying on the page.

If we can confirm seeing the latest Tweets on the homepage of the new website as stated in the requirement, we’ve verified that this requirement has been successfully implemented.

In this simple example it might seem like additional work to write this all down. However, if it is that easy, taking just a few minutes to write it down should not be a big deal. If you start writing and find out it takes any longer, it’s usually a sign that the requirement is not clear and that you need to go back and clarify it further.

 
If you were making something that already exists you would just copy what’s already been done before. So when you work on requirements, think about them as an opportunity to create something new. And as with anything, the only way to get better is to practice, practice practice.

Next time you have to write requirements for a project, focus on making sure they are:

1. Clear (must be no room for misinterpretation)

2. Verifiable (a way to test to pass fail)

If you can do these two things you’ll be well on your way to running a more effective project.