No Silver Bullet

1
No Silver Bullet

• The hardest single part of building a software
  system is deciding precisely what to build. No
  other part of the conceptual work is so difficult
  as establishing all the detailed technical
  requirements, including all the interfaces to
  people, to machines, and to other software
  systems. No other part of the work so cripples
  the resulting system if done wrong. No other
  part is more difficult to rectify later.
• Therefore the most important function that
  software builders do for their clients is the
  iterative extraction and refinement of the
  product requirements. For the truth is, the
  clients do not know what they want.
• Fred Brooks, No Silver Bullet (1987)

2
Requirements Engineering EEE493 2000
Royal Military College of Canada Electrical and
Computer Engineering

• Major Greg Phillips
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

Dr. Scott Knight knight-s_at_rmc.ca 1-613-541-6000
ext. 6190
3
Why do requirements matter?

• represent the first formalization of the desired
  deliverable
• allow for a meeting of minds between the customer
  and the development agency
• provide a basis for size and effort estimates
• provide a firm foundation for initial design work

4
Key Requirements Activities

• Requirements elicitation and analysis
• How can we find out exactly what the software
  system is expected to do?
• Requirements specification
• How can we clearly and precisely communicate the
  requirements to the software system implementers?
• Requirements management
• How can we manage changing requirements through
  the development process?
• Requirements verification
• How can we determine that we have satisfied all
  requirements?

5
Requirements Elicitation and Analysis
6
System Context
Procedures
Hardware
Documents
Software
Database
People
7
Prototyping (requirements)

• problem
• customer defines general objectives but unable to
  identify detailed input, processing, or output
  requirements
• solution

Gather requirements from customer
Build prototype
Customer evaluates prototype
Quick design
Refine prototype
8
Apprenticeship

• the analyst works as an apprentice inside the
  customers organization
• in effect, the analyst takes on the knowledge
  base of the client
• allows the analyst to communicate in the language
  of the customer
• takes considerable time as much as six months
  has been recommended

9
Joint Application Development

• the customer and the analyst work together on the
  problem
• in effect, the customer takes on the role of the
  analyst, with guidance
• requires advanced tools to allow active customer
  participation without prohibitive training
  overhead

10
Human factors engineering

• The focus of a discipline called human-computer
  interaction (HCI) which is at the intersection
  of technology and psychology
• Activity analysis
• Semantic analysis and design
• Syntactic and lexical design
• User environment design

The key activities in HCI work are prototyping
and prototype evaluation.
11
Requirements modeling

• often useful to have a visible model of the
  finished system for customers to examine
• this need not reflect the architecture chosen for
  the final implementation
• some models allow for a limited form of execution
  or simulation, which allows the customer to see
  the system in action before its actually built

12
Requirements Specification
Customer
Developer
Analyst
13
Key Attributes of a Specification

• Meaningful to the customer
• Meaningful to the developer
• Meaning the same thing to both
• Operational
• Comprehensive
• Accurate
• Precise
• Consistent
• Unambiguous

14
Specification Languages

• Natural language
• Structured Text (PDL)
• Diagrams
• data flow (plus extensions)
• control flow
• entity-relationship/object diagrams
• finite state machines
• use cases
• Formal notations
• Vienna Development Method (VDM)
• Z

15
Natural Language Specification

• easy for the customer to follow, however
• natural language is inherently ambiguous
• natural language specifications tend to be
  verbose
• some concepts are difficult to precisely specify
  in a natural language
• the best use of natural language is for
  explanatory text (around the real
  specification) and to specify requirements that
  resist more formal treatments (e.g., must run on
  the existing hardware, etc.)

16
Structured Text

• also referred to as Program Description Language
  (PDL)
• natural language, structured using formal
  programming language constructs
• some PDL (e.g., Ada) can be machine-checked

IF (barcode valid) THEN move box into
appropriate bin ELSE signal
error ENDIF
17
Data flow diagrams
Customer Correspondence
Response to Customer
Preparing Shipments
Receiving Correspondence
Supplier Response
Inventory File
Management Queries
Customer Order
Dept Queries
Order Copy
Keeping Accounts
Stocking Supplies
Reports to Depts.
Management Response
Credit File
Correspondence with suppliers
18
Finite State Machines
Motion
Auto OFF
Auto ON
No motion
ON
OFF
No motion
ON
OFF
Manual ON
Manual OFF
ON
19
Entity-relationship diagrams
Licenses
Stocks
Dealership
Builds
Car
Manufacturer
Transports
Contracts
Shipper
20
Object diagrams and use cases
You know what these look like, right?
21
Formal Notations

• based on mathematical notations, set theory
• possible to prove that the specification has or
  lacks certain properties
• typically used in systems where high reliability
  or security is a goal (e.g., nuclear reactor
  control systems, flight control systems,
  cryptographic systems)

22
Requirements Management
23
Volume

• the sheer volume of specifications can be
  overwhelming on a project of any significant size
• specifications must be organized and structured
  to make them comprehensible to the customer,
  analysts and developers
• this is a non-trivial problem databases and
  hypertext help to some extent
• an automated tool is generally needed to track
  specifications and their fulfillment

24
Change

• on a typical project, specifications change at a
  compound rate of about one percent per month
• specifications must have a baseline at any point
  in time the developers must know to what
  specification they are building
• specification changes should require formal
  authorization, typically by a configuration
  control board
• a change management system is essential

25
Relationships

• in all but the most trivial systems,
  specifications are interrelated
• the relationships must be well understood, so
  that changes to one specification can be
  adequately accounted for in the rest of the
  system
• there are many different types of specification
  relationships

26
Relationships Direct Flow Down
System
A
Subsystem 1
Subsystem 2
Subsystem 3
A
A
A
A
must be fulfilled in each individual subsystem.
27
Relationships Partitioning
System
A
Subsystem 1
Subsystem 2
Subsystem 3
X
Y
Z
Y
Z
A
X
is fulfilled if all of
,
, and
are fulfilled.
28
Relationships Interdependency
System
B
A
Subsystem 1
Subsystem 2
Subsystem 3
X
Y
Z
Y
Z
A
X
is fulfilled if all of
,
, and
are fulfilled,
B
but only as long as
is also fulfilled.
29
Next ClassSize Estimation