# Chapter 1: From Beginning to End: An Overview of Systems Analysis and Design > **Course Code**: IS332 — Analysis and Design of Information Systems > **Faculty**: Faculty of Computers and Artificial Intelligence, Cairo University (FCAI-CU) > **Department**: Information Systems Department > **Instructor**: Dr. Sherif Zahran > **Primary Reference**: *Systems Analysis and Design in a Changing World* (7th Edition), Satzinger, Jackson, & Burd — Chapter 1 --- ## Table of Contents - [1.0 Chapter Overview & Learning Objectives](#10-chapter-overview--learning-objectives) - [1.1 Software Development and Systems Analysis and Design](#11-software-development-and-systems-analysis-and-design) - [1.1.1 Core Definitions](#111-core-definitions) - [1.1.2 Systems Analysis versus Systems Design](#112-systems-analysis-versus-systems-design) - [1.1.3 The 7 Core Steps of Software Development](#113-the-7-core-steps-of-software-development) - [1.2 The System Development Life Cycle (SDLC)](#12-the-system-development-life-cycle-sdlc) - [1.2.1 The Six Core Processes of SDLC](#121-the-six-core-processes-of-sdlc) - [1.2.2 Information System Development Methodologies](#122-information-system-development-methodologies) - [1.2.3 Iterative and Agile Systems Development](#123-iterative-and-agile-systems-development) - [1.2.4 Benefits of Iterative and Agile SDLC](#124-benefits-of-iterative-and-agile-sdlc) - [1.3 Case Study: Ridgeline Mountain Outfitters (RMO)](#13-case-study-ridgeline-mountain-outfitters-rmo) - [1.3.1 Company Background](#131-company-background) - [1.3.2 The RMO Tradeshow System Project](#132-the-rmo-tradeshow-system-project) - [1.4 Pre-Project Activities (Core Process 1)](#14-pre-project-activities-core-process-1) - [1.4.1 Pre-Project Scope and Feasibility](#141-pre-project-scope-and-feasibility) - [1.4.2 System Vision Document](#142-system-vision-document) - [1.5 Day 1: Project Planning & Subsystems (Core Process 2)](#15-day-1-project-planning--subsystems-core-process-2) - [1.5.1 Partitioning the System into Subsystems](#151-partitioning-the-system-into-subsystems) - [1.5.2 Work Breakdown Structure (WBS)](#152-work-breakdown-structure-wbs) - [1.5.3 Work Sequence Draft (Gantt Schedule)](#153-work-sequence-draft-gantt-schedule) - [1.6 Day 2: Requirements & Initial Domain Modeling (Core Process 3)](#16-day-2-requirements--initial-domain-modeling-core-process-3) - [1.6.1 Identifying Use Cases](#161-identifying-use-cases) - [1.6.2 Identifying Object Classes (Domain Classes)](#162-identifying-object-classes-domain-classes) - [1.6.3 Preliminary Domain Class Diagram](#163-preliminary-domain-class-diagram) - [1.7 Day 3: Detailed Requirements & UI Prototyping (Core Processes 3 & 4)](#17-day-3-detailed-requirements--ui-prototyping-core-processes-3--4) - [1.7.1 Detailed Scope: Supplier Information Subsystem](#171-detailed-scope-supplier-information-subsystem) - [1.7.2 Use Case Diagram](#172-use-case-diagram) - [1.7.3 Activity Diagram (Workflow Analysis)](#173-activity-diagram-workflow-analysis) - [1.7.4 Draft Screen Layout & UI Prototyping](#174-draft-screen-layout--ui-prototyping) - [1.8 Day 4: Detailed System Architecture & Database Design (Core Process 4)](#18-day-4-detailed-system-architecture--database-design-core-process-4) - [1.8.1 Database Schema Design](#181-database-schema-design) - [1.8.2 Architectural Configuration Diagram](#182-architectural-configuration-diagram) - [1.8.3 Preliminary Design Class Diagram (DCD)](#183-preliminary-design-class-diagram-dcd) - [1.8.4 Subsystem Architectural Design Diagram](#184-subsystem-architectural-design-diagram) - [1.8.5 Management Insights on Design Execution](#185-management-insights-on-design-execution) - [1.9 Day 5: Construction & Programming (Core Processes 4 & 5)](#19-day-5-construction--programming-core-processes-4--5) - [1.9.1 Implementation Workflow](#191-implementation-workflow) - [1.9.2 Class Implementation Code Example](#192-class-implementation-code-example) - [1.10 Day 6: System Testing & Deployment (Core Process 6)](#110-day-6-system-testing--deployment-core-process-6) - [1.10.1 Workflow of Testing Tasks](#1101-workflow-of-testing-tasks) - [1.10.2 Final Working Screen Representation](#1102-final-working-screen-representation) - [1.10.3 First Iteration Recap & Lessons Learned](#1103-first-iteration-recap--lessons-learned) - [1.11 Course Curriculum Roadmap: The Rest of the Book](#111-course-curriculum-roadmap-the-rest-of-the-book) - [1.12 Chapter Summary & Key Terminology Glossary](#112-chapter-summary--key-terminology-glossary) --- ## 1.0 Chapter Overview & Learning Objectives This chapter provides an end-to-end walkthrough of modern information system development. By developing a real-world, mobile application—the **Tradeshow System** for **Ridgeline Mountain Outfitters (RMO)**—this chapter introduces the fundamental concepts, models, and techniques of systems analysis and design within an Agile and iterative project context. ### Core Learning Objectives Upon completing this chapter, students should be able to: 1. **Explain the Purpose of Systems Analysis and Design**: Articulate how systems analysis and design bridge the gap between organizational business problems and robust software solutions. 2. **Master the System Development Life Cycle (SDLC)**: Define the SDLC and identify its six core processes. 3. **Contrast Methodologies**: Understand how methodologies (e.g., Unified Process, Extreme Programming, Scrum) provide concrete guidelines for completing the six core processes. 4. **Characterize Agile and Iterative Development**: Differentiate between traditional predictive approaches and modern adaptive/iterative paradigms. 5. **Trace an Iterative Project**: Follow the day-by-day progression of an iteration from initial vision to working software and user testing. 6. **Identify Essential Artifacts**: - Project planning documents (System Vision Document, Work Breakdown Structure, Work Sequence Draft). - Analysis models (Use Case lists, Use Case Diagrams, Domain Class Diagrams, Activity Diagrams). - Design models (Database Schemas, Architectural Configuration Diagrams, Design Class Diagrams, Subsystem Architecture Diagrams). --- ## 1.1 Software Development and Systems Analysis and Design ### 1.1.1 Core Definitions Organizations do not build information systems for the sake of technology; they build them to solve pressing business problems, capture market opportunities, and streamline operational workflows. - **Computer Application (App)**: - A computer software program that executes on a specific computing device (e.g., smartphone, tablet, desktop, or server) to carry out a specific, bounded set of user functions. - Characterized by a **modest, well-defined scope**. - **Information System**: - A comprehensive set of interrelated components that collects, processes, stores, and provides as output the information needed to complete business tasks and make organizational decisions. - **Broader in scope than an app**: An information system typically encompasses apps, large enterprise database engines, integration middleware, networks, manual business procedures, and the people who interact with them. - **Project**: - A planned undertaking that has a defined beginning and end, adheres to constraints of schedule and budget, and produces a distinct, measurable result. ```mermaid flowchart LR subgraph Enterprise ["Enterprise Information System"] direction TB App1["Mobile App (Field Agents)"] App2["Web Application (E-Commerce)"] App3["Back-Office Desktop Application"] DB[(Enterprise Database Management System)] Procedures["Manual Procedures & Business Rules"] People["Stakeholders, Users & Analysts"] App1 <--> DB App2 <--> DB App3 <--> DB People --- Procedures Procedures --- App1 Procedures --- App2 Procedures --- App3 end ``` --- ### 1.1.2 Systems Analysis versus Systems Design Developing successful software requires answering two fundamental questions: **WHAT** must be done, and **HOW** should it be constructed. | Dimension | Systems Analysis | Systems Design | |:---|:---|:---| | **Primary Question** | **WHAT** the system must do | **HOW** the system will physically operate | | **Focus** | Understanding business needs, discovering user requirements, and defining functional capabilities | Specifying architecture, database tables, user interfaces, networks, security, and class methods | | **Key Activities** | Fact-finding, interviews, workflow modeling, identifying use cases, identifying domain classes | Designing the database schema, screen layouts, network infrastructure, and object-oriented class interactions | | **Target Audience** | Business users, managers, domain experts, and stakeholders | Programmers, database administrators, network engineers, and system architects | | **Orientation** | Problem-oriented (Problem Domain) | Solution-oriented (Technology Domain) | ```mermaid flowchart TD Need["Business Need / Problem"] --> Analysis["Systems Analysis: WHAT needs to be done?"] Analysis --> Spec["Requirements Specification & Domain Models"] Spec --> Design["Systems Design: HOW will it be built?"] Design --> Blueprints["System Architecture, Database Schemas & UI Wireframes"] Blueprints --> Construction["System Construction (Coding, Testing & Deployment)"] ``` --- ### 1.1.3 The 7 Core Steps of Software Development Regardless of methodology, building an enterprise software solution requires seven universal steps: 1. **Understand the Need**: Investigate the fundamental business problem or market opportunity. 2. **Capture the Vision**: Define the boundaries, functional goals, and expected financial/operational benefits of the proposed solution. 3. **Define a Solution**: Determine the exact functional requirements and information needs of the stakeholders. 4. **Communicate the Vision and Solution**: Use formal models, diagrams, and specifications to align developers, users, and executives. 5. **Build the Solution**: Write code, create databases, and configure system components according to the design specifications. 6. **Confirm That the Solution Meets the Need**: Verify through functional, integration, and user acceptance testing that the software satisfies the original requirements. 7. **Launch the Solution System**: Deploy the software into the live production environment, train end users, and transition into ongoing operational support. --- ## 1.2 The System Development Life Cycle (SDLC) ### 1.2.1 The Six Core Processes of SDLC The **System Development Life Cycle (SDLC)** is the entire process consisting of all activities required to conceive, build, test, launch, and maintain an information system. Modern systems engineering organizes these activities into **Six Core Processes**: ```mermaid flowchart TD CP1["Core Process 1: Identify the problem or need and obtain approval"] --> CP2["Core Process 2: Plan and monitor the project"] CP2 --> CP3["Core Process 3: Discover and understand the details of the problem or need"] CP3 --> CP4["Core Process 4: Design the system components that solve the problem"] CP4 --> CP5["Core Process 5: Build, test, and integrate system components"] CP5 --> CP6["Core Process 6: Complete system tests and deploy the solution"] classDef process fill:#e1f5fe,stroke:#0288d1,stroke-width:2px; class CP1,CP2,CP3,CP4,CP5,CP6 process; ``` #### Detailed Description of the Six Core Processes 1. **Core Process 1: Identify the problem or need and obtain approval**: - Establish initial business feasibility. - Author the **System Vision Document**. - Secure executive sponsorship and financial approval to initiate project work. 2. **Core Process 2: Plan and monitor the project**: - Define project scope and identify major subsystems. - Establish iterations, estimate staffing and budget, create the **Work Breakdown Structure (WBS)**, and track ongoing progress. 3. **Core Process 3: Discover and understand the details of the problem or need**: - Conduct detailed requirements gathering with end users. - Identify use cases, user stories, domain classes, and business workflows. 4. **Core Process 4: Design the system components that solve the problem or satisfy the need**: - Formulate system architecture (hardware, network, software platforms). - Design database schemas, user interfaces, reports, system security controls, and design class diagrams. 5. **Core Process 5: Build, test, and integrate system components**: - Write code (classes, methods, user interfaces). - Implement database structures and write queries. - Perform continuous unit testing and component integration testing. 6. **Core Process 6: Complete system tests and then deploy the solution**: - Execute end-to-end system functional testing. - Conduct User Acceptance Testing (UAT). - Convert data, train users, and cut over to the live operating environment. --- ### 1.2.2 Information System Development Methodologies An **Information System Development Process (Methodology)** is the specific framework and set of comprehensive guidelines used to execute the six core processes for a given project. Prominent methodologies include: - **Unified Process (UP)**: An object-oriented, use-case-driven, architecture-centric, and iterative methodology. - **Extreme Programming (XP)**: An agile methodology centered on rapid feedback, continuous integration, pair programming, and automated testing. - **Scrum**: An agile project management framework emphasizing small self-organizing teams, daily standup meetings, backlogs, and fixed-length iterations called **Sprints**. --- ### 1.2.3 Iterative and Agile Systems Development Modern methodologies reject the rigid, sequential "Waterfall" model in favor of **Iterative and Agile Development**: - **Agile Development**: - An approach that emphasizes extreme flexibility, close collaboration with business users, and rapid responsiveness to changing requirements throughout the project lifecycle. - Acknowledges that business requirements cannot be completely frozen upfront. - **Iterative Development**: - A development strategy where the overall system is "grown" piece-by-piece across multiple successive mini-projects called **iterations**. - Each iteration typically lasts **2 to 4 weeks** and cycles through all six core processes to deliver an increment of fully tested, working software. ```mermaid flowchart TD subgraph Iteration1 ["Iteration 1 (e.g., Supplier Subsystem)"] direction LR I1_P2["Plan"] --> I1_P3["Analyze"] --> I1_P4["Design"] --> I1_P5["Build & Test"] --> I1_P6["Deploy/Review"] end subgraph Iteration2 ["Iteration 2 (e.g., Product Subsystem)"] direction LR I2_P2["Plan"] --> I2_P3["Analyze"] --> I2_P4["Design"] --> I2_P5["Build & Test"] --> I2_P6["Deploy/Review"] end subgraph IterationN ["Iteration N (Subsequent Features)"] direction LR IN_P2["Plan"] --> IN_P3["Analyze"] --> IN_P4["Design"] --> IN_P5["Build & Test"] --> IN_P6["Final Deployment"] end Iteration1 --> Iteration2 --> IterationN ``` --- ### 1.2.4 Benefits of Iterative and Agile SDLC 1. **Early Business Value Delivery**: Portions of the operational system can be deployed and used by the business much earlier than in traditional projects. 2. **Early Risk Mitigation**: By tackling the toughest architectural and technical problems in early iterations, teams avoid finding fatal technical flaws near project deadlines. 3. **Adaptive Requirements Management**: Business users often discover their real requirements only after seeing working software prototypes. Iterations accommodate refinements without causing project failure. 4. **Improved Team Morale & Velocity**: Delivering small, functional chunks provides constant milestones and visible momentum. --- ## 1.3 Case Study: Ridgeline Mountain Outfitters (RMO) Throughout this course and textbook, concepts are anchored in the **Ridgeline Mountain Outfitters (RMO)** case study. ### 1.3.1 Company Background - **Nature of Business**: Large specialty retail firm providing high-quality outdoor and sporting apparel, gear, and accessories. - **Target Activities**: Skiing, snowboarding, mountain biking, water sports, hiking, camping, and mountaineering. - **Geographic Footprint**: Headquartered in Park City, Utah, serving the Rocky Mountain region, Western United States, and international customers. - **Evolution of Sales Channels**: - Began as a direct-mail catalog and telephone order company. - Expanded into physical retail stores across premier resort destinations. - Implemented an extensive multi-channel E-Business presence. - **Core Challenge**: Legacy back-office systems are strained by rapid growth, requiring a complete modernization into an integrated Supply Chain Management (SCM) and Customer Support System (CSS). --- ### 1.3.2 The RMO Tradeshow System Project - **The Business Opportunity**: RMO purchasing agents attend apparel and fabric trade shows across the globe (e.g., Paris, Milan, New York, Tokyo) to discover innovative clothing lines, source technical fabrics, and negotiate supplier agreements. - **The Operational Problem**: Purchasing agents previously captured supplier contacts, product notes, fabric samples, and pricing on paper notes or business cards. Data was frequently lost, delayed, or duplicated, preventing timely purchase orders upon returning to headquarters. - **The Proposed Solution**: Develop a lightweight, mobile **Tradeshow System** application running on mobile devices (tablets and smartphones) that enables purchasing agents to capture supplier and product information on-site at trade shows and synchronize directly with RMO's corporate servers. - **Educational Context**: In Chapter 1, we trace a compact **6-day iteration** of this system focusing strictly on the **Supplier Information Subsystem**. --- ## 1.4 Pre-Project Activities (Core Process 1) ### 1.4.1 Pre-Project Scope and Feasibility Before any budget is committed or developers begin work, pre-project activities take place under **Core Process 1: Identify the problem or need and obtain approval**: 1. Identify the fundamental business problem and operational need. 2. Investigate technological alternatives (laptops vs. smartphones vs. tablets). Laptops were too bulky for walking trade show floors; smartphones lacked screen real estate for high-resolution fabric photography; **tablets (e.g., iPads) provided the optimal form factor**, with smartphone compatibility as a secondary target. 3. Document initial financial and operational justification. 4. Present findings to executive management and secure formal funding and project sponsorship. --- ### 1.4.2 System Vision Document The **System Vision Document** is a formal artifact prepared during Core Process 1 to clearly articulate the business motivation, scope, and expected return on investment. ``` ================================================================================ SYSTEM VISION DOCUMENT ================================================================================ Project Name: RMO Tradeshow System (Mobile Application) Sponsoring Department: Merchandising and Purchasing Project Manager: Senior Systems Analyst Date Approved: September 15 -------------------------------------------------------------------------------- 1. PROBLEM DESCRIPTION -------------------------------------------------------------------------------- RMO purchasing agents regularly attend international clothing and fabric trade shows to discover new products and negotiate supplier arrangements. Currently, information regarding new suppliers, clothing lines, and manufacturing contacts is collected manually using paper notes, physical catalogs, and business cards. This process suffers from significant drawbacks: • Information is frequently misplaced, damaged, or delayed in transit. • Data entry into the corporate database must wait until agents return to headquarters, delaying critical purchasing decisions by weeks. • Inability to verify existing supplier records in real time leads to duplicate contacts and redundant negotiations. -------------------------------------------------------------------------------- 2. SYSTEM CAPABILITIES -------------------------------------------------------------------------------- The solution must provide mobile, connected software operating on tablets and smartphones with the following functional capabilities: • Capture and search supplier company details (name, address, country, specialties, rating). • Capture, search, and update supplier contact personnel (names, positions, direct telephone numbers, email addresses). • Record product information, descriptions, categories, target genders, and unit costs on-site. • Capture and upload high-resolution digital photographs of product designs, garments, and fabric swatches. • Provide flexible connectivity (Cellular 4G/5G and Wi-Fi) with secure HTTPS synchronization to RMO's corporate database. -------------------------------------------------------------------------------- 3. BUSINESS BENEFITS -------------------------------------------------------------------------------- • Tangible Financial Benefits: - Shorten product-to-market cycle time from 6 weeks to 10 days. - Eliminate duplicate supplier research and manual transcription labor, saving an estimated $45,000 annually. - Secure early-order supplier discounts (estimated at 3% to 5% savings on initial manufacturing runs). • Intangible Strategic Benefits: - Enhanced competitive agility in securing exclusive clothing trends. - Accurate, centralized repository of global supplier relationships. - Increased field productivity and satisfaction for purchasing agents. ================================================================================ ``` --- ## 1.5 Day 1: Project Planning & Subsystems (Core Process 2) Day 1 initiates the active development project. The project team focuses on **Core Process 2: Plan and monitor the project**. ### 1.5.1 Partitioning the System into Subsystems A complex system must be divided into smaller, manageable units called **subsystems**. A subsystem is an identifiable, fully functional partition of a complete information system. Based on the System Vision Document, the Tradeshow System is partitioned into two core subsystems: 1. **Supplier Information Subsystem**: Focuses on collecting and managing data regarding suppliers, manufacturers, vendors, and their professional contact representatives. 2. **Product Information Subsystem**: Focuses on capturing descriptions, specifications, classifications, and digital imagery of clothing and fabric items. > **Iteration Decision**: To maintain a fast pace and address fundamental dependencies first, the team dedicates the initial iteration strictly to the **Supplier Information Subsystem**. The Product Information Subsystem is deferred to Iteration 2. ```mermaid flowchart TD Tradeshow["RMO Tradeshow System"] Tradeshow --> Sub1["Supplier Information Subsystem (Assigned to Iteration 1)"] Tradeshow --> Sub2["Product Information Subsystem (Assigned to Iteration 2)"] Sub1 --> S1_F1["Look up supplier"] Sub1 --> S1_F2["Enter/update supplier"] Sub1 --> S1_F3["Look up contact"] Sub1 --> S1_F4["Enter/update contact"] Sub2 --> S2_F1["Look up product"] Sub2 --> S2_F2["Enter/update product"] Sub2 --> S2_F3["Upload product photo"] ``` --- ### 1.5.2 Work Breakdown Structure (WBS) The **Work Breakdown Structure (WBS)** establishes an exhaustive list of all tasks required to complete the iteration, categorized across the relevant SDLC Core Processes. ``` ================================================================================ WORK BREAKDOWN STRUCTURE (WBS) — ITERATION 1 (SUPPLIER SUBSYSTEM) ================================================================================ 1. CORE PROCESS 3: Discover and Understand Details 1.1 Interview purchasing agents to understand supplier tracking workflows 1.2 Identify and document all use cases for the Supplier Subsystem 1.3 Identify domain object classes and attributes 1.4 Model the preliminary Domain Class Diagram (DCD) 1.5 Construct detailed Activity Diagrams for supplier lookup workflows 1.6 Create preliminary user interface screen wireframes 2. CORE PROCESS 4: Design System Components 2.1 Design relational database schema (tables, primary/foreign keys, types) 2.2 Design system architectural configuration (client-server network topology) 2.3 Construct Preliminary Design Class Diagram (view layer vs. domain layer) 2.4 Formulate subsystem software architecture 3. CORE PROCESS 5: Build, Test, and Integrate System Components 3.1 Implement database schema in MySQL/SQL Server 3.2 Develop domain logic classes (Supplier and Contact) 3.3 Develop user interface view classes (SupplierView and ContactView) 3.4 Execute unit testing on domain methods and UI events 3.5 Integrate presentation layer with backend database queries 4. CORE PROCESS 6: Complete System Tests and Deploy Solution 4.1 Construct system functional test cases and test datasets 4.2 Execute functional quality assurance testing 4.3 Conduct User Acceptance Testing (UAT) with lead purchasing agents 4.4 Package deployment build and review iteration outcomes ================================================================================ ``` --- ### 1.5.3 Work Sequence Draft (Gantt Schedule) The WBS is translated into a time-sequenced schedule mapping out daily tasks across the 6-day iteration: | Project Day | Primary Core Process | Major Deliverables & Key Activities | Team Focus | |:---:|:---|:---|:---| | **Day 1** | **CP 2: Plan Project** | Review Vision Document, identify subsystems, develop WBS, create work sequence schedule. | Project Manager, Lead Analyst | | **Day 2** | **CP 3: Analyze Requirements** | Identify use cases for both subsystems, identify domain classes, draw preliminary class diagram. | Systems Analysts, Users | | **Day 3** | **CP 3 & CP 4: Detail & UI** | Focus on Supplier Subsystem, model activity diagram for lookup, construct UI wireframe layout. | Analysts, UI Designers, Users | | **Day 4** | **CP 4: System Design** | Design relational database tables, specify architectural configuration, construct design class diagram. | System Architects, DBA, Developers | | **Day 5** | **CP 4 & CP 5: Build & Test** | Implement PHP/C# view and domain classes, write SQL queries, conduct unit tests. | Software Developers | | **Day 6** | **CP 6: Test & Deploy** | Execute system integration tests, conduct User Acceptance Testing (UAT) with purchasing agents. | QA Testers, Users, Developers | ```mermaid flowchart LR D1["Day 1: Project Planning (WBS & Schedule)"] --> D2["Day 2: Requirements Discovery (Use Cases & Domain Classes)"] D2 --> D3["Day 3: Detail Workflows & UI (Activity Diagram & Wireframe)"] D3 --> D4["Day 4: System Architecture (Database & Class Design)"] D4 --> D5["Day 5: Construction (Coding & Unit Testing)"] D5 --> D6["Day 6: System Testing (Functional & UAT Deployment)"] ``` --- ## 1.6 Day 2: Requirements & Initial Domain Modeling (Core Process 3) Day 2 initiates **Core Process 3: Discover and understand the details of the problem or need**. The team works directly with purchasing agents to discover system capabilities. ### 1.6.1 Identifying Use Cases - **Use Case**: An activity or situation where the system is used by a specific actor to achieve a tangible business goal. - To identify use cases, analysts ask: *"What specific tasks does a purchasing agent perform when interacting with suppliers and products at a trade show?"* #### Use Case Master List (Both Subsystems) | Subsystem | Use Case Name | Functional Description | |:---|:---|:---| | **Supplier Information Subsystem** | **Look up supplier** | Search and display supplier company details, addresses, and associated contact personnel using partial name or country. | | **Supplier Information Subsystem** | **Enter/update supplier information** | Add a newly discovered supplier company or modify existing supplier attributes. | | **Supplier Information Subsystem** | **Look up contact** | Find contact person details using representative name or phone. | | **Supplier Information Subsystem** | **Enter/update contact information** | Add or modify a contact representative associated with a specific supplier. | | **Product Information Subsystem** | **Look up product information** | Search and retrieve garment specifications, fabrics, and supplier offerings. | | **Product Information Subsystem** | **Enter/update product information** | Create new clothing item entries or update pricing, gender category, and notes. | | **Product Information Subsystem** | **Upload product image** | Capture and associate digital photographs of clothing samples with product records. | --- ### 1.6.2 Identifying Object Classes (Domain Classes) - **Domain Classes**: The real-world "things" that the system needs to capture, remember, and track. - Analysts identify domain classes by inspecting the **nouns** spoken by business users during requirements interviews. | Candidate Domain Class | Core Attributes Tracked | Business Significance | |:---|:---|:---| | **Supplier** | `supplierName`, `address`, `city`, `state`, `zip`, `country`, `comments` | The manufacturing or wholesale vendor providing apparel lines. | | **Contact** | `name`, `phone`, `email`, `position`, `comments` | An individual sales or executive representative employed by a supplier. | | **Product** | `category`, `name`, `description`, `gender`, `unitCost`, `comments` | A specific clothing garment or fabric line sourced by RMO. | | **ProductPicture** | `pictureId`, `imageFile`, `caption`, `dateTaken` | High-resolution digital photograph of a product sample or fabric swatch. | --- ### 1.6.3 Preliminary Domain Class Diagram A **Domain Class Diagram** visually represents the structural foundation of the system by depicting domain classes, their internal attributes, and the associations connecting them. ```mermaid classDiagram direction LR class Supplier { +string supplierName +string address +string city +string state +string zip +string country +string comments } class Contact { +string name +string phone +string email +string position +string comments } class Product { +string category +string name +string description +string gender +string comments } class ProductPicture { +int pictureId +string imagePath +string caption } Supplier "1" -- "*" Contact : employs Supplier "1" -- "*" Product : manufactures Product "1" -- "*" ProductPicture : displays ``` > **Key Multiplicities**: > - A `Supplier` employs **1 or more (`1..*`)** `Contact` persons. Each `Contact` belongs to exactly **one (`1`)** `Supplier`. > - A `Supplier` offers **zero or more (`0..*`)** `Product` items. Each `Product` is supplied by **one (`1`)** `Supplier`. > - A `Product` may have **zero or more (`0..*`)** associated `ProductPicture` images. --- ## 1.7 Day 3: Detailed Requirements & UI Prototyping (Core Processes 3 & 4) Day 3 transitions from high-level discovery into detailed behavioral specifications for the **Supplier Information Subsystem**. ### 1.7.1 Detailed Scope: Supplier Information Subsystem The team deepens requirements for the four supplier use cases: 1. `Look up supplier` 2. `Enter/update supplier information` 3. `Look up contact` 4. `Enter/update contact information` --- ### 1.7.2 Use Case Diagram The **Use Case Diagram** visually establishes the boundary of the system, the actors interacting with it, and the specific use cases provided by the subsystem. ```mermaid flowchart LR Agent(("Purchasing Agent (Actor)")) subgraph SystemBoundary ["RMO Tradeshow System — Supplier Subsystem"] UC1(["Look up supplier"]) UC2(["Enter/update supplier information"]) UC3(["Look up contact"]) UC4(["Enter/update contact information"]) end Agent --> UC1 Agent --> UC2 Agent --> UC3 Agent --> UC4 ``` --- ### 1.7.3 Activity Diagram (Workflow Analysis) An **Activity Diagram** models the detailed sequence of procedural steps and decisions executed during a business workflow. Below is the workflow for the **Look up supplier** use case: ```mermaid flowchart TD StartNode([● Start]) --> EnterName[Purchasing agent enters supplier name or partial keyword] EnterName --> ClickSearch[Agent clicks 'Search' / 'Go'] ClickSearch --> QueryDB[System queries corporate database for matching suppliers] QueryDB --> CheckMatches{Matches found?} CheckMatches -- Yes --> DisplayList[System displays list of matching suppliers in results grid] CheckMatches -- No --> DisplayNotFound[System displays 'No Suppliers Found' message] DisplayList --> SelectSupplier[Purchasing agent selects a specific supplier row] SelectSupplier --> FetchDetails[System retrieves detailed supplier info and associated contacts] FetchDetails --> RenderScreen[System displays full supplier profile and contact cards] DisplayNotFound --> ModifyCriteria[Agent modifies search criteria or adds new supplier] ModifyCriteria --> EnterName RenderScreen --> EndNode([◉ End]) ``` --- ### 1.7.4 Draft Screen Layout & UI Prototyping During Day 3, analysts construct an initial low-fidelity screen mockup (Figure 1-16) to validate user experience with purchasing agents before writing code. #### Visual Wireframe Representation (Figure 1-16 Prototype) ``` +--------------------------------------------------------------------------------+ | RMO TRADESHOW APPLICATION — TABLET CLIENT INTERFACE | +--------------------------------------------------------------------------------+ | | | [ SEARCH CRITERIA ] | | Supplier Name: [ South Pacific_______________ ] [ SEARCH ] | | Country: [ All Countries |v] | | Product Category: [ Outerwear |v] | | | +--------------------------------------------------------------------------------+ | [ SEARCH RESULTS ] | | +---------------------------+-------------------+---------------------------+ | | | Supplier Name | Country | Contact Representative | | | +---------------------------+-------------------+---------------------------+ | | | > South Pacific Sportswear| New Zealand | Bill Williams | | | | Pacific Rim Textiles | Australia | Sarah Jenkins | | | | Southern Peak Gear | Chile | Carlos Mendez | | | +---------------------------+-------------------+---------------------------+ | +--------------------------------------------------------------------------------+ | [ SELECTED SUPPLIER PROFILE & CONTACT DETAILS ] | | Supplier Name: South Pacific Sportswear | | Address: 104 Harbor View Boulevard, Auckland, New Zealand | | Specialty: Merino Wool Technical Base Layers | | | | PRIMARY CONTACT: | | Name: Bill Williams Position: Senior Export Director | | Phone: +64 9 555 0192 Mobile: +64 21 555 8831 | | Email: bwilliams@southpacific.co.nz | | Comments: Highly reliable vendor; requires 30-day lead time on bulk yarn. | | | | [ EDIT SUPPLIER ] [ ADD NEW CONTACT ] [ CREATE PRODUCT NOTE ] | +--------------------------------------------------------------------------------+ ``` #### Detailed Visual and Functional Explanation - **Top Search Section**: Contains single-line text inputs for supplier name search and dropdown pickers for filtering by country and apparel category. A prominent action button initiates search execution. - **Middle Results Table**: A touch-responsive list displaying matching records. Selecting a row highlights the row and automatically triggers data binding in the details pane below. - **Bottom Profile Card**: An expansive view displaying complete corporate mailing data, followed by nested contact cards detailing direct telephone, email, and operational notes. --- ## 1.8 Day 4: Detailed System Architecture & Database Design (Core Process 4) Day 4 transitions into technical engineering under **Core Process 4: Design the system components**. ### 1.8.1 Database Schema Design The team transforms the conceptual domain classes into a normalized relational database schema (Figure 1-17). ```mermaid erDiagram SUPPLIER ||--o{ CONTACT : "employs (1:M)" SUPPLIER { int SupplierID PK "Identity Auto-Increment" varchar SupplierName "Not Null, Indexed" varchar Address "Mailing Address" varchar City "City" varchar State "State/Province" varchar PostalCode "Zip / Postal Code" varchar Country "Country" text Comments "Operational Notes" } CONTACT { int ContactID PK "Identity Auto-Increment" int SupplierID FK "References SUPPLIER(SupplierID)" varchar ContactName "Full Representative Name" varchar ContactPosition "Title / Role" varchar WorkPhone "Office Telephone" varchar MobilePhone "Cellular Phone" varchar EmailAddress "Primary Email" text Comments "Negotiation Notes" } ``` #### Referential Integrity and Keys - `SUPPLIER.SupplierID`: Primary key, uniquely identifies each vendor entity. - `CONTACT.ContactID`: Primary key, uniquely identifies each human contact representative. - `CONTACT.SupplierID`: Foreign key establishing a **1-to-Many (`1:M`)** referential integrity constraint. A contact cannot exist without being linked to a valid parent supplier record. Deletion of a supplier cascades or restricts contact records according to business safety rules. --- ### 1.8.2 Architectural Configuration Diagram The **Architectural Configuration Diagram** (Figure 1-18) details the physical deployment environment, hardware tiers, network boundaries, and communication protocols. ```mermaid flowchart TB subgraph Tier1 ["Tier 1: Client Presentation Tier (Mobile Field Devices)"] Tablet["Purchasing Agent Tablet (Apple iPad / Android Tablet) Runs Web Browser Client"] Phone["Purchasing Agent Smartphone (iOS / Android Phone) Secondary Mobile Client"] end subgraph NetworkEnv ["Public / Wireless Network Boundary"] Cellular["Cellular Data Network (4G LTE / 5G Mobile)"] WiFi["Trade Show / Hotel Wi-Fi (Encrypted Wireless LAN)"] Internet(("Public Internet (Encrypted TLS/HTTPS Transport)")) end subgraph Tier2 ["Tier 2: Corporate Application & Web Server Tier"] Firewall["Corporate Hardware Firewall & Reverse Proxy"] AppServer["RMO Production Web & App Server (Apache / NGINX / PHP / .NET Engine) Executes View & Controller Logic"] end subgraph Tier3 ["Tier 3: Enterprise Data Tier"] DBServer[("Enterprise Database Server (Microsoft SQL Server / MySQL) Hosts RMO Corporate Relational Database")] end Tablet --> WiFi Tablet --> Cellular Phone --> Cellular WiFi --> Internet Cellular --> Internet Internet --> Firewall Firewall --> AppServer AppServer -->|Internal Secure LAN / TCP 1433| DBServer ``` --- ### 1.8.3 Preliminary Design Class Diagram (DCD) The **Design Class Diagram** (Figure 1-19) bridges conceptual analysis classes and physical object-oriented source code. It partitions responsibilities using **Multilayer Design** into the **View Layer** (presentation and UI event handling) and the **Domain Layer** (business entities and data retrieval). ```mermaid classDiagram direction TB namespace ViewLayer { class SupplierView { -Supplier theSupplier +lookupSupplier() void +displaySupplier() void +validateSupplierInput() bool } class ContactView { -Contact theContact +lookupContact() void +displayContact() void +validateContactInput() bool } } namespace DomainLayer { class Supplier { -int supplierId -string supplierName -string address -string city -string state -string postalCode -string country -string comments +getSupplierInfo(string name, string country) List~Supplier~ +updateSupplier() bool +addSupplier() int } class Contact { -int contactId -int supplierId -string contactName -string contactPosition -string phone -string email -string comments +getContactInfo(string contactName) List~Contact~ +updateContact() bool +addContact() int } } SupplierView ..> Supplier : instantiates & queries ContactView ..> Contact : instantiates & queries Supplier "1" *-- "*" Contact : contains ``` --- ### 1.8.4 Subsystem Architectural Design Diagram Figure 1-20 demonstrates how client-side technologies integrate seamlessly with server-side components: ```mermaid flowchart LR subgraph ClientBrowser ["Client Device (Browser Sandbox)"] HTML["HTML / CSS (Visual Layout & Styling)"] JS["JavaScript Functions (validateSupplierInput() validateContactInput())"] end subgraph ViewLayerServer ["Web Application Server: View Layer"] SV["SupplierView Class (PHP) lookupSupplier() displaySupplier()"] CV["ContactView Class (PHP) lookupContact() displayContact()"] end subgraph DomainLayerServer ["Web Application Server: Domain Layer"] SC["Supplier Class (PHP) getSupplierInfo()"] CC["Contact Class (PHP) getContactInfo()"] end subgraph DatabaseEngine ["Enterprise Database"] SQLQueries[("SQL Database Engine SELECT * FROM SUPPLIER JOIN CONTACT...")] end HTML <--> JS JS -->|HTTP POST / GET Request| SV JS -->|HTTP POST / GET Request| CV SV --> SC CV --> CC SC -->|SQL Query Strings| SQLQueries CC -->|SQL Query Strings| SQLQueries ``` --- ### 1.8.5 Management Insights on Design Execution - **Design as a Multi-Tier Discipline**: System design encompasses multiple strata, ranging from high-level enterprise network topologies down to specific algorithmic method designs. - **Concurrent Engineering**: Modern iterative development rejects the antiquated notion that all design diagrams must be 100% complete before coding begins. Teams alternate continuously between targeted modeling and hands-on programming. - **Selective Modeling**: Not every minor feature requires a full diagram. Architects create formal models for complex, risk-heavy, or multi-team integration points while allowing straightforward CRUD logic to flow directly into code. --- ## 1.9 Day 5: Construction & Programming (Core Processes 4 & 5) Day 5 represents the hands-on coding and compilation phase under **Core Process 5: Build, test, and integrate system components**. ### 1.9.1 Implementation Workflow - Developers implement classes use-case-by-use-case. - Presentation templates (HTML/CSS) are wired to server-side script controllers (`SupplierView.php`). - Domain logic classes establish database connectivity via parameterized queries to eliminate security vulnerabilities such as SQL injection. - Unit testing is performed concurrently as each method is compiled. --- ### 1.9.2 Class Implementation Code Example The following code (Figure 1-21) demonstrates the server-side implementation of the presentation layer controller (`SupplierView`) in PHP: ```php theSupplier = new Supplier(); } /** * Renders the initial supplier lookup search form */ public function lookupSupplier(): void { include('lookupSupplier.inc.html'); } /** * Processes form submission, invokes domain logic, and renders results table */ public function displaySupplier(): void { include('displaySupplierTop.inc.html'); // Extract sanitised parameters from HTTP POST request extract($_REQUEST); // e.g. $supplier, $category, $product, $country, $contact // Delegate data retrieval to the Domain Layer Supplier object $results = $this->theSupplier->getSupplierInfo( $supplier, $category, $product, $country, $contact ); // Iterate through returned records and render responsive table rows foreach ($results as $resultItem) { ?> supplierName, ENT_QUOTES, 'UTF-8'); ?> contactName, ENT_QUOTES, 'UTF-8'); ?> contactPosition, ENT_QUOTES, 'UTF-8'); ?> ``` --- ## 1.10 Day 6: System Testing & Deployment (Core Process 6) The final day of the iteration focuses on validation and deployment under **Core Process 6: Complete system tests and then deploy the solution**. ### 1.10.1 Workflow of Testing Tasks Testing is an iterative quality assurance discipline. Every test cycle follows a standardized flowchart (Figure 1-22): ```mermaid flowchart TD StartTesting([● Start Testing]) --> GenData[Create Comprehensive Test Datasets & Test Scenarios] GenData --> RunTests[Conduct Test Execution: Unit, Integration & UI Verification] RunTests --> Evaluate{Defects or Errors Detected?} Evaluate -- Yes --> LogDefect[Document Errors, Exceptions, and Usability Issues] LogDefect --> PatchCode[Assign to Developers to Fix Defects & Refactor] PatchCode --> RunTests Evaluate -- No --> UAT[Conduct User Acceptance Testing with Purchasing Agents] UAT --> UATCheck{Do Users Sign Off?} UATCheck -- Yes --> DeployInc[Deploy Working Increment to Pilot Tablet Devices] UATCheck -- No --> LogDefect DeployInc --> EndTesting([◉ Complete Iteration]) ``` #### Categories of Testing Executed on Day 6 1. **Functional Quality Assurance (QA) Testing**: Executed by technical testers to ensure that every button, search algorithm, input filter, and database transaction operates without defects under normal, boundary, and invalid input conditions. 2. **User Acceptance Testing (UAT)**: Conducted directly by the purchasing agents. Tests both technical correctness and operational "fitness" to ensure the interface effectively supports fast-paced trade show interactions. --- ### 1.10.2 Final Working Screen Representation Figure 1-23 displays the final tablet browser interface as delivered at the end of Day 6: ``` +================================================================================+ | RMO TRADESHOW PORTAL [Logged in: Sarah Jenkins (Buyer)] [Logout] [?] | +================================================================================+ | SEARCH SUPPLIER DIRECTORY | | | | Supplier Name: [ Alpine Technical Weaves___________ ] | | Product Category: [ All Fabric Types |v] Country: [ Switzerland |v] | | Contact Name: [ _______________________ ] | | | | [ SEARCH DATABASE (GO) ] | +================================================================================+ | SEARCH RESULTS (3 MATCHES LOCATED) | | +---------------------------+-----------------------+-----------------------+ | | | SUPPLIER NAME | CONTACT NAME | CONTACT POSITION | | | +---------------------------+-----------------------+-----------------------+ | | | Alpine Technical Weaves | Dr. Markus Steiner | Lead Materials Chemist| | | | Alpine Technical Weaves | Heidi Zurbriggen | VP International Sales| | | | Swiss Thermocore Fibers | Beat Oberholzer | Regional Director | | | +---------------------------+-----------------------+-----------------------+ | +================================================================================+ | SUPPLIER PROFILE: Alpine Technical Weaves | | Corporate HQ: Industriestrasse 44, CH-8005 Zurich, Switzerland | | Certifications: Bluesign Approved, GORE-TEX Certified Fabric Partner | | Primary Contact Details: | | - Name: Heidi Zurbriggen | | - Direct Tel: +41 44 211 8890 | Mobile: +41 79 555 4321 | | - Email: h.zurbriggen@alpineweaves.ch | | | | [ + ADD NEW PRODUCT SAMPLE ] [ EDIT SUPPLIER DETAILS ] [ LOG MEETING ] | +================================================================================+ ``` --- ### 1.10.3 First Iteration Recap & Lessons Learned - **Iteration Scope vs. Reality**: While this academic example was condensed into 6 days, real commercial iterations typically span **2 to 4 weeks**. - **User Involvement is Paramount**: Purchasing agents participated actively on Days 1, 2, 3, and 6. Systems built in isolation from users inevitably fail to meet business expectations. - **Handling Emerging Requirements**: During Day 3 and Day 6, agents realized they also needed to record supplier booth numbers at trade shows. In an Agile project, this requirement is placed into the project backlog and scheduled for Iteration 2 without derailing the team. --- ## 1.11 Course Curriculum Roadmap: The Rest of the Book This textbook is structured around three core pillars: **Systems Analysis**, **Systems Design**, and **Project Management**. ```mermaid flowchart TD P1["Part 1: Introduction to System Development • Chapter 1: From Beginning to End (Overview) • Online Chapter A: The Systems Analyst"] P2["Part 2: Systems Analysis Activities • Chapter 2: Investigating System Requirements • Chapter 3: Identifying Use Cases & User Stories • Chapter 4: Domain Modeling • Chapter 5: Use Case Modeling (Descriptions, Activity, SSDs) • Online Chapter B: Traditional Structured Analysis (DFDs)"] P3["Part 3: Essentials of Systems Design • Chapter 6: Foundations for Systems Design • Chapter 7: Defining System Architecture • Chapter 8: Designing the User Interface • Chapter 9: Designing the Database"] P4["Part 4: System Development & Project Management • Chapter 10: Approaches to System Development (Predictive vs Adaptive) • Chapter 11: Project Planning & Project Management • Online Chapter C: Advanced PM Techniques (Pert, CPM, NPV)"] P5["Part 5: Advanced Design and Deployment • Chapter 12: Object-Oriented Design Fundamentals (CRC Cards) • Chapter 13: O-O Design: Use Case Realization (Sequence/Communication) • Chapter 14: Deploying the New System"] P1 --> P2 --> P3 --> P4 --> P5 ``` --- ## 1.12 Chapter Summary & Key Terminology Glossary ### Chapter Summary - **Systems Analysis and Design** provide the disciplined tools, models, and techniques required to translate complex organizational needs into robust information systems. - The **SDLC** comprises **six core processes**: Problem Identification, Project Planning, Requirements Discovery, System Design, Construction/Testing, and Deployment. - **Iterative & Agile Development** divide projects into small, manageable cycles delivering tested, working increments of software while remaining responsive to evolving user requirements. - The **RMO Tradeshow System** demonstrated that each iteration exercises all six core processes, producing structured artifacts from vision documents and domain models to database schemas and executable code. --- ### Key Terminology Glossary - **Activity Diagram**: A graphical UML diagram representing the procedural workflow and decision pathways of a use case or business activity. - **Agile Development**: A systems development philosophy emphasizing flexibility, close customer collaboration, continuous feedback, and rapid adaptation to changing requirements. - **Architectural Configuration Diagram**: A hardware and network topology diagram illustrating the physical distribution of clients, servers, firewalls, and communication protocols. - **Class Diagram**: A UML structural diagram showing the object classes, their attributes, and their relationships (associations) that comprise a problem domain. - **Computer Application (App)**: A targeted computer program running on a computing device to execute a bounded set of end-user functions. - **Database Schema**: The structural blueprint of a database defining tables, attributes, data types, primary keys, foreign keys, and referential integrity constraints. - **Design Class Diagram (DCD)**: An extended UML class diagram used in systems design, detailing software classes, method signatures, attribute types, and layer segregation (View vs. Domain). - **Domain Classes**: Categories of business objects in the problem environment about which the information system must store data and enforce business rules. - **Information System**: An interrelated collection of software components, databases, hardware, manual procedures, and users designed to collect, process, and distribute business data. - **Iterative Development**: An approach where a system is constructed incrementally through a succession of brief, bounded iterations (mini-projects). - **Multilayer Architecture**: An architectural pattern that separates user interface logic (View layer), business domain rules (Domain layer), and database management (Data layer). - **Project**: A planned organizational undertaking with a defined start and finish date that delivers a specific, measurable result within budget and resource constraints. - **Subsystem**: An identifiable, functionally cohesive portion of a larger system capable of operating as an integrated unit. - **System Development Life Cycle (SDLC)**: The end-to-end framework of all activities and processes necessary to conceptualize, plan, analyze, design, build, test, deploy, and maintain an information system. - **System Vision Document**: An initial project charter summarizing the business problem, proposed system capabilities, and expected operational/financial benefits. - **Systems Analysis**: Those discovery activities that enable an analyst to understand and specify in detail **WHAT** an information system must accomplish. - **Systems Design**: Those technical specification activities that describe in detail **HOW** system components, user interfaces, networks, and databases will physically operate. - **Use Case**: A distinct business activity or functional interaction that an actor initiates with the system to achieve a specific goal. - **Use Case Diagram**: A UML behavioral diagram illustrating the boundary of a system, the external actors who interact with it, and the use cases they trigger. - **Work Breakdown Structure (WBS)**: A hierarchical task decomposition specifying all operational work required to deliver a project or iteration. - **Work Sequence Draft**: A time-phased schedule (or Gantt chart) detailing task durations, predecessor dependencies, and resource allocations for an iteration.