The document outlines key activities in requirements engineering including elicitation, analysis, validation, and management, emphasizing their importance in software development. It describes various types of requirements such as user, system, functional, and non-functional, as well as techniques for gathering and validating these requirements through stakeholder engagement. Additionally, it highlights methodologies like data flow modeling and object-oriented analysis, underscoring the iterative nature of the requirements analysis process.

1. Dr. V Nagesh
Professor & Head,
Department of Information Technology
MVGR College of Engineering

2.  To describe the principal requirements
engineering activities
 To introduce techniques for requirements
elicitation and analysis
 To describe requirements validation
 To discuss the role of requirements
management in support of other
requirements engineering processes

3.  A requirement is a detailed, formal
description of system functionalities
 IEEE definition
◦ A condition of capability of a system required by
customer to solve a problem or achieve an objective
◦ A capability that a product must possess or
something a product must do in order to ultimately
satisfy the customer need, contract, constraint,
standard, specification or other formally imposed
documents

4. Gathering
Analyzing
Documenting
Validating
Managing

5.  The processes used for RE vary widely
depending on the application domain, the
people involved and the organisation
developing the requirements
 However, there are a number of generic
activities common to all processes
◦ Requirements elicitation
◦ Requirements analysis
◦ Requirements validation
◦ Requirements management

6. Software
Requirements
Business
Requirements
User & System
Requirements
Functional &
Non-Functional
requirements

7.  Define the project goal and the expected
business benefits for doing the project
 State business needs and opportunities for
the product.
 Describe the product domain and product
demand

8.  User requirements are the high-level abstract
statements supplied by customer, end user or
other stakeholders.
 System requirements are the detailed and
technical functionalities written in a
systematic manner that are implemented in
the business process to achieve the goal of
user requirements

9.  Functional requirements are the behavior or
functions that the system must support.
◦ Business rules, administrative tasks, transactions,
authentication etc.
 Nonfunctional requirements specify how a
system must behave
◦ Reliability, maintainability, performance, usability,
availability etc.

11.  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

13.  Role of system analyst is multifunctional,
fascinating and challenging
 Interacts with different people, understands
the business needs and has knowledge of
computing
 Skills of analyst include programming
experience, problem solving, interpersonal
savvy, IT expertise, and political savvy.

14.  To discover the information pertaining to
system development
 There are several techniques for finding facts
◦ Interviewing
◦ Questionnaires
◦ Joint Application Development (JAD)
◦ Onsite Observation
◦ Prototyping
◦ Viewpoints
◦ Review Records

15.  Involves eliciting requirements through face
to face interaction with individuals or a group
of people.
 Conducted to gather facts, verify and clarify
facts, identify requirements, and determine
ideas and options.
 Stakeholders are notified in advance for the
interview date, time, venue, and documents
required during the interview.
 There are 2 types of interviews:
◦ Unstructured (No predefined agenda)
◦ Structured

16.  Used to collect and record large amount of
qualitative as well as quantitative data from a
number of people.
 System analyst prepares a series of questions
in a logical manner, supplemented by
multiple choice answers and instructions for
filling the questionnaires
 Is a quick method of data collection
 Very few people take interest in responding
to and carefully filling questionnaires

17.  Is a structured group meeting just like workshop
where the customer, designer, and other experts meet
together for the purpose of identifying and
understanding the problems to define requirements.
 Has predefined agenda and purpose.
 Session is kept short and can be maximum 1 week.
 Is conducted to identify and understand problems,
resolve conflicts, generate ideas and discuss some
alternatives and the best solutions.
 Brainstorming sessions are conducted by stating the
agenda and generate ideas for much difficult
problems.
 Focus group technique involves a small group of
people to take spontaneous occurrences.

18.  Effective technique for data collection, where
system analyst personally visit client site
organization, observes the functioning of the
system, understands the flow of documents and
the users of the system etc..
 Onsite observation is important for understanding
the work in a situation.
 Helps analyst to gain insight into the working of
the system.
 Users feel uncomfortable if someone observes their
work.
 Sometimes they may interrupt the users for
understanding the work

19.  Is useful in situations where it is difficult to
discover and understand the requirements
and where early feedback from the customer
is needed.
 Is a repetitive process
 Can become costly if it is repeated many
times

20.  Way of structuring requirements
 Classified into various categories:
◦ Stakeholders
◦ Organizational
◦ Domain knowledge

21.  Reviewing existing documents is a good way
of gathering requirements
 There exists reliable data in the formalized
system

22.  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 change

23. Requirements
validation
Domain
understanding
Prioritization
Requirements
collection
Conflict
resolution
Classification
Requirements
definition and
specification
Process
entry

24.  Domain understanding
 Requirements collection
 Classification
 Conflict resolution
 Prioritisation
 Requirements checking

25.  Different models may be produced during the
requirements analysis activity
 Requirements analysis may involve three
structuring activities which result in these different
models
◦ Partitioning. Identifies the structural (part-of) relationships
between entities
◦ Abstraction. Identifies generalities among entities
◦ Projection. Identifies different ways of looking at a problem

26.  Is an activity which is carried out iteratively
throughout the course of software
development.
 Prioritization is done by system analyst, users
and developers.
 The following are analyzing techniques:
◦ Structured analysis
◦ Data-oriented analysis
◦ Object-oriented analysis
◦ Prototyping

27.  Is also referred to as process modeling or
data flow modeling
 Data flow modeling is useful to understand
the working process of the system
 Structured analysis uses a graphical tool
called DFD

28.  Is a graphical tool that describes the flow of
data through a system and the functions
performed by the system
 A DFD has four different symbols:
Process
Data Flow
Data Store
Actor

29.  Process: Denotes transformations of the input data
to produce the output data. Functional
requirements and their decomposed requirements
are represented through the process symbol.
 Data Flow: Are data in motion.
 Data Store: Is the data at rest. Incoming arrows
indicate the updating of data store while outgoing
arrow indicates the retrieval of data from the data
store.
 Actor: Is the external entity that represents the
source or sink.

31.  Construction of DFD starts with High-level
functionality of the system with external
inputs & outputs
 DFD is further decomposed into smaller
functions with the same input & output.
 Decomposition of DFD at various levels to
design a nested DFD is called levelling of
DFD

32.  Each piece of data flows through some processes while
moving one place to another.
 DFDs at each level must be numbered for reference purposes,
viz., level 0, level 1 etc.
◦ Level 0 is called context diagram
◦ Processes at level 1 can be numbered as 1,2,3,4…..
◦ The sub-process at level 2 are the decomposed sub-processes of level 1
which represent more granular level and numbered as 1.1, 1.2, 1.3… and
further 1.2 granularity may be numbered as 1.2.1, 1.2.2, …..
◦ Multiple data flow may be shown on single data flow line and bidirectional
arrows can be put for input & output.
 External agents/actor and flow are represented using nouns
viz., stock, pin, university, etc. Processes should be
represented as verbs and longer names must be connected
with “_” and these should be short but meaningful viz.,
sales_detail.

33.  Is a metadata that describes composite data structures
defined in the DFD.
 Is written using special symbols, such as “+” for composition,
“*” for repetition and “|” for selection.
 The combinations of repeated data are written using “[ ]”.
 Eg:
Restaurant_bill=dish_price+sales_tax+service_charge+seat_cha
rge+grand_total
Dish_price=[dish_name+quantity+price]*
Seat_charge=[reserved_table|common_table]

34.  Is a systematic approach for requirement
analysis that employs techniques and
graphical tools to represent the scenario of
the working system in an organization
 Uses DFDs and DDs for requirement analysis

35. Prepare context diagram
Construct Logical level 1 DFD
Decomposition of level 1 DFD
Identify man-machine boundary
Prepare data dictionary, process
descriptions
Business need
Requirements specification

39.  After constructing final DFD, boundary
conditions are identified, which ensures what
will be automated and what can be done
manually or by another machine.

40.  ER Modeling
◦ Entities
◦ Attributes
◦ Relationships
◦ Aggregation, Generalization and specialization

41.  Identification of entity & relationships
 Construct basic E-R diagram
 Add key attributes to the basic E-R model
 Add non-key attributes to the basic E-R
model
 Apply hierarchical relation
 Perform normalization
 Adding integrity rules to the model

42.  It has two aspects:
◦ Object Oriented Analysis (OOA)
◦ Object Oriented Design (OOD)
 The most common concepts and the
constructs used in OOA are:
◦ Objects & Classes
◦ Association
◦ Aggregation, Generalization & Specialization

43.  OMT approach starts with the problem
statement.
 There are 3 kinds of modelling
◦ Object modeling
◦ Dynamic modeling
◦ Functional Modeling

44.  Object models are constructed using class
diagram after analysis of application domain.
 The process of producing object models:
◦ Identifying objects & Classes
◦ Prepare a data dictionary
◦ Identifying associations
◦ Identifying attributes
◦ Refining with inheritance
◦ Grouping classes into modules

45.  The dynamic behavior and relationships over
time in the system are modeled in a dynamic
model
 Time-dependent behavior is represented in
dynamic model
 Represents sequence of operations,
interactions between objects, and the flow of
control without describing their
implementation details

46.  Illustrates the computations within a system.
 Describes what the actions are without
specifying how or when they are performed
 Specifies the meaning of operations in object
model and the actions in dynamic model
 Involves inputs, transformations and
outcomes
 Is represented in DFDs

47.  It is suitable when the requirements are not
known in advance, rapid delivery is required
and the customer involvement
 Is an iterative approach which begins with
partial development of an executable model.
 Demonstrated for customer feedback
 2 types of approaches for elicitation, analysis
and validation:
◦ Throwaway prototyping
◦ Evolutionary prototyping

48. Requirements
Analysis
Build Prototype Modify
Requirements
Evaluate No
Yes
Final system development

49.  A prototype is built with the focus that the
working prototype will be considered the final
system. 1st Prototype
2nd Prototype
nth Prototype
Final
Prototype
•
•
•
•

50.  The main focus of the problem analysis
approaches is to understand the internal
behavior of the software

51.  Correctness
 Unambiguity
 Completeness
 Consistency
 Should be ranked for importance and/or stability
 Verifiability
 Modifiability
 Testability
 Validity
 Traceability

52.  Functional Requirements
 Performance Requirements (non functional)
 Design Constraints (hardware & software)
 External interface requirements

53. 1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms & abbreviations
1.4 References
1.5 Document overview
2. General Description
2.1 Product perspective
2.2 Product functions
2.3 User Characteristics
2.4 General constraints
2.5 Assumptions and dependencies

54. 3. Specific requirements
3.1 Functional Requirements
3.1.1 Functional Requirement 1
3.1.1.1 Introduction
3.1.1.2 Input
3.1.1.3 Processing
3.1.1.4 Output
3.1.N Functional Requirement N
3.2 External interface requirements
3.3 Performance requirements
3.4 Design constraints
3.5 Security requirements
3.6 Maintainability requirements
3.7 Reliability requirements

55. 3.8 Availability requirements
3.9 Database requirements
3.10 Documentation requirements
3.11 Safety requirements
3.12 Operational requirements
3.13 Site adaptation

56.  Decision Tree and decision Table
 Program design Language
 Regular Expression
 Graphical Methods
 Mathematical Methods

57.  Requirements review
 Requirements Inspection
 Test case generation
 Reading
 Prototyping

58.  Is a process of systematically collecting,
organizing, documenting, prioritizing, and
negotiating on the requirements for a project.
 The main activities are:
◦ Planning for the project requirements
◦ Focusing on the requirements changes
◦ Managing the requirements changes
◦ Controlling and tracking the changes
◦ Agreeing on the requirements among stakeholders
◦ Performing regular requirements reviews
◦ Performing impact analysis for the required changes