Software Quality Assurance Requirements: Introduction

1
Software Quality AssuranceRequirements
Introduction

• Charles Wallace
• Michigan Technological University
• wallace_at_mtu.edu

2
Requirements definition

• A successful software product solves some problem
  in the real world
• Requirements Customers definition of a
  satisfactory solution,
• stated as constraints on the softwares effects
  on the real world
• not on the software itself
• after all, the customer is interested in the
  problem, not the software
• Confusion over requirements (missing or changing
  requirements,
• ambiguity, poor documentation) a significant
  source of risk

3
Functional vs. Nonfunctional

• Requirements typically classified as
• functional (dealing directly with system
  behavior)
• nonfunctional (e.g. cost, usability, performance)
• A product may be correct
• (satisfying all functional requirements)
• but fail to meet important nonfunctional
  requirements

4
Formalizing requirements An example(Jackson,
1995)
Two signs at the beginning of an escalator
Interpretation (?rider r) (?shoes s) wears(r,s)
Shoes must be worn
?
(?shoe s) (?rider r) wears(r,s)
Interpretation (?pet p) (?rider r) carries(r,p)
Pets must be carried
?
(?rider r) (?pet p) carries(r,p)
5
Domain understanding An example
Poké-POWER Heal Dance Once during your turn
(before your attack), you may remove 2 damage
counters from 1 of your Pokémon. You cant
use more than 1 Heal Dance Poké-Power each turn.
This power cant be used if Bellossom is affected
by a Special Condition. (Pokémon/Nintendo,
2004)

• An application domain may already have a
  well-established
• ontology, lexicon, set of best practices (some
  explicit, others implicit)
• How do we learn this information?
• documentation
• observation of the workplace
• user interviews

6
Locating and bounding the problem(Jackson, 1995)
avoids two dangers overgeneralization of
context overgeneralization of
requirements Problem described in terms of
concrete, observable phenomena
Problem domain
phenomena that affect machine state
environment
machine
specification
phenomena visible outside machine
7
What are phenomena?

• events (indivisible, instantaneous)
• states (relations between entities, may change
  over time)
• e.g.
• If the water temperature exceeds 100?F, (state)
• the controller shall turn on the warning
  light. (event)

8
What is the machine?

• The software product under development
• (which possibly interacts with other software
  machines)
• Be careful about what you mean by machine
• e.g. In the workpieces problem pattern
• (word processor, spreadsheet, etc.),
• workpieces are documents, residing in computer
  memory
• best to think of them as outside the machine

9
Example Elevator controller problem
environmental phenomena outside machine
domain detecting arrival of car at a
floor activating cable to lift car illuminating
a floor button on panel machine phenomena
invisible to environment updating car_direction
variable decrementing time_to_door_close
counter adding floor request to
pending_requests shared phenomena "open the
door" command (from controller) "door is
blocked" signal (to controller)
10
What rather than how

• Concentrate on what problem is, rather than how
  to solve it
• Extreme position don't mention order of
  operations
• input/output only
• don't refer to intermediate data structures
• Rationale avoid implementation bias
• Extreme position not always realistic
• Order of operations may be important for
  nonfunctional reasons
• Referring to intermediate data structures often
  eases description

11
References

• M.A. Jackson. Software Requirements and
  Specifications. Addison Wesley, 1995.
• M.A. Jackson. Problem Frames. Addison Wesley,
  2000.
• Pokémon/Nintendo. Belossom. Card 3XC-NR6-ZZB,
  2004.