Requirements Are Important

“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.

Feature-driven Selection

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.

Current Problems

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.

Future Requirements

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.

Technorati tags: ,

Copyright Abhijit Nadgouda.

Discussion [Participate or Link]

  1. Abhijit Nadgouda @ iface » Activity Centred Design said:

    […] Once the purpose is established, the context(s) can be identified. Although it is entirely user centric, more factors contribute to the context. If it is the software, then the layout design, the usability design, the usage patterns and more importantly tracking the usage history are part of providing the context. Some of this can be gathered when the requirements are being identified, and some has to be built when the software is being used. Usage patterns can be developed for certain users and corresponding contexts can be provided. […]

  2. iface thoughts » Blog Archive » Reuse Requires Research said:

    […] Why is this research important? One is because it can help your selection of tools can be requirements-driven rather than feature-driven. And secondly, it can help you justify your technical decisions to whoever is asking for it. […]

  3. Boxed CMS on iface thoughts said:

    […] The reason why boxed CMSs fail is because it typically tries to please everybody by including all kinds of features, which according to me is a recipe for disaster by the principle that there is no one-size fits all for anything. The frustration with using a CMS grows when you realise that you have chosen a wrong tool to do the job. So why are they still so attractive? One of the reasons is by the plethora of features are so tempting for the users/developers that they skip finding out the actual requirements. A feature-driven selection is one of the biggest reasons of selecting the wrong CMS. The features are never studied to see if they do satisfy the requirements. The fault is not only with the CMS itself, but also with the one who selects it. For a long term workability, extensibility is more important than the vertical features built in. […]

  4. Requirement Patterns on iface thoughts said:

    […] Requirements are necessary, they define the problem, they define your business need which is always unique from someone else. Unless the problem is identified and defined properly no amount of engineering is going to be able to solve it. […]

  5. Simplicity And Features on iface thoughts said:

    […] I think we lose the focus on needs or requirements a lot of times, while we focus on features. I, as a user or a developer, am scared of features. Features usually are full of buzzwords, are bullet points and usually there are a lot of them. The bullet points fail to show how my problems are solved, the buzzwords fail to explain to me what is the product about and a plethora of them hardly make me comfortable. And I am expected to understand the product just by reading the feature list. I would rather like a demo that I can try out, or an overview or case studies. A feature-drive selection can be misleading, software or not. In fact I think that a feature list can only be grasped by one who already knows the domain, not the layman. I have had this experience a lot when I have introduced my friends to blogging tools or blog clients. […]

  6. Designing With A Why on iface thoughts said:

    […] I have even wondered at times if I have killed my gut feeling entirely which makes me ask why. But this is what it is – understanding things. I cannot design, any design, without understanding the purpose, the intent. That is why I feel requirements are important, because they help in understanding things, and then in designing them. […]

  7. Placing Blame And Finding Solutions on iface thoughts said:

    […] tool. A lot of times tools are chosen without actually considering requirements, they are usually feature-driven decisions. I have seen some projects which have either failed, or just not completed because they were […]

  8. David Locke said:

    No two people in a given subject domain have the same model of that domain. In this is the roots of failure of the requirements and the application. The guts of their definitions are not negotiable. So trying to code a single conceptual model is bound to fail. It is not enough to have multiple views if the model itself can’t manage to encode the variations in meaning. This hints towards a need for a many-to-many architecture.

  9. Abhijit Nadgouda said:

    I agree. But the bigger question is then whom to ask? The business? Experts outside the business? Whatever model we do decide on, it has to be in line with the business we are doing it for and with meanings that the ones involved with it have. Is it possible that in some cases that it becomes impractical to incorporate all variations in the meaning, either because of money, time or sheer complexity?

  10. Pre-built Or Custom? | iface thoughts said:

    […] there is no one-size-fits-all solution. The CMS has to work in context of the project’s requirements and needs. Otherwise we might experience what is called a boxed CMS. In such a case, the CMS features turn […]

  11. Cost Of Software Is Not Only The Money | iface thoughts said:

    […] find out if that piece of software was really useful. What helps is understanding our needs and our requirements, and possibly even our process. And I think we know this. But we still do not do it. Why? Because […]

  12. Activity Centred Design | iface thoughts said:

    […] tracking the usage history are part of providing the context. Some of this can be gathered when the requirements are being identified, and some has to be built when the software is being used. Usage patterns can […]

  13. CMS Is Not At Fault, As Much As Wrong Choice Is | iface thoughts said:

    […] think the most common cause of CMS failure is the feature-driven selection. The management is too keen to select tools and finalize the budget to spend time on requirements. […]

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.