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
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
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.
Very practical in a large multiprogramming / multiprocessing system.
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!
You may add column attributes as needed.
<<entity>>Unify Analysis Classes
The purpose of “Unify Analysis Classes” 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.