The document provides tips and guidelines for developing effective business requirements. It discusses the importance of having a good problem solving process and defining requirements within that context. It then covers the key aspects of a problem solving framework, including identifying the problem, developing alternatives, selecting the best alternative, implementing it, and evaluating the solution. The rest of the document focuses on best practices for writing high quality requirements, such as making them verifiable, avoiding design details, using simple language, and proofreading thoroughly.

1. The Art of Problem Solving
Business Banking Client
February, 2013
PUBLIC

2. Agenda
• Context
• Problem Solving According to Dilbert!
• What’s the benefit of improving your problem solving
process?
• The Problem Solving Framework
– Identify the problem
– Develop Alternatives
– Select the best alternatives
– Implement
– Evaluate the Solution
• Top 10 Tips for Developing Business Requirements
PUBLIC

3. Requirements in Context of Problem Solving
• You can only have discussions around
requirements in the context of a good
problem solving process
• Quality requirements gathering is an outcome
of this process
• It is easier to get teams focused on having
discussions around requirements when it is
done within the problem solving framework
PUBLIC

4. Problem Solving According to Dilbert
PUBLIC

5. What’s the benefit of improving your
problem solving process?
Improved Profitability
• Increased sales
• Reduced costs
• Reduced business risk
• Reduced cost of customer
acquisition
• Increased customer
retention and Satisfaction
• Improved work processes
• Opportunities to innovate
Improved Capability
• Increase staff
resourcefulness
• More effective problem
solving
• Improve decision making
• Increased capacity to
leverage learning
• Build more effective team
collaboration
• Enhance different types of
thinking (creative, strategic)
PUBLIC

6. What happens if you don’t solve the
right problem?
• "Houston, we've got a problem." These famous words,
spoken by astronaut Jim Lovell from space in April 1970,
launched a famous public demonstration of solution-finding.
• "Failure is not an option," Gene Kranz, lead flight director for
Mission Control, announced to the ground crew in Houston as
Apollo 13 approached the critical earth-to-moon decision
loop.
• “It's so much easier to suggest solutions when you don't know
too much about the problem.”
― Malcolm S. Forbes
• “a problem well put is half solved.”
― John Dewey
•
“We always hope for the easy fix: the one simple change that
will erase a problem in a stroke. But few things in life work
this way. Instead, success requires making a hundred small
steps go right - one after the other, no slipups, no goofs,
everyone pitching in.”
― Atul Gawande, Better: A Surgeon's Notes on Performance
PUBLIC

7. The Problem Solving Framework
Requirements
definition is
important
Requirements definition is critical
PUBLIC

8. Identifying the Problem
• “If I were given one hour to save the
planet, I would spend 59 minutes
defining the problem and one minute
resolving it,” Albert Einstein said.
• You may know there is a problem, but do you know what the
root cause is?
– Can you put your finger on the actual problem?
– Are there a number of issues that are just symptoms of a bigger cause?
• “Keep it simple”
– Simply put, if you have a problem somewhere and it is causing a big
impact, measure it!
– How many times does it happen and what generic factors are causing this?
• Identify the Root Causes
– The objective here is to wade through the symptoms, and identify the root
causes to the problem.
• State the problem as requirements that need to be
solved for:
– Identify the current measure(s) which show that the problem is real
– Identify the goal measure(s) to show the benefit of the problem being
addressed and the value of meeting it
– Identify the "as-is" cause(s) of the problem, as it is the causes that must be
solved, not the problem directly
– Define the business "whats" that must be delivered to meet the goal
measure(s
PUBLIC

9. Develop Alternatives
• USE BRAINSTORMING TO
COMBINE AND EXTEND
IDEAS, NOT JUST HARVEST
THEM
• DO INDIVIDUAL
BRAINSTORMING BEFORE
AND AFTER GROUP
SESSIONS
• BRAINSTORMING SESSIONS
ARE WORTHLESS UNLESS
IDEAS LEAD TO ACTION
• BRAINSTORMING SESSIONS
ARE WORTHLESS UNLESS
IDEAS LEAD TO ACTION
PUBLIC

10. Select the Best Alternative
• Team Agreement on the
best alternative(s) to
solve the root cause
problem(s)
• There is value in the
debate
• Avoiding “group think”
• Above the line
commitment
PUBLIC

11. Implement
• Build your implementation roadmap
• Consider short, medium and longer term actions
• Ensure you plan out all of your activities
• Ensure that your implementation requirements are
fully elicited:
– Identify the people who will help specify requirements
and understand their organizational bias
– Define the technical environment (e.g., computing
architecture, operating system, telecommunications
needs) into which the system or product will be placed
– Identify "domain constraints" (i.e., characteristics of
the business environment specific to the application
domain) that limit the functionality or performance of
the system or product to be built
– Define one or more requirements elicitation methods
(e.g., interviews, focus groups, team meetings)
– Solicit participation from many people so that
requirements are defined from different points of
view; be sure to identify the rationale for each
requirement that is recorded
– Identify ambiguous requirements as candidates for
prototyping
– Create usage scenarios or use cases to help
customers/users better identify key requirement
PUBLIC

12. Best Practice Requirement Example
Bad Requirement
• The system shall be completely
reliable”
• “The system shall be maintainable”
• “Order rejections shall be less than
99%”
• “The system shall be fast”
• “The system should use artificial
intelligence”
• “The system should be totally
modular”
Good Requirement
• “The response time for the system to
present the checkout page upon an
order button click on a product detail
page shall be less than 500ms”
• “95% of all transactions on the
public-facing webstore portal shall be
processed in less than 4s”
• “MTBF for the domain controller
server shall be 5000 hours of
continuous operation”
• “The system shall present the closest
5 stores to the user on the map page,
provided that 5 stores are within the
user-defined search radius”
PUBLIC

13. Measure Success
• Did the actions we take
move the yardstick?
PUBLIC

14. Thank You!
Contact Location
1 Chris.Lamoureux@Veriday.com
2
3
905.273.4399x224
www.veriday.com

15. TOP 10 TIP FOR DEVELOPING BUSINESS
REQUIREMENTS
© 2011, TechWRITE, Inc.
PUBLIC

16. 1. Make requirements verifiable and
measurable
• One important purpose of a business
requirements document is to measure results,
but unverifiable requirements can’t be measured.
• Take for example, a requirement that says, “the
system must be easy to use.” What exactly does
that mean? A generalized statement such as this
must be made specific so that it can be tested
throughout the development process.
PUBLIC

17. 2. Do not include the solution design
The requirements focus on what needs to be
done, not how to do it. (The “how to do it” will
be covered in other design documents.)
PUBLIC

18. 3. Format requirements as separate
paragraphs
It’s important to do this so that each requirement
can be linked to details in subsequent design
documents. Specifically, each requirement should
express a single concept, such as:
• Quality measurements will be gathered monthly
through online surveys.
• The quality information gathered will be
maintained in a database.
• The database will have a reporting/query tool
available for ad hoc queries and reports.
PUBLIC

19. 4. Use details wisely
There are the two common mistakes with
details:
• One mistake is including more details than are relevant to the
reader. Ask yourself, does the reader really need to know this
detail? If not, take it out.
• The other mistake is not including enough important details.
To avoid missing critical details, take a wide view of the field
or domain of the business process – review industry studies,
reference architectures, industry and vendor white papers,
and of course Google.
PUBLIC

20. 5. Use uncomplicated sentences and
chunk information so it’s easy to
understand.
• Simple sentences are more understandable. In
addition, they lend themselves to more
precise evaluation when the project is
completed.
• To accomplish this, break out details into
bulleted chunks so they’re easier to grasp.
• Take a look at the following example that
shows how a complicated sentence can be
restructured.
PUBLIC

21. Uncomplicated Sentences Example
PUBLIC
Original: Assessments of functional quality must be derived through an
online survey of multiple business line managers, senior
executives, sales and marketing managers, production
managers, and customers and then maintained in a database
and available as monthly reports or through ad hoc queries.
Revised: Functional quality assessments will be gathered monthly
through an online survey of the following participants:
 Multiple line of business managers
 Senior executives
 Sales and marketing managers
 Production managers
 Customers
This information will be entered into a database and will be
distributed through:
 Monthly reports
 Ad hoc queries

22. 6. Avoid unnecessary words.
• If the words do not add meaning to a
sentence, leave them out. For example:
PUBLIC
Original: There must be the three following results from this
process:
Revised: The three results must be:

23. 7. Use simple words rather than
“complicated” words
PUBLIC
Difficult Simple
facilitates helps
substantiate prove
presently now
exemplifies shows
usage use
represents is
utilize use

24. 8. Avoid using “it” and “this” without
a clear antecedent
• Using the antecedent in place of “it” or “this” helps in two
ways.
• The repeated antecedent adds clarity to the sentence.
• If the sentence is “lifted” from the text, for traceability
purposes the meaning will remain understandable. For
example:
PUBLIC
Original: Add course location aids for all course locations. To
facilitate this, add or update class libraries for all
software development environments. This will allow
students to get directions to course locations at the
office as well on mobile devices.
Revised: Add course location aids for all course locations. To
provide this location functionality, add or update
class libraries for all software development
environments. The course location aids will allow
students to get directions to course locations at the
office as well as on mobile devices.

25. 9. Use terminology consistently
• Avoid using different terms for the same thing.
For example:
PUBLIC
Original: Click the Resources tab. After you click this button,
a list of resources displays.
Revised: Click the Resources tab. After you click this tab, a
list of resources displays.

26. 10. Review the document and then
spell check and proofread
• Read through the entire document to be sure the
document makes sense and flows logically. Don’t
forget to spell check. And then, proofread the
document, checking for missing words and
incorrect numbering or cross-references. Then
check that the table of contents refers to the
correct page numbers. In a final pass, read the
document aloud slowly to catch anything you
might have missed previously. (For more
information on proofreading, see TechWRITE’s
blog entitled, The lost art of proofreading.)
PUBLIC