How to Write Business Requirements Faster, Stronger, Better

One of the mistakes I made when starting with business requirements was that I focused on the phrasing instead of the meaning.

For example:

I looked at how other procedure writers wrote, adopted their style, and started to write,

The software shall…

or

The software must…

In other words, I looked at the format and presentation instead of the ultimate goal, which is to write clear business requirements that others can use.

Why did I do this?

Lack of experience mostly. Because I was new to the area, I started with the format, structure and style as these allowed me to understand business requirements from at least one angle. And these are important. But not as important as purpose and meaning.

So, over the coming weeks, we’ll look at how to write better business documents, starting out with requirements. Here are three things to take into consideration:

Use Verbs to describe requirements

Requirements are usually written in lists.

For this reason, it helps the reader understand what you want to achieve by starting each requirement with a verb. For example:

• Change the Employee field to read/write.
• Enable the user to enter 25 characters in the Employee field.
• Delete the Date field.
• Add three new fields: Age, Date, Location.

Starting your requirements with verbs helps the reader – who may not be a native English speaker- to see exactly what needs to be done.

Don’t bury the essence of the requirements in the middle of a sentence. In other words, don’t make the reader have to work for find the information. Put the most important pieces of information at the start and go from there.

Remove filler text

It’s not unusual for new business analysts for be self-conscious about their writing style. To compensate for their lack of experience they may camouflage this by over-writing the requirements. One sign of this is adopting or mimicking official sounding phrasing or the over-use of acronyms and industry terms.

You can avoid this, and write better requirements, if you remove the filler text and streamline the requirements. Paradoxically, this results in shorter requirements which are easier to scan and understand.

Understand what you’re writing about

Probably the most important part!

Unless you understand what you’re writing about, whether it’s software, services, or something else, it’s very difficult to ask the right questions, get the answers you need, and formulate them into meaningful requirements.

I suspect that most requirements fail because the business analyst doesn’t really understand the subject matter. For this reason, before you get into the nitty gritty of writing up requirements, make sure you gather as much information about the subject, arrange demos, and if possible use the software.

Once you have a clear understanding of how the product or service works, you’re in a much stronger position to write clear, meaningful, and useful requirements.

Download Now

[Learn more about these business requirement templates]