March 16, 2020

Requirements Classification Schema

By Lau

“Always do your best. What you plant now, you will harvest later.”

– Og Mandino
Always do your best. What you plant now, you will harvest later. – Og Mandino Click To Tweet

The BABOK® Guide lists four types of requirements which are the main business analysis deliverables. There are three important reasons for learning this classification. Firstly, understanding the difference between these four requirements. Secondly, understanding their purpose. Lastly, the help that having a structure offers when it comes to learning the development of a deliverable.

Requirements Classification

Business requirements.

This is the statement of goals. Business requirements describe the initiative that drives the project, thus they describe the requirements that have to be fulfilled in order to meet the project goals. The magnitude of it varies, this initiative can affect the whole enterprise, an area or something more specific.

Deliverable: A document that describes the process that must be executed o the data is needed in order to complete that process.

Stakeholder requirements.

These requirements are better known as “user requirements”. They describe the stakeholder needs which correspond to the list of problems that have to be solved in order to achieve the previously explained business requirements. The stakeholder requirements are going to be used later as the solution requirement inputs.

Deliverable: User story, User requirement.

IMPORTANT: The difference between business requirements and stakeholder requirements is that the former describes business needs, whereas the latter describes system functionalities.

Solution requirements.

These describe what has to be done in order to satisfy the stakeholder requirements and through them meet the business requirements’ goals. These requirements must include the right level of detail to allow its development.  Solution requirements are divided into two types:

Functional requirements.

Here is where all the solution functionality is described. Depending on the size or complexity of the project, this document could contain Use cases, UML Diagrams and/or Business Process Diagrams.

Deliverable: See One of the best business requirements document examples 

Non-functional requirements

These are not related to functionality, they instead describe the characteristics the solution must have in terms of capabilities and quality.

Deliverable: non-functional requirements with the information of the software performance, concurrence, security, usability, etc. 

Transition requirements.

They describe the conditions that the solution must meet in order to allow the transition from the current business state to the future one. The main distinctive characteristic is that they are specific and temporary, once the transition finishes these requirements are no longer needed.

Deliverable: data conversion document that includes the specification of what data is needed to allow the change. Another deliverable could be a user manual for training purposes. 

Because the BABOK Guide includes all the business analyst’s roles, which we have mentioned in previous articles Who is a Business Analyst? sometimes we’ll notice that there are tasks that aren’t always the responsibility of the software business analyst to be completed. For example, the non-functional requirements that in most cases are performed by the software architect. So, don’t worry if you feel like there are types of documents you still don’t know, you might not need to know them anyway.

You might also like to read about the different types of stakeholders. Remember that stakeholders are one of the 5 variables of The Business Analysis Core Concept Model and if you have read the article you would know how important it is.

Don’t forget to download this FREE Digital Book: The Master Strategy for BA Beginners where you will learn how to get your first BA job by following 3 strategic steps.

See you soon. 😉