What happens in the requirement analysis phase in SDLC

Requirements analysis allows software engineers to define user needs early in the development process. It helps them deliver a system that meets customers' time, budget and quality expectations. The process involves analyzing, documenting, validating and managing system or software requirements. Requirements analysis involves various tasks that help engineers understand stakeholder demands and explain them in simple and visual ways. It is essential to a software or system project's success.

For a project to be successful, its requirements must be:

1. Testable
2. Actionable
3. Documented
4. Measurable
5. Traceable 

Requirements analysis involves various stakeholders, such as project sponsors, throughout the project as well as end users whose inputs are most important. The best results typically occur when all parties work together to develop a high-quality requirement document.

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality software. The SDLC aims to produce a high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates. SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The life cycle defines a methodology for improving the quality of software and the overall development process.

The following figure is a graphical representation of the various stages of a typical SDLC.

A typical Software Development Life Cycle consists of the following stages −

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is performed by the senior members of the team with inputs from the customer, the sales department, market surveys and domain experts in the industry. This information is then used to plan the basic project approach and to conduct product feasibility study in the economical, operational and technical areas.

Planning for the quality assurance requirements and identification of the risks associated with the project is also done in the planning stage. The outcome of the technical feasibility study is to define the various technical approaches that can be followed to implement the project successfully with minimum risks.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved from the customer or the market analysts. This is done through an SRS (Software Requirement Specification) document which consists of all the product requirements to be designed and developed during the project life cycle.

Stage 3: Designing the Product Architecture

SRS is the reference for product architects to come out with the best architecture for the product to be developed. Based on the requirements specified in SRS, usually more than one design approach for the product architecture is proposed and documented in a DDS - Design Document Specification.

This DDS is reviewed by all the important stakeholders and based on various parameters as risk assessment, product robustness, design modularity, budget and time constraints, the best design approach is selected for the product.

A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation with the external and third party modules (if any). The internal design of all the modules of the proposed architecture should be clearly defined with the minutest of the details in DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The programming code is generated as per DDS during this stage. If the design is performed in a detailed and organized manner, code generation can be accomplished without much hassle.

Developers must follow the coding guidelines defined by their organization and programming tools like compilers, interpreters, debuggers, etc. are used to generate the code. Different high level programming languages such as C, C++, Pascal, Java and PHP are used for coding. The programming language is chosen with respect to the type of software being developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC. However, this stage refers to the testing only stage of the product where product defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate market. Sometimes product deployment happens in stages as per the business strategy of that organization. The product may first be released in a limited segment and tested in the real business environment (UAT- User acceptance testing).

Then based on the feedback, the product may be released as it is or with suggested enhancements in the targeting market segment. After the product is released in the market, its maintenance is done for the existing customer base.

Test Case Vs Test Scenarios

A test-case is a set of conditions for evaluating a particular feature of a software product. Basically, test cases help in determining the compliance of an application with its business requirements.

Whereas a test scenario is generally a one-line statement describing a feature of the application to be tested. It is used for end-to-end testing of a feature. Usually, it is derived from the use cases.

Test Case vs Test Scenario

Test Case	Test Scenario
A test case contains clearly defined test steps for testing a feature of an application.	A test scenario contains a high-level documentation, describing an end-to-end functionality to be tested.
Test cases focus on “what to test” and “how to test”.	Test scenarios just focus on “what to test”.
These have clearly defined step, pre-requisites, expected results etc. Hence, there is no ambiguity.	Test scenarios are generally one-liner. Hence, there is always possibility of ambiguity during testing.
Test cases can be derived from test scenarios. They have many to one relationship with the test scenarios.	These are derived from use cases.
Test cases are efficient in exhaustive testing of application.	Test scenarios are beneficial in quick testing of end-to-end functionality of the application.
More resources are required for documentation and execution of test cases.	Relatively less time and resources are required for creating and testing using scenarios.

Use Case Vs Test Case

Use cases are designed in the requirement and design phase of the SDLC methodology. Use cases are used to explain and document the interaction that is required between the user and the system to accomplish the user’s task. They are created to help the development team understand the steps that are involved in accomplishing the user’s goals.

Once created, use cases can often be used to derive more detailed functional requirements for the new system.

Test cases are derived from the use case and used in the testing phase of the SDLC methodology. It is used to validate whether the AUT under test is working as per requirement or not.

Below are the differences between Use Case and Test Case in tabular format.

Use Case	Test Case
A use case is a graphical representation of actions that describes the behavior of a system to do a particular task	Test Case is a document specifying a set of actions to be performed on the application under test to verify the expected functionality of the feature
To create a use case SRS (System Requirement Specification) is required	To write a test case preconditions, test data and steps are required
It is dependent on the requirement document	It is dependent on the use case
Business Analyst create use case by collecting the requirement	Tester/ QA Analyst create a test case by using use case
End user executes the use case	Testers executes the test case
The purpose of use case is to understand the end-user interaction with the system	The purpose of the test case is to validate whether that particular feature is functioning as expected or not.
The use case focuses on the end user	Test case focuses on the Test result
The result of the use case has not been verified	The result of a test case is verified with the expected result
Use case interacts with the user	Test case interacts with the result
Use case creation can be helpful in the requirement gathering, and design phase	Test case is executed in the testing phase

 

What is a Test Scenario

 A Test Scenario is a statement describing the functionality of the application to be tested. It is used for end-to-end testing of a feature and is generally derived from the use cases. 

Test scenarios can serve as the basis for lower-level test case creation. A single test scenario can cover one or more test cases. Therefore, a test scenario has a one-to-many relationship with the test cases.

What is a Test Case

A test case is a document which has a set of conditions/ actions/ steps that are performed on the software application in order to verify the expected functionality of the feature under test. A test case is mostly used to validate whether the developed feature is working as per requirement or not. It is a first-level action that is derived from test scenarios.

A test case design comprises,

Test Case Id (which should be unique)

Test Case Description

Preconditions

Test Data

Steps to execute

Expected Result

Actual Result

Status

Test case Author

Test case Executed by

Date of execution

Comments

 To write a Test Case, a QA requires basic writing skills, attention to detail, a good understanding of the application under test, and out of box thinking. A test case should be written in such a way that it can be executed by any testing team member. 

What is a Use Case

In Software testing, the term “use case” is used to describe all the possible steps a user may perform to interact with the system. It allows you to chalk out all the possible techniques and how the end-user can use the application with a set of instructions to the system and the expected result of the interaction with the system. It is a list of actions or event steps typically defining the interactions between an actor and system to achieve a goal.

Use cases also help QAs understand the areas where errors could occur while interacting with the system and design features to solve those errors. A use case is a graphical representation of a document explaining the steps an actor should perform to test the system.  

Example of a Use Case

Assuming the use case of an online shopping system between a customer and seller through an online shopping application. Here’s what the Use Case Diagram would be like.

The above use case diagram depicts an Online shopping system consisting of two main actors: Customer and Seller. Six use cases are identified to explain the high-level functionality of the online shopping system.

A customer can view products, add products to cart, checkout, and place orders. A seller can view products, update existing product details and its price, and add/remove products from inventory.