Chapter 4 - Gathering requirements

Gathering Requirements

Gathering requirements is a sortie into the unknown. Someone wants something from you; they are even prepared to pay you to get it. All you have to do is get into their head and figure out what it is they need. They may not be very good at articulating their vision, but they will no doubt have a strong case to uphold their desires.

You must also begin to find out from them who the other stakeholders in your project are, and what it is that they want. This is a tough job. What your sponsor wants, and what your users want are often opposing ideas. You have to resolve their conflicts, and clarify their ambiguities.

When gathering requirements, you must identify all external interfaces to your project, people included. You must talk to them all, sometimes together, sometimes apart, depending on the political situation, and somehow end up with a clear message of what their collective need is.

The high level questions to be answered are: what does the product have to do, and who and what must it communicate with to be able to do so?

If you think this is the easy part of the project, think again. Remember, you are partially responsible (fully responsible if you are analyst and software architect). It could be your responsibility when you miss the crucial question that would have identified the antagonistic subgroup who decides to burn down your building because they do not like the company for whom you are writing software. More likely, you will miss a crucial piece of functionality that has to be fudged into the project at a later date, spoiling your beautifully crafted solution.

As Fred Brooks points out:

The hardest single part of building a software system is deciding what to build. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.[1]

Ask the dumb questions, but ask them with purpose. People who ask dumb questions are usually idiots. You are seeking to understand. Never try to guess what is in your sponsorís mind. Use walkthroughs or scenarios. Keep an open mind. As you explain back to your audience what you think they have said, slow down your explanations into easy steps and use illustrations where possible. Remember, your sponsor is not a software developer. You must avoid words like database and user interface. File, storage and screen or page may be acceptable.

Requirements must be free of implementation details. For example, User must be able to identify themselves to the system is a realistic requirement. User must be able to enter their username and password using the keyboard might appear realistic enough, but when it comes to reengineering the system in the future, the same requirements should be reusable. In years to come, software designers may guffaw at the naivety of using a keyboard and the absurdity of a username. It may also be that the solution stated in the requirement is the wrong solution, and based only on the experience of the user. Enshrining solutions at requirements stage can lead to designs which are not necessarily best.

Why gather requirements?

You may wish to gather requirements:

You may also wish to avoid gathering requirements.

Gathering requirements blindly can limit you to getting what you think you want, or limit your sponsors to getting what they think they want.  

When you do not gather requirements, you do not begin to formulate a solution. This may be the best way to go about purchasing a piece of software. If you gather requirements, then fit each potential suitor to your requirements, you may well filter out the best suitor for your enterprise.

You may also not gather requirements initially in the hope of creating an insightful solution to a problem before becoming lost in, or guided by, the detail. In this case, you will still need to gather requirements, and must sell your prototypical ideas to your users to mould their requirements thinking before compilation.

You may consider you have no need of gathering requirements.

If you have ever thought 'hey, I can make my software really cool by doing x', then you are creating a solution to an imagined requirement. You may find it is worth writing down the requirement first and testing it out on a potential user:

programmer: "I'm thinking of putting in a friendly popup animated paperclip to help you through difficult tasks."
potential user
: "Doh!"

You may save a few units of currency, hours and neurons.

If you have ever thought: I don't do requirements, I write software! You are simply gathering requirements less formally as lists in your memory, or scrawls on post-its. A formal statement of requirements can be tested, discussed, agreed and refined.   

So how do you go about it?

Have you ever seen a man - a gendered man in this case rather than a homo sapiens of either calling - rush into a train station late, flustered, and jump on any train about to depart? Any train on any platform, whether it is the right one or not? I have never seen a woman fall to such foible. Then, when the man realizes he is heading north, not south, his agitation becomes fierce and vocal.

The train is a software development team, the man a customer. The journey is his solution, and the wrong direction headed, the software he has been landed with. His requirement was first train south. He got the first train, but unfortunately it was north as he did not have sufficient time to tease out the train direction. The train selection happened within a few heartbeats. Software definition is merely the same lack of time, understanding and communications built into a deliverable product. As gatherer of requirements, you are putting yourself on the platform in the right place at the right time to enable your man to get the first train south.

Such a brave stance in the line of withering fire may or may not be part of your job. If the project is for an external client, it is likely they will provide a business or technical analyst with whom you will work to discover and reconcile requirements. If this is the case, and you should hope it is, then the analyst leads the process. It is the analyst who has overall responsibility for discovering and documenting the requirements. Your input should be to cover possibilities, act as a peer whom ideas can be bounced off, and contribute past solutions to problems to drive the requirements to newer highs.

Two good things can come out of gathering requirements. One is the requirements. The other is to give the early project team a sense of identity and brotherhood. You are in this together.

You must also extract requirements rather than writing down long lists of what the product must do. You must create the fine line between requirement and user whim, and document only the former.

You must not expect to get all of the requirements in one hit. It is an iterative process and must continue well into the project. Intermingling your thoughts with the users' is essential to guarantee the delivery of a product to satisfy their needs. Even more importantly, if the users have had significant and constant communication with the software creators, they will get ikiwisi Ė Iíll know it when I see it - software.

Do not rely on the poisonous practice of document sign off to finalize requirements. It is the equivalent of saying: I have no faith in what I have done, and even worse: I do not trust you, and should we have a disagreement later on, I shall use your signature against you.

Some may argue that document sign off is necessary to force the users into the mindset that they must check and agree the requirements, so that later changes can be avoided, and that the requirements, once met, signal the end of a project, and possibly some monetary flow.

The sponsor and user groups are a part of your project team. You and they are collectively responsible. That responsibility must be stated and accepted by all team members at project inception. You must work with them throughout the project. They must be included in risk management when something goes wrong. They must be consulted on every change, and every step of development and delivery if you are to deliver what they need. Sign off on requirements is to accept that you might not deliver, or that if you do deliver, it will be to their requirements at the start of the project. Three months down the line, the business, or system, may have changed so much that your work is useless. Then you have delivered a useless piece of software, have put up with the stresses, strains, late nights and damaged relationships for nothing. You have wasted your time, and that is in short supply for all of us.

You can gather requirements in three ways:

The three methods above are not exclusive-or, you may intermix them freely.

Modelling the best user - one to one - monarchy

When modelling a heavily manual process which is to be automated, modelling the best user is the best way to go about it.

In other environments, using this method alone is a path for the brave and possibly foolhardy, and should be done with care. From a business perspective it appears, and can be, the best way to get the job done in the least possible time. It can also lead to software dead-ends.

The way to do it is this: sit with your user, and ask them to show you what they do. You write down the process flows, asking questions where you need to dig a little deeper, or understand a little better.

The following questions need to be on the tip of your tongue

Whenever you can, get paper documents and screen prints. Create activity diagrams, and talk your user back through the process as you understand it. You will find them only too willing to help you get it right, and it can make your job a breeze. Always bear in mind that you are trying to understand them, you are not trying to make them understand you - that will come later.

Interrogating informants - one to many - oligarchy

Understanding how a few people do what they do will give you the clearest picture. You will not fall into the trap of sating your best user and disabling or alienating the rest. Neither will you sit through the fog of user groups awaiting a clarity which seems forever delayed. 

Interrogating informants is modelling a representative sample of users one at a time. User groups are representative samples tackled together.

User group meetings - many to many - anarchy

The last exercise is the traditional one for most analysts. It is also the most frustrating and inefficient. Getting lots of people in a room and discussing how they do - or want to do - things will lead to many drawn out conversations. After sitting through enough user group meetings you may conclude that people cannot describe what they do - they just do it.

Good chairmanship is the key to productive user group meetings, but unfortunately at this level of operation, good chair-people are as easy to find as tears in the rain. It is not a quirk of language by which the leaders of organisations are blessed with the title of Chairman.

Here are a few schedule ideas for getting a user group together. Remember that this motley collection of people are part of your project team. If you can create a synergistic atmosphere in these meetings, you will deliver a far better product than if you create an adversarial atmosphere. I would go as far as to say if you create an adversarial atmosphere, you will not deliver at all. Handing a compiled product to them is not delivering!

Day 1. Preliminary user group meeting Ė one to two hours

Do not expect to get any requirements out of the first user group meeting, especially if they do not know you or each other. Instead, use this meeting to create a team spirit, and identify your expectations and the process you will go through to find out where you and they are headed.

1. Establish your credentials

Tell them who you are, and make it sound good. Let them know they can trust you to help them. Call people by their names. Nothing is sweeter to a person than the sound of their own name from the voice of another (where cultural practices permit).

2. Explain what the purpose of the user group is

A user group is a team of selected users who will provide insight into their activities for the benefit of the software developers.

3. Explain what you want

An open meeting where all ideas are encouraged.
Free speech from all.

Tell them how you will allow everyone to have their say by summing up discussions with a round robin approach. You all end up somehow in a logical sequence (circles are best, but not easy with the way we design rooms and furniture) and each person has their say in turn about their ideas, thoughts and doubts.

To silence the obstinate ridiculers, here are two short scripts you might use:

Script 1: "I have seen a great and insightful idea ridiculed into non-existence by someone who just didn't get it."

No-one will want to to be seen not getting it.

Script 2: "Sometimes a great idea will come from a member of a user group. For a moment, fate will hang around the great idea and lead or fall on the next word. So if you hear a great idea, pick it up and support it. If you hear what you consider a bad idea, pause a moment, and wait to see if another can recognize and polish the hidden gem."  

4. Explain how these ideals will create a far better software product

There will be better ideas, and ideas that can be morphed into software solutions. If everyone has input, then nothing will be missed out of the software.

5. Explain what you donít want

Rubbishing of other peopleís ideas.
People talking and not listening - get a conch if you have to.

There may be a Jack in your user group. The meetings can dissolve into chaos, but that chaos can be good, as people search for ever more radical solutions. You must ensure that out of the chaos and excitement, you end up with enough information to deliver.

Day 2. Identify preliminary requirements Ė half a day to one day

Scope out the project, and begin to flesh out the bones provided in the Project Initiation Document.

This session will be filled with discussions around statements compiled by the Business Analyst on how the participants in the user group do their work. Each task will be outlined as a scenario or series of steps, and the group will argue their way through it, clarifying options and preferences as they go.

Further meetings

Then meet once a week, or once a month, whatever you believe will be most beneficial. In subsequent meetings, the user group is informed of what is happening in development and what decisions have been made. Should these decisions be wrong, you have lost only a small amount of time. Some projects find they have followed the wrong decisions only upon delivery. That means they deliver a product, but do not deliver to the needs of the users.

In brief, here is what you want to discover during the user interviews:

  1. Who are the stakeholders?
  2. Who are the actors with which this product must connect (people, other systems and objects)?
  3. What does the project need to accomplish?
  4. How does the user group think that these accomplishments will be best met?
  5. How often do all of the things the product must do happen?
  6. How can the success of the project and product be measured?

During all of these meetings, you have a dual goal of extracting information and building your reputation. To do the latter, you may find it useful to observe other technical people and learn from their mistakes before you make them yourself. Some, for example, dive at the whiteboard to force their point of view on the discussion, or fall to lecturing. Others talk too fast for people to follow and often lose words somewhere between their throats and mouths. Keep in mind that you're just having a chat to discover what is done or what they would like to do. Don't start defending a point of view or get upset over some irrelevance. If it gets too heavy or boring, leave. Get a drink or a snack, or some fresh air and go back in when you feel you can contribute usefully once more. 

Identifying the stakeholders

The most important stakeholder is the project sponsor. This is the person who will ultimately sign the bill. He or she is by no means the only stakeholder though.

There are three varieties of stakeholder

Everyone who works with you on the project is a stakeholder, as is your boss and his boss. Their pay probably depends upon the successful conclusion of your work, and as a Software Architect, you are likely to be held at least partially responsible for non-delivery.

Question: How many stakeholders does it take to change a light bulb?

Letís ponder on this a while. You will be facing such thoughts. We shall draw some analogies. In the left column of the ensuing discussion is the story of a light bulb which naughtily goes out. Your family are all in on the race to get it fixed. The kids are tearing around the house in the excitement, banging their heads off table corners. In the right column is the owner of a company wanting some software. His thoughts are racing around in an unfamiliar domain, and he has that dangerous bit of knowledge...

Last time the light bulb went out, you had to get an ambulance because your mother fell down the stairs when her candle went out.

Last time you worked for this customer, he wasnít happy with the solution, even though you gave him exactly what he asked for. This time your boss has told you to deliver not what he asks for, but what he needs.

The light bulb

It is dark. You have to find a light bulb.

The kids are in on your search, your wife is sure she has one in a cupboard somewhere, but itís dark. No-one can see. Youíre all moving around with outstretched arms.

You can see your mother coming down the stairs, with a flickering candle lighting her way.

Is she going to help you find the light bulb, or show you how candles are better? You have more control over them you know. When she was youngÖ

Of course, you know that light bulbs are part of a whole system bringing you better and more convenient lighting. A failing light bulb is a minor inconvenience.

The software project

There is not yet a project vision. You have to create one.

Your development team members have differing ideas for the project, as does the sponsor. Everyoneís moving around in the dark, and slowly creating their own lights.

The sponsor has a bright idea. He will lead you to what he perceives is a good starting point.

Heís heard that files are far quicker than databases and is sure this is the way forward.

You know in this case, that databases are the best way to store the data. How can you get your sponsor off implementation specifics and onto his business needs?

In the short story of the light bulb and the candle, the primary stakeholders are obvious. It was you, your wife, your children and your mother.

Who else is a stakeholder?

You know for a fact that when your mother carries anything down the stairs, she doesnít look where she is going.You have warned her many times that carrying things down the stairs is dangerous for her and she should avoid it. She never listens though, and has fallen down the stairs three times in the past year while carrying something. And here she is, carrying something in less than ideal conditions.

If she never fell, then there are no more stakeholders. If she does fall, then who is a stakeholder? Certainly the ambulance driver and nurses and doctors who check her over. If you need petrol to go and pick her up afterwards, then your local garage is a stakeholder, as is the manufacturer of your car and petrol refiner. All that burning petrol is also bad for the Earth, and there are groups who oppose the use of cars now petrol is getting scarce. Suddenly there are millions of stakeholders just because stairs are dangerous. Youíd think we would have invented something better by now.

What if you decided to go the candle route? Would the light bulb maker go out of business? Would the national grid be better off? Would the candlestick maker be happier? Would the air be less healthy? Would it be more romantic?

Everyone affected by your project, either directly or indirectly, is a stakeholder. You must decide whether their stakeholding qualifies them for input into the project.

Standing in other people's shoes

In To Kill a Mockingbird[3], I was told when I studied English, the most important lesson to learn is how to stand in another personís shoes. That is, to be able to see things from another personís point of view.

If you can see something from anotherís point of view, you will be able to understand them far better, and that means you will be able to empathize and communicate with them far more easily.

I do not believe there is a lesson more valuable. I wish I could do it better, and more often.

Make a quick list of the stakeholders in the tiniest project you have worked on. It may look something like this:

Me (top programmer)
Bill (my mate who likes writing SQL)
Ben the tester (chap who likes finding obscure problems)
My boss (old fool, why doesnít he retire? I could easily do his job)
The owner of the company (he always ends up talking to irate customers when things go wrong Ė I think he enjoys it)
The salesman (he always promises too much)
The customer (clueless!)
The users (brains the size of plants)
Their customers (who cares? Ė Iíll never have to talk to them)

Now letís stand in their shoes a while, each one in turn. What do they think:

Of you?
Of your company?
Of the product they want to buy or have bought from you?



(Of me) Iím great. Iím the best programmer weíve got.
(Of our company) Itís OK I guess, we get cakes now and then. I donít get paid enough though.
(Of the product) Iíll end up writing most of it, but then I always do. No-one appreciates my efforts


(Of me) Heís OK, doesnít know anything about databases.
(Of our company) Itís OK I guess. I donít get paid enough though.
(Of the product) Iíll end up writing most of it, but then I always do. No-one appreciates my efforts

Ben the tester

(Of me) I could write better stuff than him. Nothing he gives me ever works properly
(Of our company) Itís OK I guess. I donít get paid enough though. If it wasnít for me we would certainly put out a load of rubbish.
(Of the product) Iíll end up having to tell them how to write most of it, but then I always do. No-one appreciates my efforts.

My boss

(Of me) I wish heíd be more professional, and try to understand the business a little better. Iíll be up for retirement soon, and he may take over my job, perish the thought.
(Of our company) Itís OK I guess. I donít get paid enough though.
(Of the product) We must do it better this time. I wish they would listen when I tell them to spend less time thumping out code, and more time thinking about what theyíre going to write. I should make them use punched cards like I had to do when I started. Itís a good job Iím here or the boss would spend all day screaming at them.

The owner of the company

(Of me) As little as possible
(Of our company) Why donít they get on and do a proper job. Iím tired of bailing them out. I donít get paid enough for all of this, and my ulcer is playing up. Oh no, Iíve got a lunch date with Jimmy Wilkins. I donít know if I can put up with him today. Still, heís the customer. Why does no-one understand what I have to go through to keep them in a job?
(Of the product) Why doesnít it work properly? I click here, and press this button, and the whole thing falls over. We canít release this!

The salesman

(Of me) I tell him exactly what the customer wants, and he still canít do it. Iím not looking forward to that meeting later this week. Itís all his fault. Why doesnít he do what I tell him?
(Of our company) I donít get paid enough for all of this. I should have a better car.
(Of the product) Mon Dieu!

The customer

(Of me) Anorak
(Of our company) I donít know why I keep using them. I donít know who else to go to though.
(Of the product) Thatís not what I asked for.

The users

(Of me) Anorak
(Of our company) I donít know why we keep using them.
(Of the product) Why donít they write better programs? They always crash and they never do what we want. I wish theyíd ask us when theyíre writing this stuff. Weíre the users after all.

Their customer

(Of me) They donít
(Of our company) Again, they donít
(Of the product) Look, all I want is a list of all the orders we made for this financial year. The software should be able do that. Itís a simple enough request.

Standing in other peopleís shoes is a scary thing to do, but probably the most valuable lesson you can learn. You wonít always get it right, but you can at least try.

Try it next time youíre out shopping with your loved one. Are you the one wanting to visit the twenty-third clothes or gadget shop, or the one expected to show some enthusiasm?

Try writing down all of the stakeholders for the project you are currently working on. Next to each, write down what you think they will expect from the system. If you donít know, how can you expect to deliver? Go and talk to them. It may be your first journey as a software architect. Share your ideas with them, get some information. Ask them for their ideas.

It is entirely possible that you are shielded from all possible contact with the customer, and that requirements always come through the salesman or analyst. Be bold. Speak directly to the project sponsor or user. You can not afford to play Chinese Whispers with requirements.

Identifying the actors

While you are building up the list of requirements, you should keep in the back of your mind that when you begin analysing them, you will be looking for the actors in the system. These are the people and objects with which the system will interact. To better identify these actors, you should always try to write the requirements in the form of subject, verb, object when you can. We shall see in analysis how this will help.

Discovering what the product might do

In the user interviews, you will discover many wonderful things that the product might do. Many people will happily list requirement after requirement, which will merely be their own personal whim. One person might say ďAll warning messages must be in redĒ. Another might add ďLess severe warnings could be in orangeĒ Yet another may say ďI disagree. All warning messages must be in bold black twelve point Helvetica.Ē

These are preferences, not requirements. Agree to let the setup of the system define typefaces and colours and state the requirement as The system settings will define all colours used in this application. If you do end up with All warning messages will be in dark red bold twelve point Helvetica, except when they do not prevent the current item being executed, then they will be orange, you are losing the battle. 

It is even more likely for someone to ask for something logically sensible (at least to them) yet technologically absurd. This is when negotiation by your good technically astute self will shave weeks off future argument. You might say something likeÖ

"Ö so instead of the eSandwichRequest automatically beaming you to a sandwich shop in Barbados when you fancy some spicy prawns, I think we can agree that the canteen will deliver to your desk just as effectively."

Digging in

Donít be afraid of digging in through the layers of need. It could save you a lot of time in the future. Consider the following conversation:

User: I need it by Friday because we run invoicing on Friday and that means we get paid earlier by the customer.
Analyst: How does getting paid earlier help?
User: It means our profitability is better.
Analyst: Does good profitability affect you in any way?
User: Yes, I get a better bonus. It is linked to how I control the age of payments.
Analyst: And why is your bonus important?
User: My wife wants us to get a new car this year.
Analyst: Why?
User: Smoke comes out of the exhaust on our current one, and sheís into environmental concerns.

The benefit to the business is that aged debt is less.
The benefit to the user is that his wife is happier, and therefore he is happier.

Needs are usually very delicate things. Imagine if our user went home with an amazing new exhaust invention which filtered out everything from the exhaust fumes. You might imagine his wife would be happy. He might discover that she really wanted a new car and was using the environmental impact of the current fumarole as a means to getting one.

What is a requirement?

According to the IEEE:

(1) A condition or capability needed by a user to solve a problem or achieve and objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. (3) A documented representation of a condition or capability as in (1) or (2). [5]

Here are a few examples of a requirement

Some people prefer to think of requirements as being a certain type. Functional, non-functional, technical, inverse and constraint requirements may be considered as requirement types.

Functional requirements

These are the fundamental building block requirements. Each is a statement of exactly what the software must do

Non-functional requirements

Some refer to these as global or system requirements, or call them the ~ilities. They are concerned with security, performance, portability (across operating systems), testability, understandability, etc.

Technical requirements

Some requirements documents will be composed entirely of technical requirements. If you (as architect) have extracted the need for a common component from a set of business requirements, then the component can be spun off as a separate project, and delivered against a set of technical requirements such as:

Inverse requirements

What the system must not do.


Often, software systems are expected to run on hardware already in place, or meet previously defined look and feel specifications. It is possible that it must run on specified hardware under security already in place, or be delivered according to a certain methodology. All of these requirements are constraints.

Architectural requirements

Architectural requirements are added as a means of moulding a software project to an encompassing architecture, or extracted from one project to provide a foundation for others.

It is not necessary to group requirements according to these headings in a requirement document. The value of being able to identify a requirement's type will help you to understand how and where to deliver it.

Discovering system throughput

During requirements gathering, you must identify the system throughput. The questions to answer are:

Consider the following conversation about a sales ordering system:

Sales Person: Jill Bird ĎWe take a hundred orders a day each, and there are twelve of us.í
Sales Person: Gill Warden
ĎYes, but most of them come in between 9am and 10am or 3pm and 4pm, before the order cutoffs. Yesterday I took about twenty orders before the morning cutoff.í
Business Analyst: T. Leaf ĎAre there any days or months where more orders come through than normal.í
Managing Director: Lettie Hout ĎHere is our monthly distributioní Ė presents chart marked Evidence 1 Ė ĎWe also get more orders on a Monday, probably twice as many as on other days, and of course, there are always the post holiday explosions.í
Software Architect: S. Capee ĎHow many order items are there on each order.í
Operations Manager: Cliff Gard ĎOur average is 1.6. Weíre trying to get that up to 2. It depends on the customer. At the moment we take a maximum of fifty lines per order, which occasionally means placing two orders for the larger customers who compile their orders and place only one a day. What we really want from the system is to be able to get in the order details as quickly as possible.í

From this discussion, you can see an order most often contains only one or two items and you have enough information to write a detailed order distribution graph by day, week, month and year. You have no excuse now for an overloaded ordering system. The last Ďquickly as possibleí needs assessing. Does it mean they want to be able to type quickly? Do they want a digital telephone system to pop up order details based on the callerís telephone number?

Discovering how the project and product success can be measured

Software products must save time, money or effort. As more effort takes more time, and time costs money, we usually address all three.

There may be a requirement of

Such as requirement can be broken down into a benefits case. The cost saving benefit in pure processor time will save the company $20 per process. At 100,000 processes per day, that will save in the region of $2M per day. If other effects come into play such as a faster time to market, less stock inventory etc, then they too can be built into the benefits case.

Benefits cases must always be balanced against development phases. Hit the biggest, easiest benefit first, and measure the benefits case against each phase as you go. There will be diminishing returns beyond the first phases, and you must ensure the benefit is always bigger than the cost of development and delivery. 

One expression for this approach is the 80/20 rule, where you hit 80% of the development by doing 20% of the work. I prefer the term gather the low hanging fruit. It is for people to grasp.

How to specify requirements

Requirements are usually displayed in a requirements shell. The shells are used to ensure information is complete, and can be traced back to its originator. Here is an example of a shell:

Requirement No. 1 Use Case or Event No. 1
Description We must monitor the following environmental states: temperature (internal and external), light intensity, humidity, external wind speed, pollen count.
Rationale Although all of these measurable states must be available, not all will be enabled, nor connected to an external sensor or group of sensors. Yet these are the conditions we display in the presidio product
Source Engineering (Pete Weaver)
Test All controller inputs must be calibrated and tested over one week to monitor drift. The output of the unit must be mapped against the calibration unit.
Supporting Materials \\DocStore\Reports\Drift
History These are the environmental factors we monitor, and have built our business on
Must have X Dependencies Marketing material is in preparation
Should have
Could have Conflicts None
Would like

Figure 4.1 Requirements shell

Requirements are supported by walkthroughs, or scenarios. In these brief plays, the stage is set, the actors appear, they fulfill their obligations, then exit. For example:

A customer calls on the telephone. A salesperson, already connected to the system, identifies the callerís account and enters the accountís initial screen. The display represents the status of the customer, the options available to them, and any special offers they might like to take advantage of. The customer opts for the free see-through stapler, requests the current balance of her account and decides to place an order. She asks for three packets of pencils, a pencil sharpener and a stapler, requesting the price of the total order before confirming that the order is complete. She then hangs up the telephone.

Scenarios such as this are very useful when identifying the detail of the requirements, and the conditions by which they may be fulfilled.

The document or system for recording the requirements must be formatted in a standard way, ideally from a predefined template. It is confusing for developers or anyone else receiving many different formats of requirements document.

Presenting requirements to software developers

Requirements are presented in the shell of figure 4.1 and supported by other pertinent information. They should not be presented in any hierarchy. Relationships are defined by the dependencies and conflicts of each requirement. Number them 1, 2, 3 and donít get carried away with alternate numbering schemes.

The other information in a requirements document sets the scene for the requirements, and builds upon the knowledge of the PID. For example, you may include:

The current situation: How the work is carried out at present

Stakeholders: Who they are. What their involvement is.

Roles/Goals: What are the roles involved in these requirements, and what goals or activities are associated with the roles.

Assumptions: What is assumed by these requirements.

Constraints: What environment do these requirements fit in.

Dependencies: What are these requirements dependent upon, or what is dependent upon these requirements? Also, what is this project dependent upon, and what is dependent upon this project?

OK, Iíve got my requirements, what now?

When you have what you consider is most of the requirements, you must analyze them to check that they are stated clearly enough for you to build some software. This is the process of analyzing the requirements.

We need to stretch our waterfall a little more at this point, and introduce the falls of analysis and design, which precede writing code.

Figure 4.2 The waterfall model showing analysis and design

Analysis is very much a part of the requirements process, and should continually feed back into the requirements themselves.

Requirements beget requirements

Think about the Apollo Program. It started with one requirement: Get a man to the moon. That probably triggered another: and get him back safely. From there, requirements grew like leaves on a tree.

The reality of requirements

If you have ever tried to draw anything in a word processor, or write anything in a graphics application, you will have seen the limits of the requirements process. I am sure that the word processor users wanted to draw. I am equally sure the graphics users wanted to write, but most of this software is not written by gathering requirements. It was written by programmers with hives of bees in their bonnets. All of the original spreadsheets, word processors, photomanipulators, vector graphics packages, databases and games were produced with only very high level requirements. 

And in this software, the reality is that until it was programmed, it was unlikely that it would have been specified as a requirement. Can you imagine Joe Public specifying that he would like to be able to use Phong or Gouraud shading before it had been thought of by the development team? The benefit of this approach is that groovy new software can be driven out by talented individuals. The problem is that by the time requirements are specified - I want to draw in the word processor; I want to write in the graphics package - they become too difficult to do.

In business and technical software, the situation changes. The experts are the potential users. Here, the development team will begin with the least understanding of what the software must do, but still the best understanding of what it can do. This is where synergy, cooperation and collaboration can make superb software; it is also where the greatest political challenges lie.

Where can I find out more?

Requirements gathering is discussed as a subject in its own right by many authors. Perhaps the high regard in which these books are held is an indication that the people who can best gather requirements are those who can most clearly understand how to articulate them in written form [5], [6], [7].


  1. No Silver Bullet: Essence and Accidents of Software Engineering, later reprinted in Mythical Man Month, 20th Anniversary Edition. Frederick P Brooks. Addison Wesley
  2. The Lord of the Flies. William Golding. There are many imprints of this novel.
  3. To Kill a Mockingbird. Harper Lee. There are many imprints of this novel.
  4. IEEE standard of Software Engineering Terminology. IEEE Std 610. 12-1990
  5. Mastering the Requirements Process. Suzanne and James Robertson. Addison Wesley.
  6. Exploring Requirements: Quality Before Design. Donald Gause, Gerald Weinberg.
  7. Software Requirements: Styles and Techniques. Soren Lauesen.
  8. Click here for the US book list
    Click here for the UK book list