How to Write a Good Requirement

As a Business Analyst I am often asked how best to go about writing good Requirements, this is far from an exact science and varies depending on the project, the methodology, delivery cycles and audience. 

Often, a Programme Office will determine how requirements should be gathered and classified, for example Waterfall approaches would assume a Business Requirements Document, Functional Requirements document. However, ultimately no matter what the template, poor requirements are among the top reasons for projects failing and even the best test plans need well thought out and comprehensive functional and non functional requirements.

So although good requirements will not guarantee the success of your project, poor requirements will almost always guarantee failure. So what is a requirement and how do you write good requirements.

These are the rules I follow;

So what is a Requirement?

A business requirement is a business need that must be delivered to provide value.  Requirements should always focus on the business need rather than how to achieve it (solution).

How do I Gather Requirements? 

Requirements can be elicited from users, customers and other stakeholders through workshops, interviews, questionnaires, user observation, workshops, brainstorming, use case, role playing and prototyping etc.

SDLC vs. Agile Requirements - Does it matter? 

Both methodologies rely on identifying the business requirement and should be written clearly to avoid ambiguity. In agile, each iteration implements the highest priority requirements, delivering  the end product bit by bit therefore reducing the amount of documentation upfront. However, like the more traditional approaches agile requirements must be Needed, Verifiable, Attainable and Clear to ensure the business value to achieved.   

Agile Requirements can change over the course of development and delivery cycles as they are continually reviewed/refined.

Waterfall Requirements allow business owners greater resource, cost and timeline management as they are frontloaded without scope for significant change.

Characteristics of well-written requirements

 

1. Needed 
   • A Requirement is a statement of something someone needs. It distinguishes between a need and a want. A requirement that is not necessary is not a good requirement. 
2. Verifiable 

   • A requirement must state something that can be verifiable by inspection, analysis, test or demonstration. Identify how a product meets the requirement when writing or reviewing a requirement. 

3. Attainable

   • A requirement must be attainable within a foreseeable budget and schedule and must be technically feasible. This is particularly important for Technical requirements. Higher level “Operational Requirements” may be developed without assurance of budget or schedule, but they must be technically feasible. 

4. Clear 

   • A requirement expresses a single thought. It cannot be misunderstood. It is concise, simple and grammatically correct

11 Tips for Writing Standard Requirements

 

1. Use standard Requirements terminology: use of Shall, Will and Should

• Use shall in stating requirements
• Use will in stating facts
• Use should in stating goals

Shall is the flag that identifies requirements. Each shall is contractually binding and drives the development budget. The use of shall is especially important when requirements go to an external or contacted provider.

Example 

The ABC system shall illuminate a warning light in the event ………

2. State 'what' and not 'how'.

Requirements state what is needed, not how to provide it. 

• Remove Implementation from requirements.
• Ask why you need each requirement. If the answer takes you back to a more fundamental requirement, you were stating a “how” not a “what”. 
• Eliminate operation descriptions. Instead state the requirement. Requirements that state “the user shall” or “the operator shall” are almost always operation descriptions, not requirements.
• Ensure a requirements statement is correct and complete. 

Example of a correct Requirement 

The ABC system shall measure room temperature.

Example of an incorrect Requirement

The ABC system shall use a 4 wire thermo couple to measure room temperature.

3. Use correct, unambiguous terms and good grammar

There must be one, correct understanding of a requirement. Incorrect and ambiguous requirement terms cause budget and schedule problems. Poor writing can obscure the most necessary requirement. If you can’t understand it, your developers probably can’t either. 

Ambiguous terms to avoid:

Support, etc., and/or, may, could.

Example of a correct Requirement 

The stereo amplifier shall provide outputs for two additional speakers at full rated power.

Example of an incorrect Requirement

The stereo amplifier shall support additional speakers.

4. Write verifiable requirements 

Think ahead to verification. Requirements that contain subjective, unquantifiable words are not verifiable. Ask “How will we verify or confirm that the designed and built product met the requirement. An unverifiable requirement is an unnecessary or bad requirements.

Subjective Terms:

User friendly, flexible, easy, sufficient, adequate, useable, appropriate, fast, portable, light weight, small, large, quickly, easily, clearly.

Example of a correct Requirement 

The system shall update the display every 10 seconds.

Example of an incorrect Requirement

The system shall have a fast update to the display

5. Use Consistent, concise language

Use the same terms throughout and be concise.

Correct 

The vehicle net weight shall be 2 tonnes.

And

The vehicle shall have 2 axles.

Incorrect 

The maximum vehicle net weight shall be 2 tonnes

And

The truck shall have 2 axles

6. Identify missing requirements 

Failing to mention a requirement may be tantamount to asking the product developer to make an assumption or decision about a specific detail. If you do not specify it then you cannot complain later if it is left out.The first defence against missing requirements is a well-developed operation concept. The second is using standard formats for requirements documents.  

Example

A project omitted a requirement specifying the system response to a message containing an erroneous or unrecognised location code.

Consequently when incorrect codes were encountered in a message, the system was coded to halt delivery of the message to all locations not just those with erroneous codes.

7. Eliminate Contradictory or duplicate requirements

One requirement cannot contradict another.

Example 

Requirement 1:

The maximum vehicle net weight shall be 2 tonnes.

Requirement 2:

The maximum vehicle net weigh shall not exceed 4 tonnes. 

8. Track traceability of Requirements early on in the process

Record and track relationships between levels of requirements. Document which parent requirement is driving a lower level child requirement. Checks must be made to ensure traceability is correct and complete and that requirements flow down correctly.

Design reviews should address how the design meets each requirement.

Example  

Parent:

1.118

The system shall allow user to display a diagram to show the connectivity

Child

1.118.1

The system shall allow the user to display a diagram to show the upstream and downstream connectivity.

9. Track the requirements owner of source

The requirements owner or source is the stakeholder specifying the requirement. The owner is knowledgeable about the need for the requirement.

Example 

Stakeholder:

System user, product owner, business lead

10. Track rationale for each Requirement

Rationale is an explanation for why a requirement exists, any assumptions made in writing the requirement or other information useful to managing the requirement throughout the lifecycle of the project.Capture the rationale as the requirement is written. Rationale can expose incorrect facts and wrong assumptions. 

Example 

Requirement:

The maximum truck height shall be 14 feet.

Reason:

The tunnel height restrictions for the port routes are 14feet 

Assumption:

The truck will be used on motorway journeys to the port

11. Prioritise Each Requirement

Indicating the relevant importance of each requirement early on provides options for managing requirements additions and risks and provides guidance in making design trade-off decisions.

A tree tiered prioritisation classification

Priority Level	Description	When Needed
High	Essential and non-negotiable. It must be met to obtain the basic capability	Initially or right now
Medium	Useful, negotiable or slightly deferrable.	A little later
Low	Desirable.	Someday

Requirement 1:

The maximum truck height shall be 14 feet.

Priority: High

Requirement 2:

The truck shall be decorated on both sides with the company logo.

Priority: Medium

Requirement 3:

The cab shall be decorated using the company colour scheme

Priority: Low

Remember writing good Requirements will not necessarily guarantee success for your project but writing bad ones will almost guarantee failure. So be pro-active, not re-active and get your Requirements right the first time. 

Sogeti Ireland 

At Sogeti Ireland we deliver practical and innovate solutions, built on more than 40 years of global experience. Independently recognised as world leaders in Software Testing and Quality Assurance Services, Sogeti provides thought leadership, leading practice, methodology and tools to increase quality, reduce time to market and reduce cost for organisations across all sectors. 

We offer a complete digital service portfolio to our clients in Ireland and have one of the largest specialist practices in the country.

Our PointZERO®  vision refers to doing things right from the very first moment, the point zero. Avoid wasting effort on rework; "getting it right from the start", leading to business solutions that are fit for purpose and right the first time.

You can read more about our PointZERO® visions here.