Other Requirements

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.

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 Topics for a Vision

Product Perspective Summary of Benefits Assumptions and Dependencies Cost and Pricing Licensing and Installation Summary of System Features Other requirements and constraints Vision—Product Overview

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.

Common Functionality Logging Error Handling Business Rules Security Usability Reliability Recoverability Performance Supportability Adaptability Configurability Implementation Constraints Purchased Components Supplementary 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 More Specifications

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.

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.

Other Requirements