So how do you work out what you really need?
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.