-

Leading University
Department of

Computer Science and Engineering

Assignment
On

Course Code - CSE-3214

Course Title: Software Engineering

Submitted To
Mohammad Soaib Rahman
Lecturer
Computer Science & Engineering

Leading University

Submitted by
Samira Tasneem Hussain
ID: 0182220012101075
Section: B Batch:60
Leading University, Sylhet
 Collecting Software Requirements
Collecting software requirements is a crucial step in software development, ensuring that the final product meets user
needs and business goals. This process involves gathering, analyzing, and documenting the functionalities and constraints
of a system. Effective requirement collection minimizes misunderstandings, reduces development costs, and enhances
user satisfaction. Various techniques such as interviews, surveys, observations, document analysis, and workshops help
identify stakeholder expectations, technical constraints, and potential improvements. A well-defined requirement
collection process lays the foundation for a successful software project by ensuring clarity, feasibility, and alignment
with user expectations.

Five Methods for Collecting Software Requirements

1. Interviews

Interviews are a common requirements elicitation technique used in software development to gather information
from stakeholders about their needs, expectations, and constraints for a software system. These interviews help
software engineers understand the system requirements more clearly before designing and developing the
application.

Types of Interviews
1. Structured Interviews

○ Questions are predefined and fixed.

○ Used when clear, specific information is needed.
○ Example: A developer asks a product owner about required system features using a list of predefined
questions.
2. Unstructured Interviews

○ Open-ended and flexible conversations.

○ Useful for exploring stakeholders' needs when requirements are not well-defined.
○ Example: A software analyst discusses general business challenges with a client to discover potential
software solutions.
3. Semi-Structured Interviews

○ A mix of predefined and open-ended questions.

○ Allows flexibility while keeping the discussion focused.
○ Example: An interviewer starts with prepared questions but explores additional insights based on the
interviewee’s responses.

Steps in Conducting an Interview

1. Preparation

○ Identify stakeholders (users, clients, developers, etc.).

○ Prepare relevant questions.
2. Conducting the Interview

○ Establish a comfortable environment.

○ Listen actively and take notes.
3. Recording & Documenting

○ Record responses (audio, video, or written).

○ Summarize key points and validate with the interviewee.
4. Analysis & Follow-up

○ Identify patterns, contradictions, and missing information.

○ Clarify doubts through follow-up interviews if necessary.

Advantages of Interviews in Requirement Gathering

 ● Provides direct insights from stakeholders.
● Allows clarification and follow-up questions in real-time.
● Helps identify implicit needs and expectations.

Challenges of Using Interviews

● Time-consuming and may not scale for large projects.
● Stakeholders might forget or misinterpret their own requirements.
● Interviewer bias can affect the collected data.

Example Scenario
Imagine developing an E-commerce App.

● A structured interview with the business owner may include questions about inventory management.
● An unstructured interview with customers may explore how they browse and purchase products.
● A semi-structured interview with delivery personnel may reveal challenges in tracking orders.

By conducting these interviews, developers can gather well-rounded requirements and design a system that meets user
needs effectively.

2. Surveys and Questionnaires

Surveys and questionnaires are requirement elicitation techniques used in software development to gather feedback
from stakeholders about their needs, preferences, and expectations. These methods help software engineers collect data
from a large audience efficiently.

Types of Surveys and Questionnaires

1. Surveys

● A structured method to collect data from multiple stakeholders.

● Can be conducted via online forms, emails, or paper-based methods.

2. Questionnaires

● A set of predefined questions designed to gather specific feedback.

● Used to collect quantitative and qualitative data.

Steps in Conducting Surveys and Questionnaires

1. Define Objectives

● Determine the purpose of the survey/questionnaire.

● Identify the target audience (users, clients, developers, etc.).

2. Design Questions

● Use clear and concise language.

● Include a mix of question types (multiple-choice, ratings, open-ended).

3. Distribute the Survey/Questionnaire

● Share via email, website, social media, or direct contact.

● Ensure a user-friendly format for higher response rates.

4. Collect Responses

● Monitor participation and encourage engagement.

 ● Use automated tools to record and store responses.

5. Analyze Data

● Identify patterns, trends, and common concerns.

● Convert responses into actionable requirements.

6. Report Findings

● Present insights to developers, product managers, and stakeholders.

● Make data-driven decisions for system design.

Advantages of Surveys and Questionnaires

Scalable – Can collect feedback from many stakeholders at once.
Cost-Effective – Requires minimal resources compared to interviews.
Easy Analysis – Structured responses allow quick data processing.

Challenges of Using Surveys and Questionnaires

Low Response Rates – Users may ignore or skip the survey.
Misinterpretation of Questions – Poorly worded questions may lead to inaccurate answers.
Limited Depth – Unlike interviews, responses may lack detailed explanations.

Example Scenario
Imagine developing a Ride-Sharing App.

● A survey could be sent to drivers and passengers to collect feedback on existing services.
● A questionnaire could ask passengers to rate app performance, ease of use, and pricing on a Likert scale.

By analyzing responses, developers can refine the system to better meet user expectations.

3. Observation

Observation is a requirements elicitation technique where analysts study users in their natural environment to understand how
they interact with a system, perform tasks, and encounter challenges. This method helps capture real-world usage patterns and
implicit requirements that stakeholders may not explicitly mention in interviews or surveys.

Types of Observation

1. Passive Observation
● The analyst watches users perform their tasks without interference.
● Example: Observing a cashier using a point-of-sale (POS) system to identify usability issues.

2. Active Observation
● The analyst interacts with users, asks questions, and seeks clarifications.
● Example: Observing and asking warehouse workers about inventory tracking challenges.

Steps in Conducting Observations

1. Define Objectives
● Determine what tasks and behaviors to observe.
● Identify which users or roles to study.

2. Plan the Observation

 ● Decide whether to use passive or active observation.
● Get stakeholder consent to observe their workflows.

3. Conduct the Observation

● Take notes, record videos, or capture screenshots (if permitted).
● Focus on pain points, inefficiencies, and user behaviors.

4. Analyze Findings
● Identify common patterns, bottlenecks, and user difficulties.
● Compare observations with stakeholder expectations.

5. Validate & Document Requirements

● Discuss findings with users to confirm accuracy.
● Document observations to guide system improvements.

Advantages of Observation
Captures Real Behavior – Shows how users actually work, not just how they describe it.
Identifies Hidden Issues – Reveals inefficiencies and unspoken challenges.
Provides Context – Helps understand workflow dependencies and constraints.

Challenges of Using Observation

Time-Consuming – Requires extended periods of study.
User Awareness Effect – Users may change behavior when they know they’re being observed.
Limited to Visible Actions – Cannot capture mental processes or future needs.

Example Scenario
Imagine developing a Hospital Management System.

● Passive Observation: Watching nurses and doctors use the existing patient record system to spot inefficiencies.
● Active Observation: Asking receptionists about challenges in scheduling appointments while observing their workflow.

By analyzing these observations, developers can refine system features to enhance usability and efficiency.

4. Document Analysis

Document analysis is a requirements elicitation technique where existing documents, such as reports, manuals, specifications,
and business process documents, are reviewed to gather information about the system requirements. It helps software engineers
understand the current system, business rules, and functional requirements without directly engaging with stakeholders.

Types of Documents Analyzed

1. Identify Relevant Documents

● Determine which documents contain relevant information for the software requirements.
● Example: User manuals for understanding user needs or system specifications for technical requirements.

2. Review the Documents

● Study the content thoroughly, focusing on key business rules, system constraints, and requirements.
● Look for inconsistencies or gaps in information.

3. Extract Relevant Information

● Highlight important requirements, goals, and any issues that need to be addressed.
 ● Focus on both functional and non-functional requirements.

4. Analyze and Cross-Reference

● Cross-reference findings with other requirements gathering methods (e.g., interviews, surveys) for consistency.
● Identify gaps in the information that may require further elicitation.

5. Document Findings
● Organize and document the requirements in a structured format (e.g., use cases, user stories).
● Summarize the relevant information in a requirements specification document.

Advantages of Document Analysis

Inexpensive – No need for direct interaction with stakeholders.
Unbiased – Data is already documented, so it reduces the risk of interviewer or respondent bias.
Helps Define Scope – Provides a clear understanding of existing systems and business goals.

Challenges of Document Analysis

Outdated Information – Documents may be obsolete or incomplete, leading to inaccurate requirements.
Lack of Context – Documents may not provide a full understanding of the business environment or user needs.
Limited Interaction – Cannot capture real-time feedback or implicit needs of users.

Example Scenario
Imagine developing a Customer Relationship Management (CRM) System.

● Business Documents: Analyzing the company’s sales strategies and customer service policies to understand business
goals.
● System Documents: Reviewing current CRM software documentation to identify existing features and gaps.

By analyzing these documents, developers can ensure the new system aligns with business objectives, integrates with existing
processes, and meets technical specifications.

5. Workshops and Brainstorming Sessions

Workshops and brainstorming sessions are collaborative techniques used to gather and refine software requirements through
group discussions and idea generation. These methods help stakeholders collaboratively explore needs, create solutions, and
prioritize features.

Types of Workshops and Brainstorming Sessions

1. Workshops
● Structured meetings where stakeholders (users, developers, product managers) come together to define, refine, and
prioritize requirements.
● Facilitated by a requirements engineer or moderator to ensure focus and productive discussions.
● Example: A workshop with business users and IT teams to identify features and constraints for a new software tool.

2. Brainstorming Sessions
● Informal group discussions aimed at generating creative ideas and solutions.
● Encourages participants to share unconventional ideas to explore all possibilities.
● Example: A brainstorming session with the design team to identify innovative features for a mobile app.

Steps in Conducting Workshops and Brainstorming Sessions

1. Plan the Session
● Define goals and set clear objectives for the session .
● Select participants who are key stakeholders and have relevant expertise .

2. Prepare for the Session

● Set the agenda and send it to participants in advance.
● Gather relevant background materials .

3. Facilitate the Session

● Encourage free-flowing ideas in brainstorming sessions and structured discussions in workshops.
● Capture all ideas and keep the group focused on the objectives.

4. Prioritize and Refine Ideas

● In workshops, participants may use techniques like dot voting or prioritization matrices to decide on the most important
requirements.
● In brainstorming sessions, ideas are grouped, refined, and evaluated for feasibility.

5. Document Findings
● Summarize the results of the session, including key insights, decisions, and action items.
● Create a requirements document based on the session outcomes, ensuring that all stakeholders are aligned.

Advantages of Workshops and Brainstorming Sessions

Collaborative and Engaging – Involves multiple stakeholders, fostering ownership and understanding of requirements.
Quick Decision-Making – Enables rapid identification of requirements and priorities through group consensus.

Challenges of Workshops and Brainstorming Sessions

Time-Consuming – Workshops and brainstorming sessions can take significant time to prepare and conduct.
Conflicting Opinions – Different stakeholders may have conflicting ideas, making it difficult to reach a consensus.

Example Scenario
Imagine developing a Project Management System.

● Workshop: Organizing a workshop with project managers, team leads, and developers to define critical features like task
management, timelines, and reporting.
● Brainstorming Session: Holding a brainstorming session with designers and users to explore creative ways to present
project data visually.