Lecture 06

1. Lecture 06 ITEC 4040 – Requirements Management Prof. DawidKasperowicz http://www.yorku.ca/dkasper

2. 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

3. 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

4. The Proposed Strategy ITEC 4040 – Requirements Management

5. 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

6. Building the Non-Functional View ITEC 4040 – Requirements Management

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

8. 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

9. 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

10. Building the Non-Functional View ITEC 4040 – Requirements Management

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

12. Add NFRs to the LEL - Example What NFR is Needed ? ITEC 4040 – Requirements Management

13. Add NFRs to the LEL - Example ITEC 4040 – Requirements Management

14. Building the Non-Functional View ITEC 4040 – Requirements Management

15. 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

16. Represent NFR - Example ITEC 4040 – Requirements Management

17. Represent NFR – How to Create a Graph Safety [Room] ITEC 4040 – Requirements Management

18. Represent NFR – How to Create a Graph First Decomposition ITEC 4040 – Requirements Management

19. Represent NFR – How to Create a Graph Second Decomposition ITEC 4040 – Requirements Management

20. Represent NFR – How to Create a Graph Final Version ITEC 4040 – Requirements Management

21. Building the Non-Functional View ITEC 4040 – Requirements Management

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

23. Identify and Solve Conflicts - Example ITEC 4040 – Requirements Management

24. 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

25. Extending Use Cases - Example ITEC 4040 – Requirements Management

26. 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

27. 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

28. 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

29. 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

30. 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

31. Integrating NFRs into Use Cases ITEC 4040 – Requirements Management

32. Integrating NFRs into Use Cases - Example ITEC 4040 – Requirements Management

33. Integrating NFRs into Use Cases - Example ITEC 4040 – Requirements Management

34. 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

35. Integrating NFRs into Scenarios ITEC 4040 – Requirements Management

36. 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

37. Integrating NFRs into Scenarios - Examples ITEC 4040 – Requirements Management

38. 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

39. Integrating NFRs into Class Diagrams ITEC 4040 – Requirements Management

40. 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

41. 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

42. 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

43. Examples from Case Studies – Use Cases ITEC 4040 – Requirements Management

44. Examples from Case Studies – Use Cases ITEC 4040 – Requirements Management

45. Examples from Case Studies – Use Cases ITEC 4040 – Requirements Management

46. Examples from Case Studies – Use Cases ITEC 4040 – Requirements Management

47. 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

48. The End Questions? Lecture 06 ITEC 4040 – Requirements Management Prof. DawidKasperowicz http://www.yorku.ca/dkasper