Software Analysis and System Modeling

Introduction

Software analysis is the disciplined process of examining a problem, its stakeholders, required capabilities, information, constraints, and operating environment before deciding how software should be designed and implemented. System modeling represents the results of this analysis through diagrams, structured descriptions, and complementary viewpoints.

A software system is rarely understood adequately from a list of features alone. A requirement such as “customers can place orders” raises important questions: Who is a customer? What information is needed? Which business rules apply? What happens when payment fails? How does the warehouse learn about the order? What states can an order occupy? Models help analysts answer such questions, expose omissions, communicate with stakeholders, and provide a foundation for design, testing, and project estimation.

Modeling is not an artistic activity in which a diagram is judged by appearance. A useful model is a precise, purposeful abstraction. It omits irrelevant detail while preserving information needed for a particular decision. Different models describe different aspects of the same system; they should therefore be complementary and consistent rather than competing descriptions.

Learning Objectives

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

• explain the purpose and scope of software analysis and system modeling;
• identify system boundaries, external entities, actors, and stakeholders;
• construct and interpret context diagrams and data-flow diagrams;
• use UML use-case, class, activity, sequence, and state-machine models;
• develop domain, process, data, and behavioral models from requirements;
• check models for completeness, correctness, consistency, and traceability;
• apply modeling techniques to a realistic software problem; and
• recognize practical, ethical, governance, and maintenance issues in modeling.

1. Analysis as a Bridge Between Requirements and Design

Requirements describe what stakeholders need, but they are often expressed in natural language. Natural language is accessible, yet it may be ambiguous, incomplete, or inconsistent. Analysis transforms requirements into organized representations that can be inspected before implementation begins.

Analysis normally addresses four related questions:

1. What is outside the system? This establishes the system boundary and identifies external actors, devices, organizations, and systems.
2. What must the system do? Functional requirements are examined as services, processes, interactions, and state changes.
3. What information does the system manage? Analysts identify entities, attributes, relationships, inputs, outputs, and data rules.
4. Under what conditions must it operate? Quality requirements and constraints concern security, performance, availability, legal compliance, usability, and technology limitations.

A model is an abstraction. For example, a context diagram may show only the system and its external interfaces, whereas a class diagram may describe internal concepts and relationships. Neither model is “the system” in its entirety.

Stakeholders and Viewpoints

A stakeholder is a person, group, organization, or system affected by, or able to affect, the software. Customers, operators, managers, regulators, suppliers, maintainers, and external services may all have legitimate viewpoints. A customer may focus on ease of ordering; an auditor may focus on records and access control; an operator may focus on exception handling.

Analysts should record the source of important requirements and identify conflicts explicitly. A model that satisfies one stakeholder while silently violating another is not a successful analysis artifact.

System Boundary

The system boundary defines what is included in the system under analysis and what is treated as external. Boundaries are not always obvious. In an online booking service, the booking application may be inside the boundary, while a payment gateway, email service, and identity provider are external systems. A later project could instead include payment processing within its boundary.

Boundary decisions affect requirements, interfaces, security responsibility, ownership, cost, and testing. The boundary should therefore be documented and agreed with relevant stakeholders.

2. Context Modeling

A context diagram provides a high-level view of the system as a single process or product surrounded by external entities. It answers: “With whom or with what does the system exchange information?” It does not show internal processes or detailed data structures.

External entities may include:

• human users and organizational roles;
• other software systems;
• hardware devices;
• regulatory or financial services; and
• physical processes represented by an interface.

Information flows should be named with meaningful nouns or noun phrases, such as “booking request,” “payment authorization,” or “confirmation.” Vague labels such as “data” reduce the value of the model.

Figure: A context diagram identifies the system boundary and major external exchanges; it does not describe internal processing.

A context model must be checked against requirements. Every external interaction mentioned in a requirement should be represented or deliberately excluded with an explanation. Conversely, every flow in the diagram should have a valid business purpose and an identified source and destination.

3. Process and Data-Flow Modeling

Data-flow modeling describes how inputs are transformed into outputs and where information is stored. A conventional data-flow diagram (DFD) uses four elements:

A DFD is not a program flowchart. A flowchart emphasizes control sequence and decisions; a DFD emphasizes information movement and transformation. A DFD should not imply that a data store directly sends data to another data store without a process, because the transformation or business responsibility would be hidden.

Decomposition and Balancing

A context diagram can be decomposed into a level-1 DFD containing major processes and data stores. A process can then be decomposed into a lower-level diagram. Decomposition should stop when a process is sufficiently clear to specify, estimate, design, and test.

Balancing means that inputs and outputs at a lower level correspond to the flows entering and leaving the parent process. New internal flows may appear, but external flows should not mysteriously appear or disappear. If a level-1 process receives a booking request and produces a confirmation, its child diagram must account for both flows.

A useful process specification may include a structured English description, decision table, decision tree, or precondition/postcondition statement. For example:

• Precondition: a valid booking request identifies an available resource.
• Processing: calculate price, reserve the resource, and request payment.
• Postcondition: a confirmed booking is recorded, or an explicit failure outcome is returned.

Data Dictionaries

A data dictionary defines the meaning and structure of data flows and stores. An entry for BookingRequest might contain:

• customer identifier;
• resource identifier;
• start date and end date;
• number of participants; and
• payment details or a payment token.

Definitions should specify optionality, allowable ranges, formats, ownership, and sensitivity. A data dictionary reduces semantic disagreement between analysts, developers, testers, and stakeholders.

4. UML and Complementary Models

The Unified Modeling Language (UML) is a standardized visual language for describing software-intensive systems. UML provides notation, but it does not prescribe a complete development process. A team may use selected UML diagrams alongside DFDs, domain models, prototypes, user stories, and textual specifications.

Use-Case Modeling

A use case describes a goal-oriented interaction between an actor and a system. The actor is an external role, not necessarily a specific individual. One person may play several roles, and one role may be played by many people.

A use-case description commonly includes:

• name and goal;
• primary actor and supporting actors;
• trigger;
• preconditions;
• main success scenario;
• alternative and exception flows;
• postconditions; and
• special requirements.

For “Make Booking,” the main scenario might be: the customer selects a resource, enters dates, reviews the price, submits the request, payment is authorized, and a confirmation is issued. Alternative flows include unavailable resources, invalid dates, declined payment, and notification failure.

The relationships include and extend must be used carefully. Inclusion represents behavior that is required as part of another use case. Extension represents optional or conditional behavior inserted at defined extension points. They are not general-purpose ways to organize every shared sentence.

Class and Domain Models

A domain model represents important concepts in the problem domain and their relationships. It is not necessarily a software class design. A booking domain may contain Customer, Resource, Booking, Payment, and Notification.

A class or domain model commonly shows:

• class or concept names;
• attributes or characteristic information;
• associations;
• multiplicities; and
• generalization or specialization where appropriate.

Multiplicity expresses how many instances may participate in a relationship. For example, one customer may make zero or many bookings, while each booking may belong to exactly one customer. This can be stated as Customer 1 — 0..* Booking.

Analysts should distinguish an entity from an attribute. Customer is likely an entity with an identity and lifecycle; customerEmail is an attribute. The correct choice depends on business meaning, change, ownership, and relationships rather than on a fixed naming rule.

Activity Models

Activity diagrams represent workflows, including actions, decisions, parallel activities, and their completion. They are useful for business processes such as registering a student, processing a claim, or fulfilling an order.

An activity model should make decision conditions explicit. A branch labelled “valid” and “invalid” is more useful than two unlabeled arrows. Parallel paths should indicate where work forks and where synchronization occurs. Analysts must not infer that every activity is sequential merely because it is listed vertically.

Sequence Models

A sequence diagram shows interactions between actors and objects in time order. Lifelines represent participants; messages represent requests, responses, events, or signals. Sequence models are especially useful for examining a use-case scenario and identifying responsibilities.

A sequence diagram can reveal missing operations. If a booking service must check availability, calculate a price, reserve a resource, and request payment, each responsibility should be assigned to an appropriate participant. The diagram should also consider failure responses, timeouts, retries, and duplicate requests where these are realistic.

State Models

A state model describes how an entity changes state in response to events. A booking might move through:

Requested → PaymentPending → Confirmed → Completed

with alternative transitions to Cancelled or Failed.

A state is a condition during which an object satisfies particular rules. An event triggers a transition; a guard is a condition that must be true; an action may occur during the transition. For example, authorizePayment may cause PaymentPending to become Confirmed only when the authorization succeeds.

State models are valuable when behavior depends strongly on history. They help identify invalid transitions, such as completing a booking that has never been confirmed. They also support test design: each state and transition should have relevant test conditions.

5. Modeling Data and Information Quality

Data modeling examines the information required by the system and the relationships among data items. A conceptual data model focuses on business meaning; a logical model adds attributes, keys, and more precise relationships; a physical model reflects a selected database technology.

Important data questions include:

• What facts must be stored?
• Which facts are identifying, derived, optional, or sensitive?
• Who owns and updates each fact?
• What rules constrain valid values?
• How long must the information be retained?
• What happens when a related record is deleted or corrected?

Normalization is a database design technique that can reduce inappropriate redundancy, but analysis should not become a premature database optimization exercise. At diploma level, the important principle is that each fact should have a clear meaning, owner, and update rule. Deliberate duplication may later be justified for performance, reporting, or integration, but it should be controlled and documented.

Data quality includes accuracy, completeness, consistency, timeliness, validity, and uniqueness. A model may be structurally correct while still supporting poor-quality data if it omits validation or ownership rules.

6. Maintaining Consistency and Traceability

A collection of individually attractive diagrams may still be contradictory. Model validation should therefore be systematic.

Consistency Checks

Useful checks include:

• every use-case actor appears in the context model or has a documented reason for exclusion;
• every major input and output in the context diagram is explained by lower-level processes;
• entities named in requirements have corresponding domain concepts where appropriate;
• attributes used in a process are defined in the data dictionary;
• state transitions correspond to permitted business events;
• multiplicities reflect actual business rules;
• alternative and exception flows are represented;
• terminology is used consistently; and
• security and privacy boundaries are not contradicted by data flows.

Traceability

A requirements traceability matrix links requirements to models, design elements, tests, and acceptance evidence. A simple matrix might contain requirement identifier, requirement statement, related use case, related domain concept, related state or process, and verification method.

Traceability supports impact analysis. If the rule “a booking may be cancelled only before the start date” changes, the analyst can identify affected use cases, state transitions, process specifications, database constraints, user interfaces, and tests.

Model Quality Criteria

A professional model should be:

• correct: it represents the intended business reality;
• complete: important requirements and exceptions are covered;
• consistent: related models do not conflict;
• understandable: intended readers can interpret it;
• minimal: unnecessary detail does not obscure the purpose;
• traceable: elements can be connected to requirements; and
• maintainable: changes can be made without widespread confusion.

Models should be reviewed with stakeholders, not only with other analysts. A technically elegant diagram that users cannot validate has limited practical value.

7. Worked Application: Community Clinic Appointment Service

The following is an illustrative case, not a report of a real organization.

Background and Problem

A community clinic currently accepts appointments by telephone. Staff record requests in spreadsheets, patients receive inconsistent reminders, and clinicians cannot easily see cancellations. The clinic wants a service through which patients can request appointments, staff can manage schedules, and reminders can be sent automatically.

Analysis

Stakeholders include patients, reception staff, clinicians, clinic management, a notification provider, and a privacy officer. The proposed system boundary includes appointment management and reminder coordination. The notification provider remains external.

The principal use cases are:

• Search available appointment slots;
• Request appointment;
• Confirm or reject appointment;
• Cancel appointment;
• View clinician schedule; and
• Send appointment reminder.

The domain concepts are Patient, Clinician, AppointmentSlot, Appointment, and Reminder. A patient may have many appointments; each appointment refers to one patient, one clinician, and one time slot. A slot may be available, held, booked, or blocked.

The appointment state model is:

Requested → Confirmed → Attended

with transitions from Requested to Rejected, and from Confirmed to Cancelled or Missed. A cancellation rule may be represented as a guard: cancellation is permitted only when the appointment start time has not passed and clinic policy allows cancellation.

A process model for requesting an appointment is:

1. receive patient and slot details;
2. validate patient identity and slot availability;
3. create a pending request;
4. notify reception staff or apply an approved automatic rule;
5. record the decision;
6. update slot and appointment state; and
7. send an appropriate confirmation or rejection message.

Approach and Solution

The analysis team first produced a context diagram and stakeholder-approved glossary. It then wrote use-case descriptions, developed the domain and state models, and decomposed the appointment process. A data dictionary defined patient identifiers, appointment times, status values, and notification content.

Privacy was treated as a design constraint rather than an afterthought. The model distinguished necessary clinical or scheduling data from optional information. It also identified access roles: patients should see their own appointments, clinicians should see relevant schedules, and administrative staff should receive only the information needed for their duties.

Outcome

The models exposed several issues before coding. A cancellation path had been omitted, the original data structure allowed one slot to be booked twice, and notification failure had no defined response. The revised analysis introduced an explicit slot state, a uniqueness rule for confirmed bookings, and a retry or staff-review process for failed notifications.

Learning Points

The case demonstrates that modeling is a form of reasoning, not merely documentation. Context modeling clarified responsibility boundaries; use cases exposed user goals; the domain model clarified information; the state model exposed invalid or missing transitions; and process models revealed operational exceptions.

8. Challenges, Limitations, and Professional Practice

Over-Modeling and Under-Modeling

Too little modeling leaves ambiguity and increases rework. Too much modeling creates maintenance cost and may delay learning. The appropriate level of detail depends on risk, complexity, team size, regulatory obligations, and expected change. Models should answer a question or support a decision; diagrams created only because a template demands them are unlikely to add value.

Ambiguity and False Precision

A neat diagram can create false confidence. If a requirement is uncertain, the model should mark the uncertainty and record an assumption or question. Analysts should not convert an unresolved business decision into an apparently final design choice.

Tool and Notation Limitations

Modeling tools can validate syntax, generate diagrams, and support version control, but they cannot determine whether a business rule is correct. Different tools and UML profiles may use different visual conventions. Teams should agree on notation, naming, ownership, review practices, and storage formats.

Agile and Iterative Development

In iterative development, analysis is not a single phase completed before coding. Models evolve as stakeholders learn and as prototypes expose new information. Lightweight models may be created just in time, while stable or safety-critical areas may require more formal baselines. The key is to preserve shared understanding and traceability rather than to defend a fixed document.

Ethics, Privacy, and Governance

Models can reveal sensitive information, surveillance possibilities, discriminatory rules, and excessive data collection. Analysts should ask whether each data item is necessary, who can access it, how long it is retained, and how individuals can correct it. Security boundaries, consent, auditability, retention, and applicable data-protection obligations should be represented in requirements and models.

Automated or AI-assisted modeling tools may extract entities and processes from documents, generate diagram drafts, or identify terminology inconsistencies. Such output must be reviewed by qualified people. AI may misinterpret domain language, reproduce confidential information, or invent relationships that are not supported by requirements. Human accountability, source traceability, privacy controls, and version review remain necessary.

9. Best-Practice Modeling Workflow

A practical workflow is:

1. establish the purpose, audience, and system boundary;
2. identify stakeholders and collect terminology;
3. capture goals, functional requirements, constraints, and exceptions;
4. create a context model;
5. develop use cases and process or data-flow models;
6. identify domain concepts, relationships, and important data rules;
7. model interactions and states where behavior is significant;
8. connect model elements to requirements and tests;
9. review models with stakeholders and resolve contradictions;
10. record assumptions, open issues, and decisions; and
11. maintain models as the system and requirements change.

The workflow is iterative. Discovering a missing state may require changing a use case; changing a use case may require changing the context or data model. Such feedback is evidence that analysis is working.

Chapter Summary

Software analysis transforms stakeholder needs and constraints into precise, reviewable representations. System modeling provides complementary views of scope, behavior, structure, data, processes, and interactions. Context diagrams define boundaries and external exchanges. Data-flow models show how information is transformed and stored. UML use cases describe actor goals; domain and class models describe concepts and relationships; activity diagrams describe workflows; sequence diagrams describe interactions over time; and state models describe event-driven changes in object condition.

Effective models are correct, complete enough for their purpose, consistent, understandable, traceable, and maintainable. Decomposition must preserve inputs and outputs, data dictionaries must define information clearly, and traceability must connect requirements to models and tests. The clinic case illustrates how modeling can expose missing exceptions, unclear responsibilities, data conflicts, and privacy concerns before implementation. Professional analysts treat models as living communication and reasoning tools, not as decorative documentation.

Key Terms

System analysis: Examination of a problem, its requirements, stakeholders, data, processes, and constraints.

System model: An abstraction representing selected aspects of a software system.

Stakeholder: A person, group, organization, or system affected by or able to affect the software.

System boundary: The agreed distinction between system responsibilities and external responsibilities.

Context diagram: A high-level model showing a system and its external entities and information exchanges.

External entity: A person, organization, device, or system outside the system boundary.

Data-flow diagram: A model showing data sources, transformations, stores, and destinations.

Data dictionary: A structured definition of data elements, flows, stores, and formats.

Use case: A goal-oriented interaction between an actor and a system.

Actor: An external role that interacts with a system.

Domain model: A representation of important concepts and relationships in the problem domain.

Multiplicity: A statement of how many instances may participate in a relationship.

Activity diagram: A model of actions, decisions, flows, and parallel work.

Sequence diagram: A model of participants and messages ordered in time.

State model: A representation of states, events, guards, and transitions.

Traceability: The ability to connect requirements with models, implementation, and tests.

Balancing: Ensuring that a decomposed process accounts for the parent process’s external inputs and outputs.

Functional requirement: A required service, behavior, or transformation provided by a system.

Non-functional requirement: A quality, constraint, or operating condition applied to the system.

Review Questions

Short Answer Questions

1. What is the purpose of a system boundary?
2. Name the four principal elements of a data-flow diagram.
3. How does a use case differ from an activity diagram?
4. What information does a state model represent?
5. Why is a data dictionary useful?

Long Answer Questions

1. Explain how context diagrams and decomposed data-flow diagrams can be used together while maintaining balance.
2. Compare use-case, domain, sequence, and state models, including the questions each model helps answer.
3. Describe a systematic method for checking consistency among requirements, processes, data, and behavior models.
4. Explain why stakeholder viewpoints and system-boundary decisions are important during analysis.
5. Discuss the benefits and limitations of maintaining models in an iterative or agile development environment.

Analytical / Application Questions

1. A library system allows members to borrow books, renew loans, pay fines, and receive reminders. Identify its likely external entities, major use cases, domain concepts, and at least four important states of a loan.
2. A payment process diagram shows a customer sending payment details directly to a database, with no process between them. Analyze the problem and propose a corrected modeling approach.
3. A requirement says, “A patient can cancel an appointment at any time.” Identify ambiguities and risks in this statement, then propose questions, model changes, and traceability links needed before implementation.

Multiple Choice Questions with Answers

Question 1

What is the primary purpose of a context diagram?

A. To show detailed source-code structure

B. To show the system boundary and external interactions

C. To define database indexes

D. To specify screen colors

Correct Answer: B. To show the system boundary and external interactions

Question 2

Which DFD element represents a transformation of data?

A. External entity

B. Data store

C. Process

D. Data dictionary

Correct Answer: C. Process

Question 3

What does balancing mean when a DFD is decomposed?

A. All processes must have equal names

B. Lower-level diagrams account for the parent process’s external inputs and outputs

C. Every data store must contain the same number of records

D. All arrows must point in one direction

Correct Answer: B. Lower-level diagrams account for the parent process’s external inputs and outputs

Question 4

Which UML model is most suitable for showing an actor’s goal-oriented interaction with a system?

A. Use-case model

B. State model

C. Deployment model

D. Package model

Correct Answer: A. Use-case model

Question 5

In a domain model, what does multiplicity describe?

A. The execution speed of a method

B. The number of instances participating in a relationship

C. The size of a database table

D. The number of screens in an application

Correct Answer: B. The number of instances participating in a relationship

Question 6

Which model is most useful for identifying invalid transitions such as completing an unconfirmed booking?

A. Context diagram

B. State model

C. Data dictionary

D. Component inventory

Correct Answer: B. State model

Question 7

Which statement best describes a data dictionary?

A. It defines the meaning and structure of data elements and flows

B. It automatically generates all program code

C. It replaces stakeholder interviews

D. It shows only user-interface navigation

Correct Answer: A. It defines the meaning and structure of data elements and flows

Question 8

What is a major benefit of requirements traceability?

A. It eliminates the need for testing

B. It supports impact analysis when requirements change

C. It guarantees that requirements are correct

D. It prevents all future changes

Correct Answer: B. It supports impact analysis when requirements change

Question 9

Which issue was exposed in the illustrative clinic case by explicitly modeling appointment states?

A. The need for more screen colors

B. The possibility of a slot being booked twice

C. The removal of all external services

D. The elimination of privacy requirements

Correct Answer: B. The possibility of a slot being booked twice

Question 10

Why should AI-generated models be reviewed by qualified people?

A. AI output is always too detailed to store

B. AI cannot draw any diagrams

C. AI may misinterpret requirements or invent unsupported relationships

D. Review is required only for decorative diagrams

Correct Answer: C. AI may misinterpret requirements or invent unsupported relationships