1.

Explain and Compare Functional and Non-Functional Requirements

Functional Requirements:
• Definition:
Functional requirements are statements of services or functions that the
system should provide. They specify what the system should do—how it must
react to particular inputs and behave under certain conditions.
• Examples:
o “The user shall be able to search the appointment list.”
o “Every order shall be allocated a unique identifier.”
• Key Aspects:
o Describe system behavior.
o Detail the functions and features expected.
o Serve as a basis for both contract definition and design
implementation.

Non-Functional Requirements:
• Definition:
Non-functional requirements specify constraints on the system’s services and
functions. They describe how well the system performs its functions and
impose conditions on its design and development.
• Examples:
o Performance (e.g., response time, throughput)
o Usability (e.g., ease of use, accessibility)
o Reliability (e.g., error rates, fault tolerance)
o Portability, security, and compliance with standards.
• Key Aspects:
o Are quality attributes of the product.
o May include organizational or external constraints (e.g., legislative
requirements).
o Often more difficult to measure precisely but are critical for the
system’s overall success.

Comparison:
 • Focus:
Functional requirements focus on "what" the system should do, while non-
functional requirements focus on "how" the system performs and operates.
• Specification:
Functional requirements are typically more detailed and directly observable,
whereas non-functional requirements often use qualitative measures (e.g.,
ease of use) or quantitative constraints (e.g., maximum response time).
• Verification:
Functional requirements are verified through functional tests, while non-
functional requirements are validated via performance tests, usability studies,
and other quality assurance measures.

2. Discuss the Requirements Engineering Process

Overview:
Requirements engineering is the systematic process of developing a specification of
what a software system should do. It encompasses several activities:
• Feasibility Study:
A preliminary assessment to determine if the system contributes to
organizational objectives, can be implemented within the available schedule
and budget, and is compatible with existing systems.
• Requirements Elicitation (Discovery):
Gathering requirements from stakeholders using techniques such as
interviews, questionnaires, observation (ethnography), scenarios, and use
cases. The goal is to understand both the application domain and the users’
needs.
• Requirements Analysis:
Organizing, classifying, and prioritizing the collected requirements. This
includes resolving conflicts, ensuring consistency, and identifying
dependencies.
• Requirements Specification:
Documenting the requirements in a structured and precise manner. This
document typically includes both user requirements (often in natural
language plus diagrams) and detailed system requirements.
• Requirements Validation:
Checking that the requirements are complete, consistent, unambiguous,
realistic, and verifiable. Validation techniques include reviews, prototyping,
and test-case generation.
• Requirements Management:
Maintaining and controlling changes to the requirements throughout the
 software lifecycle. This involves unique identification of each requirement,
traceability, and a formal change management process.
These steps help ensure that the final requirements document clearly defines the
system’s desired behavior and constraints.

3. What Are the Characteristics of a Good System Requirements

Document?
A good system requirements document (SRD) should:
• Clarity:
Clearly state what the system should do without ambiguity. Consistent
terminology and a standard format are essential.
• Completeness:
Include all necessary functionalities and constraints required by the user,
covering both functional and non-functional aspects.
• Consistency:
Avoid conflicts and contradictions among requirements. All requirements
should be logically aligned.
• Verifiability:
Each requirement must be testable or measurable so that it can be validated
during system testing.
• Modularity and Traceability:
Requirements should be uniquely identified to support traceability between
requirements, design, and testing. This facilitates change management.
• Understandability:
Written in a manner that is comprehensible to both technical and non-
technical stakeholders.
• Stability and Maintainability:
The document should be structured to allow controlled modifications over the
system’s lifecycle without compromising overall integrity.
Using standard structures such as those recommended by IEEE (Introduction,
General Description, Specific Requirements, Appendices, and Index) also helps
maintain quality and uniformity.

4. What Is the Feasibility Study?

Definition:
A feasibility study is a short, focused investigation conducted early in the
requirements engineering process to assess whether a proposed system is viable.
Objectives:
• Strategic Fit:
Determine if the system aligns with the overall objectives of the organization.
• Technical Feasibility:
Evaluate whether the system can be implemented using current technology,
within the given schedule and budget.
• Operational Feasibility:
Assess if the system can be integrated with existing systems and if it will
operate effectively in the intended environment.
The outcomes of the feasibility study help decide whether to proceed with the
project, modify the approach, or abandon the project altogether.

5. What Are CASE Tools?

Definition:
CASE (Computer-Aided Software Engineering) tools are software applications that
support various activities in the software development process. They aim to automate
or semi-automate tasks associated with software design, implementation, testing,
and maintenance.
Examples and Functions:
• Graphical Editors:
Used for system modeling and design (e.g., UML diagram tools).
• Data Dictionary Management:
Helps maintain a repository of data definitions and design entities.
• User Interface Builders:
Assist in constructing graphical user interfaces.
• Debuggers and Automated Translators:
Support program fault-finding and code generation.
Benefits:
• Improved Productivity:
Automation of routine tasks can reduce development time and effort.
• Enhanced Consistency and Quality:
Standardized templates and models lead to fewer errors and better
documentation.
 • Support for Requirements Management:
Facilitates traceability, change control, and documentation throughout the
software lifecycle.
While CASE tools can significantly enhance the software process, they do not
eliminate the need for creative and collaborative human effort in software
engineering.