Session 3

Download as pdf or txt
Download as pdf or txt
You are on page 1of 6

“ Requirements Gathering


Requirements Analysis

Requirements Gathering
Requirements gathering is one of the most critical phases in software development. It involves understanding what the stakeholders need,
aligning their expectations with the project scope, and ensuring the development team has a clear roadmap. Proper requirements
gathering sets the stage for a successful project and helps avoid costly missteps later.
Requirements Analysis

Types of Requirements: Functional vs. Non-functional


1. Functional Requirements
Functional requirements specify what the system should do. These are the essential features and functionalities that users will interact with. They
define how the system behaves in response to specific inputs, what processes it follows, and the expected outputs.

Examples of Functional Requirements:

● A user should be able to log into the system using an email and password.
● The system should send an email notification after a user submits a form.
● The application must calculate sales tax based on the user’s location.

In Short: Functional requirements are all about the actions the system performs for users.

2. Non-functional Requirements
Non-functional requirements describe how the system performs those functions. They cover aspects like system performance, security, usability, and
scalability. Non-functional requirements ensure the system runs efficiently, securely, and reliably, providing a seamless experience to users.

Examples of Non-functional Requirements:

● The website should load within 2 seconds.


● The system must support 5000 concurrent users.
● Data should be encrypted at rest and in transit.
Requirements Analysis

Techniques for Requirements Elicitation


Requirements elicitation is the process of gathering information from stakeholders to understand their needs. Here are some of the most commonly
used techniques:

1. Interviews

Interviews involve one-on-one or group conversations with stakeholders to extract information. By asking the right questions, the development team
gains insights into what the users expect from the system.

Example: Conducting interviews with department heads to understand their specific business processes.

2. Surveys and Questionnaires

When there are multiple stakeholders, surveys and questionnaires are efficient tools for gathering input. They allow developers to collect information
from a large group in a standardized format.

Example: Distributing a questionnaire to users asking for feedback on the most important features they need.

3. Workshops

Workshops bring multiple stakeholders together to brainstorm, discuss, and finalize requirements. They are collaborative and can uncover hidden
expectations or challenges.

Example: A workshop with product managers, QA teams, and developers to align on the product vision and scope.
Requirements Analysis

Techniques for Requirements Elicitation


4. Document Analysis

Reviewing existing documentation, such as business process manuals, system specifications, or even feedback from previous projects, can provide a
wealth of knowledge about what’s needed in the new system.

Example: Analyzing the user manual of an existing system to see which features should be carried forward or improved in the new solution.

5. Observation

In this technique, analysts observe end-users interacting with the current system or performing their daily tasks. This provides valuable insights into
user behavior and can reveal requirements that stakeholders may overlook in discussions.

Example: Observing customer service agents while they use a ticketing system to identify pain points or inefficiencies.

6. Prototyping

Prototyping involves creating a simple model or mockup of the system. This helps stakeholders visualize the end product, refine their ideas, and
provide clearer feedback.

Example: Developing a clickable wireframe of a new mobile app’s user interface to gather early feedback on design and functionality.
Requirements Analysis

Requirements Analysis
Once gathered, the requirements must be analyzed for clarity, completeness, and feasibility. This ensures that no ambiguous or conflicting
requirements make their way into development.

1. Clarification and Refinement


Sometimes, initial requirements are too vague. It’s important to work closely with stakeholders to clarify details and refine requirements to be as
specific as possible.
Example: If a stakeholder requests that “the system should be fast,” the QA team needs to clarify what "fast" means — is it a 2-second response time?
1 second?

2. Prioritization
Not all requirements are equally important. Use techniques like the MoSCoW method (Must-have, Should-have, Could-have, Won’t-have) to prioritize
which features are crucial and which can be deferred.
Example: In a project where time is tight, “user authentication” might be a must-have requirement, while “user profile customization” is a
could-have.

3. Feasibility
Some requirements may not be technically or financially feasible. It’s essential to assess whether the team can meet each requirement within the
project constraints, like budget, time, or resources.
Example: A stakeholder might ask for real-time video streaming on a platform that has limited server capacity. The team would need to analyze
whether this is feasible given the existing infrastructure.

You might also like