“Requirements are for you, not for me!”, blasts the CEO at the software provider. “Don’t waste my time on it, and don’t charge me for it. Just give me what I want.”, he continues while walking out of the meeting. Well, not exactly, but I have come across this more than just a couple of times.
Most of the times businesses decide that they want to start using a software because they think that it will solve their problems. However, the problems are only the symptoms. It is important to gather more information so that the diagnosis can be successful and the right cure can be proposed. Especially in today’s age, softwares are not just adopted by businesses, softwares become integral to execution of the business processes. However, the software can provide the perceived Return On Investment (ROI) only if the automation targets not the problems, but the root causes of these problems. To be able to do that it is imperative to gather more information – which is the requirements gathering.
Usually the decision to use a software is reactive and not proactive. This ends up being a deadline-was-yesterday project and software tools selected are mostly feature driven and not requirements driven. As an example, there are many Content Management Systems (CMSs) available today provide comparable features. Just because a CMS provides an article management system, it does not mean that it can be applied to every newspaper publications. There are various factors within the domain of article management system like workflow, flexibility of the workflow, its maintainability and more that determine the right choice.
Feature driven selection usually ends up in either the tool not being flexible enough to satisfy the requirements. Or the customization costs are so high that the budget overflows. In either case, it is termed as a failure of software engineering. The success of software engineering starts by idenfying the requirements.
As Content Management author and consultant Gerry McGovern says, “I’ve seen so many organisations that have gotten burned because they didn’t spend the time to really figure out what they wanted.”
Requirements Represent Your Business
No business is similar to another, nor should be the solution. Two businesses can work in the same domain, be of same size and be located in the same geographical area. They are still different, because there are simply too many factors that profile the business. It includes the business vision, the staff and its skillset, the budget and probably many more. For the same reason, a software solution applicable to one business cannot be copied and pasted onto another. If it is, then it will not provide the maximum returns, sometimes making it a complete failure.
Requirements represent your business and domain and make it unique. Only the requirements identification can provide what the business needs and in effect the right solutions.
Requirements identify two distinct pieces of information that provide an answer to the question – What to do?
- the existing processes and system of the business (as-is)
- the future processes and system (to-be) that encompasses the solution
The software engineering is an exercise of transition from the as-is model to the to-be model and provide the solution. If the as-is and to-be models are not identified then the software project can end up in a wild goose chase.
Requirements are usually born out of two sources:
The Business Vision, Business Rules and Constraints
These are usually long-term requirements which are defined when a business is established. Businesses have vision and rules that work as guiding principles and in the process impose a way of working. The business constraints are more distributed in nature, and can change with time. Some examples of such requirements are:
- The business has to target markets in multiple countries to be able to achieve its vision.
- The business is geographically distributed and requires communication tools within the branches.
These requirements represent the current situation, and hence the requirements can be short-termed. However, they usually indicate towards some long term root causes. In such cases it is important to look beyond and identify why the current problems exist. Usually the impact is on the underlying processes.
- The changes in the company are so dynamic today that we are not able to communicate all of them to our customers, other branches or other stakeholders.
- The maintenance work going on certain machines makes it difficult to complete the work in the scheduled time. Do we need to change the schedule?
These point towards certain underlying issues. This may be because the environmental factors have changed, and the business has to react effectively. It is also possible that these problems are being caused by certain constraints and breaking these constraints might provide the solution.
The irony of requirements is that we try to specify them, but they change with time. So does the business, and the rules and possibly the constraints. It is important to realise that businesses are dynamic and solutions should be flexible enough to accomodate them. It is not possible to envision everything, but reflecting on possibilities in the near future can help decide flexibility of the software tool that should be used.
A Piece Of Software Is Not A Solution In Itself
A software package itself is not a solution. The solution is in its application to the business and its appropriate usage. If there are problems in the underlying processes, then only the software will not help. The real solution might involve Business Process Re-engineering so that the root cause is eliminated. However it is difficult to determine if the requirements and the root causes are not identified.
There are various ways of requirements gathering but that will be another post in itself. Requirements are not for the software, but for the business itself. Only after defining the requirements can the solution be defined. Otherwise it might head for just another failed software project.
Copyright Abhijit Nadgouda.