Whether you are a Product Owner, Business Analyst, Designers or Engineers, what we talked about most at our work is Requirements. However, different roles may think of Requirements differently, which might be the gap while discussing the Requirements together. It is a waste of time, so we need a common language about Requirements to understand each other better.
First of all, we need to distinguish Requirements from documentations. I heard a lot of people saying that a user story is a requirement. Is this true? A user story is just one way to document a requirement. Requirements come from different sources, and it has different levels or types. Documentations are the ways to record the requirements. Different roles probably use different types of documentation to describe the requirement, and different teams probably use various documentations. For example, the designers use the wireframe to document, while the business analysts use user stories.
What are the requirements?
A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective. A requirement can also be a condition or capability that must be met by a solution or solution component to satisfy a contract, standard or specification.” (BABOK definition)
It is essential to remember that a requirement must be needed to solve a problem or achieve an objective. I experienced quite a lot that people were discussing a “Requirements” which was from their imagination. A simple question like “What is the value we get out of this requirement?” will break the conversation. People would then realise this is not an actual requirement.
That’s too conceptual. Now let’s see how it works in real life.
The most common ways the requirements come from are,
- new business ideas
- customer feedbacks
- competitor analysis
, etc.
No matter where they come from, the requirements are not what you expect them to be initially. What we expect is that a requirement should be specific and clear enough to follow. But actually, it is very vague at the beginning. We need to find the problem and then analyse it to come out with the requirements. So now you understand that a requirement is a thing that comes out of the proper analysis, that is why we need a good business analyst or product manager, and these analysis skills are the ones the market need most. We can talk about the skills in future posts.
Now we need to understand the requirements types to analyse well and discuss them with the team well.
What are the types of requirements?
Requirement types,
- Business requirements
- Stakeholder requirements
- Solution requirements
- Function
- Non-Function
- Transition requirements.
You can find them in the following image,
I won’t explain each of their conceptual definition. I will explain in a real-life example.
Suppose that a family with two kids, their target is to build a big house with a garage and a swimming pool. Is this a statement of our goal? Yes, it describes why a project has been initiated. It is a business requirement, and it represents a high-level objective.
The parents say we need to build three bedrooms so that each kid will have their bedrooms. Is this more specific now? Yes, it describes the needs of the stakeholders to achieve their goals. So it is a Stakeholder requirement, and it connects the business requirements and the solution requirements.
The little girl says I want my room to print in pink colour. Is it a more detailed request for the bedroom? Yes, it describes the exact capability of the little girl’s bedroom. So it is a Function Requirement, and it is the appropriate level of detail for the builder to implement.
The house architect says the house must have fire-resistant insulation in all the walls to prevent significant fire damage. Is it a function? No, we can’t feel it while we are living in the room, and we even can’t see it. Is it needed? Yes, otherwise, the house might be in danger. So it is a Non-Functional Requirements, and it describes the condition that must remain effective or qualities.
Now the house is built entirely, and the family need to move furniture in. The team that helps them move say we need to cover the floor with sheets to protect carpets. Is this still be required once they moved everything in? Now, we only need the sheets while we are moving things. So this is a Transition Requirement, and it has a temporary nature. We probably have this type of requirement while we are transmitting an old platform to a new one.
What are the different ways to document the requirements?
The documentations,
- Functional Requirement Specification
- Use case in UML
- Process in a data flow diagram
- Activity in a swim-lane diagram
- The task in a BPMN (Business Process Model and Notation) diagram
- User Story in Agile
- Wireframe and other visual documentation
, etc.
Different roles and different teams will choose various documentations to record the requirements. The value behind the documents is to remember the outcome of all analysis — the requirements.
I hope that this post can find you well. See you in the next post.
