Really obvious clues might be that a requirement derives from a law or regulation. These change, so any behaviours dictated by this requirement, may require to be controlled by parameters rather than hard-coded. Or that area of the software might be best done in a more generic way, not tied so closely to the current business processes, so that when the processes have to change as a result of a change in the regulations, the risk of costly re-development is minimised.

Note that I say minimised, rather than avoided. Again, you cannot predict the ways in which the regulations might change, just that there is a risk that they might.

These risks need to be quantified in order to decide where to build in this flexibility though. How likely is it that a particular area will change should have a bearing on how you treat that need for future change.

For example, I have worked, as a maintenance developer, on a number of systems whose developer assumed (with a fair amount of justification) that VAT would never change, and had hardcoded the calculations with the fixed amount. So when VAT did change, this necessitated a huge find/replace operation. But what I replaced it with, was a call to find out what the current rate at a particular date was, as I reasoned that now the Government have found a new toy to tinker with, they are likely to tinker with it again, so let’s deal with that now.

But this is the kind of thing that may only become obvious in hindsight. It’s not an exact science. All you can do is evaluate your requirements and make an assessment of how likely they are to change and use this to focus in on areas that need to be flexible.

No related posts.

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

Some people are amazed when I tell them what I do for a day job – but it’s so different! Is it? That well-worn lane is where it is because over time, people have found that this is the easiest/best way to get from a to b. Yes, there’s that other way, but it’s boggy in Winter, but this path is always passable, and therefore gets used more. People see the path and use it because it *is* a path, and there it still is today.

It’s the same with business processes. They are a way of getting from a to b, and over the years people have worked out what the best way of achieving that is. On first inspection, you might well ask why they don’t take that other route, as you can’t see any good reason not to. But people that have been there a while know the pitfalls and may even have been that route themselves.

Just as you might put up a sign in the landscape to warn of possible dangers, it’s important to note the other routes that were considered, and why they are not suitable. You stop the potential for endless circular discussion by documenting the warnings, but more importantly, you also allow for the re-evaluation in future, if the pitfalls are made safe. Knowledge is powerful stuff.

No related posts.

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

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.

Part of my analysis process is to test out the TRUTHs, POLICYs, LAWs and WISHes that I discover, by running them past as many interested parties as possible. Of course, not everyone gets to make decisions, but input is important. You will discover all sorts of things that maybe no-one had thought to mention and you may be told lots of things that will not longer be a TRUTH in the new system, or POLICYs that will no longer apply. Do not dismiss these. Your users will have been doing this job for a long time and have a great deal of experience that you do not. I add a caveat here – always always always ask the reason for the answers you receive. You cannot expect to be able to evaluate the input if you cannot see why you have been told something. After all, people often believe things that are not true.

Part of the importance of working with end users on this process is to discover what they hold dear and how you can map that onto the new world with minimum discomfort. Humans are wired to hold onto things they already have or know. This is a survival instinct. The fear of loss is greater than the expectation of gain, and the longer the thing has been owned, the harder it is to conceive of letting go. Once you know this, you can start to work around it.

The fact is, businesses need to change to remain viable. But what you have to do is be subtle about it. Investing the time to involve the end users softens the blow of the loss of the old way, by allowing them to feel ownership of the new way. If you can get them excited about all the shiny new stuff that will be available, and how much better things will be, and importantly – how you are taking their ideas on board and letting them shape things that will affect them – the easier the separation from the old system will be.

This has the added benefit that you will have a cohort of evangelists ready to spread the word about the great things that are coming, and to help their team members adjust. Training will also be easier, as your evangelists know the new way almost as well as you do.

Go on, talk to your users, what have you got to lose?

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.

No related posts.

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

Unfortunately, a spreadsheet is a quick and dirty way of routing round system limitations, in the same way that storing all your data in a Notes field is. Don’t have a field to store ‘SnowmanType’ in? No problem, we can keep track of that in a spreadsheet!

I confess to having a personal horror of the spreadsheet database simply because, as a relational database person, they are just so.. so woolly. You can put anything anywhere. Ugh. For example, I work with a third-party supplier who sends me spreadsheets of (manually-maintained) data. One week, I wondered why my automatic import wasn’t working. It turned out to be because halfway down a column of data, she had suddenly transposed two columns, and what used to be Postcode was now SupplierName. That’s just wrong, and quite possibly immoral.

This horror of spreadsheets tends to make me quite a rapid developer, because I know that as soon as a problem has been identified, if I don’t come up with something sharpish, I’ll have a spreadsheet to defuse. The incentive of avoiding cleaning up an ‘Excel Database’ before I can import it into something more sensible, is quite a powerful one.

Don’t get me wrong, I use spreadsheets. I spit out data into them and format it into something pretty that you can then play with. But they are an output, not the whole solution. If I can’t delete all the data from your spreadsheet, and recreate it with minimal fuss, then you are storing your data in the wrong place and I need to help you with that.

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.