Requirements Validation

1
Requirements Validation

• Concerned with demonstrating that the
  requirements define the system that the customer
  really wants
• Requirements error costs are high so validation
  is very important
• Fixing a requirements error after delivery may
  cost up to 100 times the cost of fixing a
  requirement error
• Prototyping is an important technique of
  requirements validation
• throwaway prototyping
• evolutionary prototyping

2
Requirements Analysis - Strategies

• Asking - interview, questionnaire, brainstorming
• presupposes that user can bypass his own
  limitations/ bias
• Derivation from an Existing System
• existing system may have its own peculiar
  circumstances
• Synthesis of Environmental Characteristics
• look at the problem situation and establish
  patterns
• Prototyping
• Experiment with prototypes to determine user
  requirement

3
Requirements Specification

• Results of requirements analysis
• Input to the design stage
• Must be
• unambiguous
• complete
• exact (verifiable/testable) e.g. graphical user
  interface is not verifiable
• consistent e.g using the same term
• modifiable - requirements change
• traceable - where did a requirement come from?
• usable

4
Software Requirements Specification

• IEEE standard 830
• 1. Introduction
• An overview of the document
• Purpose
• Scope
• Definitions, acronyms and abbreviations
• References
• Overview
• 2. General Description
• about overall product and matters relating to
  this
• Product Perspective - where it fits
• Product Functions
• User characteristics
• General Constraints
• Assumptions and dependencies

5
Software Requirements Specification

• 3. Specific Requirements
• all the details
• 3.1 Functional Requirements - a description of
  each transformation of inputs to outputs
• 3.2 External interface requirements - User
  interface, Hardware interfaces, Software
  interfaces(e.g. operating system), Communication
  interfaces (e.g. protocols)
• 3.3 Performance Requirements
• static - no. of terminals, no. of users etc.
• dynamic - how frequent?, how fast?
• 3.4 Design Constraints
• Standards
• hardware limitations

6
Software Requirements Specification

• 3.5 Attributes
• Availability
• Security
• Maintainability
• 3.6 Other Requirements
• For more details
• Vliet, H.V, Software Engineering, John Wiley
  Sons, 1993, p145-, P515-

7
SRS An Example

• Software Requirements Specification
• AN AUTOMATED LIBRARY SYSTEM

8
SRS An Example
9
SRS An Example
10
Tools for Specification

• Structured Systems Analysis
• late 1970s - DeMarco, Gane and Sarson, Yourden
  and Constantine
• a structured way of modelling systems
• 2 aspects
• processes
• data
• Processes - DFDs
• Data - Entity Modelling
• Data Dictionary - All data is documented in a
  central repository as the analysis is done

11
Tools for Specification

1
2
X
Y
Z
S
D
P1
P2
W
D1
12
Process Specification

• Decision Trees - graphical representation of the
  decision process
• Decision Tables -Tabular representation of a
  decision process
• Structured English - restricted form of English
  akin to a programming language.

13
Semantic Data Models

• Used to describe the logical structure of data
  processed by the system
• Entity-relation model sets out the entities in
  the system, the relationships between these
  entities and the entity attributes
• Widely used in database design. Can readily be
  implemented using relational databases

14
An Entity-Relationship Model
15
Data Dictionaries

• A data dictionary is a list of names and
  associated descriptions of entities used in the
  system
• It represents a shared repository of system
  information
• It serves as
• A mechanism for name management. As a system
  model may be developed by different people, there
  is potential for name clashes
• A link from analysis to design and implementation
• The structure of a data dictionary can be
  described by a semantic data model (next slide)

16
Structure of Data Dictionary