SDLC Requirement Analysis – All You Need to Know
Copied!
Software development is a huge task that creates a working software product and helps in Mobile App Development. SDLC Requirement Analysis plays a crucial role in it.
You can build the software product as per the customer requirements. The software product mostly complies with what end the customer had expected, but sometimes the product does not fully comply with the customer expectations.
What is Requirement Analysis?
Requirement Analysis is an important phase of SDLC. Let’s understand its concept with a Requirement Analysis example:
Customer Expectation:
What Customer Receives:
You can easily analyze from the above images that there is a mismatch in the end product to customer expectations. It can be due to many reasons like the incorrect implementation of customer requirements, faulty design, misunderstanding of customer requirements by programmers and quality team, etc.
A reasonable product delivery demands correct requirements gathering, the efficient examination of requirements gathered, and clear requirement documentation as a precondition. This entire process is known as Requirement Analysis in Software Development Life Cycle (SDLC).
Learn more → What is SDLC (Software Development Life Cycle)?
Requirements Analysis Process
The Requirement Analysis phase is SDLC’s first activity, followed by Functional Specs and so on. It is a crucial step in SDLC as it resonates with the acceptance testing, critical for product acceptance by customers.
Here, you will learn how to do the requirement analysis phase in SDLC. We will see its various steps, outcomes, challenges, and corrective measures.
Requirement Analysis begins with:
- Requirement Gathering, which is also known as Elicitation.
- It is followed by Analyzing the collected requirements to understand the feasibility and correctness of converting the requirements into a possible product.
- Then, Documenting the gathered requirements.
Requirement Gathering Techniques
To execute all the steps mentioned above, you must gather clear, concise, and correct customer requirements. Let the customer define their needs adequately, and the business analyst collects them as the customer wants.
It’s not always possible for the business analysts to do requirement gathering from the customers. It can be due to dependency on many people related to the expected end product, environment, tools, etc. So, involve the stakeholders who can influence or can be influenced by the end product.
The probable stakeholder’s group can be Software Quality Engineers (both QC and QA). This third-party vendor can provide support in the project, the end-user for whom the product is intended, another team within the organization who can provide a module or the software platform, software programmers, software libraries, etc., product development.
For example, in an organization, they develop an ADAS product ( a surround-view camera system for a prestigious OEM) for AUTOSAR stack and Bootloader binaries from another supplier.
Involving various stakeholders in the requirement gathering phase helps you to understand multiple dependencies on each other and can avert any potential future conflict.
You can create a prototype model of the intended, planned product and show it to the customer. It’s an excellent way to convey to the customers what products they are expecting and look like. Thus, helping the customer in visualizing the product that they expect and come up with clear requirements.
The prototype creation depends on two types of products:
- A similar product that the customers intended exists in the organization.
- New product to be developed.
In the first case, it is easy to show the customer how the end product will look like and will be developed. In automotive ADAS, you can offer the customers another product already in the market and developed within the organization.
For example, a surround-view camera developed for an OEM can be showcased to another OEM.
It is not advisable to show product/proto product to the customer under development as it violates the Non-Disclosure Agreement signed with another customer for whom you are developing that product. Thus, resulting in an unnecessary legal tussle.
The second case is achieved by developing a basic working model through simple coding and assembly, or a flow chart or diagram that can convince the customer how the product would look.
In all cases, it’s a breather for the requirement gathering process as the customer knows what he wants.
Now, the business analyst can organize formal requirement elicitation meetings to invite the stakeholders and note the customer’s various requirements.
The requirements gathering can be in user stories (in Agile), customer natural language documents, use cases, diagrams, flowcharts, etc. User stories are viral nowadays in modern-day software development. They are a set of customer inputs in their natural language.
Requirement Gathering Example
In the ADAS surround-view camera system, a possible user story can be: “As a user, let me check what’s there in the rearview of the car.”
Many “why” questions asked on the user stories can help the customer provide more detailed information on the requirements.
In the user story mentioned above, if a customer says, “As a user, let me check what’s there in the rearview of the car,” then, asking a question “why” can give “As a user, let me check what’s there in the rearview of the car so that I can safely park my car.”
Asking the question “why” helps create objective and atomic requirements from customers’ humongous natural language statements. You can implement it later in the code.
Another way for requirement gathering is in the form of use cases. It’s a step-by-step approach to achieve a particular result. But, the use cases do not tell you how the software will work on user input. Instead, it tells you about what is expected of user inputs.
Analyzing Gathered Requirements
Post the requirement gathering, analysis of the requirement starts. In this phase, various stakeholders sit and perform a brainstorming session. They analyze the gathered requirements and look for feasibility to implement them. Later, the discussion happens, and the ambiguity, if any, is sorted out.
It’s an essential step in requirement analysis due to the following reasons:
(1) Customer may provide some requirements that could be impossible to implement due to various dependencies.
For example, the customer may ask to surround-view the camera system with a rearview camera feature that helps in parking the car. He may also ask for the Trailer hitch feature that uses the rear camera to work.
If the customer is stating a requirement that a rearview camera for parking assistance should work at all times without any exception, then the Trailer feature would never work and vice versa.
(2) A business analyst may understand the customer requirement differently than a programmer interprets it.
As the programmers think like technical experts, customer requirements are always getting incorrectly converted to functional specifications. Hence, it’s poorly made to architecture and design documents and subsequently to code. The impact is exponential and must be checked.
A possible remedial measure is to follow the Agile method of software development, following use cases that the customer provides.
Documenting Analyzed Requirements
Once you analyze requirements, the requirement documentation begins. Various kinds of requirements come out of the SDLC requirement analysis.
Some of them are:
(1) Customer Requirement Specification
(2) Software Architecture Requirement
(3) Software Design Requirement
(4) Functional Requirement Specification (directly derived from the customer specifications)
For example, “when a user taps on the Bluetooth icon of Infotainment HMI, Bluetooth screen should be displayed.”
(5) User Interface Requirements
For example, “On the Tuner FM screen, a button must be provided to select different stations.”
The requirements mentioned above are recorded and documented in requirement management tools, like IBM DOORS, HP QC. Some organizations have customized requirement management tools to reduce costs.
Converting Business Requirements to Software Requirements
Business requirements are high-level requirements that talk about what the end-user wants from a defined action in the software system. It is not possible to develop the whole software system based on these requirements. A detailed description of how the software system or the component will be implemented is not mentioned.
The business requirements should be broken down into more detailed software requirements and further detailed functional and non-functional requirements.
To do so, just follow the below steps:
- Break the high-level business requirements into detailed user stories.
- Derive a flowchart to define the flow of activities.
- Provide the condition that justifies the derived user stories.
- Wireframes the diagrams to explain the workflow of objects.
- Define the non-functional requirements out of the business requirements.
Read about → Agile Methodologies: What is the Agile Software Development Model?
Understanding the Non-Functional Requirements Cases
The table below explains the non-functional requirements:
| SL No. | Feature/ Use Cases | CPU Load (Max) | RAM Usage (Max out of 512 MB) | Performance Parameters |
| 1 | Max no. of Bluetooth devices that you can pair to Infotainment system | 75% | 300 MB | 10 Bluetooth devices |
| 2 | Time taken to download 2000 phone contacts in Infotainment system after Bluetooth pairing and connection | 90% | 315 MB | 120 Seconds |
| 3 | Time taken to scan all the available FM stations to Tuner in the Infotainment system | 50% | 200 MB | 30 Seconds |
The non-functional requirements, unlike the functional requirements, take the entire life cycle of a project to get implemented, for they are implemented incrementally in respective Agile Sprints or different iterations.
So, that’s how you derive Software Requirements from Business Requirements.
Business Requirements vs Software Requirements
Software requirements enable the programmer and the test engineer to develop the system and test it efficiently. So, you can say that business requirements are high-level customer natural language requirements, and software requirements are detailed low-level requirements that help implement the software system.
| Business Requirements | Software Requirements |
| They are high-level customer requirements talking about “what” the system should do. It does not talk about “how” the requirements should work. | They focus on the “how” aspect of Customer requirements that explain how the system would work/ implement. |
| They deal with the business goal of an organization. For example, the user should be able to set Navigation destination. | They explain the technical know-how of the requirements. For example, when a user clicks on the Navigation destination icon, the database must load the destination details for the user to enter. |
| They are normally written in Natural language or high-level user stories. | They are functional and non-functional. The examples of non-functional requirements are performance, stress, portability, memory optimization, usability, look and feel, etc. |
| They focus on the organization’s benefit. For example, the user should be offered the information for upgrading the Navigation feature from the dealer in the Infotainment system if the Navigation is not present on the system and the user taps on the Navigation icon. | They deal with the implementation detail of business requirements in the system. For example, when a user clicks on the Navigation in the Infotainment system, an API call should be initiated for the message display to the user for system upgrade. |
Conclusion
Requirement Analysis phase in SDLC is the backbone of any SDLC model.
Any issue missed during the requirement analysis and caught at Unit testing can cost tens of thousands of dollars to any organization. It could lead to millions of dollars if it comes from the market as a callback (in 2017, the USA had charged airbag manufacturer Takata a fine of $1Billion due to exploding airbags).
The organization would do damage control tasks like root cause analysis, preparing five why documents, 8D documents, fault tree analysis, etc., instead of concentrating on software development and quality.
In the worst case, the organization is dragged into legal lawsuits filed by the customer if the affected feature is security-related like security access, airbag, ABS, etc.
Are you looking for software developers for your project, then we are a team of highly-skilled and efficient developers. Ping us.
