Cole Cioran discusses building requirements with style. He explains that there are differing definitions of requirements and that writing good requirements is challenging. Through group activities, participants discuss what constitutes a requirement, how examples and models relate to requirements, and how to write clear, concise requirements. Cole emphasizes that the definition of a requirement depends on multiple contextual factors and that analysts should facilitate stakeholders agreeing on a definition that works for their needs.

1. BUILDING REQUIREMENTS WITH STYLE
Cole Cioran
Program Manager Requirements Definition and Management
May 29, 2015
© 2015 Blueprint Software Systems Inc. All rights reserved.

2. BUILDING REQUIREMENTS WITH STYLE
• Presenter: Cole Cioran
• Program Manager, Requirements Definition and Management
• Acting VP Education, IIBA Toronto Chapter
• Description: There are a wide variety of opinions about
requirements. Cole will shed a little light on why the question
is so contentious and help you understand what makes for a
great requirement.
• Learning Objectives: After this session, you will be able to:
• Understand the problem with requirements
• Identify the difference between requirements, examples, and models
• Write better requirements!
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢2

3. © 2015 Blueprint Software Systems Inc. All rights reserved. ⎢3
Discussion
of the
Method

4. © 2015 Blueprint Software Systems Inc. All rights reserved. ⎢4

5. © 2015 Blueprint Software Systems Inc. All rights reserved. ⎢5
What How

6. IS WHAT VS HOW GOOD ENOUGH?
• Not really. For example:
• Solution requirements will dictate how a system must respond to
user input in a very detailed manner
• This definition is often used to divide who documents
requirements as opposed to what a requirement is
• This creates more confusion as it makes the question
dependent on the role as opposed to what is being created
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢6

7. SO, WHAT IS A REQUIREMENT?
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢7
A requirement is about your relationship to a decision.
If it’s your decision to make then its design.
If not, then it is a requirement.
- Alistair Cockburn

8. WHAT IS THE INDUSTRY STANDARD?
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢8

9. © 2015 Blueprint Software Systems Inc. All rights reserved. ⎢9
Everyone
has a
different
definition.

10. THE REQUIREMENTS DEFINITION PROBLEM
•There are multiple overlapping industry standards
•Consulting companies market competing definitions
•Practice leaders provide conflicting definitions
•Organizations implement their own standards
•Immature practices result in multiple definitions
•Everyone has a different definition
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢10

11. A GOOD RULE OF THUMB?
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢11
If it has
“requirement”
in it’s name it is
a requirement

12. EXAMPLE: BUSINESS RULES
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢12
Organization Definition
Tony Morgan – Business Rules and
Information Systems (2002)
A compact statement about an aspect of the business. It is a
constraint in the sense that a business rule lays down what must or
must not be the case.
Ronald Ross – Principles of the
Business Rules Approach (2003)
A directive intended to influence or guide business behaviour.
Barbara von Halle – Business Rules
Applied (2001)
The set of conditions that govern a business event so that it occurs
in a way that is acceptable to the business.
IIBA BABOK 3.0 A specific, practicable, testable directive that is under the control of
the business and that serves as a criterion for guiding behaviour,
shaping judgments, or making decisions.
Object Model Group A proposition that is a claim of obligation or necessity that is under
business jurisdiction.
Business Rules Group A business rule is a statement that defines or constrains some
aspect of the business.
Wikipedia A business rule is a rule that defines or constrains some aspect of
business and always resolves to either true or false.

13. WHAT ABOUT?
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢13
Constraint
Risk
Specification
Glossary
Principle
Value
Goal
Heuristic
Need
Objective
Rule
Stakeholder
Diagram

14. © 2015 Blueprint Software Systems Inc. All rights reserved. ⎢14
How do we
make sense
of all of this?

15. BREAKOUT ONE – WHAT MAKES UP A REQUIREMENT?
Facilitator: Share the definition for your requirement type
• What have you called requirements that match this definition?
• What are some examples of this type of requirement?
• What do these examples have in common?
• Where are they different?
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢15

16. © 2015 Blueprint Software Systems Inc. All rights reserved. ⎢16
Exemplia
Gratia
e.g.
Id Est
i.e.

17. EXEMPLIA GRATIA – E.G. OR FOR EXAMPLE
•Used to provide an example
•e.g. A user story
•As a traveler I want to fly to my destination so that I get
there sooner.
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢17

18. WHAT MAKES A GOOD EXAMPLE?
•Something to be imitated, an exemplar of success, a
model of clarity
•e.g. A user story
•As a <role>, I want <goal/desire> so that <benefit>.
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢18

19. THE PROBLEM IS…
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢19

20. WHICH IS WHY…
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢20

21. ID EST – I.E. OR THAT IS
•Used to restate an idea more clearly and offer more
information…
•i.e. Requirements should be documented, actionable,
measurable, testable, traceable, related to identified
business needs or opportunities, and defined to a level of
detail sufficient for system design.
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢21

22. THE PROBLEM IS…
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢22

23. WHICH IS WHY…
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢23

24. THE DELICATE DANCE
• Too much detail constrains solutions, limits professional
judgment, and creates inflexible systems
• Too little detail results in gaps and unexpected outcomes
• The challenge is to find the right level of detail and granularity
at each stage in an organization’s practice
• Methods like scaled agile, iterative development, wagile, and
so forth try to make the best of both worlds
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢24

25. WHAT ABOUT MODELS?
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢25

26. MODELS ADD CLARITY AND RELATE REQUIREMENTS
• Every model is designed to answer one or more questions
• If something in model doesn’t speak to the question then it
does not belong in the model
• e.g.
• A use case diagram answers the question of how use cases and
actors are related
• Business rules should be extracted from business process models
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢26

27. BREAKOUT TWO – WHAT MAKES A REQUIREMENT?
Facilitator: Share definition and what has been done so far
• What templates or standards have you have seen for this
requirement type?
• What are the key pieces you see in these standards?
• What pieces do we not need?
• What pieces would we need to make a complete requirement?
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢27

28. WHAT MAKES WRITING REQUIREMENTS SO HARD?
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢28

29. HOW DO YOU WRITE A GOOD REQUIREMENT?
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢29

30. WHAT MAKES WRITING REQUIREMENTS SO HARD?
• Analysts need to make sense of the competing needs of a
multitude of stakeholders
• The need to facilitate agreement around what those decisions
are among senior leaders
• The discipline is still maturing
• There is no one source of truth for standards
• There is no common style guide for writing them either
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢30

31. WHAT MAKES A GOOD REQUIREMENT?
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢31
Characteristic The Requirement:
Unitary Addresses one and only one thing.
Complete Is fully stated in one place without any missing information.
Atomic The requirement does not contain any conjunctions. e.g. and, or.
Traceable The requirement must meet all or part of a documented need for change.
Current The requirement be based on current conditions that apply to the organization.
Concise Must be objectively stated without jargon, acronyms, opinions, or vague language. It
can only be interpreted in one way.
Specified
Importance
Must specify how important it is. e.g. is it critical to the success of the solution, or is it a
nice to have?
Verifiable The implementation of the requirement can be verified.

32. SEVEN PRINCIPLES FOR WRITING GREAT REQUIREMENTS
• Don’t write about the writing
• Don’t confuse the subject with your work
• Only hedge when you should
• Avoid clichés like the plague
• Avoid abstract nouns, not ideas
• Don’t turn your verbs into nouns
• Adopt an active, conversational style
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢32

33. OTHERWISE, BRING ON THE ZOMBIES
In the first part of this requirement we will explore the difficulty in
creating alignment around the definition of a requirement. We might be
able to institutionalize a universal taxonomy that will
become the gold standard for the
enterprise. If we can create alignment
among the stakeholder community
we create affirmation as to that
universal taxonomy…
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢33

34. Our customers need a common
definition of what a requirement is
in order to improve project delivery.
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢34

35. Our customers must define what a
requirement is in order to reduce
the cost of rework on projects.
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢35

36. IN THE END IT IS COMPLEX…
The definition will depend upon…
• The industry and product
• Standards the organization follows
• People and their capabilities
• Relationships between decision makers
• What people have learned… or not
• Taking the time to make sense
• History of the organization with requirements
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢36

37. BREAKOUT THREE – GIVE IT SOME STYLE
Facilitator: Share the definition and work so far
• What terms have you used to define the pieces of requirements?
• What standard definitions do we need to make those terms clear?
• Based on these terms, what would be a stylish example?
• How could we refine this example to make it clear, concise and
compelling?
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢37

38. SUMMING IT ALL UP
• Requirements, examples, and models co-exist
• Examples and models show how the requirements fit together
• Requirements make sure we have covered all of the bases
• Our job as analysts is to make sure our stakeholders are confident
that they will get what they need
• Clear, concise, and compelling requirements do just that!
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢38

39. WHAT DOES THIS HAVE TO DO WITH BLUEPRINT?
• Our customers must define what each artifact in Blueprint is in
order to use the tool to reduce the cost of rework on projects.
• They will need requirements, models, and examples
• They need to understand how they are all related
• Industry standard and best practice is a starting point
• The definition will have to be right for the organization
• We cannot force one on them
• We must help them come to a definition
© 2015 Blueprint Software Systems Inc. All rights reserved. ⎢39

40. © 2015 Blueprint Software Systems Inc. All rights reserved. ⎢40
How might
better requirements
help you?