Clearly stated requirements are one of the top reasons a project is successful. This places Business Analysts in the spotlight to successfully deliver a project. Ken Shome (CBAP) discussed Writing Good Business Requirements at an Interpro hosted roundtable session, outlining the key characteristics; SMARTER.

1. BA Intelligence
Business Analysis Fundamentals
The Cornerstone of a Good Business Analyst-
Writing Good Business Requirements
By Ken Shome (CBAP)

2. BA Fundamentals: Writing Good
Requirements
• Clearly stated requirements are listed as one
of the top reasons a project is successful.
• 50-70 % of projects fail due to poorly stated
requirements
• Good Requirements are one of the key
determinants of project “success”.

3. How do you write a
good requirement?
• A good requirement should have the
following characteristics:
• Specific
• Measureable
• Achievable
• Relevant
• Traceable
• Evaluated
• Reviewed
BA Fundamentals: Writing Good
Requirements

4. Specific
• Individual: Each statement is a single
element
• Clear: Each statement is clearly
understandable
• Precise: Each statement is precise and
concise
BA Fundamentals: Writing Good
Requirements

5. Example of a Specific requirement
• ID BR-1.1.1
• Business Activity: Generate Case to Legal
• Requirement: Should have the ability for the user to refer an
approved case to Legal.
BA Fundamentals: Writing Good
Requirements

6. • Example of a poorly stated requirement
BA Fundamentals: Writing Good
Requirements
BR-1.1.1
Generate case to
Legal
If the Case is ‘Approved’ and
it is a Civil matter, the Case
will be referred to Legal for
them to pursue in the
courts. The case will be pre-
populated with information
to support the case.

7. BA Fundamentals: Writing Good
Requirements
Measurable
• Testable: each statement can be
validated/verified

8. Example of a immeasurable requirement
BA Fundamentals: Writing Good
Requirements
BR-1.1.2
Validate for
Completeness
The Applications team must be
able to perform a google like
search for all applications to
validate the application for
completeness before an
assessment can be performed.

9. Example of a Measurable requirement
• ID: BR-1.1.2
• Should have the ability for the user to perform a search for
applications with the following search attributes:
• Application ID
• First Name of Applicant
• Last Name of Applicant
• Date of Application
• Application Type
BA Fundamentals: Writing Good
Requirements

10. Achievable
• The requirement must be
realistic to be achievable.
BA Fundamentals: Writing Good
Requirements

11. Example of a unachievable requirement
BA Fundamentals: Writing Good
Requirements
BR-1.1.3 System
Should have the ability for
the system to work on all
desktops and tablets.

12. Example of a Achievable requirement
BR-1.1.3
Should have the ability for the system to be compatible with the
following operating systems:
• Microsoft Windows 8+
• Android v5+
• iOS v10+
BA Fundamentals: Writing Good
Requirements

13. BA Fundamentals: Writing Good
Requirements
Relevant
• The requirement has a rationale to
justify the requirement

14. Example of a relevant requirement.
ID: BR-0001
Rationale: The Certification team is required to notify existing
customers their certification is expiring and are required to
submit a renewal application prior to the expiry date or their
certification will be suspended.
Requirement: Should have the ability for the user to send a
certification expiry reminder notification to a customer.
Rule:
• Accreditation reminders notification may be sent up to 3
months prior to the expiry date.
• No reminders may be sent after the due date.
BA Fundamentals: Writing Good
Requirements

15. Traceable
• Each requirement is a single
element with a unique traceable ID
BA Fundamentals: Writing Good
Requirements

16. BA Fundamentals: Writing Good
Requirements
Evaluated
• Define the value and benefit of the
requirement.

17. Reviewed
• The requirements should be verified
and validated by peers,
stakeholders, SMEs and members of
the project team
BA Fundamentals: Writing Good
Requirements

18. BA Fundamentals: Writing Good
Requirements
BR-
1.1.4
Generate
Infringeme
nt Record
The Infringements team requires ability to
generate their own Case Record, and an option to
allocate the Case record immediately to a
Infringement Officer.
Upon creating a Case Record, the system will
allocate a unique Case Identifier.
Upon creating a Case Record that has no preceding
Record, the system will allocate a unique Identifier,
and link this to the Case Record.
The Infringements Team requires the ability to link
a newly generated Case Record to an existing
Record.
Example of a poorly stated requirement

19. Revised Requirements:
• ID: BR-1.1.4
• Should have the ability for Infringements team to create a case record
with the following attributes:
– Case ID
– Date of Infringement
– Infringement Type
– Name, etc ( A complete set of attributes should be included).
• ID: BR-1.1.5
• Should have the ability of Infringements team to allocate the case to an
investigator
• ID: BR-1.1.6
• Should have the ability for the system to allocate a unique identifier to a
new case record
• ID: BR-1.1.7
• Should have the ability for the Infringements team to link a new case
record to an existing case.
BA Fundamentals: Writing Good
Requirements

20. What should the business expect from your requirements?
• Describe clearly what stakeholders need
• Address the business problems and identify opportunities.
• The value to the business of addressing the problem.
• An understanding of the impact of not addressing the
problem.
BA Fundamentals: Writing Good
Requirements

21. • How do we get BAs to write good requirements consistently?
• What strategies can we apply to ensure long-term results?
BA Intelligence