To say that ‘requirements’ are the basic building block of any software or a solution explains why it is pivotal to identify clear requirements before communicating and developing solutions around them.
Business Analyst must have an understanding of what type of information is needed to float, what needs to be addressed, and what should remain untouched. Not all requirements are to be built.
The way developers need to have the concept of how loops work and how conditions are implemented before they delve into coding and building any software solutions. BAs should know how to identify what requirements fall under which category and then communicate them to different stakeholders. Requirements are any BAs language. We talk requirements!
BUT WHAT THE HELL ARE REQUIREMENTS?
That question should come into our mind when we say ‘requirements’. For someone whose domain is not business analysis or someone whose life doesn’t revolve around requirements, the literal meaning of requirement is basically ‘something that is required’, according to Merriam-webster.
For Business Analysts (since our lives do revolve around requirements and ONLY requirements), the literal meaning for us must be:
‘A usable representation of a need’ — BABOK v3
What value or values could be delivered, if that usable representation of a need is fulfilled. That’s why business analysts are an integral part of any software development because if you don’t know the requirements, no architect, developer or any member of the technical team could write a single line of code unless of course, they do the analysis themselves.
CLASSIFICATIONS AS WE KNOW IT!
BABOK classifies requirements into following:
Business Requirements — WHY DO I WANT IT?
Explains the need for initiating any project. Business requirements state the objectives of why a change is needed. It could be to reduce costs or to introduce a solution to leverage an investment like food delivery service in areas where access to markets cost a decent amount.
Stakeholder Requirements — WHAT ARE THE NEEDS?
To achieve business requirements, stakeholders need to perform the ‘What’. That’s where the stakeholder requirements come. For example, our food delivery app should receive orders. How to order? How to track that order? How one can receive that order? Stakeholder requirements serve as a bridge between business requirements and solution requirements.
Solution Requirements — WHAT DO I WANT?
Solution requirements define the functionality of the solution. It includes both the functional and non-functional requirements. In our example of a food delivery app, the functional requirements could be a list of restaurants to be displayed, search restaurants, place order, payment method, tracking orders etc. Functional requirements explain what must the solution do to achieve stakeholder requirements. On the other hand, the non-functional requirements list the conditions of the environment in which the solution operates effectively. One of the examples could be the accessibility of food delivery services to the users or defining the radius if I put it simply or what payment methods are used in that radius. Stakeholder requirements are implemented by solution requirements.
Transition Requirements — WHAT ARE THE CONDITIONS?
Transition requirements help implement the solution into production. They are temporary in nature as the solution is transitioning from the current state to future state. Transition requirements include data migration, or temporary support while the app (in our example) is going live. In BA’s world, they are mostly known as the ‘underdog’ requirements, because most BAs usually focus on stakeholders and solutions requirements. We tend to overlook the transition requirements.
In a nutshell,
Requirements are the backbones of any software development life cycle. Knowing, where to categorize a requirement, should be like a rule of thumb for any business analyst.