Module 2
Requirement Engineering
5.1 to 5.7,
6.1 to 6.5
7.1 to 7.3
Good morning everyone! Let me start with a quick story. Imagine you order a custom-made
car. You tell the company you want a fast car. They deliver a Formula 1 race car 🚗💨 … but
what you really wanted was a family SUV to travel with your parents and kids. Both are
‘fast’… but your requirement was misunderstood. Who do you think is at fault here – you, or
the company?”
👉 Student interaction: Collect answers. (Some may say company, some may say customer,
then reveal: Both – because the requirements were not clear or well-documented.)
Teacher:
“Most software project failures happen for this reason — unclear or misunderstood
requirements. In fact, studies show that 50% of project failures are caused by poor
requirements. So today, we’ll learn how to properly capture requirements.”
So what exactly is Requirements Engineering? According to Pressman, it is a systematic
process of discovering, documenting, and maintaining a set of requirements for a system
PART 1
Key Activities in Requirements Engineering (Pressman):
1. Inception – initial communication with stakeholders.
2. Elicitation – gathering requirements.
3. Elaboration – refining and expanding.
4. Negotiation – resolving conflicts.
5. Specification – writing them clearly.
6. Validation – checking if correct.
7. Management – handling changes over time.
Example:
“Suppose we are building a College Management System:
Students want easy course registration.
Faculty want attendance and grading features.
Management wants cost efficiency.
Government wants compliance with regulations.
You see? Multiple stakeholders, different priorities → that’s why RE is necessary.”
👉 Interactive question:
“If we are developing a mobile banking app, what requirements do you think customers, bank
employees, and government regulators will ask for?”
Students brainstorm and share.
Teacher notes answers on board.
Part 2: Establishing the Groundwork
Teacher:
“Before collecting requirements, we must establish the groundwork.”
Steps (Pressman):
1. Identify stakeholders – Who will use or be affected?
o Example: Online food delivery app → customers, delivery agents, restaurant
owners, admin.
2. Recognize multiple viewpoints – Each has unique priorities.
o Example:
Customer: fast delivery
Restaurant: higher sales
Delivery agent: fair pay
Admin: smooth operations
3. Encourage collaboration – bring people together.
4. Work toward shared vision – avoid conflicts later.
👉 Class Activity:
“Let’s do a quick exercise. Suppose we are designing a College Exam Portal. Who are the
stakeholders?”
Students list: students, faculty, admin staff, exam controller.
Teacher then asks: “What conflicts might arise between students and faculty
requirements?”
Discuss: (e.g., students want easy revaluation; faculty want strict timelines).
Part 3: Eliciting Requirements
Teacher:
“Now comes the most important step: elicitation. Elicitation means asking the right questions
to find out what stakeholders really need — not just what they say.”
Techniques (Pressman):
1. Interviews – one-to-one talks.
o Example: Asking students about what they want in the exam portal.
2. Questionnaires – for large groups.
3. Workshops/Focus Groups – multiple stakeholders in one room.
4. Observation – watching how people currently do tasks.
5. Use Cases/Scenarios – describing step-by-step system usage.
6. Prototyping – mockups or early versions to collect feedback.
Example:
“Think about an ATM. If I only ask a user: What do you want from an ATM? They may say
‘Cash withdrawal’. But real elicitation reveals: balance inquiry, fund transfer, mobile
recharge, mini statement, cardless withdrawal, language preference, security alerts. So we
need structured techniques.”
👉 Mini Role-play Activity (5–7 min):
Divide class into 2 groups.
Group A = Stakeholders (students, faculty, admin for exam portal).
Group B = Analysts.
Analysts ask 3 elicitation questions to each stakeholder group.
Teacher moderates, then shows how vague answers can be refined into proper
requirements.
⏰ 50 – 60 min | Wrap-up & Q/A
Teacher:
“Let’s quickly summarize today’s session:
Requirements Engineering helps us avoid misunderstandings.
Establishing groundwork means identifying stakeholders and goals.
Elicitation is about asking the right questions with techniques like interviews, surveys,
prototyping, and observation.
👉 Closing Question to Students:
‘Why do you think requirements often keep changing even after development starts?’”
(Students may say: new technology, changing business rules, user feedback, competitor
pressure).
Teacher (Final Note):
“Exactly! Requirements are living entities — they evolve. That’s why requirements
engineering is an ongoing process, not a one-time step.”
End with a quote:
“A badly defined requirement at the start is the root cause of most project failures.”
✅ This lecture is structured, interactive, and Pressman-aligned. Students get:
Theory (RE framework, techniques)
Examples (ATM, exam portal, food delivery app, banking app)
Activities (Q&A, stakeholder mapping, role-play)
Mini Role-play Activity (Heart Disease Prediction System)
⏰ Duration: 5–7 minutes
Step 1: Divide the Class into Groups
Group A = Stakeholders
o Patients – want health awareness, early alerts.
o Doctors – want accurate risk prediction & decision support.
o Hospital Admin – want better resource allocation, fewer emergency cases.
o Insurance Companies – want risk profiles for premium calculation.
Group B = Analysts (Students)
o Their job: ask the stakeholders questions to elicit requirements.
Step 2: Analysts Ask 3 Elicitation Questions per Stakeholder
Example Questions
To Patients:
1. Would you like the system to give lifestyle recommendations (diet/exercise)?
2. Do you prefer mobile app alerts or doctor reports?
3. Should the system predict only “risk” or also suggest preventive actions?
To Doctors:
1. What kind of inputs should the system consider (ECG, BP, cholesterol, family
history)?
2. Do you need explainable AI (why the system predicted high risk)?
3. Should the system integrate with hospital records?
To Hospital Admin:
1. Should the system provide population-level analytics (e.g., number of high-risk
patients in a city)?
2. Do you want real-time dashboards?
3. Should it integrate with appointment booking?
To Insurance Companies:
1. Do you want risk reports in simple percentages (e.g., 20% chance of heart disease)?
2. Should prediction models consider lifestyle factors like smoking/drinking?
3. Should the system share reports securely with your database?
Step 3: Teacher Moderates
Collect vague answers like:
o “We want accurate results.”
o “We want easy reports.”
o “We want alerts.”
Refine them into requirements:
o Functional Requirement: “System should send mobile notifications if risk >
60%.”
o Non-Functional Requirement: “System must give prediction in <5 seconds.”
o Domain-Specific Requirement: “System should use medical parameters such
as cholesterol, blood pressure, glucose levels.”
Step 4: Connect to AI Project
Heart Disease Prediction System – AI Features:
1. Prediction Model: Train ML (Logistic Regression / Random Forest / Neural
Networks) on heart disease dataset (e.g., UCI dataset).
o Input: Age, gender, cholesterol, BP, heart rate, lifestyle habits.
o Output: Probability of heart disease (Yes/No or % risk).
2. Recommendation System: Suggest preventive actions (exercise, diet, doctor
consultation) based on risk profile.
3. Doctor Dashboard: Visual analytics for patient monitoring.
4. Patient Mobile App: Risk alerts + health tips.
🎓 Learning Outcome from Activity
Students see how different stakeholders’ needs → become functional & non-
functional requirements.
They understand how AI (ML prediction + recommendation) can directly address
these needs.
👉 This turns the role-play into a practical AI healthcare project.
Would you like me to now expand this into a mini-project proposal format (objectives,
methodology, dataset, outcomes, evaluation criteria) so students can directly implement the
Heart Disease Prediction System as a semester project?