building requirements with style

BUILDING REQUIREMENTS WITH STYLE

Cole Cioran

Program Manager Requirements Definition and Management

May 29, 2015

© 2015 Blueprint Software Systems Inc. All rights reserved.

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


Discussion

of the

Method


What How

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


SO, WHAT IS A REQUIREMENT?


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

WHAT IS THE INDUSTRY STANDARD?



Everyone

has a

different

definition.

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


A GOOD RULE OF THUMB?


If it has

“requirement”

in it’s name it is

a requirement

EXAMPLE: BUSINESS RULES


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.

WHAT ABOUT?


Constraint

Risk

Specification

Glossary

PrincipleValue

Goal

Heuristic

Need

ObjectiveRule

StakeholderDiagram


How do we

make sense

of all of this?

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?



Exemplia

Gratia

e.g.

Id Est

i.e.

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.


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>.


THE PROBLEM IS…


WHICH IS WHY…


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.


THE PROBLEM IS…


WHICH IS WHY…


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


WHAT ABOUT MODELS?


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


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?


WHAT MAKES WRITING REQUIREMENTS SO HARD?


HOW DO YOU WRITE A GOOD REQUIREMENT?


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


WHAT MAKES A GOOD REQUIREMENT?


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.

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


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…


Our customers need a common

definition of what a requirement is

in order to improve project delivery.


Our customers must define what a

requirement is in order to reduce

the cost of rework on projects.


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


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?


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!


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



How might

better requirements

help you?

building requirements with style

Software

blueprint software systems

information systems

building requirements

better requirements

solution requirements

business event

business rules approach

halle business rules