What Is Requirement Analysis And Gathering In SDLC?

This Tutorial Explains What is Requirement Analysis, Requirement Analysis Steps, Examples, And Goals of Requirement Gathering in SDLC: 

Software development is a humongous task that creates a working software product.

The software product is built as per the customer’s requirement. Mostly, this software product complies with what the end customer/user had expected, while sometimes this product does not fully comply with what the customer/end-user had expected.

What Is Requirement Analysis?

Let us understand the Requirement Analysis with the help of an example.

Customer/End-user expectation:       

Customer/End-user receive:     

As you can analyze from the above images that there is a mismatch in the end product to customer expectations. This could be due to myriad reasons, viz. incorrect implementation of customer requirements, faulty design, a wrong understanding of customer requirements by programmers and quality team, etc.

However, as you can see, be it any reason for wrong product delivery, the primary reason goes to requirement. Hence, if correct requirement understanding, capturing, implementation, and testing were done, it would have helped to mitigate the erroneous and incomplete product delivery to the customer/end-user.

A good product delivery requires correct requirement gathering, the efficient examination of requirements that are gathered, and finally clear requirement documentation, as the precondition. This entire process is also called Requirement Analysis in Software Development Life Cycle (SDLC)

Requirement Analysis Stages/Steps

As you can see, Requirement Analysis is the first activity in SDLC followed by Functional Specification and so on. Requirement analysis is a vital step in SDLC as it resonates with acceptance testing that is critical for product acceptance by customers.

In this tutorial, we will explain how requirement analysis is done in SDLC. We will also see the various steps involved, outcomes, challenges, and corrective measures in requirement analysis.

Requirement analysis starts with:

1. Requirement gathering is also called elicitation.
2. This is followed by analyzing the collected requirements to understand the correctness and feasibility of converting these requirements into a possible product.
3. And finally, documenting the requirements collected.

#1) Requirement Gathering

To make sure that all the steps mentioned above are appropriately executed, clear, concise, and correct requirements must be gathered from the customer. The customer should be able to define their requirements properly and the business analyst should be able to collect them in the same way the customer is intending it to convey them.

Many a time it is not possible that requirement gathering is done efficiently by business analysts from the customer. This might be due to dependency on many people related to the expected end product, tools, environment, etc. Thus, it is always a good idea to involve all the stakeholders who could influence or could be influenced by the end product.

The possible stakeholder’s group could be Software Quality engineers (both QC and QA), any third party vendor who could provide support in the project, end-user for whom the product is intended, software programmers, and another team within the organization who might provide a module or software platform, software libraries, etc. for product development.

Example:  In an organization, they develop an ADAS product (surround-view camera system for a prestigious OEM) that needs Autosar stack and Bootloader binaries that are received from another supplier.

Involving various stakeholders in the requirement gathering stage helps in understanding various dependencies on each other and any possible future conflict could be averted.

Sometimes, it is a good idea to create a prototype model of the intended product planned, and show it to the customer. This is an excellent way to convey to customers what product are they expecting and how it may look later. This helps the customer in visualizing the product that they are expecting and helps them to come up with clear requirements.

This prototype creation depends on two types of product:

1. A similar product that customers intended, exists within the organization.
2. New product to be developed.

(i) In the first case, it is easier to show the customer what the end product would look like and how it would be developed. In automotive ADAS, it is possible to show customers another product that is already on the market and was developed within the organization.

For Example, A surround-view camera system developed for an OEM (GM, Volkswagen, BMW, etc.) can be showcased to another OEM.

Please note, it is not wise to show product/proto product to the customer which is under development as it may violate the Non-Disclosure Agreement signed with another customer for whom that product is being developed. It may also result in an unnecessary legal tussle.

Another example could be that of the infotainment system, being developed by the organization, and is already on the market. Business analysts and other stakeholders within an organization may plan a workshop demo for the customer, displaying infotainment systems with tangible HMI, device connector ports, sandbox, etc.

This will help the customer in understanding how the end product would look and provide their requirements much more clearly.

(ii) The second case may be achieved by creating a basic working model by doing simple coding and assembly (most features here are hardcoded in software programs), or by creating a flow chart or diagram that could convince customers how the product would look.

In any case, it would be a breather for the requirement gathering process as the customer now knows what he wants.

The business analyst can now organize formal requirement elicitation meetings, where all stakeholders could be invited and thus can note down the various requirements provided by the customer (in some cases, if stakeholders are more in number, a separate scribe could be appointed to note down customer requirements or user stories so that business analyst could concentrate on moderating the meeting).

Requirements gathered can be in the form of user stories (in agile development), use cases, customer natural language documents, diagrams, flowcharts, etc. User stories are becoming popular in the modern-day software development life cycle. User stories are basically a set of customer inputs in their natural language.

Requirement Gathering Example: In the ADAS surround-view camera system, one possible user story could be: “As a user, I should be able to see what’s there in the rearview of my car”.

There could be many “why,” questions asked on each user story, which will help the customer in providing more detailed information on the requirement.

In the above user story, if a customer says “As a user, I should be able to see what’s there in the rearview of my car”, asking the question “why” could give “As a user, I should be able to see what’s there in the rearview of my car, so that I can park my car safely”.

Asking the question “why” also helps in creating objective and atomic requirements from humongous natural language statements given by the customer. This can easily be implemented later in the code.

Another way of gathering the requirement is in the form of use cases. A use case is a step-by-step approach for achieving a certain result. This does not tell how the software will work on user input rather it says, what is expected of user inputs.

Example:

#2) Analyzing Gathered Requirements

Post requirement gathering, analysis of requirement starts. At this stage, various stakeholders sit and do a brainstorming session. They analyze the requirements gathered and look for the feasibility to implement them. They discuss it with each other and any ambiguity is sorted out.

This step is important in the requirement analysis process due to the following main reasons:

(i) Customer may provide some requirements which could be impossible to implement due to various dependencies.

Example: Customers may ask to surround-view the camera system with a rearview camera feature that will help in parking the car. The customer may also ask for the Trailer hitch feature which also uses the rear camera to work.

If the customer states a requirement that the rearview camera for parking assistance should work at all times without an exception, then the Trailer feature would never work and vice versa.

(ii) A business analyst might have understood the requirement from the customer differently than how a programmer would have interpreted it.

Since programmers think as technical experts, it is always possible that customer requirements are incorrectly converted to functional specifications which will later be incorrectly made to architecture and design documents and subsequently to code. The impact is exponential and so should be checked.

A possible remedial measure could be by following an agile method of software development, following use cases that customer provides, etc.

#3) Documenting Analyzed Requirements

Once the analysis of requirements is done requirement documentation starts. Various types of requirements come out of the analysis of requirements.

Some of these are:

(i) Customer Requirement specification.

(ii) Software Architecture requirement.

Example:

(iii) Software Design requirement.

Example:

(iv) Functional Requirement specification (directly derived from customer specifications.)

Example: “When the user taps on Bluetooth icon on Infotainment HMI, Bluetooth screen should be displayed”

(v) Non-functional Requirement specification (viz. performance, stress, load, etc.).

Example: “It should be possible to pair 15 Bluetooth devices with infotainment system without degradation of system performance”.

(vi) User Interface requirements.

Example: “On the Tuner FM screen, a button should be provided to select different stations”

The above requirements are recorded and documented in requirement management tools, like IBM DOORS, and HP QC. Sometimes organizations have their custom-made requirement management tools to reduce costs.

Let us now look into the process of converting Business requirements to Software Requirements (functional and non-functional).

Converting Business Requirements To Software Requirements

Business requirements, as discussed above are high-level requirements that talk about what end-user wants from a defined action on the software system. Developing the whole software system based on these requirements is not possible as a detailed description of how the software system or component will be implemented is not mentioned.

Thus, Business requirements must be broken down into more detailed software requirements which will be further detailed to functional and non-functional requirements.

To do this, the following steps could be followed:

1. Break down the high-level business requirements into detailed user stories.
2. Deriving a flowchart to define the flow of activities.
3. Providing the condition that justifies the derived user stories.
4. Wireframe diagrams to explain the workflow of objects.
5. Defining non-functional requirements out of the business requirements.

Let us start by taking an example Automotive Infotainment system.

The business requirement says, “End-user should be able to access Navigation widget box from Infotainment system HMI and should be able to set destination address”.

So, the above-enlisted steps can be implemented as:

#1) Break down the high-level business requirements into detailed user stories.

Let us convert this business requirement into a high-level user story, “As a user, I should be able to access the Navigation widget box so that I can enter the destination address”. This user story tells what is needed by the end-user. We will try to define how to implement this requirement.

Let’s start by asking possible questions about this user story viz.

1. Who are the users?
2. How can I access Navigation, onboard (from an SD card), or from SmartPhone?
3. What sort of destination entries can I enter?
4. Should I be allowed to enter the destination even when the Car is in Parking?

These are more detailed level user stories derived from high-level user stories and would help us in getting more insight into our business requirements.

At this point, we can take up one of the user sub-stories and start questioning. Let us take (no. 3):

1. Can I enter destination entries like Geo Coordinates, Postal Address, Speech Recognition, etc.?
2. Do I need GPS for entering Geo-Coordinates?
3. Can I enter the current destination address by searching from the history of addresses?

#2) Deriving a flowchart to define the flow of activities.

Now we can see that the business requirement is broken down into very detailed use cases which can be marked in the flowchart below:

#3) Providing conditions that justify derived user stories.

We can see that more detailed information is emerging due to the decomposition of the high-level business requirement into detailed low-level user stories and the flowchart. From this flowchart, we can get the technical details needed for implementation viz.

• Screen loading time to display destination entry should be 1 sec.
• The destination entry keyboard should have alphanumeric characters and special symbols.
• GPS enable/disable toggle button should be present on the Navigation destination entry screen.

The above information satisfies user stories and makes it possible for the requirement to be tested discretely and measurably avoiding any confusion with the requirement while being implemented as features.

#4) Wireframe diagrams to explain the workflow of objects.

From the above use case, we will derive a wireframe diagram that will make the user interface clearer.

#5) Defining non-functional requirements out of the Business requirements.

It’s imperative that detailed software requirements are derived from high-level business requirements, but many a time only functional requirements are identified which say how a system will behave to a particular user input/action.

However, functional requirements do not clarify systems performance and other qualitative parameters like availability, reliability, etc.

Examples:

a) We will take the example of the above automotive infotainment system.

If the driver(end-user) of the car plays music from USB and Navigation guidance is in progress, also gets an incoming call via Bluetooth in Hands-free mode then load on CPU and RAM consumption increases to a maximum level as multiple processes are running in the background.

At this point, if the driver taps on an infotainment system touchscreen interface to reject incoming calls via auto-reply SMS (the same way how we do on our mobile phones), the system should be able to perform this task and should not hang or crash. This is the performance of the system when the load is high and we test availability and reliability.

b) Another case is the Stress scenario.

Take an example, the infotainment system receives back-to-back SMSs (maybe 20 SMS within 10 sec) via a connected Bluetooth phone. The infotainment system should be able to handle all incoming SMS and at no point should miss any of the incoming SMS notifications on Infotainment HMI.

The above examples are cases of non-functional requirements that could not be tested via functional requirements alone. Although sometimes, customers miss providing these non-functional requirements. It is the responsibility of the organization to provide them with this information when a product is delivered to the customer.

Understanding Non-functional Requirements Cases

The below table explains non-functional requirements:

SL NoFeature/use caseCPU load(max)RAM usage(max out of 512MB)Performance Parameters
1Max no. of Bluetooth devices that can be paired to Infotainment system75%300 MB10 Bluetooth devices

2Time to download 2000 Phone contacts in Infotainment system after Bluetooth pairing and connection90%315 MB120 Seconds

3Time to Scan all available FM stations in Tuner in infotainment system50%200 MB30 Seconds

Non- functional requirements, unlike functional requirements, take the full life cycle of a project to get implemented, as they are implemented incrementally in respective Agile Sprints or in different iterations.

So, this is how we derive Software Requirements from Business Requirements.

Difference Between Business Requirements And Software Requirements

We have seen above how to derive Software requirements from high-level Business requirements. Software requirements enable the programmer and test engineer to develop the system and test it efficiently. So, we now know that business requirements are high-level customer natural language requirements while software requirements are detailed low-level requirements that help in the implementation of the software system.

Let us look into the detailed difference between the two requirement types.

Business RequirementsSoftware Requirements

They are high-level requirements by a customer saying “what” system should do. These requirements do not say “how” the requirements should work.They concentrate on the “how” aspect of Customer requirements. These requirements explain how the system would work/implement.

These requirements deal with the business goal of an organization.
Example: User should be able to Set Navigation destination.These requirements explain the technical know-how of the requirements.
Example: When user clicks on the Navigation destination icon, the database should load the destination details for the user to enter.

Business requirements focus on the organization’s benefit.
Example: User should be provided with information for upgrading the Navigation feature from the dealer in the Infotainment system if Navigation is not present on the System and the user taps on Navigation icon.Software Requirements deal with the implementation detail of business requirements in the system.
Example: When the user clicks on the Navigation icon on the Infotainment system, an API call should be initiated for the display of a message to the user for system upgrade.

Business requirements are normally written in Natural language or high-level user stories.Software requirements are functional and non-functional.
Example: of non-functional requirements are performance, stress, portability, usability, memory optimization, look and feel, etc.

Conclusion

Requirement analysis is the backbone of any SDLC model.

An issue missed during requirement analysis and caught at Unit testing could cost tens of thousands of dollars to an organization and this cost could lead to millions of dollars if it comes from the market as a callback (in 2017, the USA charged airbag manufacturer, Takata a fine of $1Billion due to exploding airbags).

The organization would end up performing damage control tasks like root cause analysis, preparing 5 why documents, fault tree analysis, 8D document, etc. instead of concentrating on software development and quality.

In worst cases, the organization would be dragged into legal lawsuits filed by the customer if the affected feature is security/safety-related like security access, airbag, ABS (Anti-Lock braking system), etc.