1. Chapter 7 Applying UML and Patterns -Craig Larman
Other Requirements
Chapter 7
Applying UML and Patterns
-Craig Larman

2. Introduction
While the primary requirements of a computer system tend to be the functional requirements—the list of activities that the system must perform, it is also necessary to capture an number of other requirements to build a system. These are called non-functional requirements, and may be captured in a Vision Statement, Glossary and Supplementary Specification.

3. Supplementary Specification
Documentation costs money and takes time. Use only enough resources to produce the desired results efficiently and effectively.
Documentation
Packaging
Licensing
Supportability

4. The Vision
The Vision serves to communicate to project sponsors and key stakeholders the reasons for the project, the problems to be solved, a description of the stakeholders and their needs, along with a description of the proposed solution. It includes the core requirements and becomes the contractual basis to develop further requirements.

5. Topics for a Vision Stakeholders Introduction Positioning
Market Demographics
Non-user Interests
User Interests
Key goals and problems for stakeholders
User Goals and environment
Introduction
Positioning
Business Opportunity
Problem Statement
Product Position
Alternatives
Competition

6. Why system features in Vision?
Use cases are not the only way to describe functional requirements. Sometimes a succinct list of key functional requirements will give a better immediate grasp of the problem and proposed solution.

7. Glossary
The Glossary captures terms and their definitions in the business domain supported by the system.
Be careful. Even simple terms may mean different things to different stakeholders and need to be defined.
The Glossary can also perform the role of a Data Dictionary, or be supplemented by one.

8. Supplementary Specifications
Common Functionality
Logging
Error Handling
Business Rules
Security
Usability
Reliability
Recoverability
Performance
Supportability
Adaptability
Configurability
Implementation Constraints
Purchased Components

9. More Specifications Interfaces Domain Rules (business rules)
Hardware
Software
Domain Rules (business rules)
Legal Issues
Reports
Operating Systems
Networking Systems
Process Tools
Development Tools
Design Constraints
Internationalization
Standards
Physical Environment
Operation Rules

10. Domain Rules
Domain or Business Rules are not functional requirements. Domain Rules tell how the business works, while functional requirements tell how the system works. Company policies, the laws of physics, and government regulations are examples of Domain Rules.
Do not include system features.

11. Industry Domains
Most computer consulting firms organize their staff by industry, so that they can develop application specific knowledge that will be useful to the companies hiring them.
In New Jersey, most consulting companies have at least a Telecommunications Practice and a Pharmaceutical Practice. Other areas might include Retail, Insurance, Wholesaling, Light Manufacturing, and Electric Utilities.

12. Knowledge Domains
In addition to Industry specific knowledge, there are many areas of knowledge that apply across a number of industries.
The most thoroughly specified of these knowledge domains is accounting. Others might include inventory, scheduling, and queuing. Each has a body of specific knowledge that specialists know well.

13. Sub-Domains
Within each knowledge domain, there are often specialized sub-domains.
For example, Retail Inventory, Just-In-Time Inventory, Service Inventory, Manufacturers Inventory, and Serial Number Inventory are distinct approaches, each of which is used across a variety of industries.

14. UML Diagrams in Inception
Aside from the possible inclusion of a few high level use case diagrams, the inception phase is almost all text.
Most diagramming occurs in the Elaboration Phase.