Requirement
Engineering
Evaluation Plan with tentative deadline
Evaluation component Date of evaluation
Quiz -1 01-02-2024
Quiz -2 19-03-2024
Quiz -3 16-04-2024
Project problem statement submission 03-02-2024
Project mid term evaluation 11, 13, 18, 20 (March)
Project end term evaluation 15, 17, 22, 24 (April)
Sample projects are uploaded on Blackboard
Requirement ??
• It is about WHAT not HOW
• Nothing can be said obvious
• Requirements are the descriptions of the
services provided by a system and its
operational constraints
• It may range from a high-level abstract
statement to a detailed mathematical
specification
• It may be as complex as a 500-1000 pages
of document.
• It may serve as the basis for the contract
Requirement
Engineering
• Process of discovering, analyzing,
documenting and validating the
requirements of the system
• It includes -
1. Feasibility Study
2. Requirement Elicitation and
Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
https://www.javatpoint.com/software-engineering-requirement-engineering
Requirement
Elicitation and
Analysis Process
• The requirements are analyzed to
identify inconsistencies, defects,
omission, etc.
• Challenges:
• Users often don't know what
they want
• Users express requirements in
their terms.
• Conflicting requirements.
• Changes during the analysis
process.
https://www.javatpoint.com/software-engineering-requirement-engineering
User requirements
• Usually, the first attempt for the description
of the requirements
Requirement: • In natural language or diagrams
• Readable by everybody
Levels of • Serve business objectives
Abstraction
System requirements
• Services and constraints of the system in
detail
• Useful for the design and development
• Precise and cover all cases
Requirement: Types
Functional requirements
• Services the system should provide
• What the system should do or not in reaction to particular situations
Non-functional requirements
• Constraints on the services or functions offered by the system
• Examples: Timing constraints, constraints on the development process (CASE, language, development
method…), standards etc
Domain requirements
• From the application domain of the system
• May be functional or non-functional
• Examples: Medicine, library, physics, chemistry
Functional Requirements
• Requirements that the end user specifically demands as basic facilities that
the system should offer.
• All these functionalities need to be necessarily incorporated into the system
as a part of the contract.
• Outputs for the given inputs and their relations must specify behavior of
invalid inputs too.
Example:
• What are the features that we need to design for this system?
• What are the edge cases we need to consider, if any, in our design?
Defines system properties (reliability, response time and storage)
and constraints (I/O device capability, system representations, etc.)
Categorized into:
• Product requirements
• Product behavior
Non- • E.g.: Timing, performance, memory, reliability, portability, usability
Functional • Organizational requirements
• Policies and procedures in the customer’s and developer’s
Requirements organizations
• E.g.: Process requirements, implementation requirements, delivery
requirements
• External requirements
• Factors externals to the system and the development process
• E.g.: Interoperability, legislation, ethics
Non-functional requirements may be more critical than
functional requirements.
Example:
Non-
Functional
Requirements
Requirements engineering (RE) processes
• The processes used for RE widely depending on the
• Application domain
• The people involved
• Organization developing the requirements
• However, there are several generic activities common to all processes
1. Requirements elicitation
2. Requirements analysis
3. Requirements validation
4. Requirements management
• In practice, RE is an iterative activity in which these processes are interleaved
RE.1: • Software engineers work with a range of system stakeholders to
find out about
Requirements • The application domain
• The services that the system should provide
elicitation • The required system performance,
• Hardware constraints,
• Other systems, etc.
RE.1: Problems of requirements
elicitation
• Stakeholders don’t know what they really want.
• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organisational and political factors may influence the
system requirements.
• The requirements change during the analysis process. New
stakeholders may emerge, and the business environment
may change
Requirement
Elicitation techniques
• Interviews
• Brainstorming Sessions
• Facilitated Application Specific
Techniques
• Quality Function Deployment
• The Use case Approach
Template for
writing use
cases
Template for
writing use
cases
Use case
diagram
Result
Management
System
RE.2: Requirement
Analysis
• Develop a context diagram
• Development of a prototype
• Model the requirements
• Finalise the requirements
RE.2:
Requirement
Analysis
RE2.1: Data Flow Diagram
RE2.2: Data Flow Diagram
RE2.3: ER
Diagram
RE2.4: Data dictionary
Function
Decomposition
Diagram (FDD)
RE.3: Requirements
Documentation
• The process of writing down the user and system
requirements in a requirements document.
• User requirements must be understandable by
end-users and customers who do not have a
technical background.
• System requirements are more detailed
requirements and may include more technical
information.
• The requirements may be part of a contract for
the system development
• It is therefore important that these are as
complete as possible.
RE.3: Requirements Documentation
NATURE OF THE SRS CHARACTERISTICS OF ORGANIZATION OF
A GOOD SRS THE SRS
Nature of the SRS
• Serve as a basis for agreement
between customer and provider
• A starting point of development
• Used for cost estimation and
schedule
• A basis for validation and verification
• A Basis for user manual preparation
• A basis for later enhancement
Characteristic
of a good SRS
Characteristic
of a good SRS
Characteristic
of a good SRS
Organization of the SRS
RE.4:
• Requirement reviews
Requirement • Prototyping
Validation
RE.4:
Requirements
Validation
Validation:
Requirement
reviews
Validation: Requirement reviews
RE.5: Requirement Management
Stable and volatile Planning Change
requirements management
Requirement
management:
Basic
Understanding
Requirement
Management:
Planning
Requirement
management:
Change Management
Example: Student Result Management
System
• Problem Statement
• Context Diagram
• Data Flow Diagram
• ER Diagram
• Use Case Diagram
• Use cases
• SRS
MCQs
Which of the following is a functional requirement?
• Portability
• Security
• User Interaction
• Scalability
MCQs
DFD is also called as
• Digraph
• Flow chart
• FDD
• Bubble chart
MCQs
Which of the following is not the characteristics of good software
requirement?
• Completeness
• Consistency
• Reliability
• Clarity
MCQs
Which one of the following is not a step of requirement engineering?
• Elicitation
• Design
• Analysis
• Documentation
MCQs
FAST stands for
• Functional Application Specification Technique
• Fast Application Specification Technique
• Facilitated Application Specification Technique
• None of the mentioned
