larman chapter 7

8/12/2019 Larman Chapter 7

1/14

Other Requirements

Chapter 7

Applying UML and Patterns

-Craig Larman


2/14

Introduction While the primary requirements of a

computer system tend to be the functional

requirements

the list of activities that thesystem must perform, it is also necessary tocapture an number of other requirements tobuild a system. These are called non-

functional requirements, and may becaptured in a Vision Statement, Glossaryand Supplementary Specification.


3/14

Supplementary Specification

Documentation costs money and takestime. Use only enough resources to

produce the desired results efficientlyand effectively.

Documentation

Packaging

Licensing

Supportability


4/14

The Vision

The Vision serves to communicate toproject sponsors and key stakeholders

the reasons for the project, the problemsto be solved, a description of thestakeholders and their needs, along witha description of the proposed solution. It

includes the core requirements andbecomes the contractual basis todevelop further requirements.


5/14

Topics for a Vision

Introduction

Positioning

BusinessOpportunity

Problem Statement

Product Position

Alternatives Competition

Stakeholders

MarketDemographics

Non-user Interests User Interests

Key goals andproblems for

stakeholders User Goals and

environment


6/14

Why system features in Vision?

Use cases are not the only way to

describe functional requirements.

Sometimes a succinct list of keyfunctional requirements will give a better

immediate grasp of the problem and

proposed solution.


7/14

Glossary

The Glossary captures terms and theirdefinitions in the business domain supportedby the system.

Be careful. Even simple terms may meandifferent things to different stakeholders andneed to be defined.

The Glossary can also perform the role of aData Dictionary, or be supplemented byone.


8/14

Supplementary Specifications

Common Functionality

Logging

Error Handling Business Rules

Security

Usability

Reliability

Recoverability

Performance

Supportability

Adaptability Configurability

Implementation

Constraints

Purchased

Components


9/14

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


10/14

Domain Rules

Domain or Business Rules are not functional

requirements. Domain Rules tell how the

business works, while functionalrequirements 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/14

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 areasmight include Retail, Insurance, Wholesaling,

Light Manufacturing, and Electric Utilities.


12/14

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, andqueuing. Each has a body of specific

knowledge that specialists know well.


13/14

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 distinctapproaches, each of which is used

across a variety of industries.


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

larman chapter 7

Documents