Download - Larman Chapter 7
-
8/12/2019 Larman Chapter 7
1/14
Other Requirements
Chapter 7
Applying UML and Patterns
-Craig Larman
-
8/12/2019 Larman Chapter 7
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.
-
8/12/2019 Larman Chapter 7
3/14
Supplementary Specification
Documentation costs money and takestime. Use only enough resources to
produce the desired results efficientlyand effectively.
Documentation
Packaging
Licensing
Supportability
-
8/12/2019 Larman Chapter 7
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.
-
8/12/2019 Larman Chapter 7
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
-
8/12/2019 Larman Chapter 7
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.
-
8/12/2019 Larman Chapter 7
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/12/2019 Larman Chapter 7
8/14
Supplementary Specifications
Common Functionality
Logging
Error Handling Business Rules
Security
Usability
Reliability
Recoverability
Performance
Supportability
Adaptability Configurability
Implementation
Constraints
Purchased
Components
-
8/12/2019 Larman Chapter 7
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
-
8/12/2019 Larman Chapter 7
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.
-
8/12/2019 Larman Chapter 7
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.
-
8/12/2019 Larman Chapter 7
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.
-
8/12/2019 Larman Chapter 7
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.
-
8/12/2019 Larman Chapter 7
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.