Other Requirements

1 / 31
About This Presentation
Title:

Other Requirements

Description:

Fast, Cheap, Good -- choose any two. We are back to Time, Cost and Quality. ... to work around seniority, FAA rules, union contracts, vacations, and illness. ... – PowerPoint PPT presentation

Number of Views:46
Avg rating:3.0/5.0
Slides: 32
Provided by: george85

less

Transcript and Presenter's Notes

Title: Other Requirements


1
Other Requirements
  • Chapter 7
  • Applying UML and Patterns
  • Craig Larman

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

3
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 non-functional requirements, and may be
    captured in a Vision Statement, Glossary and
    Supplementary Specification.

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

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

6
Topics for a Vision
  • Stakeholders
  • Market Demographics
  • Non-user Interests
  • User Interests
  • Key goals and problems for stakeholders
  • User Goals and environment
  • Introduction
  • Positioning
  • Business Opportunity
  • Problem Statement
  • Product Position
  • Alternatives
  • Competition

7
VisionProduct Overview
  • Product Perspective
  • Summary of Benefits
  • Assumptions and Dependencies
  • Cost and Pricing
  • Licensing and Installation
  • Summary of System Features
  • Other requirements and constraints

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

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

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

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

12
Supplementary Specifications
  • Common Functionality
  • Logging
  • Error Handling
  • Business Rules
  • Security
  • Usability
  • Reliability
  • Recoverability
  • Performance
  • Supportability
  • Adaptability
  • Configurability
  • Implementation Constraints
  • Purchased Components

13
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

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

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

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

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

18
Some Sample Domains
  • Inventory, Accounting, Queuing and Scheduling

19
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 Waltons children make up half
    of the ten richest people in the world.

20
Wal-Marts 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.

21
Economic Order Quantity
  • K-Marts 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.

22
Just-In-Time Inventory
  • By contrast, Wal-Marts system has advantages for
    both the store and the manufacturer. With
    continuous resupply, the manufacturer doesnt
    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 dont buy it elsewhere.

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

24
Manufacturers Inventory
  • The distinctive nature of a Manufacturers
    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.

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

26
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 Accountants Microsystems Inc., and I
    could sell and install a turn key system with
    both specialties and the associated hardware.

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

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

29
Possible Steps in Scheduling
  • Task Identification
  • Demand Forecasting
  • Constraint Identification
  • Resource Leveling
  • Resource Availability
  • Resource Allocation
  • Location Shifting
  • Last-minute changes
  • Feedback

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

31
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.
Write a Comment
User Comments (0)