Upload
nathaniel-rogers
View
219
Download
0
Embed Size (px)
Citation preview
36 1
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 slidesOther personal notes
Non-Functional Requirements
36 2
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 – We have a:
good understanding of the nature of the analysis classes and their responsibilities
collaborations required to support the functionality described in the Use
Cases via analysis classes
Need to address the non-functional requirements
IBM-Rational calls these “analysis mechanisms.”
Use-Case Analysis Steps – Here’s where we are:
36 3
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.
Will be refined later. Philosophy: Capture now; Realize later… (Essential points in design…)
36 4
Non-Functional Requirements – OOSE Text p.115-
36 5
Types of Requirements
Functional requirements Describe what the system should do
Non-functional requirements Consists of Constraints that must be adhered to during development (design and implementation)
Operative word: ‘Constraints.’
36 6
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
36 7
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… Let’s contrast functional and non-functional
requirements
36 8
Non-functional Requirements – Verifiable; Measured
All requirements must be verifiableIf not ‘verifiable’ then there is no indications that these requirements have been satisfied.
Some must also be measured. Some requirements are measurable, such as response time; availability time, etc.
Some may be directly measured; some measured via simulation.
We parse the non-functional requirements into categories…
36 9
Categories of Non-Functional Requirements 1. Quality Non-Functional Requirements (1 of 2) All constrain the design to meet desired quality levels of usability,
efficiency, reliability, maintainability and reusability… Examples: Response time – particularly important for processes that process a
lot of data or use networks a great deal. Requirements might stipulate < two second response. Might use a Timing bar indicating progress… Response time may be considered a functional requirement for
some ‘real time systems.
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 > xxMB of memoryVery practical in a large multiprogramming / multiprocessing
system.
36 10
Categories of Non-Functional Requirements 1. Quality Non-Functional Requirements (2 of
2)
Reliability – typically Mean Time Between Failures (MTBF) (number of failures per week; define ‘failure.’)
Availability – Measures the time application is ‘up’ and the period of down time, when down.
Recovery from failure – Mean Time To Repair: (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…
36 11
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 XP, Vista; 120 MB free disk space….
Technology to be used Programming language; database system. All
individuals are familiar with these languages / database nuances.
May/may not reduce need to train people
36 12
Categories of Non-Functional Requirements 3. Project Plan and Development Methods
Development Process/Methodology This may be specified and will greatly impace
development. SDLC; RUP; Agile Methods, Scrum; XP, Feature-Driven
Development (FDD), etc. Particular approaches to testing (done by separate
group; ‘Where in supervisory chain?’ References to these must be included; not the details
Cost and Delivery Dates; Traceability A Bigee!! Usually a very important constraint. Usually found in the Contract for the system or in a
separate project plan.
36 13
Random Thoughts - Non-functional Requirements
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
Think ‘performance’ of a real time / manufacturing app. Think ‘reliability’ of a safety-critical application
If requirement is a ‘constraint’ on design or some kind of restriction on design, then the requirement is almost always ‘non-functional.’
Certainly the presented list is not exhaustive!
36 14
Quality Models – Many and Varied (1 of 2)
Quality Models from a different source: from Art of Software Architecture… (p.70-72)
Note the different ‘categories’ for Quality Modeling according to this source: Product Operation Quality:
Accuracy, Reliability, Efficiency, Integrity, and Usability
Product Revision Quality are: maintainability, flexibility, testability
Product Transition Quality are: Interface facility, reusability, transferability
36 15
More attributes…(2 of 2)
According to Barry Boehm: Overall quality is 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, ease of development, maintenance and extension, security and control, resource efficiency, recovery
And there are numerous other ‘lists’….. These are presented to show you that there are different
‘takes’ on quality and what determines quality…
36 16
Looking down on these…(1 of 2)
Functional models such as use cases, typically drive object-oriented projects (although they certainly don’t have to…)
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.
How can these methods be efficient and yet maintainable? Efficient and yet reusable? Reusable yet modifiable?
36 17
Looking down on these…(2 of 2)
Many competing non-functional requirements. Architect must find a design that realizes a balance among
them. Example:
Performance design techniques, however, usually incorporate fewer levels of indirection and optimizations to data structures in order to improve operation execution times.
Performance gains may bring decreased maintainability / reusability features.
Cost is usually competing with everything else and it is common that usability is sacrificed first!
36 18
Where are Non-Functional Requirements Captured / Modeled?
Use Case Modeling – Bittner and Spence – p. 43 In the RUPIn the RUP, we place the non-functional requirements in the
Supplementary Specifications But this is usually considered a ‘standard’…..
Consider: (Bittner and Spence: different categories!!!) Legal and Regulatory Requirements
e.g.: The customer must be of legal age to purchase alcohol. Application Development Standards
e.g.: 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
e.g.: 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, … e.g.: The system must be written in Java 2….
Others…
36 19
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.
Consider the following problems / results: 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.”
36 20
Supplementary Specifications – Complement to Use Cases
Note use cases can capture non-functional requirements especially those that apply within the context of a single use case.
Use Supplementary Specs to capture non-functional requirements that are global in nature or do not vary from one use case to the next.
Within the Use Case: 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.
Within the Supplementary Specifications: 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 Supplementary Specifications.
Keep a balance between using the use cases and non-functional requirements.
We need both if the overall requirements objectives are to be met.
36 21
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 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.
36 22
Non-Functional Requirements – the Process
Rank the non-functional requirements. Very Important!
Sometimes accommodating non-functional requirement may cost more than implementing the use case.
There is no free lunch, and some things are not worth the cost to accommodate.
e.g. Infinite availability; levels of performance. “Don’t let [a user’s] 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.
36 23
Non-FunctionalCategory*
Number Non Functional Requirement Name
Description Applies to Use Case(s):
Exceptions
Use something like the table below.You may add ‘column attributes’ as needed.
You may wish to categorize these (or not). If not, omit column. You may also wish to add columns. You may wish a priority column!
36 24
Non-FunctionalCategory*
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
None
3 Availability The Profile Database must be available 95%
of the time
All Use Cases that require
authentication
None
Examples
36 25
Supplementary Specifications
Inserted table(s) into Supplementary Specifications.
The Supplementary Specifications document constitutes an additional artifact that we will be using.
Note also that in some cases, the non-functional requirements are called ‘analysis mechanisms’ (RUP) Have ‘persistency mechanism’; security ‘mechanism,’ etc.
Means that there will be some process to accommodate persistency, security, etc.
36 26
Analysis Classes – Use of tags { … }Non-Functional Requirements Map UML –
• 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. Persistency tag: {persistent}
• Classes that are maintained with the Legacy Course Catalog system are tagged 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. {security} or {secure mechanism}
• Distributed classes mapped to a Distribution mechanism, etc.) (Often ‘control classes’ are distributed.) {distributed}
36 27
Supplement the Use-Case Descriptions For each use case realization For each Analysis Class describe
responsibilities, etc…. …..
Know (now) about analysis classes their responsibilities, the analysis mechanisms / non-functional requirements that
these analysis classes need to implement (persistence, security, legacy, …) and
the collaborations required to support the functionality described in the use cases.
Unify Analysis Classes: Now lets review everything to ensure it is complete and consistent before moving on….
Checkpoints
Use-Case Analysis Steps
36 28
<<control>>
<<boundary>>
<<entity>><<entity>>
Unify Analysis Classes
The purpose of “Unify Analysis Classes” activity is to ensure that each analysis class represents a single well-defined concept, with non-overlapping responsibilities.
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.
36 29
SupplementarySpecification
Glossary
Use-Case Model
Analysis Classes
Evaluate Your Results
Are the Names appropriate?Are the Descriptions accurate?Are classes that should be merged actually merged?Are appropriate entity classes merged?Are aggregations captured?
36 30
Evaluating and Verifying
Now, verify analysis classes meet functional requirements of the system.
Trace down through the Use Case specifications for each Use Case. Are all responsibilities covered? Are domain / application objects captured? Properties?
Verify the analysis classes and their relationships are consistent with collaborations that they may support. If one class is sending messages to another, there is a collaboration needed.
If one class defines an ‘array’ of objects from another class, have we modeled this as an aggregation! etc.
Very important that you evaluate your results at the conclusion of Use Case Analysis.
36 31
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…
36 32(continued)
Checkpoints: Analysis Classes
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? (What does this mean to you?)
Does the class offer the required behavior? Are all specific requirements on the class
addressed?
36 33
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. (These will be methods later…)
The class should address all specific requirements on the class from the requirement specification – the Use Cases in our case.
Remove any attributes and relationships if they are redundant or are not needed by the use-case realizations.
36 34
Checkpoints: Use-Case Realizations
Have all the main and/or sub-flows been handled, including exceptional cases?\
Have all the required objects been found?
Have all behaviors been unambiguously distributed to the participating objects?
Have behaviors been distributed to the right objects?
Where there are several interaction diagrams, are their relationships clear and consistent? (next lecture)
36 35
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.