
Non-Functional Requirements:
Non-functional requirements describe HOW the software performs its functions. They define quality
attributes, performance criteria, and constraints. They are also called non-behavioral requirements.
Examples: Performance (process 1,000 transactions/second); Usability (user-friendly interface);
Reliability (99.9% uptime); Security (data must be encrypted); Portability (runs on multiple
platforms); Scalability (handles increased load).
Key Differences:
Functional requirements specify WHAT the system does; Non-functional requirements specify
HOW WELL the system does it. Functional requirements can be seen directly in the final product;
non-functional requirements are quality attributes. Functional requirements define features;
non-functional requirements define constraints.
Q3. Explain the Requirements Engineering Process in detail.
Requirements Engineering (RE) is the process of defining, documenting, and maintaining
requirements in software development. It ensures what the customer desires is correctly
understood, analyzed, and implemented.
Steps of Requirements Engineering:
1. Inception: The first phase where basic questions are asked about the project. Engineers
understand the problem, identify stakeholders, and establish effective communication between
customer and developer.
2. Elicitation: Gathering requirements from stakeholders using techniques like interviews,
brainstorming sessions, Facilitated Application Specification Technique (FAST), and Use Case
Approach. Problems that may occur: Problem of Scope, Problem of Understanding, and Problem of
Volatility.
3. Elaboration: Requirements from inception and elicitation are refined and expanded. Modeling
activities are performed and a prototype is developed.
4. Negotiation: Discussion between developer and customer about what is needed vs. what can
be feasibly built with limited resources. Topics discussed: availability of resources, delivery time,
scope, project cost, and development estimates.
5. Specification: All requirements are documented in a formal specification (SRS). Models used
include ER diagrams, DFDs, and Data Dictionaries.
6. Validation: Checking that all requirements are stated correctly, errors are debugged, and work
product meets standards. Techniques: requirements reviews, prototyping, test-case generation,
automated consistency analysis.
7. Requirements Management: Identifying, controlling, tracking, and establishing requirements
throughout the project lifecycle. Manages any changes that occur during the project.
Q4. Explain Feasibility Study and Requirement Validation.
Feasibility Study:
The objective of a feasibility study is to create reasons for developing software that is acceptable to
users, flexible to change, and conformable to established standards.