Scribd
Upload
13 views18 pages

Lecture 3 Summary

Uploaded by

bsse2380220
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
13 views18 pages

Lecture 3 Summary

Uploaded by

bsse2380220
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 18

LECTURE 3

SUMMARY:
REQUIREMENTS
ELICITATION
1. What is requirements
elicitation?
■ Requirements elicitation is the process of
finding out what people need from a
software system. It involves asking
questions, gathering information, and
writing down clear details about what the
system should do and how it should work.
2. Why is requirements
elicitation important?
 It helps everyone understand what is
needed for the project.
 Reduces the chance of mistakes and delays.
 Makes it easier to design a system that
meets user needs.
 Helps create a better, high-quality product.
3. What are the main activities in
requirements elicitation?
 Talking to Stakeholders: Work with users,
managers, and other involved people.
 Gathering Information: Use different ways to
collect details about the system.
 Writing and Checking: Make sure the
requirements are clear and complete.
 Confirming: Ensure that what’s written
matches what people need.
4. What are the levels of
requirements?
 Business Requirements: These explain the main
goals of the project and how it will benefit the
organization.
 User Requirements: These focus on what tasks
users need to do with the system.
 Functional Requirements: These describe how the
system should behave and what it must do.
 Non-Functional Requirements: These cover system
qualities like speed, security, and ease of use.
5. What are some common ways
to gather requirements?
 Interviews: Talk directly with people to learn
their needs.
 Workshops: Group meetings to discuss and
agree on requirements.
 Focus Groups: Small user groups to gather
opinions and ideas.
 Observations: Watch how people currently
work to find improvements.
 Surveys: Use questionnaires to collect
5. What are some common ways
to gather requirements?
 System Analysis: Look at other systems to
find data and connection requirements.
 User Interface Analysis: Study existing
screens or tools to understand user needs.
 Document Analysis: Review old documents,
manuals, or processes to find useful
information.
6. What do stakeholders do in
requirements elicitation?
■ Stakeholders help by sharing their needs,
goals, and any limits or rules the project
must follow. They also check the
requirements to make sure they are correct.
Examples of stakeholders include users,
managers, developers, and testers.
7. What problems can happen
during requirements
elicitation, and how can
they be solved?
 Different Opinions: Use group discussions to
find common ground.
 Unclear Details: Ask more questions and use
examples to clarify.
 Limited Time: Focus on the most important
requirements first.
 Missing Information: Talk to more people
and double-check sources.
8. What is the difference
between functional and
non-functional
requirements?
 Functional Requirements: Explain what the
system must do (e.g., "Users can upload
files").
 Non-Functional Requirements: Describe how
the system performs tasks (e.g., "System
responds within 2 seconds").
 Key Examples:
 Functional Requirement: "Users can upload
profile pictures."
 Non-Functional Requirement: "The system loads
9. Can requirements
elicitation happen more
than once?
 Yes, it is often repeated. As new ideas or
changes come up, requirements can be
updated and improved.
10.Why is planning important
for requirements
elicitation?
■ Planning helps set clear goals, choose the
right tools, and make sure everyone knows
what to expect. It saves time and avoids
confusion.
11.How do you prepare for a
requirements session?
 Set a clear agenda for the meeting.
 Gather any needed tools or materials.
 Learn about the people involved and their
roles.
 Plan for any possible challenges, like time
zones or technical issues.
12.Why is follow-up
important after gathering
requirements?
 Share notes with everyone to confirm
accuracy.
 Resolve any unanswered questions.
 Get feedback to make sure nothing is
missed.
13.What are explicit and
implicit requirements?
 Explicit Requirements: Clearly stated needs
(e.g., "System supports multiple user
roles").
 Implicit Requirements: Unspoken but
expected needs (e.g., the system must be
secure).
14.How can you find missing
requirements?
 Break big requirements into smaller pieces.
 Talk to different types of users.
 Use diagrams or checklists to spot gaps.
 Ask follow-up questions to clarify unclear
points.
15.What is the final result of
requirements elicitation?
 A complete list of requirements that
includes:
 Project goals.
 Functional and non-functional needs.
 Data rules and any limits.
 Risks and priorities.
END OF
SUMMARY

You might also like