Other Requirements

Chapter 7 Applying UML and Patterns -Craig Larman

Introduction

While the primary requirements of a computer system tend to be the functional requirementsthe 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 nonfunctional 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

Introduction Positioning Business Opportunity Problem Statement Product Position Alternatives Competition

Stakeholders Market Demographics Non-user Interests User Interests Key goals and problems for stakeholders User Goals and environment

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 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-InTime 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.