banish the word requirements? - marie atallah
TRANSCRIPT
Should we banish the word…
Copyright Marie Atallah 2011
…‘requirements’?An experimental session created by Marie Atallah
Requirements Capture
is a major cause of
division
among Business Analysts
Copyright Marie Atallah 2011
Anything goes!
Choose any path you like to
capturing requirements –
these days, they are all acceptable
Copyright Marie Atallah 2011
these days, they are all acceptable
and
many lead to confusion!
Copyright Marie Atallah 2011
Is the cause of this confusion that the
word ‘requirements’ is just too generic?
What would happen if we banished the word
Copyright Marie Atallah 2011
What would happen if we banished the word
‘requirements’ from our Requirements Catalogues?
To find out, we
put ourselves in the spotlight
to observe how we work.
Copyright Marie Atallah 2011
to observe how we work.
We experimented by brainstorming
potential categories for
Copyright Marie Atallah 2011
potential categories for
requirements capture - for both
unfamiliar and familiar fields of
work
•Engineering / building (Yellow)
•An artistic/design based product (Pink)
We brainstormed categories for a
Requirements Catalogue without
using the word ‘requirements’ for
the following types of projects:
Copyright Marie Atallah 2011
•A musical product (Green)
•A mystery product (Orange)
•An upgrade to a well-known website.
(White)
Yellow Pink Green Orange Off-white
Tunnel to link Alaska and Russia
A computer desk that folds up into a briefcase with
A new Opera to commemorate the Middle
Mystery Product 'Y'
Upgrade E-BAY to offer real-time cattle and sheep auctions with video
Here are the projects that we
considered
Copyright Marie Atallah 2011
briefcase with laptop and cables.
the Middle East revolutions
with video
A revolutionary new aircraft carrier.
Engagement portrait of William and Kate
A new song for Michael Buble
Mystery Product 'Z'
Enhance Amazon.Com to offer a DIY Estate Agency service
New HQ building for Maclaren (Formula 1)
A replacement programme for Teletubbies
An Anthem for the Olympics
Mystery Product 'W'
Enhance www.lastminute.com to offer rightnow.com functionality to offer services / events within 1 -4 hours.
• To share the types of words that we might use
for categories of requirements so that we could
We did this:
Copyright Marie Atallah 2011
for categories of requirements so that we could
explore alternatives to using the generic word
‘requirements’.
• To see if we approach the requirements-
capture process differently when we are in
unfamiliar territory
The experiment produced
an interesting set of
requirements categories for each
Copyright Marie Atallah 2011
requirements categories for each
‘project’ - without using the word
‘requirements’.
The Results also raised a number of
questions for us to ask ourselves…...
iiba banish reqs brainstorm re...
If requirements are presented in a structured
manner, could this ease communication for all
Question 1
Copyright Marie Atallah 2011
manner, could this ease communication for all
concerned?
But how do we know what the right
structure is?
Are we so usually so close to the coal
face that we can no longer see the
Question 2
Copyright Marie Atallah 2011
face that we can no longer see the
quarry?
Question 3
Copyright Marie Atallah 2011
How should the Requirements Catalogue
differ from the Business Case and Project
Plan?
Question 4
Copyright Marie Atallah 2011
Should we do more modelling?Modelling data and functions is an important but often neglected activity
during the requirements capture phase. We refreshed our modelling
skills by attempting to model a song! This provided an opportunity to
think outside the usual boundaries and focus on the modelling process.
Question 5
Copyright Marie Atallah 2011
Should all projects start with a top-
down process analysis?
Should all requirements be captured
in a structured manner?
Question 6
Copyright Marie Atallah 2011
in a structured manner?
Should we model whatever we
capture?
My personal conclusions ….
Copyright Marie Atallah 2011
Should we banish the word ‘requirements’?
YES….........
……to the Title Page of the
Requirements Catalogue!
Copyright Marie Atallah 2011
Requirements Catalogue!
Because ‘requirements’ are
just like
Copyright Marie Atallah 2011
just like
‘vegetables’! The word ‘Vegetables’ could be used on the front of a catalogue, but NOT inside! -
it is far more useful to the customer, to have them grouped into categories e.g.
carrots, potatoes etc rather than ‘Vegetable 1’ ‘Vegetable 2’. The same applies to
‘Requirements’. Of course, the categories may vary according to customer needs,
e.g. a catalogue of Vegetables for the Still Life Art Class may require classification
by colour and shape.
As we saw during the brainstorm, it is
possible to define categories for requirements
Copyright Marie Atallah 2011
possible to define categories for requirements
capture - without using the word
‘requirements’.
As we saw during the brainstorm, it is
possible to define categories for requirements
Copyright Marie Atallah 2011
possible to define categories for requirements
capture - without using the word
‘requirements’.
However, the choice of categories is crucial to the ultimate
effectiveness and measurability of the requirements
My suggestion for
Categories inside the
catalogue,
• Context model
• Required functions i.e. process models (including
business rules, Decision Models etc.)
• Required data i.e. a data model
Copyright Marie Atallah 2011
• Required data i.e. a data model
• Required reporting / MI
• Technical / non-functional specifications (e.g.
performance related requirements)
The Catalogue would also take into account and
make reference to:
• relevant legislation / regulation / standards
• relevant market / competitive drivers,
• relevant best practice / state of the art developments
My own conclusions
� The word ‘Requirements’ is just a collective name for a group of
categories - a requirement (like a vegetable) cannot usefully exist
without further clarification and context.
� Any requirement should always belong to a category (e.g. it is a
Copyright Marie Atallah 2011
� Any requirement should always belong to a category (e.g. it is a
‘process requirement’, or a ‘data requirement’ ) – and each category
should be modelled (e.g. a data model, a process model).
� Each category should map onto a Context model (e.g. a UML
Business Context Diagram, or a Level 0 Data Flow Diagram )
� The Context should always define the scope and provide a backdrop
against which the detail can be mapped.