Lecture
Download
1 / 48

Lecture 06 - PowerPoint PPT Presentation


  • 113 Views
  • Uploaded on

Lecture 06. ITEC 4040 – Requirements Management Prof. Dawid Kasperowicz http://www.yorku.ca/dkasper. Non-Functional Requirements and Elicitation. Integrating NFRs into data models can help get systems developed faster and with lower development costs [ Cysneiros ‘99]

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Lecture 06' - feivel


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Lecture 06

Lecture 06

ITEC 4040 – Requirements Management

Prof. DawidKasperowicz

http://www.yorku.ca/dkasper


Lecture 06

Non-Functional Requirements and Elicitation

  • Integrating NFRs into data models can help get systems developed faster and with lower development costs [Cysneiros ‘99]

  • A new strategy to deal with NFR starting at the early stages of system development was created

  • The first part presents some heuristics to elicit NFRs and a systematic way to search for interdependencies

    • Using the LEL as an anchor for the definition of the non-functional model

  • The second part presents some heuristics to integrate NFRs into conceptual models

    • Using the LEL as an anchor to build functional models

    • Extending the scenario model, the class, sequence and collaboration diagrams to deal with NFRs

ITEC 4040 – Requirements Management


Lecture 06

The Proposed Strategy

  • Introduce

    • New actors to use cases

    • New episodes, resources and actors to scenarios

    • New classes, operations and attributes to class diagrams

    • New classes and messages to collaboration diagrams

    • Non-functional view and NFR graphs

ITEC 4040 – Requirements Management


Lecture 06

The Proposed Strategy

ITEC 4040 – Requirements Management


Lecture 06

Building the Non-Functional View

  • Introduce NFRs in the LEL

    • New notations

    • New behavioural responses

    • New symbols

  • Represent NFRs using NFR graphs

  • Identify and solve conflicts

  • Update LEL and NFR graphs with conflict resolutions

ITEC 4040 – Requirements Management


Lecture 06

Building the Non-Functional View

ITEC 4040 – Requirements Management


Lecture 06

NFR Taxonomy

  • A NFR can be classifed as:

  • Dynamic NFR

    • Deal with abstract concepts and frequently demand an action to be made

  • Static NFR

    • Demands some information to be used, usually in a persistent way

ITEC 4040 – Requirements Management


Lecture 06

Language Extended Lexicon (LEL)

  • Aims to register the vocabulary used in the UofD

  • It is based on a system of system of symbols composed of Notions and Behavioural Responses

  • Notions specify the meaning of the symbol (denotation)

  • Behavioural Responses register the results driven from the symbol utilization (condition)

  • Its construction is based on the minimum vocabulary and circularity principles

ITEC 4040 – Requirements Management


Lecture 06

LELPropsed Extension

  • We now register Primary NFRs in the notion of the symbols

  • We register the fact that a notion or a behavioural response is stated for satisfying an NFR from another symbol (eventually from the same symbol)

  • We can now show what notions and behavioural responses are necessary to satisfy an NFR

ITEC 4040 – Requirements Management


Lecture 06

Building the Non-Functional View

ITEC 4040 – Requirements Management


Lecture 06

Add NFRs to the LEL

  • To each symbol of the LEL:

    • Check of any NRF may be necessary in this symbol. The Knowledge Base may be used to help it

    • If it is true, represent it in the Notion

    • Evaluate the possible consequences in this symbol and in other symbols due to NFR satisfaction

    • Establish a dependency link between these notions and behavioural responses to this NFR

ITEC 4040 – Requirements Management


Lecture 06

Add NFRs to the LEL - Example

What NFR is Needed ?

ITEC 4040 – Requirements Management


Lecture 06

Add NFRs to the LEL - Example

ITEC 4040 – Requirements Management


Lecture 06

Building the Non-Functional View

ITEC 4040 – Requirements Management


Lecture 06

Represent NFR

  • NFRs are represented using a graph structure very similar to the and/or trees used in problem solving

  • NFR are faced as soft goals that might be decomposed into more redefined sub-goals until we get the sub-goals that will represent how this NFR will be operationalized (its operationalization's)

  • One system can have (usually does) multiple graphs

  • NFRs are rarely 100% satisfied, and usually only satisficed

  • Some proposed extensions

    • Always use a symbol of the LEL to represent a NFR topic

    • Actors responsible for the knowledge represented in the graph should be above the graph

    • Introduce the concept of dynamic and static operationalization's

ITEC 4040 – Requirements Management


Lecture 06

Represent NFR - Example

ITEC 4040 – Requirements Management


Lecture 06

Represent NFR – How to Create a Graph

Safety [Room]

ITEC 4040 – Requirements Management


Lecture 06

Represent NFR – How to Create a Graph

First Decomposition

ITEC 4040 – Requirements Management


Lecture 06

Represent NFR – How to Create a Graph

Second Decomposition

ITEC 4040 – Requirements Management


Lecture 06

Represent NFR – How to Create a Graph

Final Version

ITEC 4040 – Requirements Management


Lecture 06

Building the Non-Functional View

ITEC 4040 – Requirements Management


Lecture 06

Identify and Solve Conflicts

  • Compare graphs with the same type (e.g.: Performance)

  • Using the knowledge base and any other applicable sources, compare graphs with conflicting types (e.g.: security and performance or usability)

  • Pair wise graphs

  • For each of the above heuristics:

  • Register positive and negative interdependencies

  • Try to solve possible conflicts (negative interdependencies)

ITEC 4040 – Requirements Management


Lecture 06

Identify and Solve Conflicts - Example

ITEC 4040 – Requirements Management


Lecture 06

Extending Use Cases

  • Because of NFR satisfaction, every use case or actor included must be followed by an expression using the pattern: {NFR_Type[NFR_topic]}

  • Represent special conditions that must prevail to a use case as a note linked to the use case.

    • E.g.: In a clinical lab system

      • Before accepting a test result, the system must:

        • Check if the employee works for the sector performing the test

        • Check if the inputted result is within a safe range

ITEC 4040 – Requirements Management


Lecture 06

Extending Use Cases - Example

ITEC 4040 – Requirements Management


Lecture 06

Extending Scenarios

  • Every change in a scenario due to an NFR satisficing must be followed by the expression: Constraint: {NFR[Topic]}

  • Reason: Traceability between models

ITEC 4040 – Requirements Management


Lecture 06

Extending Class Diagram

  • Every class will be named using a symbol of the LEL

  • Classes created due to a NFR satisficing will be followed by the same traceability pattern used in scenarios

StatusLine

{Usability[Room Control Panel]}

Place : Integer

CLG1 : Boolean

CLG2 : Boolean

SetCLGOn

(Number)

{Usability

[Room Control Panel]}

SetCLGOff

(Number)

{Usability

[Room Control Panel]}

ITEC 4040 – Requirements Management


Lecture 06

Extending Class Diagram

  • Operations that are in the class due to a NFR satisficing will always be followed by the same kind of expression used in scenarios: {NFR[Topic]}

  • We may have to represent special conditions that hold for an operation. These conditions will be represented between {}

  • If these conditions impose a significant loss of space, we might represent them inside a note

ITEC 4040 – Requirements Management


Lecture 06

Extending Class Diagram - Example

SetRoomAsOccupied()

Pre: malfunction of main sensor

Increment_people()

Pre: Motion sensor sends signal

Post: NR_i_people=NR_i_people@pre+1

Decrement_people()

Pre: Motion sensor sends signal

Post: NR_i_people=NR_i_people@pre-1

Place

AdviseUserofMalfunction() {Safety [Room]}

AdviseFMofMalfunction {Safety [HS]

GetOLSValue() {Op.Cost [Control System]}

SetRoomAsOccupied() {Accuracy [Room]}

Increment_people() {Accuracy [Room]}

Decrement_people() {Accuracy [Room]}

TurnOnEmergency() : void

Quit() : void

TurnOff() : void

ITEC 4040 – Requirements Management


Lecture 06

Integrating NFRs into Use Cases

Pick up a use case diagram

Identify LEL symbols that appear in use case names and actors

Evaluate necessary inclusions to satisfice this NFR in the use case diagram

Analyze possible impacts due to inclusions made in the use case diagram

Evaluateagain and return to step 4

Pick up next graph that applies and return to step 3

Continue until there are no use case diagrams left to analyze

ITEC 4040 – Requirements Management


Lecture 06

Integrating NFRs into Use Cases

ITEC 4040 – Requirements Management


Lecture 06

Integrating NFRs into Use Cases - Example

ITEC 4040 – Requirements Management


Lecture 06

Integrating NFRs into Use Cases - Example

ITEC 4040 – Requirements Management


Lecture 06

Integrating NFRs into Scenarios

Pick up a scenario

Analyze the scenario with titles that has a LEL symbol that appears in a NFR graph

Evaluate necessary inclusions to satisfice this NFR in the scenario

Analyze possible impacts due to inclusions made in the scenario

Evaluate again and return to step 4

Pick up the next graph that applies and return to step 3

Do it until there are no scenarios left to analyze

ITEC 4040 – Requirements Management


Lecture 06

Integrating NFRs into Scenarios

ITEC 4040 – Requirements Management


Lecture 06

Integrating NFRs into Scenarios - Examples

S

S

S

S

Safety

Safety

S

S

Lights]

[

[

Dim

Safety

Safety

S

S

[

[

Lights.

Room.

Dim

>=14

>=14

lux

lux

]

]

Illumination

Safety

Safety

S

S

[Room.

Calculate

Calculate

LuxValue

LuxValue

]

]

Safety

[Room.

S

S

LuxValue

]

]

ITEC 4040 – Requirements Management


Lecture 06

Integrating NFRs into Scenarios - Examples

ITEC 4040 – Requirements Management


Lecture 06

Integrating NFRs into Class Diagrams

Pick up a class diagram

Look for NFRs that applies to this class

Evaluate necessary inclusions to satisfice this NFR in the class diagram

Analyze possible impacts due to inclusions made in the class diagram

Evaluate again and return to step 4

Pick up next graph that applies and return to step 3

Do it until there are no class diagrams left to analyze

ITEC 4040 – Requirements Management


Lecture 06

Integrating NFRs into Class Diagrams

ITEC 4040 – Requirements Management


Lecture 06

Examples from Case Studies

  • Strategy validation

    • Strongly based on the replication project principle [Basili ‘96]

    • 3 different case studies

    • 1 in vivo (Real Application Environment)

    • In all 3 cases, they used conceptual model built by someone else and they applied the proposed strategy

      • They built the non-functional view

      • They integrated the NFRs from this view into the conceptual models that was developed by someone else

ITEC 4040 – Requirements Management


Lecture 06

Examples from Case Studies

  • Case Study 1

    • Light control system following a proposal presented in a seminar. It was conducted by Breitman [Breitman ‘00] as one of the case studies of her PhD thesis

  • Case Study 2

    • Another specification of a light control system, built by a group of undergraduate students from the Computer Science course of PUC_Rio

  • Case Study 3

    • A laboratory information system developed by a team from a software house specialized in this domain. They used the conceptual model restricted to the processing area

ITEC 4040 – Requirements Management


Lecture 06

Examples from Case Studies

  • Details on Case Study 3

    • They built the LEL with the NFR using structured interviews and existing documentation

    • From this LEL they built the set of NFR graphs

    • They validated these graphs together with the stakeholders

    • After validation, they did the integration between the functional and non-functional views

    • Several changes were made in the existing class diagram

ITEC 4040 – Requirements Management


Lecture 06

Examples from Case Studies – Use Cases

ITEC 4040 – Requirements Management


Lecture 06

Examples from Case Studies – Use Cases

ITEC 4040 – Requirements Management


Lecture 06

Examples from Case Studies – Use Cases

ITEC 4040 – Requirements Management


Lecture 06

Examples from Case Studies – Use Cases

ITEC 4040 – Requirements Management


Lecture 06

Examples from Case Studies - Conclusions

  • 46% of the existing classes were somehow changed

  • 45% more operation

  • 37% more attributes

  • Estimated overhead of 7%

    • Case Study 3

      • 1728 hours/person to build the functional view

      • 121 hours/person to build the non-functional view and to integrate it to the functional view

      • Compatible with the overhead of 10% found in a previous case study [Cysneiros ‘01]

ITEC 4040 – Requirements Management


Lecture 06

The End

Questions?

Lecture 06

ITEC 4040 – Requirements Management

Prof. DawidKasperowicz

http://www.yorku.ca/dkasper