7 . Other Requirements

1. 7. Other Requirements CSE 5324 Quiz 6 due at 5 PM, Saturday, 6 September 2014

2. 7. Other Requirements • Objectives: • Describe Supplementary Specification, Glossary, Vision and Business Rules artifacts. • Contrast these with use cases. • Define quality attributes. • Introduction: The other requirement artifacts give our case studies cohesion and provide more complete requirements examples. • Artifact definitions: • Supplementary Specifications capture and identify essential requirement-related reports, documentation, packaging, support and licensing. • The Glossary defines terms and can be used as a data dictionary. • The Vision document tersely communicates big ideas in an executive summary. • The Business (Domain) Rules capture long-living and project-spanning policies; e.g., relevant tax laws.

3. 7.1-7.3 Example Depth, Guidelines • These secondary requirements artifacts are treated with enough detail to highlight important issues. • It is important to have a top 10% list of coarse-grained requirements at Inception. As “big idea repositories,” the Vision and Supplementary Specification help clarify a first approximation of what the user wants early on. • These documents should be at the project Wiki for everyone to see and comment upon.

4. 7.4 NextGen POS Supplementary Spec • Topics: • Revision History. • Introduction. • Functionality: logging, error handling, security. • Usability: human factors metrics. • Reliability: recoverability, performance. • Supportability: adaptability, configurability. • Third-party vendor purchased components. • Free open-source components. • Interfaces: hardware, software. • Application-specific business rules: discounts. • Legal issues: taxes, licensing restrictions. • Miscellaneous: pricing, credit payments, sales tax, UPCs.

5. 7.5 Supplementary Spec Comments • Got system-wide usability, reliability, perfor-mance, supportability and more (URPS+). • Software architecture’s principle concern is to identify and resolve quality attributes in the context of functional requirements; e.g., NextGen’s tolerance of remote service faults. • Narrow applications rules can be in the SS; e.g., an algorithm for calculating discounts. • Subject matter experts explain system relevant complex formulas for the developers in the SS.

6. R U O K ? Match the following artifacts with their definitions: • Supplementary Specification __ • Glossary __ • Vision __ • Business (Domain) Rules __ • Defines terms and can be used as a data dictionary. • Tersely communicates big ideas in an executive summary. • Captures and identifies essential requirement-related reports, documentation, packaging, support and licensing. • Capture long-living and project-spanning policies; e.g., relevant tax laws.

7. R U O K ? 5. Which of the following does NOT describe a role played by the secondary requirements artifacts? __ • They include only enough detail to highlight the important issues. • They point out functional requirements that were carelessly omitted from the use cases. • Producing the top 10% list of coarse-grained requirements at Inception helps clarify a first approximation of what the user wants early on. • Uploading these artifacts to the project Wiki allows everyone to see and correct them.

8. R U O K ? 6. Which of the following topics would you NOT expect to find in a Supplementary Specification artifact? __ • Functionality • Usability • Definitions • Reliability • Supportability

9. R U O K ? 7. Which of the following does NOT describe how the Supplementary Specification benefits its system development project? __ • It clearly documents the system’s usability, reliability, performance, supportability and more (URPS+). • Its executive summary presents a common vision of the project for all participants. • It clearly describes project-specific application rules; e.g., an algorithm for calculating discounts. • It guides the software architect’s identification and resolution of quality attributes in the context of functional requirements; e.g., NextGen’s tolerance of remote service faults. • It captures subject matter experts’ complex formulas for later use by developers; e.g., earth- to aircraft-coordinate transforms.

10. 7.6 NextGen’s Partial Vision • Topics: • Revision History. • Introduction. • Positioning: business opportunity, problem statement, product position statement, competition. • Stakeholder Descriptions: market demographics, user and other stakeholder summaries, key goals, user environment. • Product overview: perspective, benefits summary, assumptions/dependencies, cost/pricing, licensing/installation. • System Features Summary: sales capture, authorization. • Miscellaneous: design constraints, -ilities, packaging.

11. 7.7 Vision Comments • This executive summary presents a common vision of the project for all participants. • Terse statements about system features; i.e., externally observable services that directly fulfill stakeholders’ needs; e.g., it authorizes payments. • Key high-level goals that span 30-50 use cases. • Identifying root problems and goals is pro-ject’s most creative, ground-breaking work: brainstorming, fishbone and pareto diagramming, affinity grouping. • Guidelines: • Lists of 10 features should be terse 2-level hierarchies. • Without repeating, summarize all other requirement docs. • Write Vision first, and revise it after writing use cases.

12. 7.8-7.9 Glossary & Data Dictionary • Topics: • Revision History. • Definitions: term, definition, format, range of values, validation rules, aliases, relationships with other elements (i.e., requirements). • Start the glossary early; it will clarify discussions. • Loaded terms like the “payment authorization request” nickname for an aggregate of data should be carefully explained in the glossary.

13. 7.10 Business/Domain Rules • Topics: • Revision History. • Rule List: identifier, rule, changeability, source. • Domain rules tell how a domain or business can operate: policies, government laws. (A weather simulation includes physical laws.) • Rules can span many projects. • Rules may clarify ambiguities in use cases, which emphasize story flow, not details. (A Process Sale rule may allow or prohibit credit payments without signature capture.)

14. 7.12 Evolutionary Requirements Table 7.1 Sample UP artifacts and their timings. • Started along with the use case model in the UP’s Inception phase, the SS, Vision, Glossary and Business Rules artifacts get refined in the Elaboration phase (Table 7.1): • Inception: Vision summarizes the project in a way that informs management’s go/no go decision. The prelim-inary Supplementary Specification helps expose risks. • Elaboration: Building important parts of the system focuses requirements and revises the vision. Stakeholders’ engagement continues. • Construction: Vision and SS don’t change much, and requirements settle down to minor perturbations.

15. R U O K ? 8. Which of the following topics would you NOT expect to find in a Vision artifact? __ • Positioning. • Stakeholder descriptions. • Product overview. • System features summary. • Supportability.

16. R U O K ? 9. Which of the following does NOT describe how the Vision artifact benefits its system development project? __ • It presents a common vision of the project for all participants. • It makes terse statements about system features; i.e., those externally observable services that directly fulfill stakeholders’ needs. • It uniquely presents key high-level goals that span 30-50 use cases. • It clearly documents the system’s usability, reliability, performance, supportability and more (URPS+). • By identifying root problems and goals, it stimulates the project’s most creative, ground-breaking work.

17. R U O K ? 10. Which of the following topics would you NOT expect to find in a Glossary artifact? __ • Definitions of terms: term, definition, format, range of values, validation rules, aliases, relationships with other elements (i.e., requirements). • A data dictionary for use in object model and sequence diagrams. • Loaded terms like the “payment authorization request” nickname for an aggregate of data should be carefully explained in the glossary. • Reliability.

18. R U O K ? 11. Which of the following topics would you NOT expect to find in a Domain Rules artifact? __ • Usability. • Domain rules. • Who made each rule. • Who is authorized to change it. • Relevant government laws.

19. R U O K ? 12. Which of the following does NOT describe how the Domain Rules artifact benefits its system development project? __ • The Domain Rules artifact indicates the source of each rule and who is authorized to change it. • It precisely defines how a domain (or business) must operate, by stating company policies and relevant government laws. • If the product is something like a weather simulation, the Domain Rules artifact also includes physical laws; e.g., heat rises. • Its rules organize the company’s product line(s) by spanning many projects. • It uniquely presents key high-level goals that span 30-50 use cases. • Rules may clarify ambiguities in use cases, which emphasize story flow, not details.

20. R U O K ? Match the UP’s first three project phases with their roles in evolving the secondary requirement artifacts described below. 13. Inception __ 14. Elaboration __ 15. Construction __ • Building important parts of the system focuses requirements and revises the vision. Stakeholders’ engagement continues. • Vision summarizes the project in a way that informs management’s go/no go decision. The preliminary Supplementary Specification (SS) helps expose risks. • Vision and SS don’t change much, and requirements settle down to minor perturbations.