The document discusses banning the word "requirements" from requirements catalogs. It describes an experiment where participants brainstormed potential categories for capturing requirements without using the word. This produced interesting alternative categories for different project types. It raises questions about structuring requirements and whether modeling should be used more. The author concludes that "requirements" is too generic and catalogs would be improved by categorizing requirements and using terms like "context model," "required functions," and "required data" instead.

1. Should we banish the word…
…‘requirements’?
An experimental session created by Marie Atallah
Copyright Marie Atallah 2011

2. Requirements Capture
is a major cause of
division
among Business Analysts
Copyright Marie Atallah 2011

3. Anything goes!
Choose any path you like to
capturing requirements –
these days, they are all acceptable
and
many lead to confusion!
Copyright Marie Atallah 2011

4. Is the cause of this confusion that the
word ‘requirements’ is just too generic?
Copyright Marie Atallah 2011

5. What would happen if we banished the word
‘requirements’ from our Requirements Catalogues?
Copyright Marie Atallah 2011

6. To find out, we
put ourselves in the spotlight
to observe how we work.
Copyright Marie Atallah 2011

7. We experimented by brainstorming
potential categories for
requirements capture - for both
unfamiliar and familiar fields of
work
Copyright Marie Atallah 2011

8. We brainstormed categories for a
Requirements Catalogue without
using the word ‘requirements’ for
the following types of projects:
•Engineering / building (Yellow)
•An artistic/design based product (Pink)
•A musical product (Green)
•A mystery product (Orange)
•An upgrade to a well-known website.
(White)
Copyright Marie Atallah 2011

9. Here are the projects that we
considered
Yellow Pink Green Orange Off-white
Tunnel to link A computer A new Opera Mystery Product Upgrade E-BAY to
Alaska and desk that folds to 'Y' offer real-time cattle
Russia up into a commemorate and sheep auctions
briefcase with the Middle with video
laptop and East
cables. revolutions
A Engagement A new song Mystery Product Enhance
revolutionary portrait of for Michael 'Z' Amazon.Com to
new aircraft William and Buble offer a DIY Estate
carrier. Kate Agency service
New HQ A replacement An Anthem for Mystery Product Enhance
building for programme for the Olympics 'W' www.lastminute.co
Maclaren Teletubbies m to offer
(Formula 1) rightnow.com
functionality to offer
services / events
Copyright Marie Atallah 2011 within 1 -4 hours.

10. We did this:
• To share the types of words that we might use
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
Copyright Marie Atallah 2011

11. The experiment produced
an interesting set of
requirements categories for each
‘project’ - without using the word
‘requirements’. iiba banish reqs
brainstorm re...
The Results also raised a number of
questions for us to ask ourselves…...
Copyright Marie Atallah 2011

12. Question 1
If requirements are presented in a structured
manner, could this ease communication for all
concerned?
But how do we know what the right
structure is?
Copyright Marie Atallah 2011

13. Question 2
Are we so usually so close to the coal
face that we can no longer see the
quarry?
Copyright Marie Atallah 2011

14. Question 3
How should the Requirements Catalogue
differ from the Business Case and Project
Plan?
Copyright Marie Atallah 2011

15. Question 4
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.
Copyright Marie Atallah 2011

16. Question 5
Should all projects start with a top-
down process analysis?
Copyright Marie Atallah 2011

17. Question 6
Should all requirements be captured
in a structured manner?
Should we model whatever we
capture?
Copyright Marie Atallah 2011

18. My personal conclusions ….
Should we banish the word ‘requirements’?
YES….........
Copyright Marie Atallah 2011

19. ……to the Title Page of the
Requirements Catalogue!
Copyright Marie Atallah 2011

20. WHY?
Copyright Marie Atallah 2011

21. Because ‘requirements’ are
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.
Copyright Marie Atallah 2011

22. So what about
inside
the Requirements Catalogue?
Copyright Marie Atallah 2011

23. As we saw during the brainstorm, it is
possible to define categories for requirements
capture - without using the word
‘requirements’.
Copyright Marie Atallah 2011

24. As we saw during the brainstorm, it is
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
Copyright Marie Atallah 2011

25. 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
• 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
Copyright Marie Atallah 2011

26. 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
‘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.
Copyright Marie Atallah 2011