Skip to content

Program Construction Methodology

Program Construction Methodology is a systematic approach to building software programs. It consists of two main components:

  1. Overall System Design
  2. Software Development

Important Note: Program construction is the entire journey, while programming is just a part of it.

Prerequisites: Essential Steps Before Development

Section titled “Prerequisites: Essential Steps Before Development”

Before beginning any software project, the following steps must be completed:

  1. System Requirements Analysis
  2. System Requirements Specification
  3. System Architecture Design
  4. System Validation

Requirements are broadly classified into two main categories:

Functional requirements describe what a system must do. They specify the actual functions and behaviors the system needs to have to meet user needs.

Two Approaches to Define Functional Requirements

Section titled “Two Approaches to Define Functional Requirements”

1. Based on Functionality (Specific Functions)

Examples for an Online Banking System:

  • The system must allow users to transfer money between accounts
  • The system must generate monthly account statements
  • The system must calculate interest on savings accounts
  • The system must allow password changes

2. Based on Behavior (How the System Responds)

Input/Output Behavior Examples:

  • Input: User enters correct PIN → Output: ATM displays main menu
  • Input: Invalid login attempt 3 times → Output: System locks account for 30 minutes
  • Input: Account balance below $100 → Output: System sends low balance alert
  • Input: User clicks “Forgot Password” → Output: System sends reset email

Non-functional requirements specify how a system should perform. They are commonly referred to as “-ilities”.

  • Reliability - How dependable is the system?
  • Scalability - Can it handle growth?
  • Usability - How easy is it to use?
  • Maintainability - How easy is it to modify?
  • Security - How well protected is it?
  • Portability - Can it work on different platforms?
  • Availability - How often is it operational?

Characteristics of Non-Functional Requirements

Section titled “Characteristics of Non-Functional Requirements”

Non-functional requirements are often:

  1. Subjective - “The system should be user-friendly”
  2. Ambiguous - “The system should be fast”
  3. Conflicting - May contradict each other

Requirements must be documented to be easily understood by:

  • Non-technical readers (customers)
  • Technical readers (software developers)

Comparison: Functional vs Non-Functional Requirements

Section titled “Comparison: Functional vs Non-Functional Requirements”
AspectFunctional RequirementsNon-Functional Requirements
ObjectiveDescribe what product doesDescribe how product works
End ResultDefine product featuresDefine product properties
FocusOn user requirementsOn user expectations
DocumentationCaptured in Use CasesCaptured as quality attributes
Origin TypeDefined by user (mostly)Defined by developers/experts
Testing• Component Testing
• Module Testing
• API Testing
• UI Testing
• Performance Testing
• Usability Testing
• Security Testing
• Load Testing

This guide provides a structured approach to understanding and implementing program construction methodology for successful software development projects.