Software Analysis, Architecture, and Design

Introduction

Software analysis, architecture, and design transform a problem description into a construction plan for a software system. Analysis asks what the system must accomplish and who needs it. Architecture establishes the system’s major structures, responsibilities, interactions, and quality attributes. Detailed design explains how individual components, data structures, interfaces, and algorithms will work.

These activities are central to the Software Development Life Cycle (SDLC). Poor analysis produces the wrong system; weak architecture produces a system that is difficult to change; and inadequate design produces defects, security weaknesses, and inconsistent user experiences. Effective engineering therefore treats analysis and design as evidence-based decision-making rather than as diagram production.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain abstraction, modularity, separation of concerns, cohesion, and coupling.
2. Translate requirements into models, architectural structures, and design decisions.
3. Compare common architectural patterns and select an appropriate pattern.
4. Design clear software interfaces and data models.
5. Use UML diagrams to communicate system structure and behaviour.
6. Apply usability and accessibility principles.
7. Conduct a structured design review and identify technical risks.
8. Evaluate design trade-offs in a practical software project.

From Requirements to Design

Analysis begins with requirements. Functional requirements describe services or behaviour, such as “the system shall allow a customer to place an order.” Non-functional requirements describe qualities or constraints, such as response time, availability, privacy, maintainability, or legal compliance.

A useful analysis sequence is:

1. Identify stakeholders and their goals.
2. Define the system boundary.
3. Identify actors, events, data, and business rules.
4. Record functional and non-functional requirements.
5. Resolve ambiguity and conflicting expectations.
6. Model important processes and information.
7. Trace each significant design decision to a requirement.

A requirement should be sufficiently clear, testable, feasible, and necessary. “The application should be user-friendly” is valuable as an aspiration but weak as a testable requirement. A stronger statement might be: “A first-time user shall complete account registration using a keyboard and receive validation feedback within two seconds under normal operating conditions.”

Problem Domain and Solution Domain

The problem domain contains the real-world concepts and activities that the software supports: customers, invoices, bookings, or examinations. The solution domain contains software components, databases, APIs, queues, and user interfaces. Analysis concentrates primarily on the problem domain; design connects it to the solution domain.

This distinction reduces premature commitment to technologies. For example, an analysis model may identify a “reservation” and a “payment,” without deciding whether the implementation will use Java, Python, a relational database, or a cloud service.

Core Design Principles

Abstraction

Abstraction represents essential characteristics while hiding unnecessary detail. A payment service may expose authorizePayment(amount, cardToken) while hiding encryption, network protocols, retries, and interaction with a banking provider.

Good abstraction simplifies reasoning. Poor abstraction either exposes implementation details or hides information that clients genuinely need. Abstractions should be based on stable responsibilities rather than on accidental implementation structure.

Modularity

Modularity divides a system into components with defined responsibilities and interfaces. A module may be a class, package, service, library, or deployable subsystem. Modules support parallel development, testing, replacement, and maintenance.

A useful module has:

• a clear purpose;
• a small, understandable public interface;
• controlled dependencies;
• information hidden behind its boundary; and
• independently testable behaviour.

Modularity does not mean that every class must be tiny. Excessive decomposition can create unnecessary interfaces, configuration, and communication overhead.

Separation of Concerns

Separation of concerns assigns different kinds of responsibility to different parts of the system. In a web application, presentation, application coordination, domain rules, and persistence may be separated. A tax calculation rule should not be scattered through HTML templates and database queries.

Separation improves changeability. A visual redesign should not require rewriting business rules, and changing a database vendor should not alter the user-interface logic.

Cohesion

Cohesion measures how strongly the responsibilities within a module belong together. High cohesion is generally desirable. A LoanCalculator containing loan-interest rules is more cohesive than a UtilityManager containing unrelated file, email, date, and payment functions.

Common cohesion levels, from weaker to stronger, include coincidental, logical, temporal, procedural, communicational, sequential, and functional cohesion. These categories are useful for diagnosis, but real systems may contain legitimate mixed responsibilities. The engineering question is whether a module has a coherent reason to change.

Coupling

Coupling describes the degree of dependency between modules. Low coupling is generally desirable because changes in one module then have fewer consequences elsewhere. Tight coupling may arise through shared global data, direct access to another module’s internal database tables, inheritance used only for code reuse, or many unstable dependencies.

Coupling is not eliminated. A useful system must communicate. The objective is controlled coupling through stable interfaces, dependency inversion, events, or data contracts where appropriate.

A practical design heuristic is: seek high cohesion within modules and low, explicit coupling between modules.

Architectural Thinking

Software architecture describes the significant structures of a system, the relationships among them, and the principles governing their design and evolution. Architecture is concerned particularly with decisions that are difficult or expensive to reverse, such as deployment boundaries, data ownership, security mechanisms, and integration protocols.

Architecture should address quality attributes as well as functionality. Typical quality attributes include:

Quality attributes can conflict. Strong encryption may increase processing cost; extensive abstraction may increase complexity; redundancy may increase operational expense. Architecture is therefore a trade-off process, not a search for one universally best structure.

Common Architectural Patterns

Layered Architecture

Layered architecture groups responsibilities into layers, often presentation, application, domain, and infrastructure. A request normally moves through a controlled direction of dependency.

Strengths: understandable structure, separation of concerns, and ease of teaching and testing.

Limitations: unnecessary layers may add latency and indirection; inappropriate rules may become concentrated in a “service” layer; strict layering can be awkward for complex workflows.

Client–Server Architecture

Clients request services from servers. The client may provide presentation while the server manages shared data and business services. The model is common in web and enterprise systems.

Important design concerns include authentication, network failure, concurrency, version compatibility, and server capacity.

Model–View–Controller (MVC)

MVC separates the model of application data and rules, the view that presents information, and the controller that coordinates input and actions. Variants differ in how much behaviour is placed in controllers or models. MVC can support parallel work, but poorly designed controllers may become large and difficult to test.

Event-Driven Architecture

Components communicate by publishing and consuming events, such as OrderPlaced. Producers need not know every consumer. This supports extensibility and asynchronous processing.

The costs include eventual consistency, event ordering, duplicate delivery, monitoring difficulty, and more complex debugging. Events should represent meaningful facts, not every internal method call.

Microservices and Modular Monoliths

A microservice is an independently deployable service organised around a business capability. Benefits may include independent deployment and scaling. Costs include distributed-system failure, operational complexity, network latency, data consistency challenges, and increased testing requirements.

A modular monolith keeps modules in one deployable application while enforcing clear internal boundaries. It is often a sensible starting point for a small or medium project because it preserves modular design without immediately introducing distributed-system complexity.

Interface Design

An interface is a contract through which components, systems, or people interact. A software interface should specify operations, inputs, outputs, errors, security expectations, and compatibility rules.

For an application programming interface (API), document:

• operation name and purpose;
• request format and validation rules;
• response format and status conditions;
• authentication and authorization requirements;
• error structure and retry guidance;
• idempotency behaviour where relevant;
• versioning and deprecation policy; and
• limits such as maximum payload size or request rate.

An operation is idempotent when repeating the same request has the same intended effect as performing it once. Idempotency is especially important when clients retry after a network timeout. For example, creating a payment with a unique client-supplied request key can prevent accidental double charging.

Interfaces should be designed for the consumer, not merely exposed from internal classes. Avoid leaking database schemas, internal exception messages, or unstable implementation details. Use meaningful names and consistent conventions.

Data Modelling and Persistence Design

Data modelling identifies entities, attributes, relationships, constraints, and lifecycle rules. An entity is a distinguishable concept, such as Student or Course. An attribute describes an entity, such as student number. A relationship expresses an association, such as a student enrolling in a course.

A relational design commonly represents entities as tables, individual instances as rows, and attributes as columns. A primary key identifies a row. A foreign key references a key in another table and supports referential integrity.

For example, a many-to-many relationship between Student and Course can be represented using an associative table, Enrollment:

The pair (student_id, course_id) may be a composite primary key if a student can enrol in a course only once. If repeated enrolments are permitted, an independent enrollment_id may be more appropriate.

Normalization reduces unnecessary duplication and update anomalies. However, denormalization can sometimes improve read performance when its costs are understood and controlled. Data design must also address retention, backup, recovery, access control, validation, and privacy.

UML and Design Models

Unified Modeling Language (UML) provides standard notation for communicating software models. It is a language for visualisation and specification, not a development methodology.

Useful diagrams include:

• Use-case diagram: actors and goals in relation to the system boundary.
• Class diagram: classes, attributes, operations, and relationships.
• Sequence diagram: time-ordered messages among participants.
• Activity diagram: workflows, decisions, and parallel activities.
• State-machine diagram: states and transitions caused by events.
• Component diagram: software components and provided or required interfaces.
• Deployment diagram: execution nodes and deployed artefacts.

A diagram should answer a specific question. A class diagram may communicate domain structure, while a sequence diagram may explain how a payment request is processed. Diagrams should use a consistent abstraction level, meaningful names, and a legend when notation is not obvious. They should be maintained as project artefacts, not created once and abandoned.

Usability and Accessibility

Usability concerns whether intended users can achieve goals effectively, efficiently, and satisfactorily in context. Design activities should involve representative users and realistic tasks rather than relying solely on developer opinion.

Important usability practices include:

• make system status visible;
• use familiar language and concepts;
• provide consistent controls and terminology;
• prevent errors where possible;
• provide clear, recoverable error messages;
• support undo or confirmation for high-impact actions; and
• test with realistic workflows.

Accessibility means that people with different abilities can perceive, operate, understand, and use the system. Design should support keyboard operation, sufficient colour contrast, visible focus, meaningful labels, scalable text, captions or transcripts where appropriate, and compatibility with assistive technologies. Accessibility should be considered from the beginning, not treated as a final cosmetic check.

Legal requirements vary by jurisdiction and sector. Teams should identify applicable standards and regulations, such as organisational accessibility policies, data-protection laws, or sector-specific obligations. Compliance is necessary but does not replace inclusive design and user research.

Design Review and Decision-Making

A design review is a structured examination of whether a proposed design satisfies requirements and manages risks. It should occur early enough to influence the design.

A practical review process is:

1. State the problem, assumptions, constraints, and quality goals.
2. Present the proposed architecture and important alternatives.
3. Trace major components and interfaces to requirements.
4. Examine data ownership, failure modes, security, accessibility, and operations.
5. Record risks, decisions, owners, and follow-up actions.
6. Revisit unresolved issues after evidence is collected.

An architecture decision record (ADR) can document the context, decision, alternatives considered, consequences, and date. This prevents teams from repeatedly reopening settled decisions and makes historical reasoning visible.

Reviewers should ask questions such as:

• What happens when an external service is unavailable?
• Which component owns each important piece of data?
• How are unauthorized actions prevented?
• Can the design be tested without the user interface or production database?
• What is the migration and rollback plan?
• Which requirement is most threatened by this design?

Reviews should examine the design, not blame individuals. Peer review, threat modelling, prototypes, and small technical experiments provide stronger evidence than personal preference.

Illustrative Case: Community Clinic Appointment System

Background

A fictional community clinic currently accepts appointments by telephone and maintains schedules in spreadsheets. It wants an online system for patients, reception staff, and clinicians.

Problem

The clinic experiences double bookings, limited visibility of cancellations, and excessive receptionist workload. The system must protect health-related information, support accessible use, and continue to provide staff access when a patient has limited digital skills.

Analysis

Stakeholders include patients, receptionists, clinicians, clinic managers, and the service provider. Important use cases are search availability, book appointment, cancel appointment, view clinician schedule, record attendance, and generate operational reports.

Key rules include:

• a time slot cannot be assigned to two appointments;
• only authorized staff may view sensitive clinical information;
• patients may view their own appointments but not another patient’s information;
• cancellation policies must be explicit; and
• every significant access and change must be auditable.

Quality requirements include accessible keyboard operation, clear error recovery, reliable backups, and acceptable response time under expected load.

Architecture and Design

A modular monolith is selected initially. Its modules are Appointment Management, Identity and Access, Notifications, Reporting, and Audit. A layered internal structure separates web presentation, application coordination, domain rules, and persistence. This choice avoids premature microservice complexity while preserving future boundaries.

The appointment module owns booking rules. A database transaction protects the invariant that a clinician and time slot cannot be double-booked. Notification delivery is separated from booking so that a temporary email failure does not silently undo a valid appointment. A durable notification task can be retried and monitored.

The interface returns clear validation messages and uses a unique appointment identifier. Authorization is checked on the server, not only by hiding buttons in the interface. Audit records contain the actor, action, time, and affected record, while avoiding unnecessary duplication of sensitive data.

Outcome

The design reduces double-booking risk, supports later integration with reminder services, and gives reviewers explicit points to test. It does not guarantee success by itself: usability testing with patients and receptionists, security testing, backup exercises, and operational monitoring remain necessary.

Learning Points

The case illustrates that architecture must connect requirements, quality attributes, data ownership, interface behaviour, and operational risk. It also shows why a simpler modular architecture may be more appropriate than a fashionable distributed one.

Challenges and Limitations

Analysis is limited by incomplete knowledge. Stakeholders may disagree, requirements may change, and users may describe current procedures rather than underlying needs. Models can create false confidence when they are precise-looking but based on weak assumptions.

Architectural patterns are not recipes. A layered structure can become rigid, event-driven systems can become difficult to observe, and microservices can multiply operational work. Design quality depends on context, team capability, constraints, and evidence.

Technical debt is another practical concern. Deliberate shortcuts may be acceptable when recorded and managed; undocumented shortcuts accumulate risk. Teams should distinguish urgent delivery decisions from permanent design commitments.

AI-assisted design tools can suggest models, code, tests, and documentation, but their output requires human verification. They may reproduce insecure patterns, expose confidential requirements, or invent unsupported assumptions. Organisations should define rules for data handling, intellectual property, review, and accountability. AI should support engineering judgement rather than replace stakeholder consultation and design review.

Best-Practice Checklist

Before implementation, confirm that:

• requirements and quality attributes are testable;
• system boundaries and responsibilities are explicit;
• modules have cohesive responsibilities and controlled dependencies;
• important decisions and alternatives are recorded;
• interfaces define validation, errors, security, and compatibility;
• data ownership, integrity, privacy, and retention are addressed;
• failure, recovery, monitoring, and deployment concerns are considered;
• usability and accessibility are tested with representative users; and
• diagrams and design documents are current enough to support communication.

Chapter Summary

Software analysis determines the problem to be solved and the needs of stakeholders. Architecture organises the system’s major structures and addresses quality attributes. Detailed design specifies component behaviour, interfaces, data, and interactions.

Abstraction, modularity, separation of concerns, high cohesion, and controlled coupling make systems easier to understand and change. Architectural patterns such as layered, client–server, MVC, event-driven, microservice, and modular-monolith designs offer useful structures but involve trade-offs. Interface design requires explicit contracts, error handling, security, and versioning. Data modelling establishes entities, relationships, constraints, and ownership. UML provides a common communication language when diagrams have a clear purpose.

Usability and accessibility are design responsibilities, not final-stage decorations. Design reviews, architecture decision records, prototypes, and threat modelling expose risks early. Professional design balances requirements, technical feasibility, user needs, operational realities, legal obligations, and maintainability.

Key Terms

Abstraction: Representation of essential characteristics while hiding unnecessary detail.

Architecture: Significant structures, relationships, and principles governing a software system.

Architectural pattern: A reusable approach to organising software structures and interactions.

Cohesion: Degree to which responsibilities within a module belong together.

Coupling: Degree of dependency between software modules.

Data model: Representation of entities, attributes, relationships, and constraints.

Encapsulation: Restriction of direct access to internal state or implementation details.

Interface: A contract through which components, systems, or users interact.

Modularity: Division of a system into components with defined responsibilities and boundaries.

Non-functional requirement: Requirement describing a quality, constraint, or condition rather than a specific service.

Primary key: Attribute or set of attributes that uniquely identifies a database row.

Quality attribute: A characteristic such as security, performance, usability, or maintainability.

Separation of concerns: Organisation of a system so different responsibilities are handled in distinct parts.

Stakeholder: Person or organisation affected by, interested in, or able to influence a system.

Traceability: Ability to connect requirements with design elements, implementation, and tests.

UML: Standard visual language for modelling software structure and behaviour.

Usability: Degree to which users can achieve goals effectively, efficiently, and satisfactorily.

Validation: Checking whether input or a proposed product satisfies defined rules or needs.

Review Questions

Short Answer Questions

1. Distinguish software analysis from software design.
2. What is the relationship between cohesion and coupling?
3. Give two advantages and one limitation of layered architecture.
4. What information should an API contract normally specify?
5. Why should accessibility be considered during design rather than only before release?

Long Answer Questions

1. Explain abstraction, modularity, and separation of concerns, and show how they reinforce one another.
2. Compare a modular monolith with microservices for a small software team.
3. Describe how a data model for a many-to-many relationship can be implemented relationally.
4. Explain the purpose of at least four UML diagram types and identify a suitable use for each.
5. Describe a structured design review process and the evidence that should be examined.

Analytical / Application Questions

1. A booking system allows two users to reserve the same time slot during busy periods. Analyse the likely design weaknesses and propose architectural, data, and testing improvements.
2. A team proposes an event-driven architecture because it is considered modern. Evaluate the proposal by identifying benefits, risks, assumptions, and circumstances in which a simpler architecture would be preferable.
3. Design the principal modules and interface responsibilities for an accessible online student-assessment system. Justify your choices using cohesion, coupling, separation of concerns, privacy, and usability principles.

Multiple Choice Questions with Answers

Question 1

Which design principle assigns distinct responsibilities to different parts of a system?

A. Separation of concerns

B. Data duplication

C. Tight coupling

D. Premature optimization

Correct Answer: A. Separation of concerns

Question 2

Which characteristic is generally desirable within a software module?

A. Many unrelated responsibilities

B. High cohesion

C. Dependence on global variables

D. Direct access to every database table

Correct Answer: B. High cohesion

Question 3

What is the primary purpose of an architecture decision record?

A. To replace all source-code comments

B. To record context, decisions, alternatives, and consequences

C. To generate database passwords

D. To measure network bandwidth

Correct Answer: B. To record context, decisions, alternatives, and consequences

Question 4

Which UML diagram best represents time-ordered messages between system participants?

A. Class diagram

B. Deployment diagram

C. Sequence diagram

D. Component diagram

Correct Answer: C. Sequence diagram

Question 5

What is a major cost of microservices?

A. They eliminate all network failures

B. They require no operational monitoring

C. They can introduce distributed-system complexity

D. They cannot be independently deployed

Correct Answer: C. They can introduce distributed-system complexity

Question 6

In a relational database, what is the main purpose of a foreign key?

A. To encrypt every column

B. To reference a key in another table and support referential integrity

C. To guarantee faster queries in all cases

D. To replace all primary keys

Correct Answer: B. To reference a key in another table and support referential integrity

Question 7

Which interface property helps prevent accidental duplicate effects when a request is retried?

A. Idempotency

B. Inheritance

C. Polymorphism

D. Denormalization

Correct Answer: A. Idempotency

Question 8

Which action best supports accessible interface design?

A. Relying only on colour to communicate status

B. Removing keyboard focus indicators

C. Providing meaningful labels and keyboard operation

D. Displaying errors without explanation

Correct Answer: C. Providing meaningful labels and keyboard operation

Question 9

What is the main architectural role of a module boundary?

A. To expose all implementation details

B. To define responsibility and control dependencies

C. To prevent all communication

D. To eliminate the need for testing

Correct Answer: B. To define responsibility and control dependencies

Question 10

Why should authorization be enforced on the server in a web application?

A. Users can always be trusted to obey hidden interface controls

B. Client-side controls alone can be bypassed

C. Server checks reduce the need for authentication

D. Authorization is unrelated to security

Correct Answer: B. Client-side controls alone can be bypassed