Top 10 Sources of Requirements | Practical and Hands-on

Let us describe a very interesting situation that happened to one of our projects.  We were modernizing one of our legacy systems developed 15 years back. The system could not fulfill changing business needs and was expensive to maintain.

Our system was supposed to handle requests which were originating from another system. Our stakeholders wanted that the moment a new request is created in the other system, it should immediately get interfaced to our system.

At best they were willing to tolerate 15 minutes gap between the originating system and the destination system.  We designed our system to handle requests at this frequency.

During system integration phase we realized that the originating system was providing data only once a week.  when we ask that we need things within 15 minutes they said that system being very complex system cannot process information that quickly and at best it could provide data at the end of the day. Finally, our system also ran at the speed of a day rather than the speed of minutes which our stakeholders were expecting.

If we look at the scenario, the reason why we couldn’t meet our stakeholder requirements was not a lacuna in our system but a lack of lacunae in the interfacing system.

Most business analysis and requirements engineering book and guides give importance to eliciting requirements from only one source, i.e. stakeholders. Unfortunately, they do not highlight the fact that requirements can actually come from multiple sources. As a business analyst, we should keep our ears and eyes open to elicit requirements from all possible sources.

In my experiences over last 25+ years a BA, I have come across the following 10 key sources of requirements.

1. Stakeholders (Sponsor, Domain SMEs, End users)

This is no doubt the most important source of requirement, in the majority of the projects. This aspect has been duly discussed at length in most business analysis guide including BABoK.

2.       Documentation

Existing documentation can be a great source of requirements especially if your project happens to be an extension of an existing project.

3. Regulatory Compliance

Regulations are again another important source of requirements for many domains such as finance, healthcare, automotive and aviation etc.

4. Existing systems

End users usually expect the existing functionalities to be available in the new system. Studying existing system functionalities will give us many requirements for the new system. At the same time, let’s remember that all existing functionalities may not be needed in the new system. This is because the business context might have changed over a period of time.

5. Interfacing systems

Practically all software systems work with other software systems. Interfaces with existing systems will impact the way we develop our system.

6. Competing products

If you happen to make a product for the market, there are obviously competing products against which your product is compared against.  We must study competing products to find what kind of features can be useful in our product as well.

7. Constraints

Organizations have their own constraints and these constraints need to be considered when we develop our new system.

8. Partner organizations

In case your organization happens to work with a partner organization, it may have some expectations on the system is being developed.

9. Benchmark system

We can look at other systems and find how certain aspects in those systems are distinctly superior to what our system, such as user interface. This benchmarking can help us gather system requirements.

10. Technological changes

Last and the possibly most important aspect is technology. Technology is changing it is very rapid pace. With technological changes, end-user expectations are also changing, such as movement towards mobility and artificial intelligence will give rise to new kind of requirements that our application needs to fulfill.

This is work in progress and not meant to be perfect and can definitely be improved.

I would encourage my BA friends to contribute to this list so that we can make it an exhaustive list. A good functional requirements analysis technique will be quite helpful for all BAs.

About me

I am a professional BA, trainer, coach and author.

If you like my posts please like/share/comment and spread the word in your network.

Would love to connect with fellow professionals.

You can also reach me at LN@AdaptiveUS.com