There are as many answers to that question as there are practitioners of the subtle art of requirements gathering. I think it’s important to employ common sense and not adhere to a purely academic approach here. Ultimately you are dealing with software for people, and people don’t always behave rationally. And seldom do they read the books that tell you how requirements elicitation should be performed.

So I take a practical approach. I start by trying to work out where the boundaries of the system will be, and who will be joining in the game. Even if the parties are not interested in participating, I still like to be able to see all the moving parts and work out what I think the potential impact will be on these parts.

I’m not arrogant enough to believe that you can entirely predict the behaviour of real people when faced with a new set of processes and procedures, so I like to take it right back to basics and take the end users and other stakeholders with me.

I start by writing down everything anyone tells me, and who told me it and when. From this, i assemble a list of assertions about the world, which I call TRUTHS. These are things that must be true of the new system e.g. ‘a User must be able to locate an item of inventory on a shelf’. I’m not calling them requirements at this stage as this hasn’t been tested yet. Once I have a set of TRUTHS, these must be tested by the stakeholders to see if they are indeed TRUE. My definition of TRUE encompasses the idea of being always true for the given problem domain. If your business changes and stops keeping inventory, you have changed the problem domain and will have a new set of requirements to satisfy.

TRUTHS do not include such things as ‘we must send x letter withing 4 days’ as this is not always going to be true. This is a POLICY. This is a rule devised by the business to control how something is done, not the things that must be done. POLICY-type requirements can and will change. Pressure on staff may mean that 4 days is not possible, and the POLICY changes to 5 days. But you will always need to be able to locate that item of inventory.

Also in the mix are a type of externally-introduced POLICY that I call a LAW. This is where legislation or possibly even laws of physics determine what the system must do. I make the distinction between POLICY and LAW to show which items come within the control of the commissioners and which don’t. Sometimes the distinction can be hard to make, if your POLICY is as a direct result of compliance with legislation. I use inheritance to express where a POLICY is connected to a LAW (and therefore subject to change if the legal basis for it changes).

Once you’ve established all the things that must be true of the finished system, everything else is probably a WISH. This is not to say that these are optional, frivolous or should be discarded without consideration. It will be many of the WISHes that make the difference between a perceived failure, and a resounding success.

I think it’s important to get the stakeholders thinking about the semantics of their requirements, because it’s important to consider *why* something is a requirement, especially when trying to prioritise. If you don’t know why a system should do something, how do you know that it should?

A side effect of this process is that people begin to really question what they do and why they do it, which can only be a good thing.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

The short answer is, you can’t hope to.

There are many reasons why this can’t happen, but the most striking one for me is that of elapsing time. If you express your needs perfectly on day one, by day two a new requirement may have occurred to you. By day three your competitor has made a move that you need to counter, by day four there is a new piece of legislation that you need to comply with etc etc. I exaggerate, of course, but not by much. This is why, with the best will in the world, and the most intelligent people determining the requirements, the requirements for the software at the point of delivery may no longer resemble the requirements at the start of the project. Importantly, this is no-one’s fault. But it does leave you with software that is not fit for your new purpose, and that is everyone’s problem.

To me, requirements need to be living things. They need to have a birth, they must have parents (originators), they must be examined at regular intervals to make sure they are still healthy, and sometimes they must die and be replaced by new requirements. A requirement that does not meet these rules, is not a true requirement, as it cannot be justified. So if your requirements are just sentences adrift in time and space, can you be sure they are truly requirements?

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Much as I generally dislike Jack Straw, my opinion of him improved somewhat as a result of his ability to change his mind. As far as I understand the 30-second news story, he did the right thing. He had an idea, it looked to him like a good idea, he asked a few people what they thought, they didn’t like it and said it was a bad idea, he wasn’t sure, so he decided not to go ahead with what he now wasn’t sure was a good idea. If only more people felt able to do that.

From my perspective, he got two things right: he canvassed opinion, and he then used that to revise his decision. It is not a sign of weakness to ask other people to think about your problem with you. It is not a sign of weakness to then use their advice. It is not a sign of weakness to change your mind. It is a sign of weakness to blindly go ahead with what you now see is a bad idea just because you are not brave enough to hold up your hand and say you’ve made a mistake.

The same applies to development projects: if you see you’ve made a design mistake, you can always paper over it and leave it as a hidden treasure for the maintenance programmer who inherits the system. Or, you can bite the bullet, admit you’ve got it wrong, and then re-do the work until it is right. Unfortunately, it is hard to communicate to non-techs exactly why you need to re-do the work and why you are adding extra time to the project. It’s easier to pretend you haven’t noticed the problem and just steam ahead and meet deadlines.

The trouble is, when you get it wrong, users suffer. Good software is invisible to the user – they stop noticing what they are using to do their job, and just do their job. Bad software makes every task seem difficult and awkward. So I would argue (and have done) that it is better to nip the problems in the bud in the development stage, rather than leave it for someone to apply sticking plasters later on.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Most companies have some form of IT infrastructure: you almost have to. Most of the companies that have this IT infrastructure, do not appreciate what it can, and does, enable them to do. Which is excellent, because good IT should be unobtrusive; it should be a natural part of your everyday life and enable you to do your job more effectively.

Time progresses and technologies improve, but has your business reevaluated its IT strategy lately? What is there available now that could help you survive this downturn? Is there any way you could invest some money now and enable your operation to become leaner, smarter, faster. Evolution doesn’t just apply to nature, you know.

Almost every day, I come across an instance of a user-grown ‘system’ that has evolved to try and cope with a demand. It’s not the best solution, but it does the job. Once I’ve worked out what that job is, I can then rationalise the process and smooth off those rough corners that have been a niggle for the users. I am always amazed with the ingenuity of people when faced with a problem. Sometimes the solutions they come up with just need a little automation to make them more efficient.

The other day, I met with a group of users who have a particularly cumbersome application designed for them. The original user of the system signed off the development work solely on the basis that it was ‘better than what we had before’. So, over the years, as needs have changed, it has become harder and harder to use this application, as it didn’t really do what was required in the first place.

Before the meeting, I sat and thought about the process that the application is designed to assist with. I put myself into the position of a user of the system, and all the things I would want and need to be able to do. The users did the same and came to me with a mind-map of their process and a wishlist of features. I talked them through my ideas and then asked them what they thought. I had covered most of their wish list, and more. So development work will start on that, and together we will turn a department struggling to cope, into an efficient, stress-free team, who can spend more time on customer service, and less time wondering which button to press.

These are exciting times indeed.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.