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

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.

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

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.

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

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.

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.

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

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

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.

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.

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.

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.

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.