business analysis fundamentals – writing good business requirements
DESCRIPTION
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.TRANSCRIPT
BA Intelligence
Business Analysis Fundamentals
The Cornerstone of a Good Business Analyst-Writing Good Business Requirements
By Ken Shome (CBAP)
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”.
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
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
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
• 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.
BA Fundamentals: Writing Good Requirements
Measurable
• Testable: each statement can be validated/verified
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.
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
Achievable
• The requirement must be realistic to be achievable.
BA Fundamentals: Writing Good Requirements
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.
Example of a Achievable requirementBR-1.1.3Should 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
BA Fundamentals: Writing Good Requirements
Relevant
• The requirement has a rationale to justify the requirement
Example of a relevant requirement. ID: BR-0001Rationale: 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
Traceable
• Each requirement is a single element with a unique traceable ID
BA Fundamentals: Writing Good Requirements
BA Fundamentals: Writing Good Requirements
Evaluated
• Define the value and benefit of the requirement.
Reviewed
• The requirements should be verified and validated by peers, stakeholders, SMEs and members of the project team
BA Fundamentals: Writing Good Requirements
BA Fundamentals: Writing Good Requirements
BR-1.1.4
Generate Infringement 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
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
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
• How do we get BAs to write good requirements consistently?• What strategies can we apply to ensure long-term results?
BA Intelligence