Comprehensive Guide to System Architecture Methodology: Conceptual Analysis, Business Analysis, Requirement Analysis, and Design Phases

Conceptual Analysis

Before the article starts, several concepts are explained: methodology as the process from input to expected output, design as a documented expression of intent, and the role of a system architect who considers people, hardware, software, and network.

Business Analysis

Overview

Business analysis studies the domain before system development to understand concepts and processes, aiming to optimize workflows and create business value.

Business Analysis Phase Activity Model

The phase produces a domain model and a business model.

Domain Model

A visual representation of domain concepts and relationships, often depicted as class diagrams; common errors include mixing the system into the domain model and unclear concept partitioning.

Purpose of Domain Model

The domain model helps align team understanding, guides database and system design, and ensures consistent implementation.

Business Model

Captures the dynamic aspects of business, defining business objects (actors, workers, entities), business use cases, and processes, illustrated with a restaurant example.

Business Use Cases

Describe services an organization provides externally.

Business Process

Uses sequence diagrams to show workflow before and after system implementation, highlighting the value of automation.

Purpose of Business Process Analysis

Express dynamic operation of the business.

Enable better system support design.

Assess value by comparing pre‑ and post‑implementation processes.

Summary

Understanding both static (domain model) and dynamic (business process) aspects is essential before building a system.

Requirement Analysis

Requirement analysis is part of requirement engineering, covering early research, analysis, definition, and later management (validation, tracking, change control). Architects focus on analysis and definition.

Requirement Analysis Phase Activity Model

Outputs include system context, functional requirements (use‑case model), and non‑functional requirements.

System Context

A diagram showing the system’s relationships with users and external systems.

System Use Cases

Named with verb phrases, derived from business processes.

Difference Between System and Business Use Cases

Business use cases describe organizational capabilities; system use cases describe system capabilities.

A system use case is an operation within a business flow.

Functional vs Use Case

Use cases are dynamic artifacts; functional specifications are static design outputs.

Non‑Functional Requirements

Include usability, performance, security, economy, scalability, portability, and other quality attributes.

Architecture Design (Key)

Architects translate analysis results into architecture, focusing on component decomposition, logical and physical architectures, and meeting functional and non‑functional requirements.

Components, Functions, Modules

Components are process‑level units; functions and modules belong to design phases. A component may contain multiple modules that cooperate to realize a function.

Architecture

Defines the internal structure (components and their relationships) and technical elements; design aims to satisfy both functional and non‑functional needs.

Architecture Design Phase Activity Model

Produces an architecture work plan, logical architecture, physical architecture, component lists, deployment plans, and technology selection.

Logical Architecture (Non‑Technical)

Decomposes the system into logical components and relationships, using component diagrams for static relations and sequence diagrams for dynamic interactions; readable by non‑technical stakeholders.

Physical Architecture (Technical)

Maps logical components to technical components (subsystems, processes, objects) and addresses non‑functional concerns.

Summary

Architecture design determines component division, key technology decisions, and overall system quality, cost, and efficiency.

High‑Level and Detailed Design

High‑Level Design

Focuses on functional module division and interface definitions (names, purposes, parameters, return values).

Detailed Design

Covers internal module implementation, UI design, and database design.

Subsequent Engineering Phases

Development Phase

Developers implement code based on architecture and detailed design artifacts.

Testing Phase

Testers verify functional and non‑functional requirements, delivering a test plan, test cases, and test report.

Deployment Phase

Deployers execute deployment plans, schemes, manuals, scripts, and implementation steps.

Operations Phase

Operations staff produce operation plans, schemes, manuals, scripts, and reports to maintain the system.