Scribd
Upload
6 views

Lecture 5,6 SE

Requirement Engineering (RE) is crucial for identifying and managing software requirements to meet stakeholder needs effectively. It encompasses functional, non-functional, and domain-specific requirements, each with distinct characteristics and examples. The process involves elicitation, analysis, and specification of requirements, culminating in a structured Software Requirement Specification (SRS) document.

Uploaded by

chumarkwl786
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
6 views

Lecture 5,6 SE

Requirement Engineering (RE) is crucial for identifying and managing software requirements to meet stakeholder needs effectively. It encompasses functional, non-functional, and domain-specific requirements, each with distinct characteristics and examples. The process involves elicitation, analysis, and specification of requirements, culminating in a structured Software Requirement Specification (SRS) document.

Uploaded by

chumarkwl786
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Course: Software Engineering Course Code: CS1113

Course Instructor: Dr. Amna Asif Lodhi

Lecture Notes: Requirement Engineering

1. Introduction to Requirement Engineering

Requirement Engineering (RE) is the process of identifying, analyzing,


documenting, and managing software requirements. It ensures that software meets
stakeholder needs while being feasible, reliable, and scalable.

Why is Requirement Engineering Important?

 Ensures clear communication between developers and stakeholders.


 Reduces ambiguity and misunderstandings.
 Helps in cost estimation and project planning.
 Ensures software meets business objectives.

2. Types of Requirements

Software requirements are classified into three main types:

2.1 Functional Requirements

Definition: Functional requirements describe what the system should do. They
define features, operations, and business logic.

Examples:

 A user should be able to register and log in to the system.


 The system should process online payments securely.
 The application should send notifications for upcoming deadlines.

Characteristics:

 Specifies input, processing, and output.


 Defines system behavior.
 Often written in use cases or user stories.

2.2 Non-Functional Requirements (NFRs)

Definition: Non-functional requirements define how the system should perform


rather than what it does.

Types and Examples:

 Performance: The website should load within 2 seconds.


 Security: All user passwords must be encrypted.
 Usability: The system should be accessible to visually impaired users.
 Scalability: The application should support 100,000 concurrent users.
 Availability: The system should have 99.9% uptime.
Course: Software Engineering Course Code: CS1113
Course Instructor: Dr. Amna Asif Lodhi

Key Points:

 Ensures system quality.


 Impacts user satisfaction and maintainability.
 Often documented using quality attributes (ISO 25010 framework).

2.3 Domain Requirements

Definition: Domain requirements are specific to a particular industry or business


domain.

Examples:

 Healthcare System: The software must comply with HIPAA regulations.


 Banking Application: Transactions must be logged for audit trails.
 E-commerce Platform: Must integrate with payment gateways (e.g.,
PayPal, Stripe).

Key Points:

 Derived from business rules, laws, and regulations.


 Often non-negotiable due to compliance standards.
 Need subject matter experts (SMEs) for validation.

3. Requirement Elicitation, Analysis, and Specification

3.1 Requirement Elicitation

Requirement elicitation is the process of gathering user needs using different


techniques.

Techniques for Requirement Elicitation

Technique Description Example


One-on-one discussion with Ask users about their pain
Interviews
stakeholders. points in a banking app.
Surveys & Collect structured feedback Users rate mobile app
Questionnaires from a large audience. usability on a scale of 1-10.
Group discussions to brainstorm Team gathers to define
Workshops
requirements. features for an HR system.
Watching users interact with Analyst observes cashiers
Observation
current systems. using a POS system.
Creating a mock-up to refine Sketch an initial UI for an
Prototyping
user needs. online shopping cart.

Best Practice: Use multiple techniques for better accuracy.

3.2 Requirement Analysis


Course: Software Engineering Course Code: CS1113
Course Instructor: Dr. Amna Asif Lodhi

Once requirements are gathered, they need to be analyzed for clarity, feasibility, and
consistency.

Key Aspects of Analysis

 Feasibility: Can the requirement be implemented with current technology?


 Consistency: Are requirements free of contradictions?
 Completeness: Are all necessary requirements covered?
 Prioritization: Which requirements are critical vs. optional?

Example: A customer wants a "24/7 AI chatbot" for support.


✅ Feasibility Check: Can AI handle all queries without human help?
✅ Consistency Check: Does this align with other requirements?
✅ Prioritization: Is this a must-have or a future feature?

3.3 Requirement Specification

After analysis, requirements are formally documented in a structured format.

Methods of Specification

 Natural Language (simple sentences, but prone to ambiguity)


 Use Case Diagrams (visual representation of user interactions)
 Formal Notations (mathematical/logical statements for precision)

Example (Natural Language Specification): 📌 "The system shall allow registered


users to reset their password via email verification."

Example (Use Case Diagram for a Banking App):

 Actor: Customer
 Use Cases: Login, View Balance, Transfer Money
 System: Banking Application

4. Writing a Software Requirement Specification (SRS) Document

The Software Requirement Specification (SRS) document provides a detailed


description of system requirements.

4.1 Structure of an SRS Document

1. Introduction

 Purpose of the system


 Scope of the project
 Definitions, acronyms, and abbreviations

2. Overall Description

 Product perspective (new system or enhancement?)


Course: Software Engineering Course Code: CS1113
Course Instructor: Dr. Amna Asif Lodhi

 User characteristics (who will use it?)


 Dependencies and constraints

3. Functional Requirements

 List of system features (e.g., "Users can search for books in the library
system.")

4. Non-Functional Requirements

 Performance, security, usability, and compliance standards.

5. Domain-Specific Requirements

 Any regulations or industry-specific constraints.

6. Appendices

 Glossary of terms, references, and external documents.

4.2 Example SRS (Library Management System)

Functional Requirement Example: "The system shall allow users to search for
books by title, author, or genre."

Non-Functional Requirement Example: "The system must respond to search


queries within 2 seconds."

Domain Requirement Example: "The system should comply with university data
privacy policies."

5. Summary

 Functional requirements define what the system does.


 Non-functional requirements define how well the system performs.
 Domain requirements are industry-specific constraints.
 Elicitation techniques (e.g., interviews, surveys) help gather accurate
requirements.
 Analysis ensures feasibility, consistency, and completeness.
 An SRS document formally defines all requirements in a structured format.

You might also like