REQUIREMENT ENGINEERING

REQUIREMENTS ANALYSIS AND
SPECIFICATION
2.1 Software Requirements: Functional and Non-Functional,
2.2 User requirements,
2.3 System requirements,
2.4 Software Requirements Document
2.5 Requirement Engineering Process:
2.6 Feasibility Studies,
2.7 Requirements elicitation and analysis,
2.8 Requirements validation,
2.9 Requirements management
2.10 Classical analysis: Structured system Analysis,
2.11 Petri Nets
2.12 Data Dictionary

2.1 Software Requirements
 The requirement for a system is the description of
the services provided by the system and its
operational constraints.
 A requirement is simply a high level, abstract
statement of a service that the system should
provide or a constraint on the system
 Requirement Engineering
◦ The process of finding out, analyzing,
documenting and checking these services and
constraints is called requirement engineering.
3/14/2023 2

2.1 Software Requirements
3/14/2023 3

2.1.1 Types of requirement
 User requirements
 System requirements
3/14/2023 4

2.1.2 Functional and Non-Functional
 Functional requirements
 Non-functional requirements
 Domain requirements
3/14/2023 5

2.1.3 Functional requirements
 Describe functionality or system services.
 Depend on the type of software, expected users
and the type of system where the software is used
 Functional user requirements may be high-level
statements of what the system should do but
functional system requirements should describe
the system services in detail
 The LIBSYS system
◦ A library system that provides a single interface
to a number of databases of articles in different
libraries.
◦ Users can search for, download and print these
articles for personal study
3/14/2023 6

2.1.4 Requirements completeness
and consistency
 In principle, requirements should be both complete
and consistent.
 Complete
◦ They should include descriptions of all facilities
required.
 Consistent
◦ There should be no conflicts or contradictions in
the descriptions of the system facilities.
3/14/2023 7

2.1.5 Non-functional requirements
Performance
requir ements
Space
requir ements
Usability
requir ements
Efficiency
requir ements
Reliability
requir ements
Portability
requir ements
Inter oper ability
requir ements
Ethical
requir ements
Legislative
requir ements
Implementa tion
requir ements
Standar ds
requir ements
Delivery
requir ements
Safety
requir ements
Privacy
requir ements
Product
requir ements
Organisational
requir ements
External
requir ements
Non-functional
requir ements
3/14/2023 8

Parameters Functional Requirement Non-Functional Requirement
What is it? Verb Attributes
Requirement It is mandatory It is non-mandatory
Capturing type It is captured as use case. It is captured as a quality attribute.
End-result Product feature Product properties
Capturing Easy to capture Hard to capture
Objective
Helps you verify the functionality of
the software.
Helps you to verify the
performance of the software.
Area of focus Focus on user requirement
Concentrates on the user’s
expectation.
Documentation Describe what the product does Describes how the product works
Type of Testing
Functional Testing like System,
Integration, End to End, API
testing, etc.
Non-Functional Testing like
Performance, Stress, Usability,
Security testing, etc.
Test Execution
Test Execution is done before non-
functional testing.
After the functional testing
Product Info Product Features Product Properties
3/14/2023 9

2.1.6 Goals and requirements
 Non-functional requirements may be very difficult to
state precisely and imprecise requirements may be
difficult to verify.
 Goal
◦ A general intention of the user such as ease of
use.
 Verifiable non-functional requirement
◦ A statement using some measure that can be
objectively tested.
 Goals are helpful to developers as they convey the
intentions of the system users.
3/14/2023 11

2.1.7 Domain requirements
 Derived from the application domain and describe
system characteristics and features that reflect
the domain.
 Domain requirements be new functional
requirements, constraints on existing
requirements or define specific computations.
 If domain requirements are not satisfied, the
system may be unworkable
 Train protection system
◦ The deceleration of the train shall be computed
as:
◦ Dtrain = Dcontrol + Dgradient
3/14/2023 12

2.2 User requirements
 User requirements are defined using natural
language, tables and diagrams as these can be
understood by all users
 Problems with natural language
◦ Lack of clarity
◦ Requirements confusion
◦ Requirements amalgamation
 LIBSYS requirement
◦ LIBSYS shall provide a financial accounting system that
maintains records of all payments made by users of the
system. System managers may configure this system so
that regular users may receive discounted rates
3/14/2023 13

2.3.1 System requirements
 More detailed specifications of system functions,
services and constraints than user requirements.
 They are intended to be a basis for designing the
system.
 They may be incorporated into the system
contract.
 System requirements may be defined or illustrated
using system models
3/14/2023 14

2.3.2 Requirements and design
 In practice, requirements and design are
inseparable
 System architecture may be designed to structure
the requirements;
 The system may inter-operate with other systems
that generate design requirements;
 The use of a specific design may be a domain
requirement
3/14/2023 15

2.3.3 Problems with NL (Natural
Language) specification
 Ambiguity
◦ Natural language understanding relies on the specification
readers and writers using the same words for the same
concept. This leads to misunderstandings
◦ EX: Signs displayed by an escalator.
 Over-flexibility
 Lack of modularisation
◦ It may be difficult to find all related requirements. To
discover the consequence of a change, you may have to
look at every requirement rather than at just a group of
related requirements.
3/14/2023 16

2.3.5 System requirements
specification using a standard form
3/14/2023 17

2.3.5 Tabular specification
 Used to supplement natural language.
 Particularly useful when you have to define a
number of possible alternative courses of action.
3/14/2023 18

2.3.6 Graphical models
 Graphical models are most useful when you need
to show how state changes or where you need to
describe a sequence of actions
3/14/2023 19

2.3.7 Sequence diagrams
 These show the sequence of events that take place
during some user interaction with a system.
 You read them from top to bottom to see the order
of the actions that take place.
 Cash withdrawal from an ATM
◦ Validate card;
◦ Handle request;
◦ Complete transaction
3/14/2023 20

3/14/2023 21
ATM Database
Card
Card number
Card OK
PIN request
PIN
Option menu
<<exception>>
invalid card
Withdraw request
Amount request
Amount
Balance request
Balance
<<exception>>
insufficient cash
Debit (amount)
Debit response
Card
Card removed
Cash
Cash removed
Receipt
Validate card
Handle request
Complete
transaction
2.3.8 Sequence diagrams

2.3.9 Interface specification
 Most systems must operate with other systems and
the operating interfaces must be specified as part
of the requirements.
 Three types of interface may have to be defined
◦ Procedural interfaces;
◦ Data structures that are exchanged;
◦ Data representations.
 Formal notations are an effective technique for
interface specification
3/14/2023 22

2.4.1 Software Requirements
Document
 The requirements document is the official
statement of what is required of the system
developers.
 Should include both a definition of user
requirements and a specification of the system
requirements.
 It is NOT a design document. As far as possible, it
should set of WHAT the system should do rather
than HOW it should do it
3/14/2023 23

2.4.2 Users of a requirements document
3/14/2023 24

2.4.3 IEEE requirements standard
 Defines a generic structure for a requirements
document that must be instantiated for each
specific system.
 Introduction.
 General description.
 Specific requirements.
 Appendices.
 Index.
3/14/2023 25

2.4.4 Requirements document structure
 Preface
 Introduction
 Glossary
 User requirements definition
 System architecture
 System requirements specification
 System models
 System evolution
 Appendices
 Index
3/14/2023 26

2.5 Requirement Engineering Process
 Feasibility studies
 Requirements elicitation and analysis
 Requirements validation
 Requirements management
 The processes used for RE vary widely depending
on the application domain, the people involved and
the organization developing the requirements
3/14/2023 27

2.5.1 Requirement Engineering
Process
3/14/2023 28

2.5.2 Spiral model of Requirements
engineering
3/14/2023 29
Requirements
specification
Requirements
validation
Requirements
elicitation
System requirements
specification and
modeling
System
requirements
elicitation
User requirements
specification
User
requirements
elicitation
Business requirements
specification
Prototyping
Feasibility
study
Reviews
Syst em requirements
document

2.6 Feasibility studies
 A feasibility study decides whether or not the
proposed system is worthwhile.
 A short focused study that checks
◦ If the system contributes to organizational
objectives;
◦ If the system can be engineered using current
technology and within budget;
 If the system can be integrated with other
systems that are used
3/14/2023 30

2.6.1 Feasibility study implementation
 Based on information assessment (what is
required), information collection and report writing.
 Questions for people in the organization
 What if the system wasn’t implemented?
 What are current process problems?
 How will the proposed system help?
 What will be the integration problems?
 Is new technology needed? What skills?
 What facilities must be supported by the
proposed system?
3/14/2023 31

2.7 Elicitation and analysis
 Sometimes called requirements elicitation or
requirements discovery.
 Involves technical staff working with customers to
find out about the application domain, the
services that the system should provide and
the system’s operational constraints.
 May involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders
3/14/2023 32

2.7.1 Problems of requirements
analysis
 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.
3/14/2023 33

2.7.2 The Requirement
Process
Requirements
discovery
Requirements
classification and
organization
Prioritization and
negotiation
Requirements
documentation
3/14/2023 34

2.7.3 Process activities
Requirements discovery
 The process of gathering information about the
proposed and existing systems and distilling
the user and system requirements from this
information.
 Sources of information include
Documentation,
System stakeholders and
The specifications of similar systems
3/14/2023 35

2.7.4 Viewpoints
 Viewpoints are a way of structuring the
requirements to represent the perspectives of
different stakeholders. Stakeholders may be
classified under different viewpoints
 Types of viewpoint
◦ Interactor viewpoints
◦ Indirect viewpoints
◦ Domain viewpoints
3/14/2023 36

2.7.4.1 Viewpoint identification
 Providers and receivers of system services
 Systems that interact directly with the system
being specified
 Regulations and standards
 Sources of business and non-functional
requirements.
 Engineers who have to develop and maintain the
system
 Marketing and other business viewpoints
3/14/2023 37

3/14/2023 38
Article
providers
Finance
Library
manager
Library
staff
Users
Interactor
Indirect
All VPs
Classification
system
UI
standards
Domain
External
Staff
Students Cataloguers
System
managers
2.7.4.2 Viewpoint identification
EX: Library Management System

2.7.5 Interviewing
 In formal or informal interviewing, the RE team puts
questions to stakeholders about the system that
they use and the system to be developed.
 There are two types of interview
◦ Closed interviews where a pre-defined set of
questions are answered.
◦ Open interviews where there is no pre-defined
agenda and a range of issues are explored with
stakeholders
3/14/2023 39

2.7.6 Ethnography
 Social scientist spends a considerable time
observing and analyzing how people actually
work.
 People do not have to explain or articulate their
work.
 Social and organizational factors of importance
may be observed.
 Ethnographic studies have shown that work is
usually richer and more complex than suggested
by simple system models
3/14/2023 40

2.7.6.1 Ethnography and prototyping
3/14/2023 41

2.7.6.2 Scope of ethnography
 Requirements that are derived from the way that
people actually work rather than the way I which
process definitions suggest that they ought to work.
 Requirements that are derived from cooperation
and awareness of other people’s activities
3/14/2023 42

2.8 Requirements validation
 Concerned with demonstrating that the
requirements define the system that the customer
really wants.
 Requirements error costs are high so validation is
very important
◦ Fixing a requirements error after delivery may
cost up to 100 times the cost of fixing an
implementation error
3/14/2023 43

2.8.1 Requirements checking
 Validity. Does the system provide the functions
which best support the customer’s needs?
 Consistency. Are there any requirements
conflicts?
 Completeness. Are all functions required by
the customer included?
 Realism. Can the requirements be
implemented given available budget and
technology
 Verifiability. Can the requirements be
checked?
3/14/2023 44

2.8.1.1Requirements validation
techniques
 Requirements reviews
 Prototyping
 Test-case generation
3/14/2023 45

2.8.1.2 Requirements reviews
 Regular reviews should be held while the
requirements definition is being formulated.
 Both client and contractor staff should be involved
in reviews.
 Reviews may be formal (with completed
documents) or informal. Good communications
between developers, customers and users can
resolve problems at an early stage.
3/14/2023 46

2.8.1.3 Review checks
 Verifiability. Is the requirement realistically
testable?
 Comprehensibility. Is the requirement properly
understood?
 Traceability. Is the origin of the requirement clearly
stated?
 Adaptability. Can the requirement be changed
without a large impact on other requirements?
3/14/2023 47

2.9 Requirements management
 Requirements management is the process of
managing changing requirements during the
requirements engineering process and system
development.
3/14/2023 48

2.9.1 Requirements change
 The priority of requirements from different
viewpoints changes during the development
process.
 System customers may specify requirements from
a business perspective that conflict with end-user
requirements.
 The business and technical environment of the
system changes during its development.
3/14/2023 49

2.9.1.1 Requirements evolution
3/14/2023 50

2.9.1.2 Requirements classification
3/14/2023 51

2.9.1.3 Requirements management
planning
 During the requirements engineering process, you
have to plan:
◦ Requirements identification
◦ A change management process
◦ Traceability policies
◦ CASE tool support
3/14/2023 52

2.9.1.4 Traceability
 Traceability is concerned with the relationships
between requirements, their sources and the
system design
 Source traceability
 Links from requirements to stakeholders who
proposed these requirements;
 Requirements traceability
 Links between dependent requirements;
 Design traceability
 Links from the requirements to the design;
3/14/2023 53

2.9.1.5 CASE tool support
 Requirements storage
 Change management
 Traceability management
 Automated retrieval.
3/14/2023 54

2.9.1.6 Requirements change
management
3/14/2023 55

UNIT-2 TWO MARKS
1.What is requirement engineering?
 Requirement engineering is the process of establishing the services that the
customer requires from the system and the constraints under which it operates
and is developed.
2.What are the various types of traceability in software engineering?
i.Source traceability – These are basically the links from requirement to
stakeholders
ii.Requirements traceability – These are links between dependant
requirements.
iii.Design traceability – These are links from requirements to design.
3.Define software prototyping.
 Software prototyping is defined as a rapid software development for validating the
requirements.
4.What are the benefits of prototyping?
i. Prototype serves as a basis for deriving system specification.
ii. Design quality can be improved.
iii. System can be maintained easily.
iv. Development efforts may get reduced.
v. System usability can be improved.
3/14/2023 56

UNIT-2 TWO MARKS
5.What are the prototyping approaches in software process?
i. Evolutionary prototyping – the initial prototype is prepared and it is
then refined through number of stages to final stage.
ii.Throw-away prototyping – a rough practical implementation of the
system is produced. The requirement problems can be identified
from this implementation.
6.What are the advantages of evolutionary prototyping?
i.Fast delivery of the working system.
ii.User is involved while developing the system.
iii.More useful system can be delivered.
iv.Specification, design and implementation work in co-ordinate
manner
3/14/2023 57

UNIT-2 TWO MARKS
7.What are the various Rapid prototyping techniques?
i.Dynamic high level language development.
ii.Database programming.
iii.Component and application assembly.
8.What is the use of User Interface prototyping?
This prototyping is used to pre-specify the look and feel of user interface in
an effective way
9. What are the characteristics of SRS?
◦ Correct – The SRS should be made up to date when appropriate
requirements are identified.
◦ Unambiguous – When the requirements are correctly understood
then only it is possible to write an unambiguous software.
◦ Complete – To make SRS complete, it should be specified what a
software designer wants to create software.
◦ Consistent – It should be consistent with reference to the
functionalities identified.
◦ Specific – The requirements should be mentioned specifically.
◦ Traceable – What is the need for mentioned requirement?
3/14/2023 58

UNIT-2 TWO MARKS
10.What is data modeling?
 Data modeling is the basic step in the analysis modeling. In
data modeling the data objects are examined independently
of processing. The data model represents how data are
related with one another.
11.What is a data object?
 Data object is a collection of attributes that act as an aspect,
characteristic, quality, or descriptor of the object.
12.What are attributes?
 Attributes are the one, which defines the properties of data
object.
13.What is cardinality in data modeling?
 Cardinality in data modeling, cardinality specifies how the
number of occurrences of one object is related to the number
of occurrences of another object.
3/14/2023 59

UNIT-2 TWO MARKS
14.What does modality in data modeling indicates?
 Modality indicates whether or not a particular data object
must participate in the relationship.
15.What is ERD?
 Entity Relationship Diagram is the graphical representation of
the object relationship pair. It is mainly used in database
applications.
16.What is DFD?
 Data Flow Diagram depicts the information flow and the
transforms that are applied on the data as it moves from input
to output
3/14/2023 60

UNIT-2 TWO MARKS
17.What does Level0 DFD represent?
 Level 0 DFD is called as „fundamental system
model‟ or „context model‟. In the context model the
entire software system is represented by a single
bubble with input and output indicated by incoming
and outgoing arrows.
18.What is a state transition diagram?
 State transition diagram is basically a collection of
states and events. The events cause the system to
change its state. It also represents what actions are
to be taken on the occurrence of particular event
3/14/2023 61

UNIT-2 TWO MARKS
19.Define Data Dictionary.
 The data dictionary can be defined as an organized
collection of all the data elements of the system with
precise and rigorous definitions so that user and system
analyst will have a common understanding of inputs,
outputs, components of stores and intermediate
calculations.
20.What are the elements of Analysis model?
i.Data Dictionary
ii.Entity Relationship Diagram
iii.Data Flow Diagram
iv.State Transition Diagram
v.Control Specification
vi.Process specification
3/14/2023 62

UNIT-2 TWO MARKS
21.What are functional requirements?
 Functional requirements are” statements of services the system should provide
how the system should react to particular input and how the system should
behave in particular situation.
22.What are non functional requirements?
 Non functional requirements are constraints on the services or functions offered
by the system such as timing constraints, constraints on the development
process, standards, etc……..
23.What is the outcome of feasibility study?
The outcome of feasibility study is the results obtained from the following questions:
Which system contributes to organizational objectives?
Whether the system can be engineered? Is it within the budget?
Whether the system can be integrated with other existing system?
24.What is meant by structural analysis?
The structural analysis is mapping of problem domain to flows and transformations.
The system can be modeled by using Entity Relationship diagram, Data flow diagram
and Control flow diagrams.
3/14/2023 63

REQUIREMENT ENGINEERING

More Related Content

Similar to REQUIREMENT ENGINEERING

Recently uploaded

REQUIREMENT ENGINEERING