Function Definition
 From Investigation to Specification
 Defining Functions
 The Universal Function Model
 Identifying and Documenting Functions
 Function Navigation Models
 Dialogues
Investigation
FEASIBILITY
Feasibility Report
Develop
Business
Activity Model
Overview DFM
BAM
Investigate
and Define
Requirements
Investigate
Current
Processing
Current Physical DFM
Task Models
Derive
Logical View of
Current
Services
Logical DFM
Current Environment LDM
Requirements Catalogue
Task Models
Assemble
Investigation
Results
Investigate
Current
Data
Investigation
Specification
Define Work
BSO
Practice Model
BSO
Requirements Catalogue
Logical DFM
Requirements Catalogue
Current Environment LDM
User Catalogue
Task Models
User Roles
Develop Users’
Define Required
Develop
Conceptual
System
Required Data
Models
Processing
Model
User Object Models
Required System DFM
Task Models
User Object Model
Task Models
Requirements Catalogue
Derive System
Enhance
Functions
Required Data
Model
Req. System LDM
Function
Definitions
Develop
Develop
Processing
Specification
Prototypes
Req. System LDM
Function
Specification
Definitions
Window Specifications
Window Navigation Models
Task Models
Entity Life Histories
Help System
Effect Correspondence Diagrams
Specifications
Enquiry Access Paths
Requirements Catalogue
User Object Models
Dialogue Structures
Required System LDM
Assemble
Requirements
Specification
Requirements Catalogue
Defining Functions
The technique of Function Definition serves a
number of different purposes:
 To define the services that the computerised
system will offer its users;
 To help analysts and users towards a shared
understanding of what the system will do;
 To provide the basis for the system’s
specification;
 To ensure that all design products are
traceable to requirements.
Defining Functions
 The services offered by a computerised
information system to its users are known as
Functions
 The Functions that are available to a given
user depend on that user’s role
 Functions are usually accessed through a
series of one or more menus
 Functions usually involve the user in some
sort of dialogue with the system
Defining Functions
For each Function we will have to:
 Design the human computer interface (and where
applicable interfaces with other computer systems).
 Specify the database processing that supports each
Function.
 Consider ways of preventing erroneous data from ending
up in the database.
 Gather information that can be used to predict and tune
the performance of the Function.
 Ensure that the work done on each Function is not
duplicated elsewhere and make use of work already done
elsewhere.
 Ensure that the Function is included in the user’s training
manual.
Function Definition Concepts
 We can define the concept of a Function
in several ways, which together give a
good idea of what a Function actually is:
A Function is a set of processing that users wish
to carry out at the same time
A Function is a set of processing designed to
handle the effects of an event (or group of
events) on the system
A Function is the basic unit of processing for
input to Physical Design (where programs will be
specified to implement it)
Function Types
We classify each Function in three main ways:
 Enquiry or Update
 User or System Initiated
 On-line or off-line
Function Components
Input
Function
Input
Process
Events
Enquiry
Triggers
Update or
Enquiry
Process
Integrity
Errors
Control Syntax
Errors Errors
Function Definition Boundary
Event &
Enquiry
Output
Database
Function
Output
Process
Valid
Output
Function
Error
Process
Error
Output
Identifying Functions
1
Maintain Purchase Order
1.1
b
Purchaser
P.O.Quantities
Product Details
Supplier
Details
Create
Proposed
Purchase Order
1
Proposed P.O.
Availability
Supplier
Amended P.O.
Confirm
Purchase
Order
Amended P.O.
2
Delivery
Schedule
1.3
Delivery
Schedule
Suppliers
D6
Depot
D1
Purchase
Orders
1.2
Delivery
Details
Stock Clerk
D7
Purchase Order
*
i
Products
Depot Address
*
a
D3
Arrange
Delivery
*
3
Identifying Functions
 Enquiry functions (other than those which
form a major part of the systems
functionality) will be documented in the
Requirements Catalogue, rather than the
Required System Data Flow Model. Each
enquiry entry in the Requirements Catalogue
will initially be identified as a function in its
own right.
Documenting Functions
For each Function we record










An identifier
The Function’s Name
The Function’s type
A description
The business event
The business activity
Error handling
The system event or enquiry
The User Role
DFD Processes
 I/O Structures &
Descriptions and
Dialogues
 Requirements
 Tasks
 User Object Model
 Windows
 Common Processing
 Service Level
Requirements
 Volumes
Function Navigation Models
Functions may be broken down into components when:
 the Function is very large and it is more manageable
to break it down into several parts
 the Function contains more that one event/enquiry:
we can define one or more components for each
event and enquiry
 there are parts of the function that will be used by
other functions too: again events and enquiries will
often feature in more than one function.
Function Navigation Models
Web
Browse
and Buy
Place
Order
Make
Payment
Identifying Dialogues
A good way of identifying dialogues is to use
the Function Definitions and User Role
documentation to identify exactly who will
require access to each function. The easiest
way of documenting this is by using a User
Role/Function Matrix
Identifying Dialogues
Function
User
Role
X X X
Delivery Scheduler
X
Goods In Clerk
Purchaser
X
P. O. Clerk
X X
Stock Keeper
X X
X
Critical Dialogues
Function
User
Role
X X X
Delivery Scheduler
X
Goods In Clerk
Purchaser
X
P. O. Clerk
X X
Stock Keeper
X X
X
Investigation
BAM
RD
DFM
WPM
Conceptual Model
LDM
RDA
Internal design
Construction
External
Design
FD
Policies and Procedures
Specification
User Organisation
BSO
Decision Structure
The Place of Function Definition