Session 3
Session 3
Session 3
”
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
● 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.
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.
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
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.
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.