FUNCTION ORIENTED DESIGN

 Function Oriented Design – A Beginner’s Guide

When designing software, one of the most widely used approaches is Function Oriented Design (FOD). In this method, the system is broken down into smaller, interacting modules — with each module performing a specific, well-defined function. This approach ensures clarity, modularity, and ease of maintenance since the system is viewed primarily from a functional perspective.

What is Function Oriented Design?

Function Oriented Design focuses on decomposing a problem into functions. Each module in the system performs a unique task, and together, these modules collaborate to achieve the overall system goal. Instead of starting with objects or classes (as in Object-Oriented Design), FOD emphasizes functions and data flow.

Design Notations

To represent the design, engineers use notations — either graphical or mathematical — to document decisions and illustrate system behavior. In function-oriented design, the key notations include:

1. Data Flow Diagrams (DFD)

Data Flow Design captures how information moves through the system. A DFD shows:

• The flow of data from inputs to outputs
• The sequence of functional transformations applied along the way

Why DFDs are powerful:

• Easy to understand without technical training
• Clearly depict end-to-end processing (from data entry to output)
• Widely supported by CASE tools for system design

Each DFD consists of symbols representing processes, data stores, and data flows. While the symbols may vary slightly between methods, their purpose remains the same — to visualize how information is processed.

2. Data Dictionaries

A Data Dictionary complements a DFD by providing detailed descriptions of all the data elements used in the system. It serves as a standard reference for developers and analysts, preventing miscommunication in large projects.

For example:

grossPay = regularPay + overtimePay

Here, grossPay is defined in terms of its components: regularPay and overtimePay.

Why it matters:

• Ensures consistent vocabulary across the team
• Defines data structures in terms of their components
• Acts as a knowledge base for future maintenance

3. Structured Charts

A Structured Chart shows how the system is divided into modules and how these modules interact. Think of it as a hierarchy diagram for software functions.

It highlights:

• System partitions into modules
• Relationships between modules
• Flow of information between components

Structured charts treat each module as a black box, where functionality is visible to users without revealing the internal design.

4. Pseudo-code

Pseudo-code is an informal way of expressing system logic using plain English, combined with programming-like constructs. It is especially useful in both preliminary and detailed design phases.

Example constructs:

• If – Then – Else
• While – Do
• End

Pseudo-code makes design decisions easy to read, share, and refine before actual coding begins.

Why Function Oriented Design Matters

Function Oriented Design provides:

• Clarity by focusing on functions and processes
• Consistency through standard notations like DFDs and Data Dictionaries
• Maintainability by modularizing the system into well-defined components

In short, it’s a structured, systematic approach that helps software teams design reliable, scalable systems.

Key Takeaway: Function Oriented Design is all about breaking down a system into functions, mapping out data flow, documenting it with data dictionaries, and structuring it with charts and pseudo-code — making complex systems easier to design and understand.