1.
Functional and Non-Functional Requirements with Examples & Impact
on System Design
Functional Requirements
These define the specific behavior or functions of a system. They describe what
the system should do.
Examples:
• A banking application must allow users to withdraw money from an ATM.
• A social media platform should allow users to upload photos and videos.
Non-Functional Requirements (NFRs)
These define quality attributes of a system, such as performance, security,
usability, and scalability.
Examples:
• The website must handle 10,000 concurrent users (Performance).
• The system should comply with GDPR regulations (Legal Compliance).
• The response time should not exceed 2 seconds (Usability).
Impact on System Design:
• Performance NFRs influence architecture choices (e.g., caching, load
balancing).
• Security NFRs require encryption, authentication mechanisms.
• Usability NFRs impact UI/UX design decisions.
• Scalability NFRs drive cloud-based solutions.
A system may meet functional requirements but fail if non-functional aspects
(e.g., speed, security) are not adequately addressed.
2. Challenges in Defining & Implementing Non-Functional Requirements in
Large-Scale Systems
1. Difficult to Quantify – Unlike functional requirements, NFRs like "ease of
use" or "maintainability" are subjective.
2. Conflicting Priorities – High security might reduce performance; low
latency may increase costs.
3. Changing Expectations – As the system scales, new performance or
regulatory requirements may arise.
4. Measurement & Validation – Testing performance, reliability, or security
in real-world conditions is challenging.
5. Integration Complexity – Large systems involve multiple subsystems;
ensuring uniform compliance with NFRs is difficult.
Solution: Define NFRs using measurable metrics (e.g., "Response time ≤ 2
seconds for 95% of requests") and validate through performance tests.
3. User Requirements vs. System Requirements (Differences & Importance)
Feature User Requirements System Requirements
Definition High-level needs of users Detailed specifications for developers
How the system should be
Focus What the system should do
implemented
"The app should allow users to "The system should store flight details
Examples
book a flight" in an SQL database"
Format Natural language Structured technical descriptions
Importance of Maintaining Distinction:
• Helps developers translate user expectations into implementable solutions.
• Prevents miscommunication between stakeholders and developers.
• Avoids unnecessary complexity in implementation.
4. Problems if User Requirements Are Not Properly Translated into System
Requirements
• Misalignment with Business Goals – A system may be developed with
unnecessary features.
• Increased Development Costs – Frequent changes and rework due to
incorrect interpretations.
• User Dissatisfaction – The final product may not meet user needs despite
being functionally correct.
• Integration Failures – Poorly defined system requirements may lead to
compatibility issues.
Properly structured Software Requirements Documents (SRDs) help prevent
these issues.
5. Interface Specification & Its Importance
Interface Specification defines how different software components, modules, or
systems interact.
Example:
• API documentation specifying how a payment gateway (PayPal, Stripe)
integrates with an e-commerce site.
Importance in Software Development:
• Ensures seamless communication between system components.
• Supports modular development, allowing independent teams to work in
parallel.
• Facilitates integration with third-party systems.
6. Key Elements of an Interface Specification & Their Role in
Interoperability
1. Function Descriptions – Defines input parameters, expected output, and
error handling.
2. Data Formats – Specifies data structure (JSON, XML, etc.).
3. Communication Protocols – Defines how data is exchanged (HTTP,
WebSocket, etc.).
4. Error Handling Mechanisms – Describes how the system responds to
failures.
5. Security Requirements – Defines authentication and encryption methods.
How It Ensures Interoperability:
• Provides a clear contract between interacting systems.
• Reduces integration issues by standardizing data formats.
• Ensures compatibility across different platforms.
7. Essential Components of a Software Requirements Document (SRD) & Its
Importance
Components:
1. Introduction – Purpose, scope, definitions.
2. Functional Requirements – Features and expected behavior.
3. Non-Functional Requirements – Performance, security, usability
constraints.
4. System Models – Diagrams (Use Case, ER, Data Flow).
5. Interface Requirements – Internal and external APIs.
6. Assumptions & Constraints – Environmental and business limitations.
Importance of SRD in Software Development:
• Acts as a contract between stakeholders and developers.
• Prevents scope creep by clearly defining deliverables.
• Serves as a reference for testing and validation.
8. How an SRD Reduces Software Development Risks & Ensures Project
Success
1. Avoids Miscommunication – Stakeholders and developers work from the
same document.
2. Supports Requirement Traceability – Links requirements to design, code,
and tests.
3. Improves Planning & Budgeting – Helps in resource allocation.
4. Facilitates Change Management – Controlled requirement modifications.
Example:
Without an SRD, a project may deliver a system with missing features or incorrect
implementation, leading to costly rework.
9. Key Techniques in Requirements Elicitation (Advantages & Limitations)
Technique Advantages Limitations
Deep insights, stakeholder Time-consuming, biased
Interviews
perspectives responses
May lack detailed
Surveys/Questionnaires Covers many users quickly
responses
Collaborative, resolves
Workshops Requires coordination
conflicts
Users may alter behavior
Observation Uncovers implicit needs
when observed
Early feedback, reduces Costly to build
Prototyping
misunderstandings prototypes
Complex for large
Use Case Analysis Captures user interactions
systems
A combination of techniques ensures comprehensive requirement gathering.
10. Importance of Stakeholder Involvement in Requirements Elicitation &
Managing Conflicts
Importance of Stakeholder Involvement:
• Ensures alignment with business objectives.
• Captures diverse perspectives (users, developers, business owners).
• Helps prioritize features based on real user needs.
Managing Requirement Conflicts:
1. Prioritization (MoSCoW Method) – Categorize as Must-have, Should-
have, Could-have, Won't-have.
2. Negotiation & Trade-offs – Balance cost, feasibility, and impact.
3. Prototyping & Feedback Loops – Validate assumptions through iterative
development.
4. Stakeholder Consensus Meetings – Align expectations before finalizing
requirements.
Example Conflict:
• Marketing Team: "We need advanced AI analytics."
• Development Team: "AI is costly and delays delivery."
• Resolution: Prioritize a basic AI version for launch, with an advanced
version in later releases.
11. Techniques for Requirements Validation and Its Role in Software Quality
Requirements validation ensures that the collected requirements accurately
represent the needs of stakeholders and are feasible for implementation. The key
techniques include:
• Requirements Reviews: A manual examination of requirements
documents by stakeholders to identify ambiguities, inconsistencies, or
omissions.
• Prototyping: Creating a working model of the system to validate
requirements with end users before full-scale development.
• Test Case Generation: Writing test cases based on requirements to verify
correctness and completeness.
• Formal Methods: Using mathematical techniques to validate
requirements, ensuring correctness in safety-critical systems.
• Stakeholder Feedback & Walkthroughs: Conducting structured
discussions with stakeholders to confirm that requirements align with their
needs.
Impact on Software Quality:
• Reduces errors in the development phase.
• Enhances stakeholder satisfaction.
• Prevents costly rework by detecting issues early.
• Improves maintainability and extensibility of the software.
12. Consequences of Inadequate Requirements Validation
Failure to validate requirements properly can have several negative effects on
software development, including:
• Increased Costs & Delays: Errors in requirements detected late in
development require costly rework.
• Poor Software Quality: Unclear or incorrect requirements result in buggy
or inefficient systems.
• User Dissatisfaction: A system that does not meet user needs leads to low
adoption and complaints.
• Scope Creep: Ambiguous requirements can lead to uncontrolled feature
additions, affecting project timelines.
• Project Failures: Misalignment with business objectives may result in
project abandonment.
13. Requirements Management & Its Importance
Requirements Management is the process of documenting, analyzing,
prioritizing, and controlling changes to requirements during software
development. It includes:
• Requirement Identification: Assigning unique IDs for tracking.
• Change Management: Handling modifications in a controlled manner.
• Traceability Maintenance: Ensuring requirements are linked to design,
code, and tests.
• Version Control: Keeping track of requirement changes over time.
Importance in Handling Changes:
• Helps manage evolving stakeholder expectations.
• Ensures proper impact analysis before implementing changes.
• Reduces development risks and maintains project alignment.
14. Role of Traceability in Requirements Management & Ensuring
Consistency
Traceability refers to the ability to track requirements throughout the software
lifecycle. It includes:
• Forward Traceability: Linking requirements to design and
implementation.
• Backward Traceability: Ensuring each implemented feature aligns with
an original requirement.
• Bidirectional Traceability: Maintaining both forward and backward
links.
How It Ensures Consistency:
• Ensures all requirements are implemented.
• Helps identify the impact of changes on related components.
• Supports compliance with industry standards and audits.
15. Context Model & Its Significance
A Context Model is a high-level representation of a system’s interaction with its
environment. It typically includes external entities, users, and systems interacting
with the software.
Significance:
• Helps define system boundaries.
• Identifies external dependencies.
• Aids in understanding system constraints.
• Provides a foundation for requirement specification.
16. How Context Models Help Identify System Boundaries & Interactions
• Defines External & Internal Elements: Separates what is inside the
system from external actors.
• Clarifies Interfaces: Identifies how data and control signals flow between
the system and its environment.
• Prevents Scope Creep: Clearly establishing boundaries ensures the
system doesn’t expand beyond its intended functionality.
17. Role of Behavioral Models in Software Engineering
Behavioral Models describe how a system behaves over time, focusing on
interactions, events, and state changes.
How They Help:
• Clarify system responses to different inputs.
• Aid in early validation of workflows.
• Support communication between developers and stakeholders.
• Improve software maintainability by providing structured behavior
documentation.
18. Types of Behavioral Models with Examples
1. State Machine Models: Represent system states and transitions.
o Example: ATM state diagram (Idle → Card Inserted → PIN Entered
→ Transaction Processed).
o Application: Embedded systems, process automation.
2. Data Flow Models: Show how data moves through a system.
o Example: Online order processing system (Order → Validation →
Payment → Shipping).
o Application: Data-driven applications.
3. Sequence Diagrams: Represent interactions between objects over time.
o Example: User logging into a website (User → Authentication
Server → Database → Response).
o Application: Object-oriented software design.
19. Data Model & Its Importance in Software Engineering
A Data Model defines how data is structured, stored, and related within a system.
It consists of entities, attributes, and relationships.
Importance:
• Ensures data integrity and consistency.
• Supports database design and query optimization.
• Provides a blueprint for application development.
Example: A Library Management System may have:
• Entities: Book, Member, Loan.
• Relationships: A Member borrows a Book.
• Attributes: Book (ISBN, Title), Member (ID, Name).
20. Comparison: Data Models vs. Object Models
Feature Data Model Object Model
Focus Structured representation of data Objects and their interactions
Components Entities, attributes, relationships Objects, classes, methods
Example Relational databases (ER models) Object-Oriented Programming
Application Database schema design Software system architecture
How They Help in Software Design:
• Data Models provide a structured way to store and retrieve data efficiently.
• Object Models enable encapsulation, reusability, and modularity in
software design.
