System Analysis, SDLC, and Data Modeling Essentials

Posted on Oct 28, 2025 in Creation and Design

System Analysis and Design (SA&D) Importance

Systems analysis and design (SA&D) provides the tools and techniques necessary for developers to:

  • Understand the business need.
  • Capture the vision and define a solution.
  • Communicate the vision and the solution effectively.
  • Build the solution and direct others in its construction.
  • Confirm that the solution meets the need.
  • Launch the solution application.

The Role of SA&D: Customer Needs vs. Developer Tasks

Users/Customers often express needs like:

  • “I need a system to upload images.”
  • “I would like to adjust images before uploading.”

Developers must translate these needs into actionable steps:

  • What should I code?
  • Planning, capturing the vision, understanding details, and specifying needs.

Defining a System Development Project

A Project is a planned undertaking that has a beginning, an end, and produces a predetermined result or product, usually specified in terms of cost, schedule, and performance requirements.

A System Development Project is a planned undertaking that produces an Information System (IS).

Steps in Developing Any New System:

  1. Analysis: To understand information needs.
  2. Design: To define the system architecture (based on needs).
  3. Implementation: The actual construction of the system.

Project Components and Deliverables

  • Work Product: Any item produced by the project as a result of a task (e.g., piece of code, model, document).
  • Deliverable: A work product specifically intended for the client.
  • Schedule: A list of a project’s milestones, activities, and deliverables with intended start and finish dates.
  • Participant (a.k.a. project member): Any person participating in a project.
  • Task: Work to be performed by a project participant to create a work product.

Project Organization and Interactions

Projects often rely on a Team-based organization. A Team is a small set of participants working on the same activity or task, such as:

  • Management Team
  • User Interface Team
  • Database Team
  • Network Team
  • Application Team
  • Control Team

Project interactions include:

  • Reporting: To report status information.
  • Decision: To propagate a decision.
  • Communication: To exchange all other types of information needed for decision or status reporting.

The System Development Life Cycle (SDLC)

The Systems Development Life Cycle (SDLC) is a general term used to describe the method and process of developing a new information system.

SDLC Structure and Benefits

Without the structure and organization provided by the SDLC approach, projects are at risk for missed deadlines and low quality. SDLC provides essential elements for successful development:

  • Structure
  • Methods
  • Controls
  • Checklists

Phases in the SDLC

Sets of related activities are organized into phases. In the “classical” life cycle, these phases are sequential, but variations exist:

  1. Project Planning Phase
  2. Analysis Phase
  3. Design Phase
  4. Implementation Phase
  5. Support Phase (Note: This phase is sometimes referred to as the System Life Cycle, or SLC, rather than SDLC.)

This sequential approach is often referred to as the “Classic” Waterfall Life Cycle.

Data Modeling Fundamentals

Why Data Modeling is Essential

Analysts create process models to represent how the business system will operate, but they also need to understand the information that is used and created by the business system.

What does a data model tell us?

Data models illustrate the people, places, or things about which information is captured and how they are related to each other.

How are data models created?

Data models are drawn by an iterative process in which the model becomes more detailed and less conceptual over time. Since the data model is free of any implementation or technical details, analysts can focus on matching the diagram to real business requirements.

Tools for Creating Data Models

Many CASE tools (Computer-Aided Software Engineering) can help create logical and physical data models. For example:

  • ERwin by Platinum Technology can automatically generate many different kinds of databases from the models created.
  • Many CASE tools come bundled with database management systems (DBMS) and are particularly good for modeling databases that will be built in their companion databases (e.g., Oracle Designer and Oracle database).

If a CASE tool is not available, software drawing tools such as Visio, Visual Paradigm, and Lucidchart can be used.

Understanding the Entity Relationship Diagram (ERD)

An Entity Relationship Diagram (ERD) is a picture that shows the information created, stored, and used by a business system. On an ERD:

  • Similar kinds of information are listed together and placed inside boxes called entities.
  • Lines are drawn between entities to represent relationships among the data.
  • Special symbols are added to communicate high-level business rules.

ERD Elements: Entity

An Entity is the basic building block for a data model. It could be a person, place, event, or thing about which data is collected.

  • Depicted by a rectangle, and described by a singular noun spelled in capital letters (e.g., CUSTOMER).
  • Contains a name, a short description, and an identifier—the way to locate information in the entity.
  • Entities represent something for which there exist multiple instances or occurrences. (If there is only one drone base model, there is no need to create an entity for it.)

ERD Elements: Attribute

An Attribute is some type of information that is captured about an entity (e.g., last name, home address, email address). We only need those attributes that will actually be used by the business process.

  • The form of the entity name is usually appended to the beginning of each attribute (e.g., CUSTOMER_LastName) to make it clear as to which entity it belongs, preventing confusion.
  • One or more attributes can serve as the identifier (noted by an asterisk).
  • You can have a concatenated identifier.
  • You can find a unique field.
  • You can wait to assign an identifier for each instance in the design phase.

ERD Elements: Relationship

Relationships are associations between entities, shown by lines connecting them.

  • Each relationship has a parent entity (on the “one” side) and a child entity (on the “many” side).
  • Relationships should be clearly labeled with active verbs to reveal their semantics.
  • If a verb is given to each relationship, it should be read in two directions (Example: CUSTOMER places ORDER).

ERD Elements: Cardinality and Modality

Cardinality is a property of relationships, denoting the ratio of parent instances to child instances. It answers: “How many instances of one entity are associated with an instance of the other?”

  • The cardinality could be 1:1, 1:N (one-to-many), or M:N (many-to-many).
  • 1:1 relationship: One instance of the parent entity is associated with exactly one instance of the child entity (Example: assigning desks to employees).
  • 1:M relationship: The most common type (Example: customer places order).

Modality refers to whether an instance of an entity can exist without a related instance in the related entity (i.e., whether the relationship is required or optional).

  • Can we have a customer instance without a related custom drone order instance? (Optional)
  • Can we have a customer drone order instance without a customer instance? (Required)

Modality indicates whether the relationship between an entity instance and an instance of the related entity is null (optional) or not null (required).

  • Place a zero (0) on the relationship line next to the parent entity if nulls are allowed (Optional).
  • Place a bar (|) on the relationship line next to the parent entity if nulls are not allowed (Required).

Data-Intensive Applications: Key Concerns

Most applications and systems today are data-intensive, rather than computer-intensive. The three major concerns regarding data-intensive applications are Reliability, Scalability, and Maintainability.

Reliability: Fault Tolerance

Reliability is the ability of a system to continue working correctly, even when things go wrong. The things that can go wrong are called faults, and systems that anticipate faults and can cope with them are called fault-tolerant or resilient.

  • Fault: One component of the system deviating from its specification.
  • Failure: When the system as a whole stops providing the required service.

It is impossible to reduce the probability of faults to zero; therefore, we need to design systems to prevent faults from causing failures.

Scalability: Coping with Increased Load

Scalability describes the system’s ability to cope with increased load. For example, if the system grows from 1,000 concurrent users to 1 million, causing performance degradation.

Scalability is not a simple label. It is meaningless to say “X is scalable.” Instead, the discussion should focus on: “If the system grows in a particular way, what are our options to cope with the growth?”

Maintainability: Reducing Long-Term Costs

The majority of the cost of software is not in its initial development, but in its ongoing maintenance, which includes:

  • Fixing bugs and keeping systems operational.
  • Investigating failures.
  • Adapting the system to new platforms.
  • Modifying it for new use cases.
  • Repaying technical debt.
  • Adding new features.