What is a requirement in business analysis? What lifecycle does it go through and how can requirements be analyzed?
Robert McCloskey, American author and illustrator of children’s books.
Business analysis comprises many tasks and questions that have to be solved. The business analysis body of knowledge (BABOK), a handbook and guidelines from the international institute of business analysis (IIBA), separates this activity into six areas of knowledge. Two of these especially concern requirements: requirements analysis and design definition as well as requirements life cycle management.
Well-formulated requirements that are regularly communicated with the stakeholders are essential to be able to provide the desired product. Emphasis here is on “desired”. Because many projects fail to fulfill the goals and desires of their customers – because requirements were not understood or not even recognized. But just what is a requirement? According to the BABOK, the definition is:
“a usable representation of a need. Generally represented by means of documents.”
Here, the third version of the BABOK also differentiates between the requirements and design: a requirement describes the what and should present the need, whilst the design describes the how and represents the solution.
Click here to learn more about business analysis according to BABOK >>
A requirement is not an organization goal like, for example:
“Profits should increase by 53% within the year”
That is a business goal.
A requirement is not a project boundary like, for example:
“The software has to be delivered on May 31st 2018”
A project plan is used for that.
And it doesn’t describe the how:
“The language should be selected with a drop-down menu”
The design definition is responsible for that.
Requirements are, for example:
“Users should be able to add items to their shopping cart”
“Users should be able to view the items in the shopping cart at any time”
Definition of business analysis according to the International Institute of Business Analysis (IIBA):
Requirements can be classified according to four categories. Here we will use the terms from the BABOK.
The knowledge area “requirements analysis and design definition” includes classical requirements engineering.
Here, you have to determine the current needs of the stakeholders and record them as requirements. That means: all the information that you collected in the survey now has to be organized, structured and documented in requirements. To do this, you specify and model the requirements. For example, they can be recorded with text or in diagrams like use case diagrams. A combination of both is the best method, because the details of the requirement can be recorded in text and the context can be presented visually in a diagram.
To record requirements in text, you can orientate yourself by the ISO 29148, a norm of requirements engineering. It suggests, i.a., the following text template:
[Condition] [Subject] [Action] [Object] [Limitation]
If signal X is received, [Condition] then the system [Subject] should set [Action] the bit for the maintenance of the signal X [Object] within two seconds [Limitation].
Verification and validation also belong to these tasks.
Verification is concerned with the necessary quality standards that a requirements has to fulfill to be able to continue to use a business analysis. For this standard, the requirement has to, according to BABOK, have the following features:
For verification, you have to ask the following questions, for example: if a requirement should work on a range of information – is there a requirement that created this information? Do you need a requirement to delete this information again? And are you using consistent terminology? To answer this question and get rid of any uncertainties, requirements should run through detailed reviews and different hands.
Validation concerns the value that a requirement creates for the stakeholders. Even if a requirement is verified, it won’t necessarily be used. That is why you, as a business analyst, have to constantly check if requirements actually create added value. But even if the stakeholders need it – does the requirement also conform to the business case? If not, then it should be allocated to another business case or completely removed from the solution.
When you have validated the requirements, you also have to specify the interaction of the requirements or the requirements architecture and the possibilities of implementation into the design options.
Then the business analyst is responsible for communicating the solution options and their added value for the organization, and to suggest solutions. You get six results from the knowledge area:
This knowledge area, requirements life cycle management, should make sure that the organization, solution requirements and designs are coordinated.
You have to be able to trace requirements at all times. Only that way can you confirm, amongst other things, whether they are really needed. What exactly does that mean? Each requirement has relationships to other elements. So they always have to have a source. Who needs them and why? In business analysis a requirement always goes back to one or more stakeholders and their needs. Depending on the classification, the requirement is also connected with other requirements. For example, a stakeholder requirement might stem from a business requirement. And then they are connected with test cases to test their implementation. That way the following dependencies, amongst others, are controlled:
Stakeholder > Need > Business Requirement > Stakeholder Requirement > Solution Requirement
Maintain: As a business analyst, you have to keep requirements up-to-date during and also after your instigated changes. Apart from this, it is advisable to be able to use requirements again in other solutions. To keep them up to date, you should regularly carry out a review. Of course, this requires that all participants have access to the requirements and also that they are understood by everyone. Take note: a requirement that is not accepted or implemented can still be used for other solutions.
Prioritize: Not all requirements have the same priority – depending on the stakeholder and the benefits, you have to define the order in which the requirements should be implemented. The prioritization should be continuous to be able to react to changes. For example, the benefit, cost or risk might change over the course of the project. In agile projects, the product owner re-sorts the entries in the product backlog. To prioritize requirements, you need techniques like risk analysis or MoSCoW analysis.
Evaluate: As a business analyst you have to evaluate how the suggested changes will affect the requirements. This evaluation is only successful if new needs or solutions have been identified.
Approve: And then you have to accept or reject the requirements to continue processing the solution. This can occur formally or informally.
Manage requirements with software
So, you have to record the collected information as requirements – be it through text or diagrams. So that you can verify requirements, you have to ensure the correctness or quality. That only works if the contents can be seen and signed off on by all participants – namely through reviews. You also have to be able to ensure traceability so as to be able to trace requirements to stakeholders and their needs, and to other requirements. How do you proceed without having to use different tools for different results? Use a software with which you can keep an overview of everything: create requirements in text or visually with diagrams, for example, in connection with use case diagrams. For quality assurance, requirements can be reviewed and you are kept up-to-date on the current state with e-mail notifications. And the relationship of the requirements to the stakeholders, needs, other requirements and test cases? An overview of everything, in both text and diagrams – with just one piece of software.
