0% found this document useful (0 votes)
26 views56 pages

SE Lecture Week3

User Interaction is a functional requirement as it specifies a service or function that the system should provide. DFD is also called as Data Flow Diagram. Reliability is not a characteristic of good software requirements. Characteristics include completeness, consistency, clarity, modifiability, traceability etc. Design is not a step of requirement engineering. The main steps are elicitation, analysis, validation and documentation. FAST stands for Facilitated Application Specification Technique.

Uploaded by

Devangi Joshi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
26 views56 pages

SE Lecture Week3

User Interaction is a functional requirement as it specifies a service or function that the system should provide. DFD is also called as Data Flow Diagram. Reliability is not a characteristic of good software requirements. Characteristics include completeness, consistency, clarity, modifiability, traceability etc. Design is not a step of requirement engineering. The main steps are elicitation, analysis, validation and documentation. FAST stands for Facilitated Application Specification Technique.

Uploaded by

Devangi Joshi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 56

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

You might also like