1 / 77

Introduction

Introduction. What are Non-Functional Requirements ?. NFRs are also known as Quality Requirements [ Chung 93 ] [ Boehm 96 ]. Unlike Functional Requirements, Non-Functional requirements states constraints to the system as well as particular behavior that the system must have.

yardan
Download Presentation

Introduction

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Introduction

  2. What are Non-Functional Requirements ? • NFRs are also known as Quality Requirements [Chung 93] [Boehm 96]. • Unlike Functional Requirements, Non-Functional requirements states constraints to the system as well as particular behavior that the system must have. • Non-Functional Requirements are always together with a Functional Requirement [EAGLE 95][Chung 00].

  3. Non-Functional Requirements examples • Time to Market • Reliability • Security • Modularity • Portability • Size • Safety • Testability • Mobility • Standard compliant • Robustness • Complexity • Learnability • Adaptability • Architectural integrity • Cost • Configurability • Efficiency • Maintainability • Flexibility • Profitability • Performance • Usability • Understandability • Risk • Resilience • Reusability NFRs are important for the success of the system !!

  4. Why bother with Non-Functional Requirements

  5. A Recent Press Release WASHINGTON (AP, Jan 17th 2002) -- Microsoft's chairman, Bill Gates, is steering his software empire onto a new strategic heading, putting security and privacy ahead of new capabilities [new functionality] in the company's products. In an e-mail to employees obtained by The Associated Press, Gates refers to the new philosophy as "Trustworthy Computing" and says his highest priority is to ensure that computer users continued to venture safely across an increasingly Internet-connected world.

  6. Another case neglecting non-functional requirements (NFRs) The London Ambulance System was deactivated just after its deployment because, among other reasons, many non-functional requirements were neglected during the system development e.g. reliability (vehicles location), cost (emphasis on the best price), usability (poor control of information on the screen), performance (the system did what was supposed to do but he performance was unacceptable), [Finkelstein 96] [Breitman et all 99].

  7. Why Non-Functional Requirements ? • Nowadays, the market demands more and more non-functional aspects to be implemented in information systems besides its functionality. • Works [Dardene 93] [Mylopoulos 92] [Chung 95] have shown that complex conceptual models must deal with non-functional aspects. • This Non-Functional aspects should be dealt within the process of Non-Functional Requirements (NFR) definition.

  8. Why Non-Functional Requirements ? • Errors due to omission of NFRs or to not properly dealing with them are among the most expensive type and most difficult to correct [Mylopoulos 92] [Ebert 97] [Cysneiros 99]. • Recent works point out that early-phase Requirements Engineering should address organizational and Non-Functional Requirements, while later-phase focus on completeness, consistency and automated verification of requirements [Yu 97].

  9. Why Non-Functional Requirements ? • Few works addresses the integration of early and late requirements [Yu u95] [Cysneiros 99]. • Interdependencies between NFRs must be identified and dealt with. • For Example : • A Clinical Analysis Lab information system has the following Functional Requirement. • The system must have a file containing all the clients to be used by the Marketing Division. • Together with this Functional Requirements we have the following NFR: • 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: • Patient’s admission must last less then 4 minutes.

  10. Functional x Non-Functional Requirement • Suppose we are dealing with a Clinical Analysis Laboratory software system. • There will be a Functional Requirement: • “The System must provide a data entry to input the results of tests to a patient’s report” • Associated to this Requirement one may find the following Security NFR: • “Depending on the result of a test only the supervisor will be able to input this value to the patient’s report”

  11. Functional x Non-Functional Requirement • NFRs define global constraints • on a software system or subsystem, • a functional requirement, • the development or • deployment processes • NFRs are often subjective in nature • NFRs are generally stated • informally, • are often contradictory, • difficult to enforce during development • Difficult to evaluate for the customer prior to delivery. • FRs are local in nature (often defined as scenarios of interactions with the system) • FRs are objective in nature. • FRs are generally stated • more formally (structured english, Use Cases/UML, formal methods) • Usually do not conflict with each other. • Achieving FRs can be enforced by todays design methods • FRs can be evaluated by customers.

  12. Approaches For Dealing with NFRs • Product-Oriented • The focus is on the final product. • Almost always uses a quantitative approach. • Only measure what did or did not do. Do not help to prevent problems. • Most of the NFR work use this approach [Keller 90] [Boehm 78] [Basili 91] [Hauser 88].

  13. Quantitative approach Maintainability Desired value Measurement system comparison (3) Lets compare the measured value with a desired value Measured value (2) Lets measure the degree to which it meets maintainability using some maintainability metric. Software Object (1) Given an existing software object

  14. Approaches to Deal with NFRs • Process-Oriented • The focus is on the software development process. • Aims to help finding out the necessary NFRs during the development process. • Always use a qualitative approach. • Aims to help justifying design decisions. • Few works use this approach [Dobson 91] [Chung 00] [Cysneiros 99].

  15. Qualitative approach Maintainability Not so good (1) Given two existing software objects good (2) Lets compare them with each other and see which one achieves maintainability, relatively speaking, better Software Object1 Software Object2 good Bad Some ordering vis-à-vis maintainability

  16. Product vs. Process Maintainability Desired value Measurement system comparison Measured value (2) Measuring software object Maintainability Performance (1) How can maintainability be achieved ? (3) May hurt performance of the system Software object Interfaces (2) By using encapsulation techniques to establish interfaces. (1) Existing software object Software Objects Product approach Process approach

  17. Approaches to Deal with NFRs • Product and Process-oriented approaches are complementary to each other. • Product-oriented approaches can provide you with tools to validate the product. • Process-oriented approaches can guide in searching for ways to achieve NFRs while developing the software.

  18. Eliciting is not Enough • Integrating NFRs into data models can help to get software deployed faster and with lower development costs [Cysneiros 99].

  19. Our Proposal • We propose a strategy to deal with NFR since the early stages of software development • The first part presents some heuristics to elicit NFR and a systematic way to search for interdependencies • Uses the Language Extended Lexicon (LEL) [Leite 93] as an anchor for the definition of the non-functional model • The second part presents some heuristics to integrate NFRs into conceptual models • Also uses the LEL as an anchor to build the functional model • Extends the scenario model [Leite 97], the class, sequence and collaboration diagrams [Rumbaugh 99] to deal with NFR

  20. The Proposed Strategy

  21. Functional View Sequence Diagram Use Cases Class Diagram Collaboration Diagram Scenarios New Actors and Use Cases New Classes, Operations and Attributes New Episodes, Resources and Actors LEL New Classes, and messages NFR and its impacts NFR Graph Non-Functional View

  22. Building the Non-Functional View Client Changes due to Conflict Resolution Knowledge on the Problem Positive and Negative Influences Conflicts Design Decisions Introduce NFRs in the LEL Identify and Solve Conflicts Represent NFR New Notions New Behavioral Responses New Symbols NFR Graph LEL with NFRs 1 2 3 LEL Symbol Primary NFR Knowledge Base on NFRs Interdependencies LEL

  23. NFR Taxonomy • A NFR can be classified as Primary and Secondary ones where the secondary once is a decomposition of a Primary one • For Examples: • Accuracy Primary • Numeric • Write information at the right time • Dynamic NFR • Are those that deal with more abstract concepts and frequently demands an action to be • Static NRR • This type of NFR always demands some information to be used, usually in a persistent way Secondary

  24. Language Extended Lexicon (LEL) • Aims to register the vocabulary used in the UofD • It is based on a 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 (connotation) • Its construction is based on the minimum vocabulary and circularity principles

  25. LEL – Proposed Extension • We now register Primary NFR 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

  26. Building the Non-Functional View Client Changes due to Conflict Resolution Knowledge on the Problem Positive and Negative Influences Conflicts Design Decisions Add NFRs to the LEL Identify and Solve Conflicts Represent NFR New Notions New Behavioral Responses New Symbols NFR Graph LEL with NFRs 1 2 3 LEL Symbol Primary NFR Knowledge Base on NFRs Interdependencies LEL

  27. Add NFRs to the LEL • To each symbol of the LEL : • Check if any NFR belonging to the Knowledge Base may be necessary in this symbol • 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 notion and behavioural Reponses to this NFR

  28. What NFR is Needed ? Example

  29. Building the Non-Functional View Client Changes due to Conflict Resolution Knowledge on the Problem Positive and Negative Influences Conflicts Design Decisions Add NFRs to the LEL Identify and Solve Conflicts Represent NFR New Notions New Behavioral Responses New Symbols NFR Graph LEL with NFRs 1 2 3 LEL Symbol Primary NFR Knowledge Base on NFRs Interdependencies LEL

  30. Represent NFR • We propose the use of the NFR Framework • NFR are represented using a graph structure very similar to the And/Or trees used in problem solving • NFR are faced as softgoals that might be decomposed into more refined subgoals until we get the subgoals that will represent how this NFR will be operationalized (its operationalizations) • One system can have (usually does) n graphsSatisfice • NFR are rarely 100% satisfiedX Satisfy • Some proposed extensions • Always use a symbol of the LEL to represent an NFR Topic • Represent above the graph the actor(s) responsible for the knowledge represented in the graph • Introduces the concept of Dynamic and Static Operationalizations

  31. Actor who was the source of the Knowledge Facility Manager Safety Topic has to be a symbol of the LEL [Room] S Safety S Safety [Room. Safety S S [Room. Malfunction] [Room. Control Panel] Light scene. Current light scene >= Safe Illumination] Safety S Safety Safety Safety [Located S [Malfunction. Near the [Malfunction. S S [Malfunction. Malfunction of OLS ] Door] Motion Detector] FM Safety S Get informed] [Light Scene. Safe Illumination=14 Lux] S = Satisficed P = Partially D = Denied Safety Safety S S [Malfunction of OLS. [Malfunction Static Operationalization Dynamic Operationalization . All CLG set on] User. Get informed]

  32. How to Create a Graph Safety [Room]

  33. A First Decomposition S S S S S Safety [Room] Safety Safety Safety [Room. Safety [Malfunction of OLS. [Malfunction. Light Scene. [Located Near the Door] All CLG set on] User. Safe Illumination=14 lux ] Get informed]

  34. Final Version Facility Manager Safety [Room] S Safety S Safety [Room. Safety S S [Room. Malfunction] [Room. Control Panel] Light scene. Current light scene >= Safe Illumination] Safety S Safety Safety Safety [Located S [Malfunction. Near the [Malfunction. S S [Malfunction. Malfunction of OLS ] Door] Motion Detector] FM Safety S Get informed] [Light Scene. Safe Illumination=14 Lux] Safety Safety S S [Malfunction of OLS. [Malfunction . All CLG set on] User. Get informed]

  35. Building the Non-Functional View Client Changes due to Conflict Resolution Knowledge on the Problem Positive and Negative Influences Conflicts Design Decisions Add NFRs to the LEL Identify and Solve Conflicts Represent NFR New Notions New Behavioral Responses New Symbols NFR Graph LEL with NFRs 1 2 3 LEL Symbol Primary NFR Knowledge Base on NFRs Interdependencies LAL

  36. Identify and Solve Conflicts • Compare graphs with the same type (ex: Performance) • Using the Knowledge Base from the OORNF Tool, compare graphs with conflicting types (Ex: 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)

  37. S P S P S S P S S P P S P Example Manager of the Processing Area Manager of the Medical Bureau Reliability Op . Restriction [ test ] [ Patient’s Report ] Claim [As soon as al the results Reliability D are ready and reviewed the report [ Eletronicaly sign must be printed ] Patient’s Report ] - Time Restrictions [ Print Patient’s Report ] Reliability Reliability [LIS . [Range to be signs if Eletronicaly signed ] all results are Time Restrictions within range] [ Results Ready ] Time restrictions Time Restrictions Time Restrictions Time restrictions [ Medical Bureau . . [ Results [ Admitted [LIS. Eletronicaly Signs to Inspect ] Tests ] Printing queue for Patient’s Report ] Patient’s Report ] Time restrictions [ Medical Bureau . . Eletronical Signature ] Time restrictions [LIS. Eletronicaly Signs Patient’s Report ]

  38. Using Catalogues – Another Alternative Softgoal Operationalization Claim Contribution Link Correlation Link

  39. Traceability [ Test Results] Traceability [ Changes] S S S S S S S S Traceability [ Who entered results] Traceability [What Results] Traceability [ When results Changed] Traceability [ Store ALL results] Traceability [ Store Identification of ALL Who entered results] Traceability [ Store Date and time of ALL result changes]

  40. Security [ Patient’s Record] Usability [ Patient Adviser] Cost [ Patient Adviser] Availability [ Patient’s Record] Usability [ Provide Coninuoes Access] Usability [ Provide Improved Presentation] Usaability [ Improve Cognition] D S S S S S P S D S D S D D Usability [Reduce Memory Load] Usability [Use Graphics] Usability [ Assure Timeliness of Information] Usability [Use a Desktop] Usability [Use a PDA] Usability [Use 5+2 Rule] Usability [Allow for Multiple Modality] + + - + + -

  41. Extending Functional View Models

  42. Extending Use Cases • Every use case or actor included, due to NFR satisfaction, must be followed by an expression using the pattern: {NFR_Type[NFR_topic]}. • Represent Special Conditions that must prevail to an Use Case as a note linked to this Use Case, using whenever possible OCL to describe these conditions • Ex: In a Light Control System • The Use Case Turn Off Lights after T3 Sec must have a special condition saying that this will only happen if the room is empty • We should them represent it as: Pre: room.number_people=0

  43. Example Verify Access {Security[Input Results]} Pick Up a Patient Processing Area Employee LIS Set Result {pre: (employee.sector=test.sector AND test.result in est.saferange) OR employee.position=“SM”} {Security[Input Results]} Check Sector {Security[Input Results]} Check If results are in Range {Security[Input Results]}

  44. Extending Scenarios [Leite 97] • Every change in a scenario due to an NFR satisficing must be followed by the expression : Constraint: {NFR[Topic]} • Reason: Traceability between models

  45. Extending the Class Diagram • Every class will be named using a symbol of the LEL • Classes created due to an NFR satisficing will be follwed 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]}

More Related