Systems Project: System Requirements Specification (SRS) Drafting and Architecture Review

SS3 Term 1 • Week 6

About 45 minutes

In Senior Secondary 3, you have reached the summit of secondary school computing education. You understand the internal registers of the CPU, how data is transmitted through submarine fiber cables, how relational algebra powers database engines, and how transactions prevent financial corruption.

Now, how does a Chief Technology Officer (CTO) or Senior Systems Architect organize all these moving parts into a professional, multi-million-naira software project?

They author a System Requirements Specification (SRS) following the IEEE 830 Standard.

In this capstone mid-term project, you will step into the shoes of a Lead Software Architect designing an enterprise solution: the Kinspire National Student Identity and Examination Portal.

Learning Outcomes

By the end of this project lab, you will be able to:

Structure a formal SRS document adhering to IEEE 830 conventions.
Author measurable functional specifications with unambiguous acceptance criteria.
Map enterprise 3-Tier Architecture incorporating Presentation, Business Logic, and Data Tiers.
Conduct an Architectural Review Audit to detect vulnerabilities, scope creep, and bottlenecks.

Key Vocabulary

Term	Technical Definition
SRS	System Requirements Specification; a comprehensive technical document describing system behavior, features, interfaces, and constraints.
IEEE 830	The international engineering standard governing the structure and content of software specifications.
3-Tier Architecture	A client-server software architecture where Presentation, Application Logic, and Data Management are developed and maintained as independent modules.
Scope Creep	Unplanned, unbudgeted expansion of software requirements during project development without adjusted schedules.
API Gateway	An architectural server component that accepts client API calls, handles authentication, and routes requests to back-end services.
Traceability Matrix	A grid linking each individual client requirement to its corresponding architectural design component and unit test case.

The Standard IEEE 830 SRS Structure

A formal engineering specification contains five core sections:

1. Introduction
   1.1 Purpose of the System
   1.2 Document Scope
   1.3 Definitions, Acronyms, and Abbreviations
   1.4 References
   1.5 Overview

2. Overall Description
   2.1 Product Perspective & Context
   2.2 User Characteristics (Learners, Teachers, System Admins)
   2.3 Operating Environment & Constraints
   2.4 Assumptions and Dependencies

3. Specific Requirements
   3.1 External Interface Requirements (UI, Hardware, Software, API)
   3.2 Functional Requirements (Decomposed with Unique IDs: FR-01, FR-02...)
   3.3 Non-Functional Requirements (Performance, Security, Reliability)
   3.4 Database Logical Requirements (ERD Entities & Normalization)

4. Verification Criteria & Acceptance Testing
   4.1 Test Cases and Traceability Matrix

Modern 3-Tier Enterprise Architecture

Modern cloud applications isolate concerns into three tiers:

[ TIER 1: Presentation Layer ]
  Mobile App (Flutter / Android) & Web Portal (React / Vue)
       │  (HTTPS / REST / JSON)
       ▼
[ TIER 2: Application Logic Layer ]
  API Gateway & Microservices (Python FastAPI / Node.js / Go)
  - Authentication (JWT / OAuth2)
  - WAEC Grading Engine
  - NIBSS Payment Verification
       │  (Encrypted Database Connection / Connection Pool)
       ▼
[ TIER 3: Data Tier ]
  PostgreSQL Relational Database (3NF Normalized) & Redis Cache

Architectural Benefits:

Security: The database is never exposed to the public internet; it sits in a private virtual cloud subnet accessible only by Tier 2.
Scalability: If millions of students check results simultaneously, we can scale Tier 1 and Tier 2 horizontally without touching the database schema.
Maintainability: Modifying the mobile app UI requires zero changes to the SQL database schema.

Practical Activity: Automated SRS Verification and Traceability Checker

Let us write a Python auditing tool that ingests system requirements, checks them for ambiguity, verifies unique requirement IDs, and audits test traceability.

Step 1: Create `srs_audit_tool.py`

# Automated SRS Requirements and Traceability Audit Tool

class Requirement:
    def __init__(self, req_id, category, text, test_case_id):
        self.req_id = req_id
        self.category = category # Functional / Non-Functional
        self.text = text
        self.test_case_id = test_case_id

    def audit_quality(self):
        issues = []
        # Flag ambiguous buzzwords prohibited by IEEE 830
        ambiguous_terms = ["fast", "user-friendly", "flexible", "robust", "approximate", "as soon as possible"]
        for term in ambiguous_terms:
            if term in self.text.lower():
                issues.append(f"Ambiguous term detected: '{term}'. Requirements must be quantitatively measurable.")
        if not self.test_case_id:
            issues.append("Missing Traceable Test Case ID. Untestable requirement!")
        return issues

# Assemble Kinspire SRS Requirements Set
srs_specification = [
    Requirement("FR-01", "Functional", "The system shall authenticate student credentials using 10-digit National ID and biometric fingerprint token.", "TC-AUTH-01"),
    Requirement("FR-02", "Functional", "The system should be user-friendly and fast when printing exam score sheets.", "TC-PRINT-01"),
    Requirement("NFR-01", "Non-Functional", "The API shall process 10,000 concurrent login requests with response latency <= 800 milliseconds.", "TC-LOAD-01"),
    Requirement("NFR-02", "Non-Functional", "The system shall encrypt all stored database records at rest using AES-256 GCM.", None),
    Requirement("FR-03", "Functional", "The portal shall export certified academic transcripts as tamper-evident cryptographic PDFs.", "TC-EXP-01")
]

print("=== KINSPIRE IEEE 830 SPECIFICATION AUDIT ===")
total_reqs = len(srs_specification)
valid_reqs = 0

for req in srs_specification:
    flaws = req.audit_quality()
    print(f"\nAudit: [{req.req_id}] ({req.category})")
    print(f"  Description: '{req.text}'")
    if flaws:
        print(f"  STATUS: REJECTED ({len(flaws)} architectural flaws found)")
        for flaw in flaws:
            print(f"    - {flaw}")
    else:
        print(f"  STATUS: APPROVED (Measurable, verifiable, and traceable to {req.test_case_id})")
        valid_reqs += 1

print("\n" + "=" * 55)
print(f"AUDIT SUMMARY: {valid_reqs} of {total_reqs} requirements passed quality verification.")
if valid_reqs < total_reqs:
    print("ACTION REQUIRED: Systems analyst must revise rejected requirements before architectural sign-off!")

Step 2: Run the Audit Script

python srs_audit_tool.py

Expected Results and Model Output

When you run srs_audit_tool.py, your terminal will display:

=== KINSPIRE IEEE 830 SPECIFICATION AUDIT ===

Audit: [FR-01] (Functional)
  Description: 'The system shall authenticate student credentials using 10-digit National ID and biometric fingerprint token.'
  STATUS: APPROVED (Measurable, verifiable, and traceable to TC-AUTH-01)

Audit: [FR-02] (Functional)
  Description: 'The system should be user-friendly and fast when printing exam score sheets.'
  STATUS: REJECTED (2 architectural flaws found)
    - Ambiguous term detected: 'user-friendly'. Requirements must be quantitatively measurable.
    - Ambiguous term detected: 'fast'. Requirements must be quantitatively measurable.

Audit: [NFR-01] (Non-Functional)
  Description: 'The API shall process 10,000 concurrent login requests with response latency <= 800 milliseconds.'
  STATUS: APPROVED (Measurable, verifiable, and traceable to TC-LOAD-01)

Audit: [NFR-02] (Non-Functional)
  Description: 'The system shall encrypt all stored database records at rest using AES-256 GCM.'
  STATUS: REJECTED (1 architectural flaws found)
    - Missing Traceable Test Case ID. Untestable requirement!

Audit: [FR-03] (Functional)
  Description: 'The portal shall export certified academic transcripts as tamper-evident cryptographic PDFs.'
  STATUS: APPROVED (Measurable, verifiable, and traceable to TC-EXP-01)

=======================================================
AUDIT SUMMARY: 3 of 5 requirements passed quality verification.
ACTION REQUIRED: Systems analyst must revise rejected requirements before architectural sign-off!

Common Mistakes to Avoid

Using Subjective, Unmeasurable Adjectives in Requirements: Saying software must be "robust," "fast," or "intuitive" creates disputes during acceptance testing. Always use quantitative thresholds: "Latency $\le 800\text{ ms}$ under $10,000$ active connections."
Failing to Maintain a Traceability Matrix: Every functional requirement must link to a specific test case ID (TC-XXX). If a requirement has no test case, there is no proof it works.
Confusing Architectural Tiers with Physical Machines: 3-Tier architecture is a logical separation of concerns. During early prototyping, all three tiers can run on a single developer laptop. In production, they are deployed across separate distributed servers.

Notebook Summary

The IEEE 830 Standard structures System Requirements Specifications into Scope, Description, Specific Requirements, and Verification Criteria.
3-Tier Architecture separates Presentation (UI), Application Logic (Business Services), and Data (Storage), enhancing security, maintainability, and scalability.
Requirements must be atomic, measurable, unambiguous, and traceable to verification test cases.
Formal requirements audits prevent scope creep and catastrophic engineering failures.

Optional Extension Challenge

Rewrite requirement FR-02 from the lab exercise to eliminate all ambiguous language and author an accompanying test case specification (TC-PRINT-01) detailing the preconditions, input action, and expected measurable outcome.