Non-Functional Requirements Notes taken from: Object Oriented Software Engineering text; Art of Software Architecture (Stephen Albin) Use Case Analysis (Bittner and Spence); Use Cases – Requirements in Context (Kulak and Guiney) Some notes from Rational Software Corporation slides Other personal notes

Use-Case Analysis Steps – Here’s where we are: OOADv4.2 Instructor Notes Use-Case Analysis Steps – Here’s where we are: Analysis mechanisms and their characteristics were discussed in the Architectural Analysis module. This section describes how to document the analysis mechanisms and analysis mechanism characteristics for the identified analysis classes. Supplement the Use-Case Descriptions For each use-case realization Find Classes from Use-Case Behavior Distribute Use-Case Behavior to Classes For each resulting analysis class Describe Responsibilities Describe Attributes and Associations Non-Functional Requirements – Now we have a pretty good understanding of the analysis classes, their responsibilities, and the collaborations required to support the functionality described in the Use Cases. Now we need to address the non-functional requirements in some detail. Rational calls these analysis mechanisms. Module 7 - Use-Case Analysis

Non-Functional Requirements The purpose of “identifying non-functional requirements” is to get a handle on these absolutely necessary requirements that are normally not ‘functional.’ During Analysis, this information is speculative and will be refined later. Capture now; realize later… (Don’t want to miss these important points in design…)

Non-Functional Requirements – OOSE Text p.115-

Types of Requirements Functional requirements Describe what the system should do Non-functional requirements Constraints that must be adhered to during development (design and implementation) Operative word: ‘Constraints.’

Functional requirements What inputs the system should accept What outputs the system should produce What data the system should store that other systems might use What computations the system should perform The timing and synchronization of the above

Non-Functional requirements Mostly not unique to a single use case. Generally thread themselves throughout some use cases Transcend locality Some of these conflict with each other Some support ‘efficiency’ of code and ‘inefficiency’ in maintenance…

Non-functional Requirements – Verifiable; Measured All must be verifiable If not ‘verifiable’ then there is no indications that these requirements have been accommodated. Some must also be measured. Some requirements are measurable, such as response time; availability time, etc. Some may be measured directly; some via simulation. We parse the non-functional requirements into categories…

Categories of Non-Functional Requirements – Quality Non-Functional Requirements 1. Quality Requirements – All constrain the design to meet these desired quality levels of usability, efficiency, reliability, maintainability and reusability Discuss!!! Response time – particularly important for processes that process a lot of data or use networks a great deal. Might be after < two second response or Timing bar indicating progress of a search or computation… For some ‘real time systems,’ this should be considered as a functional requirement. Throughput – for computationally-intensive applications or for heavy transaction-oriented systems, the ‘number of transactions per minute or number of computations per minute can/must be measured. Resource usage – Application cannot use more than X MB of memory… Very practical in a large multiprogramming / multiprocessing system. Reliability – typically MTBF (number of failures per week; define ‘failure.’)

Categories of Non-Functional Requirements – Quality Non-Functional Requirements Availability – Measures the time application is ‘up’ and the period of down time, when down. Recovery from failure – MTTR – critical to some applications; not so for others; checkpoint restarts; auto-saves, etc. If you specify the detailed procedure to follow, then this is a functional requirement. Allowances for Reusability – may specify that a certain percentage of the system must be designed generically to support reusability…

Categories of Non-Functional Requirements – 2 Categories of Non-Functional Requirements – 2. Environment and Technology Constraints Platform What hardware / software the software must be able to work on. Normally indicate ‘least’ platform e.g. Windows 95; 25 MB free disk space…. Technology to be used  Programming language; database system. All individuals are familiar with these languages/database nuances. Reduces need to train people

Categories of Non-Functional Requirements – 3 Categories of Non-Functional Requirements – 3. Project Plan and Development Methods Development Process / Methodology SDLC; RUP; particular approaches to testing (done by separate group). References to these must be included; not the details Cost and Delivery Dates A Bigee!! Usually a very important constraint. Usually found in the Contract for the system or in a separate project plan.

Thoughts - Non-functional requirement Not always clear that a requirement is non-functional and functional. If requirement is a fundamental part of the application’s functionality, then it should be stated as a functional requirement; If requirement is a ‘constraint’ on design or some kind of restriction on design, then the requirement is ‘non-functional.’ Certainly the presented list is not exhaustive!

Quality Models – Many and Varied From Art of Software Architecture…p. 70-72 Criteria for (N.B. Different categories…) Product Operation Quality are: Accuracy Reliability Efficiency Integrity Usability Product Revision Quality are: maintainability, flexibility, testability Product Transition quality are: Interface facility, reusability, transferability

More attributes… Overall quality (Boehm) as a function of these metrics: Validity, clarity, understandability, modifiability, modularity, generality, economy, resilience, documentation Laurence Best’s Application Architecture identifies: Accuracy and comprehensiveness; simplicity of use, operational flexibility, easy of development, maintenance, and extension, security and control, resource efficiency, recovery And there are numerous other ‘lists’…..

Looking down on these… Functional models such as use cases, typically drive object-oriented projects. Attributes such as modifiability are not easily expressed in purely object-oriented terms and need supplemental text descriptions to represent the design. Each attribute MUST be considered during design and usually requires the architect to make multiple passes as a design. Class design: start by addressing functionality only Second pass to incorporate modifiability constraints while making sure that the functionality is not compromised. Sometimes, multiple passes are needed to incorporate various requirements and to evaluate the design tradeoffs.

Looking down on these… Many competing non-functional requirements. Architect must find a design that realizes a balance among them. Example: modifiability and performance are often commonly competing requirements because modifiability design techniques usually have extra levels of indirection (interfaces) and incorporate stricter encapsulation of data and services to make modifications more local and less pervasive. Performance design techniques, however, usually incorporate fewer levels of indirection and optimizations to data structures in order to improve operation execution times. Cost is usually competing with everything else and it is common that usability is sacrificed first!

Where do they go? Use Case Modeling – Bittner and Spence – p. 43 In the RUP, we place the non-functional requirements in the Supplementary Specifications Consider: (N.B. again, different categories!!!)  Legal and Regulatory Requirements The customer must be of legal age ot purchase alcohol. Application Development Standards The system must be developed in accordance with the Rational Unified Process Quality attributes of the system to be built must include usability, reliability, performance, supportability requirements The system must be available at least 90% of the time. Constraints placed on the design and implementation of the system such as operating system, environments, … The system must be written in Java Others…

Supplementary Specifications Very misleading to think ‘supplementary specs’ are inferior or lesser than functional specs. Many projects have run amuck because they did not consider these requirements. May have formed a major part of the overall critical success criteria. E.g. System must support 300-500 simultaneous users; On entry into user acceptance testing, system supported eight simultaneous users; Developers had concentrated on the user interface and completely ignored this supplementary spec item. Upon further review, it was noticed that the developer did not investigate any of the requirements beyond the scope of the most basic flow of events. “Not surprisingly, the system was never deployed.”

Supplementary Specifications Should complement the use cases. Note that use cases can capture non-functional requirements especially those that apply only within the context of a single use case. Use the Supplementary Specifications to capture those non-functional requirements that are global in nature or do not vary from one use case to the next. Typically, if the amount of interaction in use cases is large, the majority of requirements will be captured here and there may be just a few, global, non-functional requirements; conversely, if the amount of interaction in the use case is small, then the majority of requirements may be captured as non-functional requirements and found in the Supp. Specs. Keep a balance between using the use cases and the non-functional requirements. We need both if the overall objectives of the requirements are to be accommodated.

Non-Functional Requirements – the Process Use Cases – Kulak and Guiney… Identify the non-functional requirements Validate with appropriate stakeholders Document the requirements Capture its name, its effect, both the system and business degradation that would result if the requirements are not satisfied Best time to capture them is when exploring the functional requirements Document it right away from your sources of information (interviews, questionnaires, …) Ask users about response times, what bothers them now; what is fine. Be certain to differentiate between business-related concerns which can often be added to a use case description, with non-functional requirements.

Non-Functional Requirements – the Process Rank them. VIP Sometimes accommodating non-functional requirement may cost more than implementing the use case. There is no free lunch, and somethings are not worth the cost to accommodate. E.g. Infinite availability; levels of performance. “Don’t let [a users] initial assumptions drive you into an architectural nightmare.” Use a template to document the non-functional requirements, as found in our Use Case book, p. 79.

Non Functional Requirement Name Use something like the table below. You may add column attributes as needed. Non-Functional Category* Number Non Functional Requirement Name Description Applies to Use Cases: Exceptions You may wish to categorize these (or not). If not, omit column. You may also wish to add columns.

Examples Non-Functional Category* Number Non Functional Requirement Name Description Applies to Use Cases: Exceptions 1 Persistency Student objects need to be persistent Where Student Objects are Updated None 2 Security System Administrator actor needs to be authenticated Those Use Cases that access the Profile Database 3 Availability The Profile Database must be available 95% of the time All Use Cases that require authentication

Supplementary Specifications These tables need to be inserted into a new document called the Supplementary Specifications. These constitute an additional artifact that we will be using. Note also that in some cases, the non-functional requirements are called ‘mechanisms’ (RUP) Have ‘persistency mechanism’; security ‘mechanism,’ etc. Means that there will be some process to accommodate persistency, security, etc.

OOADv4.2 Instructor Notes Analysis Class to Non-functional Requirements map As analysis classes are identified, it is important to identify the non-functional requirements that might apply to them Classes that must be persistent are mapped to the Persistency Mechanism and tagged as persistent Classes that are maintained with the Legacy Course Catalog system are mapped to the Legacy Interface mechanism; Classes for which access must be controlled (like who can read and modify instances of the class) are mapped to a Security mechanism., etc. Distributed classes mapped to a Distribution mechanism, etc.) (Often ‘control classes’ are distributed.) Module 7 - Use-Case Analysis

Use-Case Analysis Steps OOADv4.2 Instructor Notes Use-Case Analysis Steps Supplement the Use-Case Descriptions For each use-case realization Find Classes from Use-Case Behavior Distribute Use-Case Behavior to Classes For each resulting analysis class Describe Responsibilities Describe Attributes and Associations Qualify Analysis Mechanisms Unify Analysis Classes We have a pretty good understanding of the analysis classes, their responsibilities, the analysis mechanisms / non-functional requirements that they need to implement (persistence, security, legacy, …) and the collaborations required to support the functionality described in the use cases. Now lets review everything to ensure it is complete and consistent before moving on…. Checkpoints Module 7 - Use-Case Analysis

Unify Analysis Classes OOADv4.2 Instructor Notes Unify Analysis Classes In this step, we homogenize/blend the classes and responsibilities discovered for the different use cases. Homogenization, at this point is just a synchronization of the Use-Case Analysis efforts for each of the use cases, before moving into Architectural Design. This homogenization is internal to the results of the finding classes activity; it doesn't consider the 'big picture'. The “big picture” is considered later in Architectural Design, where the newly discovered analysis classes are “homogenized” with the existing architecture (note: there are only “existing classes” if this is not the first iteration). The purpose of “Unify Analysis Classes” is to ensure that each analysis class represents a single well-defined concept, with non-overlapping responsibilities. <<boundary>> Name of analysis class should capture role; (e.g.EnrollmentForm) Description of class should capture role played by class in the system. Merge classes that define similar behavior or represent the same thing. Merge entity classes that define the same attributes Aggregate behaviors of merged classes. If you do any of these things, make sure you update any supplemental use case descriptions where necessary. <<control>> <<entity>> <<entity>> Module 7 - Use-Case Analysis

OOADv4.2 Instructor Notes Evaluate Your Results Analysis Classes Glossary Supplementary Specification Use-Case Model Module 7 - Use-Case Analysis

Evaluating and Verifying Now, verify analysis classes meet functional requirements of the system. Verify the analysis classes and their relationships are consistent with collaborations that they may support. Very important that you evaluate your results at the conclusion of Use Case Analysis. The ‘formality’ and ‘when’ you do this verification is up to the project.

Use-Case Analysis Steps OOADv4.2 Instructor Notes Use-Case Analysis Steps Supplement the Use-Case Descriptions For each use-case realization Find Classes from Use-Case Behavior Distribute Use-Case Behavior to Classes For each resulting analysis class Describe Responsibilities Describe Attributes and Associations Qualify Analysis Mechanisms Unify Analysis Classes Checkpoints - Check the ‘quality’ of the model against criteria that the Designer looks for… Module 7 - Use-Case Analysis

Checkpoints: Analysis Classes OOADv4.2 Instructor Notes Checkpoints: Analysis Classes The checkpoints for analysis classes are a subset of the checkpoints for design classes. A more detailed checklist is provided in the Rational Unified Process. Are the classes reasonable? Does the name of each class clearly reflect the role it plays? Does the class represent a single well-defined abstraction? Are all attributes and responsibilities functionally coupled? Does the class offer the required behavior? Are all specific requirements on the class addressed? (continued) Module 7 - Use-Case Analysis

Checkpoints: Analysis Classes Note: All checkpoints should be evaluated with regards to the use cases being developed for the current iteration. The class should represent a single well-defined abstraction. If not, consider splitting it. The class should not define any attributes and responsibilities that are not functionally coupled to the other attributes or responsibilities defined by that class. The classes should offer the behavior the use-case realizations and other classes require. The class should address all specific requirements on the class from the requirement specification. Remove any attributes and relationships if they are redundant or are not needed by the use-case realizations.

Checkpoints: Use-Case Realizations OOADv4.2 Instructor Notes Checkpoints: Use-Case Realizations Have all the main and/or sub-flows been handled, including exceptional cases? Have all the required objects been found? Has all behavior been unambiguously distributed to the participating objects? Has behavior been distributed to the right objects? Where there are several interaction diagrams, are their relationships clear and consistent? Module 7 - Use-Case Analysis

Checkpoints: Use-Case Realizations Note: All checkpoints should be evaluated with regards to the use cases being developed for the current iteration. The objects participating in a use-case realization should be able to perform all of the behavior of the use case. If there are several interaction diagrams for the use-case realization, it is important that it is easy to understand which interaction diagrams relates to which flow of events. Make sure that it is clear from the Flow of Events description how the diagrams are related to each other.

Review: Use-Case Analysis OOADv4.2 Instructor Notes Review: Use-Case Analysis What is the purpose of Use-Case Analysis? What is an analysis class? Name and describe the three analysis stereotypes. What is a use-case realization? Describe some considerations when allocating responsibilities to analysis classes. Describe the role of non-functional requirements in complementing functional requirements. Describe the tie-in of non-functional requirements to use cases. Module 7 - Use-Case Analysis