ITEC 4040

Lecture
Click to edit Master 6 –styles
text Solution-Oriented Requirements, Requirements
Modelling, NFR Modelling
Second level
Third level
Fourth level
Fifth level

*Based on presentations by Luiz Marcio Cysneiros

1
 Solution-Oriented Requirements

• Solution-oriented requirements define the properties and features to be fulfilled

by the system

• Contrasted to goals and scenarios

• Solution-oriented requirements should document a single, consolidated view and

be conflict free

• Solution-oriented requirements should be defined in a way that facilities the

development of the system

2
 Three Perspectives of Solution-Oriented Requirements

• Data perspective:
• Focuses on defining the data/information to be managed by the software system
• Static aspects of data are considered and defined
• Entities
• Relationships
• Attributes
• The manipulation of the data (dynamic aspects) are not considered in this perspective
• Defines the requirements for the data and data structures of the system
• Entity Relationship Diagrams
• Domain Class Diagrams
• Etc…
• “What is the system concerned with?”

3
 Three Perspectives of Solution-Oriented Requirements

• Functional perspective:
• Defines the processes to be provided by the system
• The manipulation of the data in each process and the input-output relationships
• The information flows among the processes
• Processes and their interactions between the processes as well as the data stores from
the data perspective may need to be defined
• E.g. Data flow diagrams, Sequence Diagrams
• “What will the system do?”

4
 Three Perspectives of Solution-Oriented Requirements

• Behavioral perspective:
• Defines the overall behaviour of the system
• Define the external stimuli that the system receives and the reactions of the system as
well as the relationship between stimuli and reactions
• Define the possible states or modes in which the system can be
• Define the allowed transitions between states or modes as reactions to stimuli
• E.g. statecharts / state machine diagrams, sequence diagrams
• “How will the system do it?”

5
 Three Perspectives of Solution-Oriented Requirements

• Each of these 3 perspectives represents a specific view on the software solution

• These 3 perspectives are interrelated

• Specification of the data of the system exists and is important in both the data and
functional perspectives
• Specification of the system functions exists and is important in both the functional and
behavioural perspectives
• Overlap in representation of information leads to the need to keep information and the
representation of information consistent

• Over the course of software history, modelling languages have been developed to support
the documentation of requirements within each perspective

6
 Documenting Solution-Oriented Requirements Using
Natural Language
• When natural language is used to document requirements, the three perspectives of data,
function, and behaviour often are intermingled

• E.g.
• R1: If a glass break detector attached to the entrance door detects that the entrance door has been
damaged, the system shall enter the alarm state and inform the security company

• Data aspects: ________

• Functional aspects: ________

• Behavioural aspects:________

7
 Documenting Solution-Oriented Requirements Using
Natural Language
• When natural language is used to document requirements, the three perspectives of data,
function, and behaviour often are intermingled

• E.g.
• R1: If a glass break detector attached to the entrance door detects that the entrance door has been
damaged, the system shall enter the alarm state and inform the security company

• Data aspects: glass break detector attached to the entrance door

• Functional aspects: inform the security company

• Behavioural aspects: enter the alarm state

8
 Documenting Solution-Oriented Requirements Using
Models
• The utilization of models allows a dedicated modelling language to be used for each
perspective

• Allows a clear separation of concerns

• Allows for the definition of essential concepts for each respective perspective

• Supports stakeholders in focusing on a specific perspective when documenting solution-

oriented requirements

• The intermingling of the three perspectives is controlled and purposeful

9
 Models – Physical vs Conceptual

• Physical models are commonly used in traditional engineering disciplines

• In software engineering, since software is abstract, we utilize symbolic models

(conceptual models)

• Conceptual models support communication between different stakeholders and

are far easier to comprehend than natural language documentation of the same
information

10
 Models – Relation to the Universe of Discourse

• Universe of discourse:
• Comprises any part or aspect of the existing or conceived reality under consideration

• Model:
• An abstract representation of the universe of discourse created for a specific purpose

11
 General Modelling: Description

• A model is an abstraction of reality emphasizing specific characteristics

• One single model is not enough to represent all the characteristics a system must
have

• Models can be:

• Graphical
• Descriptive
• Mathematical

12
 General Modelling: Benefits

• Can represent a viewpoint of the environment before a system is implemented

• Can show alternative solutions

• Show future needs

• Represent parts of a system

• Useful for organizing information and to specify requirements and to

communicate requirements

• Models can guide elicitation

• Help to find new questions
• Used to be considered an elicitation technique, not anymore

13
 Models – Descriptive vs Prescriptive

• Descriptive
• Different than the usage of “descriptive” in terms of descriptive vs graphical
• Descriptive models document information about the current state of the universe of
discourse

• Prescriptive models represent an intended, future state of the universe of discourse

• Desired-state models are prescriptive models

14
 Models – Descriptive vs Prescriptive: Properties

• Central properties of both descriptive and prescriptive models:

• Reduction: A conceptual model reduces the information documented about the
universe of discourse
• Extension: A conceptual model extends the information documented about the
universe of discourse by defining additional properties which are not observable in the
universe of discourse

15
 General Modelling – Level of Abstraction

• Allow us to incrementally deal with complexity

• Provide information about the scope and complexity of a problem

• Allow us to communicate with different stakeholders

• Models have their own phenomena

• Models have their own relationships among those phenomena

• A model is only useful if the model’s phenomena correspond in a systematic way

to the phenomena of the domain being modelled

16
 General Theory of Systems

• Every system is a sub-system that is part of a larger system

• Interconnected parts aiming at a common goal

• Hierarchical in a tree structure

• Divide and Conquer

• Partition problems into less complex problems

• No matter where you look you can almost always divide any system into at least 2
subsystems

• Systems almost never operate alone

• Models can represent systems, subsystems, parts of subsystems, processes,

organizational groupings, etc…

17
 The Model vs. The Domain

• There will always be:

• Phenomena in the model that are not present in the application domain
• Phenomena in the application domain that are not in the model

18
 The Model vs. The Domain

• A model is never perfect

• “If the map and the terrain disagree, believe the terrain”
• Perfecting the model is not always a good use of your time

19
 The Model vs. The Domain: Suppressing Irrelevant Details

• A model typically represents only part of the information about the universe of discourse
through abstraction mechanisms.

• Abstraction Mechanisms:
• Selection: abstraction mechanism whereby particular aspects of the universe of
discourse which are selected to be represented in the conceptual model
• Ignores other aspects completely
• i.e. the model does not contain any information about the neglected aspects
• Aggregation: abstraction mechanism that combines different aspects in the universe of
discourse and represents the aggregated aspect in a condensed form in the model
• Classification/generalization: abstraction mechanism that identifies commonalities and
suppresses differences between a set of aspects in the universe of discourse. The
commonalities are then represented as generalized information in the model

20
 Models – Level of Formality

• Formalism seeks to minimize:

• Ambiguity
• Inconsistency
• Omission

• Aim for unique and well-defined interpretations

• Natural Language (Informal)

• Extremely expressive and flexible
• Good for elicitation
• Not good for modelling
• Useful for annotating models for readability
• Easy to understand and to communicate with stakeholders
• Poor at capturing key relationships
• Ambiguity is a big problem

21
 Models – Level of Formality

• Semi-Formal notation
• Captures structure and some semantics
• Can perform reasoning, consistency checking, etc…
• Examples:
• Diagrams, tables, Structured English (Pseudocode)
• Mostly visual – for rapid communication with a variety of stakeholders

22
 Models – Level of Formality

• Formal notation
• Precise semantics, model checking and extensive reasoning possible
• Underlying mathematical model (e.g., set theory, Finite State Machines, Petri
Nets, etc.)
• Very detailed models (may be more detailed than we need)
• RE formalisms are for conceptual modeling, hence differ from most computer
science formalisms
• Sometimes, formal problems are particularly hard to understand
•  e  exemplar  ( b  library  belongs(b.code,e.n_item))
• For a given exemplar e in some collection, there exists a library b such that the
code of b is an item of the exemplar e.
• Certain elements from the library are contained within the exemplar’s items
• These elements include code and item
• You will see formal notation most commonly as constraints within models

23
 Common Formal Notation Examples

• Exact meanings may differ depending on language

• = is equivalent to
• x=y
• x is equivalent to y

• + and, composition of data elements

• x+y
• x and y (mandatory composition)

• | or
• x|y
• x or y (either-or)

• { … } iterations of
• x{…}y
• x to y repetitions of the element (x and y upper/lower bounds are optional)
• x = 1{a}3
• x is equivalent to one to three repetitions of a

24
 Common Formal Notation Examples

• Exact meanings may differ depending on language

• […|…|…] choice of one of several possibilities within a set

• x = a + [b | c]
• x is equivalent to the composition of a and either c or b

• (…) optional
• Zero or one iterations of the element …
• x = a + b + (c)
• x is equivalent to the composition of a and either c or b

• “ “ primitive data element

• Element not defined in terms of other data elements, taken literally
• x = “0” | “1”
• x is equivalent to either the character “0” or “1”

• *…* comment
• Textual explanation of a data element

25
 Modeling Techniques
• Modeling Enterprises
• Goals & objectives
• Organizational structure
• Tasks & dependencies
• Agents, roles, intentionality

• Modeling Information & Behaviour

• Information Structure (ERD, Class diagrams)
• Behavioural views (state machines, sequence
diagrams)
• Scenarios and Use Cases
• Information flow (DFDs)
• Process flow (BPMN, activity diagrams)
• Timing/Sequencing requirements

• Modelling System Qualities (NFRs)

• All the ‘ilities’:
• Usability, reliability, evolvability, safety,
security, performance, interoperability,
26
 Modeling Principles
• Facilitate Modification and Reuse
• Experienced analysts reuse their past experience
• They reuse components (of the models they have built in the past)
• They reuse structure (of the models they have built in the past)
• Smart analysts plan for the future
• They create components in their models that might be reusable
• They structure their models to make them easy to modify

• Helpful ideas:
• Abstraction
• Strip away detail to concentrate on the important things
• Decomposition (Partitioning)
• Partition a problem into independent pieces, to study separately
• Viewpoints (Projection)
• Separate different concerns (views) and describe them separately
• Modularization
• Choose structures that are stable over time, to localize change
• Patterns
• Structure of a model that is known to occur in many different applications
27
 Decomposition / Partitioning
• Partitioning
• Captures aggregation/part-of relationship
• Every sub-problem is at the same level of detail
• Every sub-problem can be solved independently
• Solutions for each sub-problem can be combined to solve the original
problem
• Advantages
• Different people can work on different sub-problems
• Facilitates parallelism
• Maintenance gets easier
• Disadvantages
• Solutions for sub-problems may not be easy to combine
• Real world structure is not hierarchical
• Choosing a partitioning is a risk
• Sometimes decisions are made too early – lack of problem
understanding
28
 Decomposition / Partitioning

• Example:
• Goal is to develop a spacecraft
• Partition the problem into parts:
• Guidance and navigation | Data handling | Command and control |
Environmental control | Instrumentation | Etc.
• Note: this is not a design, it is a problem decomposition
• Actual design might have any number of components, with no relation
to these sub-problems
• However, the choice of problem decomposition will probably be reflected in
the design

29
 Abstraction (again)
• Abstraction
• A way of finding similarities between concepts by ignoring some details
• Simplifies many types of analysis
• Allows different entities to be treated the same
• Focuses on the general/specific relationship between phenomena
• Classification groups entities with a similar role as members of a single class
• Generalization expresses similarities between different classes in an IS-A
association
• Example:
• Requirement is to handle faults on the spacecraft
• Might group different faults into fault classes
• Option 1: Based on location – instrumentation fault, communication fault,
processor fault, etc.
• Option 2: Based on symptoms – no response from device, incorrect
response, self-test failure, etc.

30
 Modelling Philosophies

• Systems

• Entities and Processes

• Objects

• Data

• Agents

• Goals

31
 Why do we model?

• To show different levels of detail

• To focus on different things
• Data vs processing
• To help clarify and refine the design
• Developing models raises questions that need to be considered
• To simplify complex aspects of systems
• Depending on the intended viewer
• To learn from the modelling process
• New questions arise that need to be answered to complete the model
• To reduce complexity by abstraction
• Systems can be complex and intangible
• Help focus on important aspects
• To remember all of the details
• Models are a way of storing information for later use in a form that can be
digested

32
 Why do we model?

• Communication!
• To communicate with other development team members
• Show others aspects of the system in a succinct way
• Someone working on IO can use a model to communicate with
someone working on processing details
• To communicate with various stakeholders
• Users need to see clear and complete models to understand what the
analyst is proposing
• Users often work with the analyst to create models (this process can
help users better understand what the system can do)

33
 Why do we model?

• Documentation!
• To document what was done for future maintenance or enhancement
• To package everything in a form that future developers can understand the
system
• So that they can modify or update the system

34
 Semiotics of Conceptual Models

• Semiotics is a sub-discipline of language

theory

• Deals with the representation of information

by means of symbols at the language level

• The semiotic triangle illustrates and defines

the relationship between the symbols of a
language and their meaning in the universe of
discourse

• Referent: the existing or conceived object in

the universe of discourse that is referenced by
a symbol of the language

• Symbol: a symbol is an atomic construct of the

language. Symbols represent information
about the universe of discourse

• Reference: the reference is the image

(thought) a person has in mind about the
referent or symbol

35
 3 Levels of Semiotics

• Syntax: defines the atomic language constructs and the valid combinations of these
constructs

• Semantics: defines the meaning of the language constructs

• Semantics are typically based on the defined syntactic rules

• Pragmatics: deals with effects that the interpretation of the representation has on the
behaviour of the interpreting actor
• E.g. the reaction of the driver caused by perceiving and interpreting a stop sign

36
 Modelling Quality

• Quality is assessed with respect to the three levels of semiotics

• Syntactic quality
• Semantic quality
• Pragmatic quality

37
 Syntactic quality

• “Quality of the form”

• A measure of compliance with the syntactic rules defined for the modelling language

• E.g. poor quality: utilizing the wrong arrowheads in UML diagrams

38
 Semantic Quality

• “Quality of the meaning”

• The extent to which the information documented in the conceptual model corresponds to
the aspects that exist in the universe of discourse

• 2 aspects:

• Validity of the model: measure of the extent to which the information documented in the
model exists in the universe of discourse

• Completeness of the model: measure of the extent to which the relevant aspects of the
universe of discourse are contained in the model

• E.g. poor quality: utilizing <<includes>> relationship when the universe of discourse should
actually be represented by an <<extends>> relationship

39
 Pragmatic Quality

• “Quality of usage”

• Describes the degree to which the model is suitable for its purpose

• How well the representation of information of the universe of discourse in the model is
suited for the specific use

• Thus, to determine the pragmatic quality, it is necessary to determine the desired use of the
considered model

• E.g. poor quality: utilizing a state machine diagram (even a syntactically and semantically
correct one) to illustrate the static structure of a system to a stakeholder (state machine
diagrams contain few static aspects)

40
 Interrelations between Quality

• Syntactic errors often impair the semantic quality of a model

• since incorrect syntax frequently goes along with incorrect representation of aspects of
the UoD in the conceptual model

• Semantic errors often impair the pragmatic quality of a model

• Since semantic errors convey invalid or incomplete information about the UoD
• Models that are invalid or incomplete are often also not suitable for its purpose

• Syntactic errors can impair the pragmatic quality of a model

• Models that contain syntactic errors are incomprehensible
• This reduces the pragmatic quality because people cannot interpret the model
correctly

41
 Modelling Languages

• Modelling languages define syntax and semantics

• Syntax defines the permissible atomic symbols (modelling constructs) and the rules for
combining the symbols into language expressions

• Semantics defines the meaning of each individual symbol and the permissible combinations
of symbols

42
 Modelling Languages: Abstract Syntax

• Abstract syntax defines the abstract language constructs of the modelling language and
their permissible combinations without prescribing a specific notation for the constructs

• Concrete syntax establishes a relationship between the language constructs defined by the
abstract syntax and concrete representations of these constructs

43
 Metamodels

• Models that describe models

• Highest Level of Abstraction

44
 Rules for Stopping Decomposition

• When each process has been reduced to a single decision, calculation or database operation

• When each data store represents data about a single entity

• When the system user does not care to see any more detail

• When every data flow does not need to be split further to show that data are handled in
various ways

• When you believe that you have shown each business form or transaction, online display
and report as a single data flow

• When you believe that there is a separate process for each choice on all lowest-level menu
options

45
 Interrelation of Model-Based and Textual Requirements

• Requirements artefacts can be documented using natural language or a conceptual

modelling language

• Requirements models are conceptual models that document requirements using a

conceptual modelling language

• The stakeholders who create a requirements model must know the modelling language in
order to document the respective requirements correctly

• The stakeholders who interpret a requirements model must be familiar with the modelling
language in order to interpret the model correctly

46
 Interrelation of Model-Based and Textual Requirements

• Requirements are documented predominantly using natural language

• Using natural language has disadvantages and advantages

• The disadvantages can be minimized by simply utilizing multiple formats for documenting
requirements

• Conceptual models can be used to visualize the relationships between textual requirements
or to provide a more abstract view of the textual specifications

• Models can also be used to detail requirements documented in natural language

47
 Interrelation of Model-Based and Textual Requirements

48
 Use Cases

• Use case— an activity that the system performs, usually in response to a request
by a user

• Use cases define functional requirements

• Analysts decompose the system into a set of use cases (functional decomposition)

• Two techniques for Identifying use cases

• User goal technique
• Event decomposition technique

• Name each use case using Verb-Noun

• Ie: Produce Report

49
 Use Case Diagrams

• Use case diagram— a UML model used to graphically show uses cases and their relationships
to actors

• Recall UML is Unified Modeling Language, the standard for diagrams and terminology for
developing information systems

• Actor is the UML name for a end user

• Automation boundary— the boundary between the computerized portion of the application
and the users who operate the application

• Primarily used to show the functional perspective

50
 Use Case Diagrams

51
 Use Case Diagrams – Relationships: <<includes>>

• A relationship between use cases where one use case is

stereotypically included within the other use case— like a called
subroutine. Arrow points to subroutine

• The behaviour of the included Use Case is inserted into the

behaviour of the including Use Case

52
 Use Case Diagrams – Relationships: <<extends>>

• An extending use case defines, possibly conditionally, behaviour

that can be inserted into the behaviour of the extended Use Case

53
 Class Diagrams

• Key components:
• Classes represented as rectangles divided into 3 sections
• Classname, stereotype, sometimes Object name
• Attributes
• Methods
• Relationships
• Association
• Inheritance (Generalization/Specialization)
• Aggregation
• Composition
• Relationship cardinality/multiplicity
• Relationship message direction

• Well rounded, good at showing the data and to a lesser extent functional perspectives. Not
well suited for behavioural perspective

54
 Design Class Notation
• Sale superclass with subclasses
• Note the generalization/specialization relationships (inheritance)

55
 Design Class Stereotypes
• Stereotype: a categorization of a model element as a certain type
• Notation: <<stereotype>>
• 4 standard stereotypes:
• Entity class
• Describes something users deal with
• Objects of entity classes usually need to be remembered
• Thus are usually persistent classes
• A persistent class has objects that continue to exist after the
program quits
• Boundary class aka View class
• Exists on a system’s automation boundary
• Usually user interfaces
• Can be system interfaces
• Controller class
• Mediates between boundary classes and entity classes
• Usually acts as a switchboard or implements complex business
logic
• Data access class
• Retrieves and sends data to a database

56
• Usually handles SQL queries
 Design Class Notation
• Visibility: whether other objects can directly access that attribute
• Visible = public = +
• Invisible = private = -
• Data type: data types (can be programming-language specific or not) that the attribute needs to
be stored as (e.g. char, bool, date, string, float, etc…)
• Property: usually key (for primary key)
• Primary key: for good database design, such as normalization. Denotes a unique identifier
of an object
• Parameter: commonly called argument in programing languages, the input data for a method
• Return-type: the data type that the method outputs

57
 State Machine Diagrams AKA Statecharts

• State Machine Diagram – a diagram which shows the life of an object in states and
transitions

• Origin state – the original state of an object before it begins a transition

• Destination state – the state to which an object moves after completing a transition

• pseudostate – the starting point in a state machine diagram. Noted by a black circle.

• Conditional Transitions:
• action-expression – some activity that must be completed as part of a transition
• guard-condition – a true/false test to see whether a transition can fire

58
 State Machine Diagrams

• Example: Printer

• Transition Statements
• Formal
• Transition-name (parameters) [guard-condition] / action-expression

59
 State Machine Diagrams: Concurrency

• Statecharts are well suited for the behavioural perspective

• Concurrent states – when an object is in one or more states at the same time

• Path – a sequential set of connected states and transitions

• Concurrent paths – when multiple paths are being followed concurrently, i.e. when one or
more states in one path are parallel to states in another path

60
 State Machine Diagrams: Concurrency

• Concurrent paths often shown by synchronization bars (same as Activity

Diagram)

• Multiple exits from a state is an “OR” condition.

• Multiple exits from a synchronization bar is an “AND” condition.

61
 Statechart Example 2

62
 Statechart Example 3

63
 Data Flow Diagrams

• Popular representation of functional models

• Depicts processes (functions), the flow of data through these processes, and the sources and
endpoints of this data

• Process: represents a task or activity that the system shall provide or implement
• A process consumes some input data, processes the data, and passes on the result to another
process
• Represented with circles/ovals/rounded rectangles

• Source/Sink: represents external objects that communicate with the system through data
flows
• Represented with squares/rectangles
• Sources and sinks are outside the system boundary

• Data store: defines a repository of data

• Internal objects
• Persistently record data in the system
• Processes likely use this data for their purpose
• Represented with rectangles with a line on the left side
64
 Data Flow Diagrams

65
 Data Flow Diagrams vs Flowcharts

• A DFD may look like a flowchart but it is not

• DFDs do show the flow of data through a system, but flowcharts show the flow of control

• A process on a DFD can have dramatically different timing (e.g. hourly vs weekly vs on-
demand)

• Processes on flowcharts have consistent timing and order

• Process on flowcharts execute one at a time, processes on DFDs can operate in parallel

66
 Levels of Abstraction and Process Decomposition

• Processes can be abstracted or decomposed

67
 DFD Levels and Levels of Abstraction

• DFDs are often decomposed into additional diagrams to provide multiple levels of detail
• They numerically increment up to infinity

• Higher-level diagrams provide general views of the system

• Higher-level DFDs have a lower “Level” number (starting from zero)

• Lower-level diagrams provide detailed view of the system

• A context diagram is a special level of DFD

• It is the highest level of abstraction (higher than Level 0)
• A context diagram specifically shows the entire system represented as a single process,
rather than any amount of process decomposition
• Its purpose is to only show the flow of data in and out of the system boundary, without
showing any detail inside the system boundary

68
 DFD Levels and Levels of Abstraction

69
 DFD Levels and Levels of Abstraction: Context Diagram

70
 DFD Levels and Levels of Abstraction: Level 0

71
 DFD Levels and Levels of Abstraction: Level 1

72
 DFD Levels and Levels of Abstraction: Level 2

73
 Sequence Diagram
• Emphasizes the sequence (time) of messages sent between objects for a
specific use case
• Can have loop frames, alt frames, and opt frames
• Can have repeating inputs and outputs
• Lifelines show the passage of time
• Activation lifelines show the period during which a method of an object is alive
and executing
• Well-suited for the behavioural perspective

74
 Synchronous vs Asynchronous Messages
• Synchronous Message AKA Synchronous Call
• Filled Arrow Head
• Message is sent from source lifeline to target lifeline
• Source lifeline is blocked from other operations until it receives a response from the
target lifeline
• Must have a reply message
• Asynchronous Message AKA Asynchronous Call
• Open or Flat Arrowhead
• Does not necessarily need a reply message
• Does not block operations
• Used for responses that are neither time sensitive nor order sensitive

75
 System Sequence Diagram

• A special case of sequence diagram that:

• Only shows actors and the system (represented as a single object)
• Note: the system would never be represented as an object on a Class Diagram
• Shows input and output message requirements for a use case

76
 System Sequence Diagram
• Loops:
• Detailed Notation (loop frame) vs Alternate Notation

77
 System Sequence Diagram
• Opt Frames (Optional)

• Alt Frames (if/else)

78
 (Design) Sequence Diagram

79
 (Design) Sequence Diagram

80
 Interdependencies between FRs and NFRs

• Interdependencies between NFRs and FRs are “standard” on an SRS

• FR: The system must provide a data entry interface to input the results of tests into a
patient’s report.

• Associated with this FR, one may find the following Security NFR:

• NFR: “Depending on the result of a test, only the supervisor will be allowed to input
this value into the patient’s report”.
• And then this could be further elaborated based on “result of a test”

• Notice this NFR is conditional and “real-time”, as opposed to a flat security

requirement.

81
 Interdependencies between NFRs and NFRs

• Commonly, one NFR has different solutions that impact other NFRs.

• A classical situation is security, which usually impacts performance and usability.

82
 Interdependencies between NFRs and NFRs

• Interdependencies between NFRs and NFRs on an SRS must be identified and deal
with.

• For Example:

• A clinical analysis lab system has the following FR:

• The system must have a file containing all past and current clients to be used
by the Marketing Division.

• An NFR is linked to this FR:

• This file must be complete enough to allow the Marketing Division to
prospect new clients.

• But an NFR associated with the Client’s attendance states:

• The patient admission process must last less than 4 minutes.
• Traceability: (Reasoning) Fear, people just go home.

83
 Elicitation vs Modeling NFRs

• Traditional models, even UML models, do not reflect NFRs very well.

• Integrating NFRs into data models can help to get software deployed faster and
with lower development costs.

84
 Effective NFR Elicitation and Modeling

• Two-Part approach to effective NFR Elicitation and Modeling:

• First:

• Heuristics to elicit NFRs and a systematic way to search for NFR

interdependencies.
• Language Extended Lexicon (LEL)
• Softgoal Interdependency Graphs

• Second:

• Heuristics to integrate NFRs into conceptual models.

• LEL can be used as an anchor to build the functional model
• Various UML diagrams can be extended to deal with NFRs

85
 Functional View vs Non-Functional View
• Both views are anchored in the use of the LEL.

• NFR Graphs are an artifact that is part of the Non-Functional View.

• NFR Graphs can help produce use cases, which can then be used to develop all
other UML diagrams.

86
 Extending Functional View Models

• Models that represent the functional viewpoint can be extended to model NFRs
as well

• Doing this requires operationalizations from Non-Functional View analysis

87
 Language Extended Lexicon (LEL)
• Technically a descriptive model, but much more of a tool

• Aims to register the vocabulary used in the UofD

• Relies on the identification of words, phrases, or

sentences that are peculiar to the social environment
under study.

• Identification can result from any elicitation technique.

• Based on a system of Symbols composed of Notions and

Behavioural Responses

• Notions: specify the meaning of a symbol (denotation)

• Behavioural Responses: register the results driven from

utilization of the symbol (connotation)

• A good technique to model tacit knowledge that has

been elicited
88
• Can also contain scenarios
 Language Extended Lexicon (LEL)
• LEL construction sticks to two principles:
• Minimum vocabulary principle:
• Refers to the sole use of frequent words with clear meaning that are
part of a restricted vocabulary.
• The usage of restricted language, generally structured English,
minimizes ambiguity.
• Natural Language can be ambiguous, formality helps combat this.
• Circularity principle:
• Refers to the use of symbols from the language to describe notions and
behavioural responses.
• Stems from studies that show that while explaining a symbol, actors use
symbols from their own (possibly domain-specific) language.
• Whenever possible, use existing symbols to define new symbols.

• Important: LEL contains symbols not functions

89
 LEL Example for a Library
• Symbol: Renew Book

• Notions:
• Book exemplar is lent to a library user
• Library user wants to keep the book exemplar longer.

• Behavioural Responses:
• Library Employee changes return date for the book exemplar

• Note: the underlined words are more symbols in the LEL and demonstrate the
circularity principle at work

90
 LEL Example for a Library
• Symbol: Return Date

• Notions:
• Established date to return book

• Behavioural Responses:
• If return date is prior to current date, the book exemplar is overdue

91
 LEL Example for a clinical analysis lab system

92
 LEL Symbol Categories

Notion Behavioral Responses

Subject Who is the subject What actions are executed
Verb Who does *, when it happens What are the consequences in the
and what procedures are environment (other actions that might
involved take place) and what are the new states
Object Define the object and identify Actions that can be applied to the object
other objects that may have
any relationship with this one
State What does it mean and which Identify other states and actions that
actions led to this may happen other caused by a state
transition

93
 NFR Framework

• Focuses on defining the quality attributes and constraints of a system

• Defines guidelines for modelling NFRs in a concise and effective manner

• Focuses on Softgoals and Operationalizations

• Softgoals and Operationalizations have relationships

• These relationships aid in their satisfaction or denial

94
 NFR Framework Example: Safety (of a clinical lab)

95
 Softgoal Interdependency Graphs

• NFR Framework Graphs focus on how to satisfy a particular NFR (a softgoal)

• Can be decomposed into subgoals
• Subgoals can be operationalizations

• Softgoal Interdepency Graphs focus on how softgoals and subgoals influence

each other
• Ie. The interdependencies
• But also show operationalizations

• Can help with identifying NFRs, identifying fit criteria, proxies, etc…

• SIGs are usually organized into SIG catalogues to provide possible alternatives to
solve or satisfy a particular NFR

• Since we want as many alternatives as possible, catalogues strive to be as

complete as possible

96
 SIG Catalogues

• A collection of SIGs, that may represent many NFRs, to provide as comprehensively as

possible as many alternatives as possible.

• Generally are focused on a single NFR, and all NFRs that may influence it.

• Abstraction facilitates readability and understandability (of the SIG catalogue).

• Readability and understandability benefits the usability of SIGs.

• (The SIG legend has changed from previous examples simply because it is slightly more
modernized)

97
 Case Study: Trust Catalogue

• SIG Catalogues generally have a high-level or multiple higher-level views that can be
decomposed into lower-level views

• Level of abstraction plays the same role as UML diagrams

• Trust is affected by Corporate Social Responsibility, Reputation, Internal Trust, Ethics,

Transparency

98
 Case Study: Trust Catalogue (CSR)

• Broad (higher-level) softgoals are represented as their own SIG

99
 Case Study: Trust Catalogue (Reputation)

100
 Case Study: Trust Catalogue (Internal Trust)

101
 Case Study: Trust Catalogue (Ethics)

102
 Case Study: Trust Catalogue (Transparency)

103
 The Integration Method: Integrating NFRs into Use Cases

104
 The Integration Method: Integration into Use Cases

105
 The Integration Method: Integration into Use Cases

106
 Extending Use Cases

• Clinical Lab example:

107
 Case Study – Clinical Lab (Processing Results)
• Resulting Use Case Diagram after integrating Security:

108
 Case Study – Clinical Lab (Processing Results)
• Integrating Reliability and Correctness

109
 Extending Classes

110
 Extending Classes

• If special conditions on a method impose a significant loss of space, they may be

represented inside a UML note

111
 Case Study – Clinical Lab (Processing Results)
• Integrating Traceability:

• When analyzing the Class Diagram, it is insufficient to represent the needed amount of Traceability

• New Class added: Log of Inspection

112
 Case Study – Clinical Lab (Processing Results)
• Integrating Reliability and Time Restrictions:
• The Medical Bureau needs to electronically sign patient reports before patient reports can be given to patients.

113
 Case Study – Clinical Lab (Processing Results)
• Design Sequence Diagram for Review Patient Report (before adding NFRs)

114
 Case Study – Clinical Lab (Processing Results)
• Design Sequence Diagram for Review Patient Report (after adding NFRs)

115