Each industry has its own jargon, and each business probably has its own spin on that, and a set of short-cuts to concepts that may only make sense once you understand the business thoroughly.

Knowing these verbal shortcuts, and using the right language to use can make all the difference when you are getting to know users and starting the collaboration process. Knowing the right words marks you as part of the tribe, one of the initiated. The user can relax and know that they don’t have to start from basics, that they can get straight on with the part that interests them.

It’s important to check your understanding as soon as possible, as a misunderstanding that is left unchecked, can lead to a serious loss of confidence later on. I’ve seen a project stumble almost fatally because a word was used that was not recognised as being part of the authorised lexicon.

No related posts.

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

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.

As usual, I put myself in the position of having to do the job, and I really really dislike not having enough information to hand to do a job. I don’t like not knowing what the previous person has done or agreed or been discussing. I don’t like having to wade in without the full picture, exposing myself and the company to unnecessary risk. I then put myself in the shoes of the actual customer, and decided that this stance I was taking would vastly benefit them too. No-one likes to have to explain themselves over and over and over, to different people, none of whom have the foggiest about my situation or what has been promised me.

But in order to improve people’s recording of this information, you have to provide a measurable benefit to the recorder. When you are busy, it is often difficult to make time to write down the minutiae of a discussion, and of course you will remember all the details, so what’s the point?

As a developer, I see people’s faces become stony when you start talking about ‘typing up notes’ or ‘logging calls’: “I simply don’t have time to do that.” So what I try to do is to work out how I can save them time in other places, or make it easy and natural to record more information. If you can create that email in the application, and have it save back to the notes, attached to the addressee and the case, that achieves my objective, and theirs. Little things like that can make all the difference to the perceived success of your application.

I’m in a slightly unusual position here in that I’m the systems analyst as well as the developer. I’m not just writing the code, I’m trying to change the world (for my users at least!). The two roles do conflict at times. With my user advocate hat on, I want the best from the user experience, I want the application to be a delight and to solve all the niggly interface problems that grind away at your morale (never underestimate the cost to your business of unusable or badly-written software). But the developer has a deadline, the developer has to provide all these features in an often unreasonable timescale. Functionality has to come before delight. In this crossfire, is where projects get abandoned.

No related posts.

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