How to do a Requirements Review from a BA Perspective

Good requirements lay the foundation of success for a software product. Good and definite requirements enable the project managers and the project team to meet the expectations of stakeholders. So requirements review is very important for successful software development.

The role of a business analyst is vital in documenting the project requirements. It is the job of a business analyst to gather requirements from all stakeholders and ensure that the proposed software solution meets all business needs.

As a business analyst, you might be thinking that ’Yes, I do understand the importance of good requirements but how do I do requirements’ review from a BA perspective?’

Do not worry! In this article, we will start by understanding the job of a business analyst. We will skim through the characteristics of good requirements so that you can compare the requirements, being reviewed, against those characteristics. Finally, we will discuss the perspective of a business analyst in detail and see how to do requirements review from a BA perspective.

What does a Business Analyst do?

Once we know what is expected from a BA, we can take steps to meet those expectations.

A business analyst does business analysis of the software project. He enables the organizational change by defining the needs of stakeholders and proposing technical solutions that aim to deliver value to the business.

The International Institute of Business Analysis defines the process of business analysis thus:

Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.

Requirements management is the core responsibility of a business analyst. A business analyst understands the business cases and gathers requirements from all stakeholders. A BA also analyses those requirements and assures that there is no conflict between the requirements; they seek clarifications from stakeholders if there are any unclear or vague requirements.

The deliverable from a business analyst is a business requirements document and functional specification documents. The business analyst makes sure that the proposed solution meets all the business needs, yet does not add unnecessary requirements or features in the proposed solution.

Pre-requisite for Requirements Review

Before we discuss how to do requirements review from a BA perspective, there are a few concepts that are necessary to understand.

Understand the Business Objectives

Usually business case is used to justify the need of the project and get approval on the project. However, it is essential for the business analyst to understand all business cases and objectives that are to be addressed from the potential solution. This step comes prior to the elicitation of requirements.

This step includes discovering the ‘Why’ for the project. The grasp on business objectives enables business analysts to set boundaries for the system. Within this boundary, the scope of the project is defined and subsequently system requirements are elaborated. The boundary of business objectives is used to eliminate any unnecessary requirement or functionality which may emerge only as a desire of any stakeholder.

Business objectives are used by the stakeholders and project team to prioritize the requirements. Besides these, one of the core responsibility of the business analyst is to verify that the proposed solution meets all business objectives of the client. A good business analyst will not only make sure that the developed solution caters all business cases, but he will also assure to rid of any extra feature or functionality requirements i.e. prevent gold plating.

Know Characteristics of Good Requirements

You can review a requirement and improve it, only if you know requirements. Let’s have a look at the characteristics of good requirements and you can ensure that the following elements are present in the reviewed requirements document.

Correct

The requirements must be correct and define the actual needs of the stakeholders. If a BA specifies a requirement based on a ‘guess’, it may lead to an incorrect system specification. Only the customer and stakeholder can verify the correctness of requirement.

Feasible

The requirements should be feasible – possible and realistic to implement. The requirements should be attainable within the budget and time constraints.

Understandable

Requirements should be easily understandable by the stakeholders, project managers and project team. Use short sentences and easy language to express a requirement.

Clear and Unambiguous

It is the first characteristic of a good requirement. The requirement must be clear and unambiguous i.e. there should be only one way to interpret the requirement. Such a requirement leaves no room for misunderstanding by the user. If a requirement is vague and leaves something up to the reader to interpret, the requirement is ambiguous.

Testable/ Verifiable

Every requirement meets a business need. Thus, requirements should have an objective criterion against which it can be tested. When implemented, the tester should be able to test the requirement and record the result as ‘Pass’ and ‘Fail’.

Requirements Review from a BA Perspective

We know that business analysts gather the requirements and document them. It is possible that a junior BA prepared the requirements document and you, as a senior BA, need to review it.

A business analyst does not have the luxury to skim through the document or overlook any section in the requirements document. They need to review the requirements thoroughly with full attention to the details, because the requirements lay down the basis of successful project. While performing the requirements review, a BA needs to ask the following questions while examining the requirements.

Is the requirement correct?

The first aspect to be reviewed about the requirement is its correctness. Yes, we have said that the customers and stakeholders verify the correctness of a requirement. However, as a business analyst you can raise question on any requirement that does not make sense to you. It is possible that a stakeholder specified a requirement, but you do not find it user friendly and hence, you can talk to the stakeholders about it. Ensure that all requirements are specified by the stakeholders and are linked to the business objectives of the software product.

Is the requirement feasible?

The feasibility of requirement is another important aspect that needs to be reviewed by the analyst. You might not have the expertise to determine whether a requirement is technically feasible or not. However, you need to flag such requirements and discuss the feasibility of its implementation with the relevant technical people.

Example 1: The product shall switch between displaying and hiding non-printing characters instantaneously.

Comment: Computers cannot do anything instantaneously, so this requirement is not feasible.

Example 2: The system should take input in the natural language of the user.

Comment: Unless it is a project of artificial intelligence, this requirement is not feasible as the computers have not developed the intelligence to interpret the human language and understands the commands automatically.

A requirement might be realistic to implement, yet it may be constrained by the project budget and completion time.

Is the requirement understandable?

The requirement should be easily understandable. It is recommended that requirements should be terse and written in easy language. Also, make sure that the ‘words’ precisely describe your requirement. Too many, unnecessary words and long sentences might confuse the readers. The more straightforward and plain worded a requirement, the better it is. Review that each requirement should express a single thought in a concise manner.

Is the requirement clear and unambiguous?

Software industry widely exploits the outsourcing of resources. As a result, virtual teams are very popular in the software industry. A virtual team is generally composed of people belonging to different regions and backgrounds. This follows that different team members might comprehend the requirements differently, due to difference in their mindsets. Hence, it becomes a challenge for a business analyst to document requirements in a clear and unambiguous manner.

Examples of ambiguous phrases that you need to watch out for include ‘as needed’, ‘faster’, ‘better’, ‘manage’,’ may’ and ‘etc’. We are listing below a few unclear and ambiguous requirements:

Example 1: A five-digit code shall be entered in the ‘Code’ text box.

Ambiguities:

• ‘Who’ should enter the code?
• What if the user enters 4-digit code?
• What if the user tries to enter 6-digit code?

Example 2: Dashboard screen should appear quickly.

Ambiguities:

• How long is quickly?

Example 3: User shall be able to create profile, edit details and delete the profile if needed.

Ambiguities:

• Comment: This requirement can be broken down into three separate requirements.
• Is create profile and edit details same screen?
• Can user edit all details of the profile?
• Are there any conditions that need to be checked before the user can delete a profile?

If any abbreviations are used, mention their acronyms at least once leaving no room for misunderstanding. You might also give names or titles to different sections, components and modules of the system to refer to them in the later sections.

Is the requirement testable?

A requirement must state objective criteria which can be used by testers to verify the requirement. Remember, if a requirement lacks ‘Acceptance Criteria’, it can lead to the conflicts and issues between stakeholders and project manager.

Acceptance criteria serves as the agreement between both parties. If the application meets ‘acceptance criteria’ of the requirements, stakeholders cannot raise an objection if they are unhappy with the output. Hence, it becomes critical to review that a requirement is testable.

Example 1: Consider a bad requirement, the system shall be user friendly.

Comments: There is no instrument to gauge the user friendliness of the system as every individual will have different definition of user friendliness.

A good requirement will contain verifiable criteria of user friendliness, say, ‘The user interface shall be menu driven. It shall provide dialog boxes, help screens, radio buttons, dropdown list boxes, and spin buttons for user inputs’.

Example 2: User shall be able to filter search results.

Comments: This requirement does not mention the parameters of ‘filter’. If such a requirement is given to developer, he will add some filter options using his common sense. The tester might disagree and propose different filters. This will create a conflict and unnecessary delay in the development process.

A good requirement will contain the details of filters i.e., user shall be able to filter search results on the basis of serial number, first name, date created.

After checking individual requirements, you need to verify a few more aspects of the entire set of requirements.

Are requirements consistent?

As there can be multiple stakeholders for a single project; each stakeholder defines his own requirements. There is a possibility that two stakeholders define conflicting requirements for one feature. The person who documented the requirement may not know it at that time, but you should point out any such inconsistent requirements in your review. These conflicting requirements need to be reconciled by approaching stakeholders again and develop a shared understanding of the business objectives.

Are requirements complete?

This can be a challenging condition to review by the business analyst. There is really no way to attain 100% completeness in requirements. There is always a chance that stakeholder comes one week before the production with a new requirement. On the other hand, you can minimize the chances of this scenario by engaging stakeholders throughout the software development lifecycle process and taking their feedback at regular intervals.

Are there any redundant requirements?

Requirements should be expressed only once, else they might create confusions. There can be some general requirements for the entire system. For example, calendar shall be available when a user enters a date. A separate section can be created where all general requirements are listed.

Recap

Good requirements are vital to the success of any project. It is job of a business analyst to gather and document business requirements for a project. The business analyst reviews the requirements for their correctness, feasibility, understandability, clarity, ambiguity, testability, consistency, completeness and redundancy. Moreover, the requirements specification document should contain consistent and complete requirements for the project.

---

Did you find this post helpful? Do you have any tips to do a requirements review from a BA perspective?