✅ Slide-by-Slide Summary of "Introduction to Software Engineering –

Chapter 1"

🔹 Slide 1: Topics Covered

 Professional software development

 Software engineering ethics

 Case studies used in the course

🔹 Slide 2: What is Software Engineering?

 Software drives all developed nations’ economies.

 Increasing system complexity and software dependency.

 Software engineering = use of theories, tools, and methods for

professional software development.

 Significant portion of GNP is spent on software.

🔹 Slide 3: Software Costs

 Software often costs more than hardware.

 Maintenance > development costs.

 Focus on cost-effective software development.

🔹 Slide 4: Causes of Software Project Failure

 Increased complexity and changing demands.

 Not using proper software engineering methods.

 Results in expensive and unreliable software.

🔹 Slide 5: (Visual or spacing placeholder)

Sensitivity: Internal
 🔹 Slide 6–7: FAQ About Software Engineering

 Software = Programs + documentation.

 Good software = Functional, dependable, maintainable, usable.

 Software engineering = Concerned with all production aspects.

 Four key activities: specification, development, validation, evolution.

 Difference from Computer Science: Practical development vs.

theoretical study.

 System Engineering = Includes software + hardware + processes.

🔹 Slide 8: Software Product Types

 Generic: Marketed broadly (e.g., Photoshop).

 Customized: Built for specific clients (e.g., traffic systems).

🔹 Slide 9: Product Specification Ownership

 Generic: Developer controls specs.

 Customized: Customer controls specs and changes.

🔹 Slide 10: Good Software Attributes

 Maintainability: Easy to evolve.

 Dependability/Security: Safe, reliable, protected.

 Efficiency: Minimal resource use.

 Acceptability: Usable and compatible.

🔹 Slide 11–12: What Software Engineering Covers

 Covers all software production, from planning to maintenance.

 Must consider organizational and financial limits.

 Not just coding: also includes tools, methods, project management.

Sensitivity: Internal
 🔹 Slide 13: Software Process Activities

 Specification: Define functions and constraints.

 Development: Design and coding.

 Validation: Ensure requirements are met.

 Evolution: Updates for changing needs.

🔹 Slide 14–15: General Issues in Software

 Heterogeneity: Many device types.

 Business/Social Change: Needs quick updates.

 Security/Trust: Software must be safe and trusted.

 Scale: Small (wearables) to large (cloud systems).

🔹 Slide 16–20: Software Engineering Diversity

 No one-size-fits-all method.

 Tailor tools/methods to system type and team.

 Types of applications:

o Stand-alone

o Interactive/web-based

o Embedded control

o Batch processing

o Entertainment

o Modeling/Simulation

o Data collection

o Systems of systems

🔹 Slide 21–24: Web-Based Software Engineering

Sensitivity: Internal
  Web = Platform for applications.

 Use of Web Services and Cloud Computing.

 Reuse, incremental/agile development, and rich interfaces

(AJAX/HTML5).

 Service-oriented systems: Components are replaceable.

 Customizable environments for different user groups.

🔹 Slide 25: (Empty/visual placeholder)

🔹 Slide 26–32: Software Engineering Ethics

 Engineers must act ethically, not just legally.

 Issues:

o Confidentiality

o Competence

o Intellectual Property

o Computer Misuse

 ACM/IEEE Code:

o 8 principles (public, client, product, judgment, management,

profession, colleagues, self)

🔹 Slide 33–34: Ethical Dilemmas

 Conflict with management.

 Unethical release of unsafe systems.

 Working on military or nuclear systems.

🔹 Slide 35–39: Case Study – Insulin Pump

 Controls insulin delivery based on blood sugar sensors.

Sensitivity: Internal
  Life-critical system.

 Must always be available and accurate.

 Includes system architecture and requirements.

🔹 Slide 40–45: Case Study – Mentcare

 Patient management for mental health care.

 Local/centralized data access.

 Features:

o Record editing

o Warnings

o Reporting

 Concerns:

o Privacy

o Safety

🔹 Slide 46–49: Case Study – Wilderness Weather Station

 Remote data collection (weather instruments).

 Satellite communication.

 Backup, monitoring, power control, dynamic updates.

🔹 Slide 50–54: Case Study – iLearn

 Digital learning environment.

 Tools selected by teachers/students.

 Service-oriented, modular architecture.

 Integrates general tools (e.g., spreadsheets) and educational content.

🔹 Slide 55–56: Key Takeaways

Sensitivity: Internal
  SE = full software lifecycle.

 Attributes: maintainability, efficiency, dependability, acceptability.

 Software engineers must follow ethical and professional standards.

 Core SE principles apply to all systems.

✅ Summary complete with all concepts and ethics, case studies,

definitions, and system types covered. Nothing has been skipped.

✅ Full Summary of "Software Processes – Chapter 2"

🔹 Slide 1: Topics Covered

 Software process models

Sensitivity: Internal
  Process activities

 Coping with change

 Process improvement

🔹 Slide 2: What is a Software Process?

 Structured set of activities to develop software.

 Key activities:

o Specification: Define system functions.

o Design & Implementation: Organize and build the system.

o Validation: Check if system meets customer needs.

o Evolution: Modify system as needs change.

 Software process model: Abstract view of a software process.

🔹 Slide 3: Process Descriptions

 Describe activities and order (e.g., design, modeling).

 May include:

o Products: Results of an activity.

o Roles: Responsibilities of people.

o Pre-/Post-conditions: Statements that must be true

before/after a process.

🔹 Slide 4: Plan-Driven vs. Agile

 Plan-driven: Fixed activities, progress measured by plan.

 Agile: Incremental planning, flexible to change.

 Most real processes combine both.

🔹 Slide 6: Process Models

Sensitivity: Internal
  Waterfall model: Phased approach (specification before
development).

 Incremental development: Activities interleaved, flexible.

 Integration and configuration: Use pre-existing components.

 Most real-world projects combine elements of all.

🔹 Slide 8: Waterfall Model Phases

1. Requirements analysis & definition

2. System/software design

3. Implementation & unit testing

4. Integration/system testing

5. Operation & maintenance

 ❗ Change is hard mid-process, so each phase must finish before the

next.

🔹 Slide 9: Waterfall Problems

 Not flexible to requirement changes.

 Best for well-understood systems.

 Used in large, distributed engineering systems for coordination.

🔹 Slide 11–12: Incremental Development

 Cheaper to accommodate changes.

 Easier to get feedback via demos.

 Faster delivery of working software.

🔹 Slide 13: Problems of Incremental Development

 Lacks visibility for progress.

Sensitivity: Internal
  Structure degrades over time unless refactored.

🔹 Slide 14: Integration & Configuration

 Based on reuse (COTS = Commercial off-the-shelf).

 Components can be adapted/configured.

 Reuse is now standard in business systems.

🔹 Slide 15: Types of Reusable Software

 Standalone systems (COTS)

 Object libraries (.NET, J2EE)

 Web services (invoked remotely)

🔹 Slide 16: Reuse-Oriented Engineering Stages

1. Requirements specification

2. Software discovery & evaluation

3. Requirements refinement

4. System configuration

5. Component integration

🔹 Slide 17: Pros and Cons of Reuse

✅ Lower cost & risk, faster delivery ❗ System may not meet all needs; less
control over updates

🔹 Slide 19–20: Real Process Activities

 Mix of technical, collaborative, and managerial activities.

 4 key activities:

o Specification

Sensitivity: Internal
 o Development

o Validation

o Evolution

 Organized differently across models (e.g., sequential vs. interleaved).

🔹 Slide 21: Requirements Engineering

1. Elicitation & Analysis – Identify stakeholder needs.

2. Specification – Define detailed requirements.

3. Validation – Check for correctness.

🔹 Slide 22–24: Design & Implementation

 Translate specifications into working software.

 Design:

o Architecture: System structure.

o Database: Data storage.

o Interface: Component connections.

o Component: Search for reuse; otherwise design it.

 Implementation: Write/assemble software.

 Debugging = fixing faults.

🔹 Slide 26–27: Validation (V & V)

 Ensure software meets requirements.

 Includes:

o Reviews, testing

o Execution with test cases

🔹 Slide 28: Testing Stages

Sensitivity: Internal
  Component testing – Small pieces.

 System testing – Whole system.

 Customer testing – Real data use.

🔹 Slide 29: Testing in V-model

 Aligns development with testing phases.

🔹 Slide 30: Software Evolution

 Change is constant due to new business needs.

 Line between development & maintenance is fading.

🔹 Slide 33: Coping with Change

 Driven by:

o Business change

o New tech

o Changing platforms

 Involves rework & implementing new functionality.

🔹 Slide 34–35: Reducing Rework Costs

 Anticipation: Use prototypes to foresee changes.

 Tolerance: Use incremental methods for easy updates.

🔹 Slide 36–37: Prototyping

 Quick version to explore features/needs.

 Benefits:

o Better usability

o Closer to real needs

Sensitivity: Internal
 o Better design

o Less effort

🔹 Slide 38–40: Prototype Development

 Focus on unknowns, may skip reliability/security.

 Often lacks documentation and quality for real use.

🔹 Slide 41–42: Incremental Delivery

 Deliver system in chunks.

 Early delivery = faster feedback.

 Prioritize features in early releases.

 Changes allowed for future increments.

🔹 Slide 43–45: Pros and Cons of Incremental Delivery

✅ Delivers value early, reduces failure risk, more testing of key features ❗
Hard to identify shared functionality early; may conflict with procurement
norms

🔹 Slide 47: What is Process Improvement?

 Improves quality, reduces cost/time.

 Understand current processes, identify issues, make changes.

🔹 Slide 48: Approaches to Improvement

 Maturity-based: Focus on process management.

 Agile: Reduce overhead, speed up delivery.

🔹 Slide 50–51: Improvement Activities

Sensitivity: Internal
 1. Measurement – Quantify process.

2. Analysis – Identify issues.

3. Change – Apply improvements.

🔹 Slide 52: Process Metrics Examples

 Time, effort (person-days), number of defects.

🔹 Slide 54: SEI Capability Maturity Levels

1. Initial – No control

2. Repeatable – Basic management

3. Defined – Documented processes

4. Managed – Quality tracked

5. Optimising – Continuous improvement

🔹 Slide 55–57: Key Points

 Software processes = All activities to build systems.

 Process models: Waterfall, Incremental, Reuse-based.

 Must adapt to change (via prototyping, incremental delivery).

 Process improvement = Maturity or agile approach.

✅ Complete summary of all slides with explanations, advantages,

drawbacks, and definitions. Nothing is left out.

Sensitivity: Internal
 ✅ Full Summary of "Agile Software Development – Chapter 3"

🔹 Slide 1: Topics Covered

 Agile methods

 Agile development techniques

 Agile project management

 Scaling agile methods

🔹 Slide 2: Rapid Software Development

 Speed of delivery is key due to fast-changing requirements.

 Plan-driven models can't always adapt quickly enough.

 Agile methods arose in the late 1990s to shorten delivery cycles.

Sensitivity: Internal
 🔹 Slide 3: Agile Development

 Specification, design, implementation are interleaved.

 Developed as increments with customer involvement.

 Frequent delivery + minimal documentation.

 Automated tools (e.g., testing) support development.

🔹 Slide 4–5: Agile vs. Plan-driven

 Plan-driven:

o Follows pre-defined stages with fixed outputs.

o May be iterative within stages.

 Agile:

o Activities are interleaved.

o Outputs emerge through negotiation and development.

🔹 Slide 6–7: Agile Methods

 Developed due to frustration with rigid methods of the 1980s–90s.

 Focus on:

o Working code, not documentation

o Quick iteration

o Rapid delivery and response to change

🔹 Slide 8: Agile Manifesto

 Values:

o Individuals & interactions > processes/tools

o Working software > documentation

o Customer collaboration > contract negotiation

o Responding to change > following a plan

Sensitivity: Internal
 🔹 Slide 9: Agile Principles

1. Customer involvement

2. Incremental delivery

3. People not process

4. Embrace change

5. Maintain simplicity

🔹 Slide 10: Agile Applicability

 Best for:

o Small/medium commercial product development

o Custom systems with active customer involvement

o Systems with low external regulation

🔹 Slides 11–12: Extreme Programming (XP)

 Key agile method from late 1990s.

 Releases every 2 weeks; builds may occur daily.

 All tests must pass for a build to be accepted.

🔹 Slides 13–15: XP Practices (a)

 Incremental planning – User stories prioritized by customer.

 Small releases – Deliver minimal usable functions quickly.

 Simple design – Enough to meet current needs.

 Test-first development – Write tests before coding.

 Refactoring – Continuous code improvement.

🔹 Slides 15–16: XP Practices (b)

Sensitivity: Internal
  Pair programming – Two programmers per task.

 Collective ownership – Any developer can change any code.

 Continuous integration – Integrate + test continuously.

 Sustainable pace – Avoid overtime.

 On-site customer – User available full-time in team.

🔹 Slide 17: XP and Agile Principles

 Aligns with core agile ideas: small releases, team collaboration,

adaptability, simplicity.

🔹 Slide 18: XP Practices in Agile

 Most agile teams use some XP practices:

o User stories

o Test-first

o Refactoring

o Pair programming

🔹 Slide 19–20: User Stories

 Customer part of team; defines and selects stories.

 Stories broken into tasks used for estimating time and cost.

🔹 Slide 21–23: Refactoring

 Continuous code improvement.

 Improves understandability and maintainability.

 Examples: class cleanup, method extraction, naming.

🔹 Slides 24–26: Test-First Development

Sensitivity: Internal
  Tests written before functionality.

 Ensures clarity of requirements.

 Uses frameworks like JUnit.

 Customer helps write acceptance tests.

🔹 Slide 27–28: Test Automation

 Tests are written as code and executed automatically.

 Helps catch bugs early.

 Useful for rapid development cycles.

🔹 Slide 29: Test-First Problems

 Programmers may write poor/incomplete tests.

 UI elements are hard to test.

 Test coverage may still be insufficient.

🔹 Slides 30–31: Pair Programming

 Improves code quality and knowledge sharing.

 Team members rotate pairs.

 Informal review process.

🔹 Slide 33–34: Agile Project Management & Scrum

 Agile PM = Deliver on time and within budget using agile practices.

 Scrum focuses on iterative planning:

o Planning → Sprint → Closure

o 2–4 week sprints

🔹 Slide 35–36: Scrum Terminology

Sensitivity: Internal
  Dev team – ≤7 developers, self-organizing

 Product backlog – List of all work

 Product owner – Prioritizes features

 Scrum – Daily team meeting

 ScrumMaster – Enforces process

 Sprint – Iteration (2–4 weeks)

 Velocity – Effort completed per sprint

🔹 Slide 37–40: Scrum Cycle

 Sprint starts with backlog selection.

 Team works in isolation; ScrumMaster shields from distractions.

 Ends with review and begins next sprint.

 Team holds daily Scrums for updates and problem-solving.

🔹 Slide 41: Scrum Benefits

 Better communication

 Visible progress

 On-time delivery

 Improved trust with customers

🔹 Slide 44–45: Scaling Agile Methods

 Scaling up = Adapting to large systems.

 Scaling out = Spreading agile practices in large orgs.

 Fundamentals remain: short releases, test-driven, good team

communication

🔹 Slide 46–47: Agile Challenges

Sensitivity: Internal
  Agile conflicts with contract-based legal environments.

 Best suited to new systems, not maintenance.

 Coordination harder in distributed teams.

🔹 Slide 48–49: Agile Maintenance Issues

 Maintenance hard due to:

o Limited documentation

o Limited customer/team continuity

🔹 Slide 50: Choosing Agile or Plan-Driven

 Consider:

o Do you need upfront specs? → Plan-driven

o Can you deliver in parts + adapt? → Agile

o Team size? Small → Agile, Large → Plan-driven

🔹 Slides 51–52: Agile vs. Organization Practices

 Customer involvement may not always be possible.

 Prioritizing changes can be tough with many stakeholders.

 Short iterations may clash with long-term business planning.

🔹 Slide 54–56: Team and Org Factors

 Large systems need detailed specs and documentation.

 Agile works best with co-located skilled teams.

 Traditional engineering orgs may resist agile culture.

🔹 Slide 57–62: Large Systems and Scrum at Scale

 Challenges:

Sensitivity: Internal
 o Many teams, time zones

o Mixed systems (old/new)

o Diverse stakeholders

o Integration, communication

 Multi-Team Scrum:

o Role replication (multiple ScrumMasters/Product Owners)

o Scrum of Scrums – inter-team coordination

o Shared architecture via Product Architects

🔹 Slide 63: Agile Across Organizations

 Reluctance due to risk

 Cultural resistance and varying skill levels

 Incompatibility with formal quality procedures

🔹 Slides 64–65: Key Points

 Agile = frequent releases + test-first + collaboration

 Scrum = iterative project management framework

 Most real projects blend agile + plan-driven

 Scaling agile = hard, especially for regulated or large systems

✅ Summary complete with all practices, principles, terms, benefits,

challenges, and scaling considerations. No content left out.

Sensitivity: Internal
 ✅ Full Summary of "Agile Software Development – Chapter 3"

🔹 Slide 1: Topics Covered

 Agile methods

 Agile development techniques

 Agile project management

 Scaling agile methods

🔹 Slide 2: Rapid Software Development

 Speed of delivery is key due to fast-changing requirements.

 Plan-driven models can't always adapt quickly enough.

 Agile methods arose in the late 1990s to shorten delivery cycles.

🔹 Slide 3: Agile Development

 Specification, design, implementation are interleaved.

 Developed as increments with customer involvement.

 Frequent delivery + minimal documentation.

 Automated tools (e.g., testing) support development.

🔹 Slide 4–5: Agile vs. Plan-driven

 Plan-driven:

o Follows pre-defined stages with fixed outputs.

o May be iterative within stages.

Sensitivity: Internal
  Agile:

o Activities are interleaved.

o Outputs emerge through negotiation and development.

🔹 Slide 6–7: Agile Methods

 Developed due to frustration with rigid methods of the 1980s–90s.

 Focus on:

o Working code, not documentation

o Quick iteration

o Rapid delivery and response to change

🔹 Slide 8: Agile Manifesto

 Values:

o Individuals & interactions > processes/tools

o Working software > documentation

o Customer collaboration > contract negotiation

o Responding to change > following a plan

🔹 Slide 9: Agile Principles

1. Customer involvement

2. Incremental delivery

3. People not process

4. Embrace change

5. Maintain simplicity

🔹 Slide 10: Agile Applicability

 Best for:

Sensitivity: Internal
 o Small/medium commercial product development

o Custom systems with active customer involvement

o Systems with low external regulation

🔹 Slides 11–12: Extreme Programming (XP)

 Key agile method from late 1990s.

 Releases every 2 weeks; builds may occur daily.

 All tests must pass for a build to be accepted.

🔹 Slides 13–15: XP Practices (a)

 Incremental planning – User stories prioritized by customer.

 Small releases – Deliver minimal usable functions quickly.

 Simple design – Enough to meet current needs.

 Test-first development – Write tests before coding.

 Refactoring – Continuous code improvement.

🔹 Slides 15–16: XP Practices (b)

 Pair programming – Two programmers per task.

 Collective ownership – Any developer can change any code.

 Continuous integration – Integrate + test continuously.

 Sustainable pace – Avoid overtime.

 On-site customer – User available full-time in team.

🔹 Slide 17: XP and Agile Principles

 Aligns with core agile ideas: small releases, team collaboration,

adaptability, simplicity.

Sensitivity: Internal
 🔹 Slide 18: XP Practices in Agile

 Most agile teams use some XP practices:

o User stories

o Test-first

o Refactoring

o Pair programming

🔹 Slide 19–20: User Stories

 Customer part of team; defines and selects stories.

 Stories broken into tasks used for estimating time and cost.

🔹 Slide 21–23: Refactoring

 Continuous code improvement.

 Improves understandability and maintainability.

 Examples: class cleanup, method extraction, naming.

🔹 Slides 24–26: Test-First Development

 Tests written before functionality.

 Ensures clarity of requirements.

 Uses frameworks like JUnit.

 Customer helps write acceptance tests.

🔹 Slide 27–28: Test Automation

 Tests are written as code and executed automatically.

 Helps catch bugs early.

 Useful for rapid development cycles.

Sensitivity: Internal
 🔹 Slide 29: Test-First Problems

 Programmers may write poor/incomplete tests.

 UI elements are hard to test.

 Test coverage may still be insufficient.

🔹 Slides 30–31: Pair Programming

 Improves code quality and knowledge sharing.

 Team members rotate pairs.

 Informal review process.

🔹 Slide 33–34: Agile Project Management & Scrum

 Agile PM = Deliver on time and within budget using agile practices.

 Scrum focuses on iterative planning:

o Planning → Sprint → Closure

o 2–4 week sprints

🔹 Slide 35–36: Scrum Terminology

 Dev team – ≤7 developers, self-organizing

 Product backlog – List of all work

 Product owner – Prioritizes features

 Scrum – Daily team meeting

 ScrumMaster – Enforces process

 Sprint – Iteration (2–4 weeks)

 Velocity – Effort completed per sprint

🔹 Slide 37–40: Scrum Cycle

 Sprint starts with backlog selection.

Sensitivity: Internal
  Team works in isolation; ScrumMaster shields from distractions.

 Ends with review and begins next sprint.

 Team holds daily Scrums for updates and problem-solving.

🔹 Slide 41: Scrum Benefits

 Better communication

 Visible progress

 On-time delivery

 Improved trust with customers

🔹 Slide 44–45: Scaling Agile Methods

 Scaling up = Adapting to large systems.

 Scaling out = Spreading agile practices in large orgs.

 Fundamentals remain: short releases, test-driven, good team

communication

🔹 Slide 46–47: Agile Challenges

 Agile conflicts with contract-based legal environments.

 Best suited to new systems, not maintenance.

 Coordination harder in distributed teams.

🔹 Slide 48–49: Agile Maintenance Issues

 Maintenance hard due to:

o Limited documentation

o Limited customer/team continuity

🔹 Slide 50: Choosing Agile or Plan-Driven

Sensitivity: Internal
  Consider:

o Do you need upfront specs? → Plan-driven

o Can you deliver in parts + adapt? → Agile

o Team size? Small → Agile, Large → Plan-driven

🔹 Slides 51–52: Agile vs. Organization Practices

 Customer involvement may not always be possible.

 Prioritizing changes can be tough with many stakeholders.

 Short iterations may clash with long-term business planning.

🔹 Slide 54–56: Team and Org Factors

 Large systems need detailed specs and documentation.

 Agile works best with co-located skilled teams.

 Traditional engineering orgs may resist agile culture.

🔹 Slide 57–62: Large Systems and Scrum at Scale

 Challenges:

o Many teams, time zones

o Mixed systems (old/new)

o Diverse stakeholders

o Integration, communication

 Multi-Team Scrum:

o Role replication (multiple ScrumMasters/Product Owners)

o Scrum of Scrums – inter-team coordination

o Shared architecture via Product Architects

🔹 Slide 63: Agile Across Organizations

Sensitivity: Internal
  Reluctance due to risk

 Cultural resistance and varying skill levels

 Incompatibility with formal quality procedures

🔹 Slides 64–65: Key Points

 Agile = frequent releases + test-first + collaboration

 Scrum = iterative project management framework

 Most real projects blend agile + plan-driven

 Scaling agile = hard, especially for regulated or large systems

✅ Summary complete with all practices, principles, terms, benefits,

challenges, and scaling considerations. No content left out.

✅ Full Summary of "Chapter 4 – Requirements Engineering"

🔹 Slides 1–2: Introduction

 Topics: Functional/non-functional requirements, RE processes,

elicitation, specification, validation, change.

 Requirements engineering (RE): Process of defining system

services and constraints.

Sensitivity: Internal
  System requirements: Descriptions produced during the RE process.

🔹 Slides 3–4: What is a Requirement?

 Ranges from abstract ideas to detailed specifications.

 May serve two functions:

o Basis for contract bid (open to interpretation).

o Basis of contract (must be defined precisely).

 Davis' quote: Requirements evolve — abstract for bidding, detailed for

development.

🔹 Slide 5–6: Types of Requirements

 User requirements: Natural language and diagrams; written for

customers.

 System requirements: Structured and detailed; may be part of

contract.

🔹 Slides 7–8: Requirement Readers and Stakeholders

 Stakeholders: Affected parties (e.g., end users, managers, owners,

external entities).

🔹 Slides 10–12: Mentcare Stakeholders

 Includes patients, doctors, nurses, receptionists, IT staff, ethics

managers, health care managers, records staff.

🔹 Slide 13: Agile and Requirements

 Agile avoids detailed RE due to changing requirements.

 Uses incremental RE and user stories.

 Problematic for large/critical systems.

Sensitivity: Internal
 🔹 Slides 14–15: Functional and Non-functional Requirements

 Functional: System behaviors and responses.

 Non-functional: Constraints (timing, standards).

 Domain: Constraints from operating environment.

🔹 Slides 16–18: Mentcare Functional Examples and Issues

 Examples: Search clinics, generate patient lists, identify users.

 Problems with imprecise or ambiguous terms (e.g., "search").

🔹 Slide 19: Completeness and Consistency

 Complete: All required facilities.

 Consistent: No contradictions.

 Hard to achieve in practice.

🔹 Slides 20–23: Non-functional Requirements

 Define properties: reliability, speed, storage.

 May affect architecture (e.g., to improve performance).

 Classifications:

o Product (e.g., availability)

o Organizational (e.g., login via health card)

o External (e.g., legal privacy standards)

🔹 Slide 24–25: Goals and Verifiability

 Goals: General (e.g., ease of use).

 Verifiable requirements: Testable (e.g., <2 errors/hr after training).

Sensitivity: Internal
 🔹 Slide 26: Metrics

 Speed (transactions/sec), size (MB), reliability (MTTF), robustness

(restart time), portability, usability (training time).

🔹 Slides 27–29: RE Processes

 Common activities:

o Elicitation

o Analysis

o Validation

o Management

 RE is iterative, often spiral.

🔹 Slides 30–34: Elicitation & Stakeholder Collaboration

 Involves working with stakeholders to discover domain, services, and

constraints.

 Stages:

o Discovery

o Classification

o Prioritization/negotiation

o Specification

🔹 Slide 35–38: Discovery Methods – Interviews

 Types: Closed (structured) or open (freeform).

 Tips: Be open-minded, use prompts.

 Interviews mix both types for effectiveness.

🔹 Slide 39–40: Interview Problems

Sensitivity: Internal
  Jargon may confuse REs.

 Domain knowledge may be assumed/unspoken.

🔹 Slides 41–44: Ethnography

 Observe how work is actually done.

 Captures hidden complexities.

 Focused ethnography: Combines with prototyping.

 Drawback: Shows existing practice but not innovation.

🔹 Slides 45–49: Stories and Scenarios

 Real-life use examples improve engagement.

 Scenario elements:

o Starting point

o Normal and error flows

o Other activities

o End state

 iLearn Example: Photo upload system in classroom; includes

moderator, naming issues, etc.

🔹 Slides 50–52: Requirements Specification

 Translates user needs into formal document.

 User reqs: For non-tech customers.

 System reqs: Detailed for developers.

 Formats:

o Natural language

o Structured forms

o Graphical models (UML)

Sensitivity: Internal
 o Mathematical (rare, formal)

🔹 Slides 53–56: Writing and Issues in NL Specification

 Guidelines: Use standard format, consistent wording, avoid jargon.

 Common problems:

o Lack of clarity

o Mixing types

o Amalgamation (multiple requirements in one)

🔹 Slides 57–60: Structured and Tabular Specification

 Structured: Standard fields for actions, inputs, outputs, conditions.

 Tabular: Best for conditional logic (e.g., insulin pump dosage based on
sugar rate).

🔹 Slides 64–66: Use Cases

 In UML: Describe actors and their interactions.

 Show all possible system uses.

 Supported by diagrams and sequences.

🔹 Slides 67–70: Requirements Document Structure

 Sections:

o Preface, Intro, Glossary

o User/system requirements

o Architecture, Models, Evolution

o Appendices, Index

 Tailored per system type and process (e.g., IEEE standard).

Sensitivity: Internal
 🔹 Slides 71–76: Validation

 Ensure system matches customer needs.

 Checks: Validity, consistency, completeness, realism, verifiability.

 Techniques:

o Reviews

o Prototypes

o Test-case generation

🔹 Slide 77–79: Requirements Change

 Caused by:

o New tech or laws

o Budget/user conflicts

o Large/diverse user communities

 Final requirements are a compromise.

✅ All concepts, definitions, examples, techniques, and processes are covered

completely with no skipped content.

Sensitivity: Internal