Navigation
SYSTEM ANALYSIS AND DESIGN Module Specification
Unit 1: Module Specification
1. What is a Module Specification?
A module specification (also called module design specification, component specification, or function specification) is a formal document that describes a single module (subroutine, function, method, or procedure) in sufficient detail for a programmer to implement it correctly without needing further clarification.
Analogy: If modularization is the architectural blueprint of a house, a module specification is the detailed instruction sheet for building one specific room – including dimensions, materials, wiring, plumbing, and how it connects to adjacent rooms.
)
1.1 Purpose of Module Specification
| Purpose | Explanation |
|---|---|
| Unambiguous guidance | Programmers know exactly what to code. |
| Contract between design and implementation | Defines what the module does (not how it does it internally – but the specification includes internal logic via structured English). |
| Basis for unit testing | Test cases are derived directly from the specification. |
| Documentation for maintenance | Future developers understand the module without reading code. |
| Reusability | Clear specifications make modules easier to reuse in other projects. |
1.2 Module Specification vs. Other Artifacts
| Artifact | Focus | Level of Detail |
|---|---|---|
| DFD process | What the process does (input/output) | High‑level |
| Data dictionary | Data structures | Data‑only |
| Structured English | Algorithmic logic | Detailed, but may be informal |
| Module specification | Complete, formal description of a module (interface + logic + data + errors) | Most detailed |
| Code | Executable implementation | Implementation |
2. Components of a Module Specification
A complete module specification typically contains the following sections. (Use a standard template.)
)
2.1 Identification
- Module name – Unique, meaningful, verb‑noun (e.g.,
Calculate_Tax,Validate_Customer). - Module ID / number – Mapping to structure chart or DFD process (e.g.,
MOD-2.3.1). - Author – Analyst/designer responsible.
- Date – Created and last modified.
- Version – For change control.
2.2 Purpose / Description
A one‑to‑two sentence summary of what the module does.
Example: “This module computes the federal income tax based on the employee’s gross pay and filing status.”
2.3 Interface Specification
Defines how other modules (or the outside world) communicate with this module.
| Interface Element | Description |
|---|---|
| Input parameters | List each parameter: name, data type, length, range, whether optional, and description. |
| Output parameters / return value | Similar detail. |
| Global data accessed (if any) | Names of global variables or shared data areas (discouraged but sometimes needed). |
| Files / databases accessed | Data stores read or written (by name, as in data dictionary). |
| Exceptions / error indicators | How the module signals errors (e.g., return code, exception flag). |
](/images/tutorials/system-analysis/interface_spec_diagram.svg)
)
Example Interface:
Module: CALC_TAX
Inputs:
- Gross_Pay (decimal, 7,2; range 0.00 – 10,000.00; mandatory)
- Filing_Status (character, 1; values: 'S'=single, 'M'=married; mandatory)
Output:
- Tax_Amount (decimal, 7,2; range 0.00 – calculated value)
Files accessed: Tax_Rate_Table (read only)
Error indication: Returns -1 if Gross_Pay is negative or Filing_Status invalid.
2.4 Local Data Structures
List any variables, constants, or arrays that are used only inside the module (not visible outside).
Example:
Tax_Bracket(integer)Rate(decimal, 5,3)MAX_GROSS = 10000.00(constant)
2.5 Processing Logic (Algorithm)
Written in Structured English (or pseudocode). Must be detailed enough to convert directly to code.
2.6 Error Handling
Describe how the module responds to invalid inputs, missing data, or runtime errors (e.g., file not found).
2.7 Performance Constraints
Response time, maximum calls per second, memory usage, etc.
2.8 Dependencies / Called Modules
List other modules that this module calls (sub‑modules). If none, it is a leaf module.
3. Writing a Good Module Specification
| Practice | Why |
|---|---|
| Use a standard template | Ensures completeness and consistency across modules. |
| 1–3 pages per spec | Long specifications indicate low cohesion; split the module. |
| Write for a programmer | Avoid jargon; define all terms. |
| Specify the “what” and the “how” | Both interface (what) and algorithm (how) are needed for implementation. |
| Validate with a structured walkthrough | Review with other analysts and a lead programmer. |
4. Complete Module Specification Example
System: Payroll System
Module Name: CALC_TAX
Module ID: MOD‑4.2
Author: J. Analyst
Date: 2025-04-06 Version: 1.0
4.1 Purpose
Calculate the federal income tax withholding for an employee based on gross pay and filing status, using progressive tax brackets.
4.2 Interface
- Inputs:
Gross_Pay,Filing_Status - Outputs:
Tax_Amount - Error indication: Function returns -1.
4.3 Processing Logic (Structured English)
BEGIN CALC_TAX (Gross_Pay, Filing_Status)
IF Gross_Pay < 0 OR (Filing_Status <> 'S' AND Filing_Status <> 'M') THEN
RETURN -1
ENDIF
CALL GET_TAX_RATE (Gross_Pay, Filing_Status) -> Rate, Bracket
Tax_Amount = Gross_Pay * Rate
IF Tax_Amount > 2000 THEN
Tax_Amount = 2000
ENDIF
RETURN Tax_Amount
END
5. Module Specification in the Context of SAD Lifecycle
)
Requirements → DFDs → Data Dictionary → Decision Tables/Trees →
Modularization (Structure Chart) → Module Specifications →
Coding → Unit Testing
5.1 Relationship to Other Design Artifacts
| Artifact | How it relates to Module Specification |
|---|---|
| Structure chart | Each box on the chart corresponds to one module specification. |
| DFD primitive process | May map to one module specification (or several). |
| Data dictionary | Data types and structures used in the module interface. |
| Decision table | May be used as the logic section of a module specification. |
| Structured English | The processing logic section is written in Structured English. |
6. Summary and Key Takeaways
- A module specification is the detailed blueprint for a single module – the direct input to coding and unit testing.
- It must be complete, unambiguous, and verifiable. Use a standard template to avoid missing sections.
- The interface is a contract: once frozen, changes require approval.
- Processing logic should be written in Structured English (pseudocode).
- Include error handling and test cases as part of the specification, not afterthoughts.