NJIT

Other Requirements

Chapter 7

Applying UML and Patterns

Craig Larman

Trade Offs

Fast, Cheap, Good -- choose any two. We are back to Time, Cost and Quality.

Each will affect the others. When I had my own business, I used

several different printers for different combinations of fast, cheap, and good.

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.

Not a checklist

This section is not a listing of things that have to be documented in a system. It is a description of a wide variety of possible items and artifacts.

Documentation costs money and takes time. Use only enough resources to produce the desired results efficiently and effectively.

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

Vision—Product Overview

Product Perspective Summary of Benefits Assumptions and

Dependencies Cost and Pricing Licensing and

Installation

Summary of System Features

Other requirements and constraints

Key Vision Questions

Problem Statement Key High Level Goals Key Problems for the Stakeholders What are the root problems and goals?

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 Specification

The Supplementary Specification captures such requirements as documentation, supportability, packaging, licensing and many of the “-ilities” of systems.

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

NJIT

Some Sample Domains

Inventory, Accounting, Queuing and Scheduling

Inventory

Doing Inventory right can give a company an overwhelming competitive advantage.

Wal-Mart is really a computerized Retail Just-In-Time inventory system with stores attached. It is so good that it put K-Mart in bankruptcy and Sam Walton’s children make up half of the ten richest people in the world.

Wal-Mart’s Inventory

Wal-Mart puts the responsibility for restocking their stores on their suppliers. Every time an item is sold, the cash register notes the transaction and the store computer accumulates them. The suppliers have direct access to this information, and send resupplies whenever necessary.

Economic Order Quantity

K-Mart’s Inventory was based on EOQ, which balances off quantity discounts against the cost of placing an order. This is an adversarial system, because stores want small orders (to avoid overstock sales and costly warehousing) while manufacturers want big orders so they can run production lines efficiently.

Just-In-Time Inventory

By contrast, Wal-Mart’s system has advantages for both the store and the manufacturer. With continuous resupply, the manufacturer doesn’t have to wait for an order. They might keep one production line running all year. In addition, both parties benefit from keeping an item in stock so that customers don’t buy it elsewhere.

Another JIT Example

The automobile industry has long sought to have Just-In-Time Inventory. Factory complexes have been built in Spain and Brazil where parts manufacturers own plants next to the automobile assembly plants. In some cases, the part manufacturers even put their parts on the car on the assembly line.

Manufacturer’s Inventory

The distinctive nature of a Manufacturer’s Inventory is the “Kit.” A Kit is a collection of parts that might include other Kits. For example, a right front door kit for an automobile might include a door shell kit, a window kit, an inside panel kit, a lock kit, a door handle, an armrest and other items.

Serial Number Inventory

The distinctive feature of a serial number inventory is that each item is unique. You cannot apply the idea of Economic Order Quantity. Think of an Automobile Dealer. Even if two cars are the same make, model, and color, with the same accessories, they have unique Vehicle Identification Numbers, and must be tracked separately.

Accounting Sub-Domains

Another knowledge domain that has specialized sub-domains is accounting. I used to own a company that sold accounting systems to Certified Public Accountants.

I had two specialties; tax preparation software and client write-up software, and I represented several manufacturers of software. My main source was Accountant’s Microsystems Inc., and I could sell and install a turn key system with both specialties and the associated hardware.

Queues

Queuing theory is used in a wide variety of industries, because no one can afford to maintain resources for peak demand in times of slack demand. Think of tellers in a bank, cash registers in a store, pumps at a gas station, or telephone switches in a central office.

Queuing theory helps banks identify how many tellers they need, and tells local phone companies when they need to upgrade their central offices.

Scheduling

Resource scheduling is closely related to queuing theory. Once you know what your demand for resources is, how do you fulfill those demands?

One of the most demanding scheduling tasks is airline crew scheduling. You need the right number of people in the right place at the right time, and have to work around seniority, FAA rules, union contracts, vacations, and illness.

Possible Steps in Scheduling

Task Identification Demand Forecasting Constraint Identification Resource Leveling Resource Availability Resource Allocation Location Shifting Last-minute changes Feedback

Requirements Reliability

Never assume that requirements are completely understood, adequately captured, effectively described, or reasonably complete.

Requirements discovery and scope creep tend to occur throughout the software development process and even after the system is put into production.

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.