Banish the word Requirements? - Marie Atallah

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


Anything goes!

Choose any path you like to

capturing requirements –

these days, they are all acceptable


these days, they are all acceptable

and

many lead to confusion!


Is the cause of this confusion that the

word ‘requirements’ is just too generic?

What would happen if we banished the word


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.


to observe how we work.

We experimented by brainstorming

potential categories for


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:


•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


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:


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


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


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


face that we can no longer see the

quarry?

Question 3


How should the Requirements Catalogue

differ from the Business Case and Project

Plan?

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.

Question 5


Should all projects start with a top-

down process analysis?

Should all requirements be captured

in a structured manner?

Question 6


in a structured manner?

Should we model whatever we

capture?

My personal conclusions ….


Should we banish the word ‘requirements’?

YES….........

……to the Title Page of the

Requirements Catalogue!


Requirements Catalogue!

WHY?


WHY?

Because ‘requirements’ are

just like


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.

So what about

inside


inside

the Requirements Catalogue?

As we saw during the brainstorm, it is

possible to define categories for requirements



capture - without using the word

‘requirements’.

As we saw during the brainstorm, it is




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


• 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


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

Banish the word Requirements? - Marie Atallah

Business

Transcript of Banish the word Requirements? - Marie Atallah