1

Software
Requirements
Engineering
DR. NADEEM IQBAL KAJLA
Assistant Professor
MNS-university of agriculture Multan
Goal Oriented Software 2

Requirement Engineering
 “Goal-oriented requirements engineering is concerned
with the use of goals for eliciting, elaborating, structuring,
specifying, analyzing, negotiating, documenting, and
modifying requirements.
Goal 3

 Goals can be viewed as the earliest/highest-level

requirements artefacts Can form the organizing locus for
all subsequent RE activities

 Goal is an objective a system under consideration

should achieve.
 Goals may be formulated at different levels of abstraction, 4
ranging from high-level, strategic concerns to low-level,
technical concerns

For example:
 Strategic Concerns such as “serve more passengers” for a
train transportation system or “provide ubiquitous cash
service” for an ATM network system
 Technical Concern such as for a train transportation system
“acceleration command delivered on time” for a train
transportation system or “card kept after 3 wrong
password entries” for an ATM system).
Goal Concerns 5

 Functional
 Associated with services to be provided

 Non-Functional
 Associated with quality
 Safety, security, accuracy, performance etc
Why we Need Goals? 6

 To achieve requirement completeness

 Provide a precise criterion for sufficient completeness of
requirement specification. The specification is complete with
respect to a set of goals.
 To avoid irrelevant requirements
 Goals provide a precise criterion for requirements
pertinence; a requirement is pertinent with respect to a
set of goals in the domain considered if its specification is
used in the proof of one goal at least
 7
 To explain requirements to stakeholders
 Goals provide the rationale for requirements, in a way similar
to design goals in design processes.
a goal refinement tree provides traceability links from high-
level strategic objectives to low-level technical requirements
 To explore alternative system proposals
 Requirements engineers are faced with many alternatives to
be considered during the requirements elaboration process.
 alternative goal refinements provide the right level of
abstraction at which decision makers can be involved for
validating choices being made or suggesting other
alternatives overlooked so far.
 To manage conflicts among multiple viewpoints 8
 Goals have been recognized to provide the roots for
detecting conflicts among requirements and for resolving
them eventually.

 To refine the Goals

 Goal refinement provides a natural mechanism for
structuring complex requirements documents for
increased readability
 Separating stable from more volatile information 9
 an important concern for managing requirements
evolution.
A requirement represents one particular way of
achieving some specific goal; the requirement is
therefore more likely to evolve, towards another way of
achieving that same goal, than the goal itself.
 The higher level a goal is, the more stable it will be.
 goals drive the identification of requirements to support
them;
 they have been shown to be among the basic driving forces,
together with scenarios, for a systematic requirements
elaboration process
How we can define Goals 10

 Preliminary analysis of the current system

 Searching for keywords in the preliminary documents for
example Interview transcripts
 Refinement
 Asking HOW
 Abstraction
 Asking Why
Goal Modeling 11

 The benefit of goal modeling is to support heuristic,

qualitative or formal reasoning schemes during
requirements engineering

 Goals are generally modelled by intrinsic features such

as their type and attributes, and by their links to other
goals and to other elements of a requirements model.
Goal are modelled by 12

 Types
 Functional/Non-Functional

 Attributes
 Name

 Links
 Inter Goal Links
 Links between goals and other items
Goals Types/Taxonomies 13

 Functional Goals
Underlie services that the system is expected to deliver
 Satisfaction Goals
 Concerned with satisfying agent requests
 Information Goals
 Concerned with keeping such agents informed about the states
 Non-Functional Goals
Refer to expected system qualities such as security, safety, flexibility etc
 Accuracy Goals
 Require the state of software objects to accurately reflect the
state of the corresponding monitored/controlled objects in the
environment
  Performance Goals 14
 Specialized into time and space performance
 It also includes the time and throughput goals
 Security Goals
 Specialized into confidentiality, integrity and availability goals
 Soft and Hard Goals
 The goals whose satisfaction can not be established in a clear cut
sense are soft goals.
 Soft goals are specially useful for comparing alternative goal
refinement and choosing best to them.
 Hard goals are those whose satisfaction can be established through
some verification techniques
 Temporal Behavior Goals 15

 Achieve Goals
 Goals generate system behavior
 Require some target property to be satisfied in some future
state
 Maintain Goals
 It has some restrict behaviors
 Require some target property to be permanently satisfied in
every future state.
 Optimize Goals
 Compare behavior to favor those which better ensure some
soft target property
Goal are modelled by 16

 Types
 Functional/Non-Functional

 Attributes
 Name

 Links
 Inter Goal Links
 Links between goals and other items
Goal Attributes 17

 Goals can be intrinsically characterized by attributes

such as Names and their specification.
 Priority is another important attribute
 Priorities are often used to resolved conflict among
goals.
 Qualitative values for an attribute allow mandatory or
optional goals to be modelled with various degrees of
optionality.
Goal Links 18

Links form the basis for defining goal structures

 Links of goals with each other (inter-goal link)
 Are aimed at capturing situations where goals
positively or negatively support other goals
 Links with other elements of requirements model
(agents, scenarios, operations)
19