1.
Differentiate between Functional and Nonfunctional Requirements
Functional requirements describe what the system should do. They define the functions, features,
and services the system must provide. For example, in an ATM system, functional requirements
include: withdrawing money, depositing cash, transferring funds, and printing receipts. These are
directly related to the system’s purpose and user interactions.
Non-functional requirements, on the other hand, describe how the system should perform. They
focus on quality attributes such as performance, usability, security, reliability, and scalability. For
example, an ATM must process a withdrawal within 2 seconds, ensure 99.9% system uptime, and
secure user transactions with encryption.
Importance: Non-functional requirements are equally important because even if a system has all the
required functionalities, it may fail if it is slow, insecure, or unreliable. For instance, an ATM that
works but takes 5 minutes to process a transaction will not satisfy users. Similarly, an online
shopping site may have all required features but will fail if it crashes during peak sales.
In summary, functional requirements define the actions of a system, while non-functional
requirements define the qualities of those actions. Together, they ensure that the software is not
only feature-rich but also efficient, secure, and user-friendly.
2. Requirements Elicitation Techniques
Requirements elicitation is the process of gathering software requirements from stakeholders such
as customers, end-users, and domain experts. Several techniques are used to ensure accurate and
complete requirements:
1. Interviews: One-on-one discussions with users to understand needs.
2. Questionnaires/Surveys: Useful for gathering information from a large group of users.
3. Observation: Watching how users interact with current systems.
4. Document Analysis: Studying manuals, reports, or existing software.
5. Brainstorming: Group sessions for generating ideas.
6. Collaborative Requirements Gathering (CRG): Workshops where stakeholders, users,
and developers work together to define requirements.
7. Usage Scenarios: “Use cases” that describe step-by-step interactions between users and
the system (e.g., customer withdrawing money from an ATM).
8. Quality Function Deployment (QFD): A structured method that converts customer needs
into technical specifications to ensure quality.
Example: For an e-commerce site, elicitation may include interviewing buyers and sellers,
analyzing competitor platforms, and observing shopping patterns.
In conclusion, requirements elicitation ensures that both explicit and hidden needs are captured,
preventing misunderstandings and costly rework later in the software development lifecycle.
3. Explain Requirements Engineering in Detail
Requirements Engineering (RE) is a systematic process of defining, documenting, and maintaining
software requirements. It ensures that the final product meets customer expectations and business
goals.
Importance: Without proper requirements engineering, projects may face cost overruns, delays, or
failure due to unclear or misunderstood requirements. RE acts as a communication bridge between
stakeholders and developers.
Major Tasks in RE:
1. Inception: Understand business goals and feasibility.
2. Elicitation: Gather requirements using techniques like interviews, surveys, and use cases.
3. Elaboration: Refine requirements into detailed models.
4. Negotiation: Resolve conflicts between stakeholders.
5. Specification: Document requirements formally in an SRS (Software Requirement
Specification).
6. Validation: Verify that requirements are correct, complete, and feasible.
7. Management: Track changes and maintain requirement traceability.
Example: In an online banking system, RE would include defining functional needs (fund transfer,
balance inquiry) and non-functional needs (transaction security, 24/7 availability).
In summary, RE ensures that the software is built correctly, with well-defined scope, minimizing
risks of failure.
4. Establishing the Groundwork in Requirements Engineering
Before gathering requirements, groundwork must be established to ensure clarity and stakeholder
alignment. This involves three major components:
1. Stakeholders: Identify everyone who has an interest in the system—end users, customers,
developers, project managers, and regulatory bodies. Each stakeholder has different expectations.
For example, a bank manager may want reports, while a customer wants quick transactions.
2. Viewpoints: Different stakeholders have different perspectives. A user’s viewpoint may
focus on ease of use, while developers focus on technical feasibility. Viewpoint analysis helps
reconcile these differences.
3. Collaboration: Successful requirements gathering requires teamwork. Workshops,
prototyping, and group discussions help stakeholders communicate effectively and agree on
priorities.
Establishing groundwork avoids miscommunication, ensures requirements are aligned with
business goals, and builds trust between customers and developers. It lays a strong foundation for
the remaining steps of requirements engineering.
5. First Questions a Requirements Engineer Should Ask
A requirements engineer must ask fundamental questions to avoid assumptions and
misunderstandings. These include:
1. What is the main purpose of the system? (Defines business goals.)
Example: “ Is the purpose of the food delivery app only to deliver food, or also to manage
restaurants and riders?”
2. Who are the end-users? (Defines user roles.)
Example: Customers, delivery agents, and restaurants are all users of a food delivery app.
3. What environment will the system operate in? (Hardware, software, network.)
Example: Should the app work on both Android and iOS?
4. What constraints exist? (Budget, deadlines, technology limits.)
Example: Should the payment system comply with RBI guidelines?
These questions help identify correct requirements early, reduce ambiguity, and prevent costly
rework later.
6. Requirements Traceability
Requirements traceability is the ability to track each requirement throughout the software lifecycle.
It ensures that every requirement is implemented, tested, and linked back to its origin.
Types:
1. Backward Traceability: Tracing a requirement back to its source (e.g., customer request).
2. Forward Traceability: Ensuring each requirement is implemented and tested in design,
code, and test cases.
3. Bidirectional Traceability: Combination of both forward and backward traceability.
Significance:
• Ensures no requirement is missed.
• Helps during changes to identify affected parts of the system.
• Improves project transparency and quality assurance.
Challenges:
• Large projects with thousands of requirements are difficult to track.
• Maintaining traceability requires continuous effort and documentation.
Example: In an ATM system, if a requirement says “ ATM must allow withdrawal within 2
seconds,” forward traceability ensures design and test cases exist to verify this.
7. Structure of an SRS Document (Case Study: ATM System)
An SRS (Software Requirements Specification) is a formal document that captures all software
requirements in a structured format. It acts as a contract between customer and developer.
Typical Structure:
1. Introduction – Purpose, scope, definitions.
2. Overall Description – System context, constraints, assumptions.
3. Functional Requirements – Features like withdrawal, deposit, balance inquiry.
4. Non-functional Requirements – Performance, security, reliability.
5. System Models – Use case diagrams, DFDs, ER diagrams.
6. External Interfaces – Hardware, software, communication interfaces.
7. Appendices – Glossary, references.
Case Study Example (ATM):
• Functional: Users must log in with PIN, withdraw/deposit money, print mini statement.
• Non-functional: ATM should process transactions within 2 seconds, be available 24/7,
and encrypt PIN data.
Thus, SRS ensures clarity, reduces miscommunication, and serves as a baseline for design and
testing.
8. Why Do We Need SRS?
The Software Requirements Specification (SRS) is essential for several reasons:
1. Agreement Document: Acts as a legal contract between customers and developers,
ensuring both understand the same requirements.
2. Avoids Miscommunication: Prevents ambiguity and conflicting interpretations.
3. Basis for Design and Development: Designers and developers use SRS as a reference.
4. Testing and Validation: Testers verify the software against requirements listed in SRS.
5. Project Management: Helps in cost estimation, scheduling, and progress tracking.
6. Maintenance: Provides a record for future modifications.
Without SRS, projects may suffer from scope creep, delays, and misunderstandings. In summary,
SRS is the foundation of successful software engineering.
9. Seven Distinct Tasks in Requirements Engineering
The seven tasks of RE are:
1. Inception: Understanding goals and feasibility.
2. Elicitation: Gathering requirements.
3. Elaboration: Refining details and creating models.
4. Negotiation: Resolving conflicts among stakeholders.
5. Specification: Writing formal documentation (SRS).
6. Validation: Ensuring correctness and completeness.
7. Management: Handling changes and maintaining traceability.
Together, these tasks form a complete cycle for handling requirements systematically.
10. Scenario-Based Modeling
Scenario-based models help represent requirements in real-world user situations. They include:
• Use Case Diagrams: Visualize user-system interactions. Example: “Customer withdraws
money from ATM.”
• User Stories: Short descriptions of user needs. Example: “As a student, I want to register
for courses online.”
• Activity Scenarios: Step-by-step workflows showing how processes are executed.
Purpose: Makes requirements easy to understand for both technical and non-technical stakeholders,
ensures clarity, and helps identify missing functionality.
11. Five Tasks in Requirements Monitoring
Requirements must be continuously monitored to ensure alignment with project goals. The five
tasks are:
1. Track changes in requirements.
2. Verify each requirement is implemented.
3. Ensure requirements are tested properly.
4. Monitor dependencies and conflicts.
5. Report progress to stakeholders.
This prevents overlooked requirements, scope creep, and quality issues, ensuring successful project
delivery.
