~ By G Chandrashekar
Requirements Analysis: It all looks so simple in the beginning. But then, whether you are building a new system from scratch or buying a system and customising it to meet the specific business model of your company, you have to go through the grind of analysing the requirements. It's no mean task. The budget can run into scary numbers and that's tough enough. But the more difficult question is how you make sure the new system does what the users (and of course the customers) expect. If you are replacing an existing system, the new system should do whatever the legacy system is doing at least as effectively and efficiently, if not better. That's a huge challenge.
Here are a dozen practical tips that will come in handy during this exercise:
Innumerable studies have shown that requirements gathering is the single most important step in the Software Development Life Cycle. It's far more expensive to fix a requirements error than a coding error. But somehow everyone seems to believe that a requirements specification document is the easiest part to produce, and the design/coding part is the more difficult. It can't be further from the truth. No one ever built a good structure without the right foundation. Make sure that you take time to gather the requirements fully and analyse them in depth. Budget sufficient time to gather and analyse the requirements in enough detail. Don't hurry it unless you want to bury it.
One-liners don't help one to design and develop a system. But that's what you get many a time. And everyone will interpret it based on their own knowledge and experience. You can't buy insurance against getting the interpretation wrong. You need to get the big picture right, but also need to get into the minute details. Ask for details, however minor the issue seems. You may discover something really critical.
Don't look at requirements in isolation. The requirements exist to support a business event. Get to know what the business is - every single aspect of what you are trying to support. Once you do that, the links between the various pieces of the puzzle start emerging. The requirements simply fall into place. You know what's critical and why. The right solution emerges when you go back to the drawing board.
During the requirements gathering you get a huge amount of data, often in disparate forms. Word documents, spreadsheets, PowerPoint presentations, image files. The list is endless. Document, index and retain every bit of information you come across using a good software tool. Ask everyone in the project to document everything in a centralised database, not on their desktops. Keep it updated. There is no doubt the context and understanding that comes with a document can't always be translated into requirements. But when a person leaves the project/organisation you can't afford to lose whatever information exists in his grey cells. Document it. Anyone looking at the requirements later need not reinvent what's already known.
The actual users know best, but often it's their bosses who come for the meetings with the business analysts and development team. Arguably the men in black suits have the big picture and probably can bring out the requirements more clearly, but the actual system users are the ones who know the key elements and the pain points. Involve them whenever you can. Especially when usability and workflow is key to the success of the system.
Often what the users say is not what they actually mean. The reasons are many. It could be because of a communication gap, because they assume that certain things are just too basic to mention, or simply forget. Watch them in action. Don't just see, observe! You will be pleasantly surprised with the results. The process flow is often the most critical factor for the success of the system that's built. Unfortunately most requirements gathering happens between the four walls of a conference room or over calls, not on-site. See things in action, not in your imagination. Many a time, I have found that an hour spent on-site is worth more than an entire day's discussion.
All too often we end up building a system that handles the normal flow perfectly well. Everyone can tell you what the 'happy path' is; but only the ones who use the system in an actual business scenario can tell you all that can go wrong. And if you don't build your system to handle the 'can-go-wrong stuff', you have built a house of cards. Don't just ask the users for the 'happy path', encourage them to tell you about the 'unhappy path'. But remember; ask the right users.
With multiple systems implemented in today's business environment, often the users do not know which system is doing what. It's all transparent to them. Transparency is good from users' perspective, but not for those looking to build a new system. Users will tell you what they think their existing system is doing. Get to know the scope of the system you are trying to build/replace. Involve the technical folks who can provide this information to avoid rework.
Look for user manuals and system manuals. You will find a lot of them gathering dust in some forgotten corner. While the users can tell you about things they always do, there are things they don't remember - or don't understand. A properly signed-off document can be a gold mine of information. It could tell you not only what the system does, but also why. The why part can be a clincher when you need to make certain decisions on whether or not to build a specific feature in the new system.
Often the users want to see the new system doing things in exactly the same way the earlier system does. The guys at the top would be happy with that too since it lessens the cost of training and avoids mistakes. The technology platform you are using for the new system could be a lot better, but do things in a way that is unfamiliar to the users. Get the buy in from the senior management. Let the users know that it is going to be different. After all, you are building a new system, not producing a copy of the old one!
It is not too uncommon for users to ask for some features in the new system based on what their legacy system does. They may genuinely believe that it is the business requirement while it is actually a limitation of the system. No one realises that it is a limitation because that's what they have always been doing. Don't end up building in those limitations.
You think reports are the easier part? Think again. It's the reports that provide a view of what's happening in the organisation to the folks who make all those critical decisions. Goof up on the reports and you have done everything to doom the organisation. By the way, the organisation may have a huge inventory of reports that are generated in their existing system, but is anyone using them? Building a new report costs money. Not just the one time effort of building and testing them, but ongoing cost for printing, distribution, storing and destroying them. And yes, you are increasing your carbon footprint too. Cutting down the number of reports by half when a new system is introduced is not all that rare. Look at it as an opportunity to clean up the reports inventory.
The right team with the right amount of time spent can be the key to success of the most critical phase of building a new system. Take your time, quite literally. It can mean the difference between a successful and failed project.
The author is a Lead Consultant with Finacle, the Core Banking solution from Infosys Technologies Ltd., a world leader in IT services. The views expressed in this article are of the author and do not necessarily reflect the views of the company.