# Chapter 2: Investigating System Requirements
> **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 2
---
## Table of Contents
- [2.0 Chapter Overview & Learning Objectives](#20-chapter-overview--learning-objectives)
- [2.1 The RMO Consolidated Sales and Marketing System (CSMS) Project Context](#21-the-rmo-consolidated-sales-and-marketing-system-csms-project-context)
- [2.1.1 Strategic Planning and Architectural Plans](#211-strategic-planning-and-architectural-plans)
- [2.1.2 The Four Core Subsystems of CSMS](#212-the-four-core-subsystems-of-csms)
- [2.2 Systems Analysis Activities (Core Process 3)](#22-systems-analysis-activities-core-process-3)
- [2.2.1 The Five Analysis Activities](#221-the-five-analysis-activities)
- [2.2.2 Iterative Nature of Analysis Activities](#222-iterative-nature-of-analysis-activities)
- [2.3 What Are Requirements? The FURPS+ Framework](#23-what-are-requirements-the-furps-framework)
- [2.3.1 Functional versus Non-Functional Requirements](#231-functional-versus-non-functional-requirements)
- [2.3.2 The FURPS Categories](#232-the-furps-categories)
- [2.3.3 The Extended FURPS+ Categories](#233-the-extended-furps-categories)
- [2.3.4 FURPS+ Comparison Matrix](#234-furps-comparison-matrix)
- [2.4 Stakeholders: Involving the Right People](#24-stakeholders-involving-the-right-people)
- [2.4.1 Definition and Categories of Stakeholders](#241-definition-and-categories-of-stakeholders)
- [2.4.2 Comprehensive Stakeholder Matrix](#242-comprehensive-stakeholder-matrix)
- [2.4.3 Stakeholders of RMO's CSMS Project](#243-stakeholders-of-rmos-csms-project)
- [2.5 Information-Gathering Techniques](#25-information-gathering-techniques)
- [2.5.1 Interviewing Users and Stakeholders](#251-interviewing-users-and-stakeholders)
- [2.5.2 Distributing and Collecting Questionnaires](#252-distributing-and-collecting-questionnaires)
- [2.5.3 Reviewing Inputs, Outputs, and Procedures (Document Analysis)](#253-reviewing-inputs-outputs-and-procedures-document-analysis)
- [2.5.4 Observing and Documenting Business Processes](#254-observing-and-documenting-business-processes)
- [2.5.5 Researching Vendor Solutions](#255-researching-vendor-solutions)
- [2.5.6 Collecting Active User Comments and Suggestions](#256-collecting-active-user-comments-and-suggestions)
- [2.6 Models and Modeling in Systems Analysis](#26-models-and-modeling-in-systems-analysis)
- [2.6.1 What is a Model?](#261-what-is-a-model)
- [2.6.2 Types of Models (Textual, Graphical, Mathematical)](#262-types-of-models-textual-graphical-mathematical)
- [2.6.3 Six Major Reasons for Modeling](#263-six-major-reasons-for-modeling)
- [2.6.4 Analysis Models versus Design Models](#264-analysis-models-versus-design-models)
- [2.7 Documenting Workflows with UML Activity Diagrams](#27-documenting-workflows-with-uml-activity-diagrams)
- [2.7.1 Definition of Workflow and Role of Activity Diagrams](#271-definition-of-workflow-and-role-of-activity-diagrams)
- [2.7.2 UML Activity Diagram Standard Notation & Symbols](#272-uml-activity-diagram-standard-notation--symbols)
- [2.7.3 Case Study 1: Sequential Order Fulfillment Workflow](#273-case-study-1-sequential-order-fulfillment-workflow)
- [2.7.4 Case Study 2: Concurrent Processing Workflow (Forks and Joins)](#274-case-study-2-concurrent-processing-workflow-forks-and-joins)
- [2.7.5 Guidelines for Constructing Activity Diagrams](#275-guidelines-for-constructing-activity-diagrams)
- [2.8 Chapter Summary & Key Terminology Glossary](#28-chapter-summary--key-terminology-glossary)
---
## 2.0 Chapter Overview & Learning Objectives
Chapter 2 expands upon the fundamental foundations established in Chapter 1 by diving deep into **SDLC Core Process 3: Discover and understand the details of the problem or need**. This core process represents the heart of systems analysis.
To build an effective information system, analysts must thoroughly investigate business processes, understand stakeholders' problems, specify system requirements with absolute clarity, and document operational workflows using industry-standard models.
### Learning Objectives
After studying this chapter, students should be able to:
1. **Explain the Five Key Systems Analysis Activities**: Articulate how analysts gather information, define requirements, prioritize capabilities, prototype user-interface dialogs, and evaluate requirements with users.
2. **Differentiate Functional and Non-Functional Requirements**: Apply the **FURPS+** framework to classify business functions, usability, reliability, performance, security, and technical design constraints.
3. **Analyze Stakeholder Roles**: Identify and categorize internal, external, operational, and executive stakeholders, ensuring all affected perspectives are represented.
4. **Select and Execute Information-Gathering Techniques**: Determine the optimal combination of interviews, questionnaires, document review, observation, vendor research, and user feedback.
5. **Understand the Critical Role of Modeling**: Explain why analysts build models (abstraction, communication, complexity reduction) and distinguish analysis models from design models.
6. **Construct UML Activity Diagrams**: Model complex real-world workflows using swimlanes, action states, transition flows, decision diamonds, and concurrency synchronization bars (forks and joins).
---
## 2.1 The RMO Consolidated Sales and Marketing System (CSMS) Project Context
### 2.1.1 Strategic Planning and Architectural Plans
Information systems development projects rarely occur in isolation. Instead, they originate from an organization's overall **Information Systems Strategic Plan**, which establishes two major roadmaps:
1. **Technology Architecture Plan**: Specifies the hardware infrastructure, operating system platforms, network topologies, database management engines, and telecommunication protocols to be utilized throughout the enterprise.
2. **Application Architecture Plan**: Identifies the integrated portfolio of computer software applications required to support the organization's strategic goals and operational workflows.
At **Ridgeline Mountain Outfitters (RMO)**, the strategic growth of retail stores, mail-order telephone channels, and e-commerce web sales overwhelmed their aging legacy systems. Management initiated the **Consolidated Sales and Marketing System (CSMS)** to replace fragmented software with an integrated, modern platform.
---
### 2.1.2 The Four Core Subsystems of CSMS
The CSMS project is partitioned into four functional subsystems (Figure 2-1):
```mermaid
flowchart TB
subgraph EnterpriseCSMS ["RMO Consolidated Sales & Marketing System (CSMS)"]
direction TB
subgraph Sub1 ["1. Sales Subsystem"]
S1["• Search Catalog & Check Stock
• Process In-Store Point of Sale
• Process Phone / Mail Orders
• Online Shopping Cart Checkout"]
end
subgraph Sub2 ["2. Order Fulfillment Subsystem"]
S2["• Warehouse Pick List Generation
• Package & Ship Merchandise
• Track Shipments with Couriers
• Process Customer Returns"]
end
subgraph Sub3 ["3. Customer Account Subsystem"]
S3["• Create & Maintain Profiles
• Track Purchase History
• Manage Credit & Billing Info
• Loyalty Program Management"]
end
subgraph Sub4 ["4. Marketing Subsystem"]
S4["• Dynamic Product Catalog Setup
• Promotional Pricing & Sales
• Marketing Analytics & Demographics
• Social Media & Campaign Tracking"]
end
DB[(Central Enterprise Database)]
Sub1 <--> DB
Sub2 <--> DB
Sub3 <--> DB
Sub4 <--> DB
end
```
---
## 2.2 Systems Analysis Activities (Core Process 3)
### 2.2.1 The Five Analysis Activities
Systems analysis involves discovering and understanding the details of an organization's problem. Core Process 3 is divided into **five essential activities** (Figure 2-2):
```mermaid
flowchart TD
A1["1. Gather Detailed Information
(Interviews, Questionnaires, Document Review, Observation)"]
A2["2. Define Requirements
(Model Functional & Non-Functional Requirements via FURPS+)"]
A3["3. Prioritize Requirements
(Classify by Essential, Important, Nice-to-Have for Iteration Planning)"]
A4["4. Develop User-Interface Dialogs
(Model User-System Interaction Flow & Early Screen Layouts)"]
A5["5. Evaluate Requirements with Users
(Review Models, Conduct Walkthroughs, Gather Direct Feedback)"]
A1 --> A2
A2 --> A3
A3 --> A4
A4 --> A5
A5 -->|Feedback & Changes| A1
```
#### In-Depth Description of Each Activity
1. **Gather Detailed Information**:
- The analyst meets with stakeholders, distributes questionnaires, analyzes existing manuals and reports, observes actual work routines, and studies competing industry solutions.
- Answers: *"How do employees perform their tasks today, and what information do they need?"*
2. **Define Requirements**:
- The gathered information is synthesized into structured logical models (Use Cases, Class Diagrams, Activity Diagrams).
- Both functional requirements (business functions) and non-functional requirements (security, performance) are systematically documented.
3. **Prioritize Requirements**:
- In an iterative project, not all features can or should be built in the first iteration. Requirements are partitioned into:
- **Mandatory (Must-Have / Essential)**: Critical core features required for business viability.
- **Important (Should-Have)**: Significant operational improvements that can wait for Iteration 2 or 3.
- **Optional (Nice-to-Have)**: Enhancements to be implemented only if schedule and budget permit.
4. **Develop User-Interface Dialogs**:
- Analysts model the conversation flow between user and software. Storyboards, wireframes, and menu hierarchies help users visualize how daily tasks will be performed on screens.
5. **Evaluate Requirements with Users**:
- An iterative feedback mechanism where analysts present their models, activity diagrams, and screen mockups back to the users for validation, catching misconceptions before construction.
---
### 2.2.2 Iterative Nature of Analysis Activities
In traditional Waterfall methodologies, analysis was treated as a rigid, one-time phase. In modern **Agile and Iterative development**, analysis activities occur across every iteration:
- **Iteration 1**: High-level analysis of the overall architecture and in-depth analysis of the first subsystem.
- **Subsequent Iterations**: Deep-dive analysis occurs just ahead of construction for that iteration's specific use cases.
- Analysis models are continuously refined as users interact with working software increments.
---
## 2.3 What Are Requirements? The FURPS+ Framework
### 2.3.1 Functional versus Non-Functional Requirements
A **System Requirement** is a statement of what the system must do or a characteristic the system must exhibit to solve an organizational problem.
```mermaid
flowchart LR
Req["System Requirements"] --> FR["Functional Requirements
(Activities & Functions system must perform)"]
Req --> NFR["Non-Functional Requirements
(Quality attributes, constraints, performance goals)"]
```
- **Functional Requirements**:
- The business uses and functional capabilities the users carry out with the system.
- Directly correspond to the **Use Cases** of the system (e.g., *"Calculate sales tax"*, *"Generate warehouse pick list"*, *"Lookup customer order history"*).
- **Non-Functional Requirements**:
- The behavioral properties, performance standards, quality constraints, and environmental limitations under which the functional capabilities must operate.
---
### 2.3.2 The FURPS Categories
To systematically capture both functional and non-functional requirements, analysts use the **FURPS** acronym developed by Robert Grady at Hewlett-Packard:
- **F — Functional Requirements**:
- Business rules and operational processes.
- Automated tasks and functions.
- System calculations, reports, and data transformations.
- **U — Usability Requirements**:
- Operational ergonomics and user interface ease-of-use.
- Look-and-feel standards (typography, color palettes, button placement).
- Online user assistance, help documentation, and error recovery guidance.
- **R — Reliability Requirements**:
- System dependability and availability (e.g., 99.99% uptime).
- Mean Time Between Failures (MTBF).
- Fault tolerance, automated failover, disaster recovery, and automated database backups.
- **P — Performance Requirements**:
- System throughput and operational speed (e.g., *"Search results returned in under 1.5 seconds"*).
- Processing capacity and concurrent user volume (e.g., *"Support 5,000 simultaneous checkouts during peak sales"*).
- Resource consumption (CPU usage, network bandwidth limitations).
- **S — Security Requirements**:
- Authentication mechanisms (passwords, multi-factor authentication, biometric logins).
- Role-based authorization controls (who can view vs. edit sensitive payroll or customer data).
- Data encryption standards (TLS 1.3 in transit, AES-256 for resting database records).
- Physical facility and server room access controls.
---
### 2.3.3 The Extended FURPS+ Categories
The **"+"** in **FURPS+** extends the model to encompass engineering constraints and technical boundaries:
- **Design Constraints**:
- Specific technical hardware, operating systems, and architectural limitations imposed on developers (e.g., *"Must execute within Safari on iOS and Chrome on Windows"* or *"Must utilize existing Oracle 19c database"*).
- **Implementation Requirements**:
- Constraints regarding programming languages, enterprise libraries, development tools, coding standards, or source code version control (e.g., *"Must be coded in C# .NET Core using Entity Framework"*).
- **Interface Requirements**:
- Specifications for communicating with external third-party systems and legacy enterprise applications (e.g., *"Real-time REST API integration with FedEx / UPS for shipping labels"* or *"EDI integration with banking clearinghouses"*).
- **Physical Requirements**:
- Physical characteristics and environmental limitations of the computing hardware (e.g., *"Handheld warehouse barcode scanners must withstand a 2-meter drop onto concrete"* or *"Must operate in refrigerated warehouse environments at -20°C"*).
- **Supportability Requirements**:
- Characteristics that facilitate long-term maintenance, software patching, technical upgrades, and localization (e.g., *"Multi-currency and multi-language support (English, Spanish, French)"* or *"Automated continuous integration build pipeline"*).
---
### 2.3.4 FURPS+ Comparison Matrix
| Category | Type | Primary Question Asked | Real-World RMO CSMS Example |
|:---|:---|:---|:---|
| **F — Functional** | Functional | *What business activities must the system execute?* | Allow a customer to place an online order and receive email invoice confirmation. |
| **U — Usability** | Non-Functional | *How easily can users navigate and operate screens?* | UI layout must allow warehouse clerks to scan and confirm items with one hand on a tablet. |
| **R — Reliability** | Non-Functional | *How dependable is the system against failures?* | System must guarantee 99.95% availability during 4th quarter retail shopping season. |
| **P — Performance** | Non-Functional | *How fast and scalable is transaction throughput?* | Product inventory status must update in under 1.0 second across 10,000 concurrent browser sessions. |
| **S — Security** | Non-Functional | *How are data and resources protected from threats?* | Credit card data must be tokenized and comply strictly with PCI-DSS Level 1 compliance. |
| **+ Design Constraints** | Constraint | *What architectural rules constrain construction?* | Must deploy inside RMO's existing corporate Linux private cloud virtual machines. |
| **+ Implementation** | Constraint | *What tools and languages must be used?* | Backend business logic must be authored in Java Enterprise Edition (JEE) with Spring Boot. |
| **+ Interface** | Non-Functional | *How does the system exchange data with external entities?* | Nightly batch export of general ledger journals to the legacy corporate SAP accounting engine. |
| **+ Physical** | Constraint | *What physical environment constraints exist?* | Retail store POS terminals must include integrated magnetic stripe and EMV chip readers. |
| **+ Supportability** | Non-Functional | *How easily can the system be configured and maintained?* | System must allow business managers to modify seasonal promotional discounts without recompiling code. |
---
## 2.4 Stakeholders: Involving the Right People
### 2.4.1 Definition and Categories of Stakeholders
A **Stakeholder** is any person or group who has an interest in the successful implementation, operation, or outcome of an information system project.
Stakeholders are the primary source of business requirements. Failure to involve the correct stakeholders leads directly to systems that are technically functional but operationally rejected.
Stakeholders are categorized along two orthogonal dimensions:
1. **Organizational Boundary**:
- **Internal Stakeholders**: Individuals employed within the sponsoring organization.
- **External Stakeholders**: Entities operating outside the organizational boundary (customers, partners, suppliers, government regulatory agencies).
2. **Interaction Level**:
- **Operational Stakeholders**: Individuals who regularly interact with the system on a daily or frequent basis to complete hands-on operational work.
- **Executive Stakeholders**: Individuals who do not directly interact with daily data entry screens, but who rely on summarized executive reporting, fund the project, or hold financial and strategic accountability for system success.
---
### 2.4.2 Comprehensive Stakeholder Matrix
Figure 2-4 illustrates how stakeholders are distributed across these quadrants using a comprehensive corporate accounting system:
```mermaid
flowchart TD
subgraph Matrix ["Corporate Information System Stakeholder Quadrants"]
direction TB
subgraph TopRow ["INTERNAL TO ORGANIZATION"]
direction LR
subgraph Q1 ["Internal Operational Stakeholders"]
O1["• Bookkeepers & Accounting Clerks
• Billing Specialists
• Payroll Processing Staff
• Inventory Controllers"]
end
subgraph Q2 ["Internal Executive Stakeholders"]
E1["• Chief Financial Officer (CFO)
• Corporate Controller
• Internal Audit Directors
• Vice President of Operations"]
end
end
subgraph BottomRow ["EXTERNAL TO ORGANIZATION"]
direction LR
subgraph Q3 ["External Operational Stakeholders"]
O2["• Retail & Online Customers
• Supplier Billing Representatives
• Courier Dispatchers (UPS/FedEx)
• Bank Settlement Clerks"]
end
subgraph Q4 ["External Executive Stakeholders"]
E2["• Board of Directors
• External Financial Auditors (KPMG/PwC)
• Tax Authorities (IRS / Tax Dept)
• Regulatory Agencies (SEC)"]
end
end
end
```
---
### 2.4.3 Stakeholders of RMO's CSMS Project
For the RMO Consolidated Sales and Marketing System, analysts identified key stakeholders across multiple organizational tiers (Figure 2-5):
1. **Executive Stakeholders**:
- **John Blankens (President / CEO)**: Concerned with overall return on investment, competitive differentiation, and corporate image.
- **William McDougal (VP Sales & Marketing)**: Driven by sales growth, promotional agility, customer retention, and brand expansion.
- **Financial Executives**: Monitor capital expenditures, software licensing costs, and operational cost savings.
2. **Operational Stakeholders**:
- **Phone and Mail-Order Sales Clerks**: Require streamlined, intuitive screens to rapidly enter customer phone orders without navigating multiple confusing menus.
- **Warehouse Shipping and Receiving Personnel**: Need rugged, barcode-integrated displays to pick items, verify garment sizes, and print courier labels rapidly.
- **Marketing Specialists**: Require tools to update online seasonal catalogs, post marketing banners, and analyze demographic shopping patterns.
3. **External Stakeholders**:
- **Online Consumers**: Seek a responsive, intuitive, and secure e-commerce shopping experience across desktops, tablets, and smartphones.
- **Third-Party Logistics Partners (FedEx, UPS)**: Require standardized API data exchanges to accept package tracking notifications.
4. **Technical & Support Staff**:
- Database Administrators (DBAs), network engineers, cybersecurity officers, and IT help-desk technicians who will maintain the platform long after launch.
---
## 2.5 Information-Gathering Techniques
To discover requirements, systems analysts employ **six proven information-gathering techniques**:
```mermaid
flowchart LR
A["Information Gathering Techniques"] --> T1["1. Interview Users & Stakeholders"]
A --> T2["2. Distribute & Collect Questionnaires"]
A --> T3["3. Review Documentation & Inputs/Outputs"]
A --> T4["4. Observe & Document Business Processes"]
A --> T5["5. Research Vendor Solutions"]
A --> T6["6. Collect Active User Feedback"]
```
---
### 2.5.1 Interviewing Users and Stakeholders
Interviewing is the **single most effective, informative, and widely used fact-finding technique**. It enables direct two-way dialogue, non-verbal observation, and deep exploration of complex exceptions.
#### Themes for Interview Questions (Figure 2-6)
When questioning users, analysts structure their inquiries around four core themes:
1. **What are the Business Processes?**:
- *"What specific steps do you take to process a customer return?"*
- *"Who initiates the order fulfillment process?"*
- *"How do exceptions or backorders get handled?"*
2. **What Data is Required and Stored?**:
- *"What specific details about a customer must be captured?"*
- *"What fields appear on your current inventory pick tickets?"*
- *"What calculations determine promotional discounts?"*
3. **What Business Rules Govern the Operations?**:
- *"Under what conditions can a customer return merchandise without a receipt?"*
- *"What is the maximum credit limit for corporate wholesale accounts?"*
4. **What are the User Interactions and Interfaces?**:
- *"What reports do you print every Monday morning?"*
- *"What screen layouts slow you down during phone orders?"*
#### The Three Phases of an Effective Interview
```mermaid
flowchart LR
P1["Phase 1: Preparation
• Establish objectives
• Select interviewees
• Prepare customized agenda
• Review existing documents"] --> P2["Phase 2: Conduct Interview
• Introduce purpose & establish rapport
• Follow structured agenda
• Probe deeply for exceptions
• Take detailed notes / record
• Document open questions"]
P2 --> P3["Phase 3: Follow-Up
• Transcribe notes within 24h
• Send summary to interviewee
• Confirm accuracy & sign-off
• Update Open-Items List"]
```
#### Sample Interview Checklist & Agenda Templates (Figures 2-7, 2-8, 2-9)
```
================================================================================
SAMPLE INTERVIEW AGENDA (FIGURE 2-8)
================================================================================
Project: RMO Consolidated Sales and Marketing System (CSMS)
Interviewee: Mary Pat Coleman, Supervisor of Phone Order Operations
Interviewer: Lead Systems Analyst
Date/Time: October 4, 10:00 AM – 11:30 AM
Location: Conference Room C (Headquarters)
MEETING OBJECTIVE:
Understand the end-to-end procedural steps and data capture requirements
involved in taking customer orders over the telephone.
AGENDA TOPICS:
1. Introduction and Project Scope Overview (05 mins)
2. Walkthrough of Current Phone Order Workflow (25 mins)
- Customer verification / lookup
- Item inquiry and stock verification
- Payment processing and gift card redemption
3. Identification of Current Bottlenecks & Frustrations (20 mins)
4. Discussion of Proposed System Features & Mobile Support (20 mins)
5. Review of Sample Order Confirmation Emails & Invoices (15 mins)
6. Wrap-Up, Action Items, and Open Questions (05 mins)
================================================================================
```
#### The Open-Items List (Figure 2-9)
During interviews, questions inevitably arise that the interviewee cannot answer immediately. Analysts maintain an **Open-Items List** to ensure no unanswered requirement is forgotten:
| Item # | Open Question / Ambiguity | Assigned Person | Target Resolution Date | Current Status |
|:---:|:---|:---|:---:|:---:|
| **101** | What is the maximum dollar limit for online credit card transactions before manager authorization is required? | Controller (Accounting) | Oct 12 | Open |
| **102** | Does the system need to calculate Canadian GST/PST sales tax for mail orders shipped to Vancouver? | Tax Compliance Manager | Oct 14 | Resolved (Yes) |
| **103** | How many days must digital trade show photos be retained online before archiving to cold storage? | VP Merchandising | Oct 18 | Open |
---
### 2.5.2 Distributing and Collecting Questionnaires
Questionnaires enable analysts to collect quantitative information from hundreds or thousands of geographically dispersed stakeholders (e.g., all 45 RMO retail store managers or 5,000 online consumers).
- **Strengths**: Cost-effective, fast, wide demographic reach, responses are easily aggregated and tabulated statistically.
- **Weaknesses**: Lacks depth, cannot probe ambiguous answers, inflexible, notoriously low response rates (often 10%–20%).
#### Types of Questions Used (Figure 2-10)
1. **Closed-Ended Multiple Choice**:
- *"How frequently do you access the online supplier catalog?"*
`[ ] Daily [ ] Weekly [ ] Monthly [ ] Never`
2. **Likert Rating Scale (Quantitative Opinion)**:
- *"The current inventory search screen provides fast and accurate results."*
`1 (Strongly Disagree) 2 (Disagree) 3 (Neutral) 4 (Agree) 5 (Strongly Agree)`
3. **Open-Ended Text**:
- *"What single improvement would most increase your daily productivity when fulfilling customer orders?"*
---
### 2.5.3 Reviewing Inputs, Outputs, and Procedures (Document Analysis)
Existing forms, paper invoices, Excel spreadsheets, training manuals, and legacy software screens are rich repositories of business rules and data models.
- **Document Analysis in Practice**:
- Analysts collect blank and completed copies of every current document (e.g., **Figure 2-11: RMO Mail-Order Form**).
- Inspecting completed forms reveals which fields are mandatory, which are optional, how users handle unexpected edge cases, and what calculations are performed manually.
- **Caution**: Existing forms reflect *current* limitations and legacy workarounds. Analysts must distinguish true underlying business requirements from archaic habits.
---
### 2.5.4 Observing and Documenting Business Processes
Direct observation allows analysts to see what employees *actually* do, rather than what they *say* they do or what procedure manuals claim.
- **Techniques**:
- Shadowing an order clerk or warehouse picker during peak shipping hours.
- Recording cycle times for order entry and identifying ergonomic obstacles.
- **The Hawthorne Effect**: People often alter their behavior when they know they are being observed. Analysts must build rapport and observe unobtrusively over sustained periods to see natural workflows.
---
### 2.5.5 Researching Vendor Solutions
Most business problems have already been solved by software vendors. Researching commercial off-the-shelf (COTS) applications, SaaS platforms, industry whitepapers, and competing websites provides invaluable benchmarking:
- Discovers best-in-class industry features.
- Enables informed "Build vs. Buy" decisions.
- Stimulates user imagination with proven interface models.
---
### 2.5.6 Collecting Active User Comments and Suggestions
Rather than treating requirements gathering as a finite event, analysts establish continuous feedback loops:
- Feedback buttons built directly into software prototypes.
- User advisory committees meeting weekly.
- Focus groups evaluating interactive wireframes.
---
## 2.6 Models and Modeling in Systems Analysis
### 2.6.1 What is a Model?
A **Model** is an abstraction and representation of some aspect of the system being built.
Because information systems are too vast and complex to comprehend all at once, analysts construct models to isolate specific facets of the system (e.g., data structures, workflows, or architectural tiers) without being distracted by irrelevant implementation details.
---
### 2.6.2 Types of Models (Textual, Graphical, Mathematical)
```mermaid
flowchart TD
Models["System Models"] --> T["Textual Models
Written specifications, user stories, use case descriptions, open-items lists"]
Models --> G["Graphical Models
UML diagrams, flowcharts, entity-relationship diagrams, UI wireframes"]
Models --> M["Mathematical Models
Formulas, algorithms, network queuing equations, Net Present Value (NPV)"]
```
- **Unified Modeling Language (UML)**:
- The industry-standard graphical notation and vocabulary maintained by the Object Management Group (OMG) for specifying, visualizing, and documenting software artifacts.
---
### 2.6.3 Six Major Reasons for Modeling (Figure 2-12)
Why do software engineers spend considerable time and effort building models instead of going straight to code?
```mermaid
flowchart TD
R1["1. Learning from the Modeling Process
(Building the model forces analysts to uncover hidden assumptions and ask critical questions)"]
R2["2. Reducing Complexity by Abstraction
(Separates essential business logic from distracting low-level code mechanics)"]
R3["3. Remembering All Details
(Serves as a reliable, permanent repository for thousands of interrelated requirements)"]
R4["4. Communicating with Development Team
(Provides precise, unambiguous technical specifications for programmers and database architects)"]
R5["5. Communicating with Users & Stakeholders
(Enables non-technical business users to verify and validate system behavior visually)"]
R6["6. Documenting for Future Maintenance
(Ensures future maintenance developers understand original architecture and intent)"]
R1 --- R2 --- R3 --- R4 --- R5 --- R6
```
---
### 2.6.4 Analysis Models versus Design Models (Figure 2-13)
| Development Phase | Core Models Produced | Primary Focus |
|:---|:---|:---|
| **Systems Analysis Models**
*(Problem Domain — "WHAT")* | • **Use Case Diagram**: High-level functional capabilities and actors.
• **Use Case Description**: Step-by-step textual scenario.
• **Activity Diagram**: Graphical workflow of business procedures.
• **Domain Model Class Diagram**: Real-world business entities and associations.
• **State Machine Diagram**: Lifecycle states and events of complex domain objects. | Logical, platform-independent business requirements. |
| **Systems Design Models**
*(Solution Domain — "HOW")* | • **Design Class Diagram (DCD)**: Software classes, methods, visibility, and layers.
• **Interaction Diagrams (Sequence & Communication)**: Object message passing.
• **Package Diagram**: Software module decomposition and dependencies.
• **Database Schema**: Relational tables, foreign keys, and indexes.
• **User Interface Wireframes & Storyboards**: Detailed screen designs and navigation.
• **Architectural Configuration Diagram**: Hardware tiers, network topography, and protocols. | Physical, platform-dependent implementation blueprints. |
---
## 2.7 Documenting Workflows with UML Activity Diagrams
### 2.7.1 Definition of Workflow and Role of Activity Diagrams
- **Workflow**: The end-to-end sequence of work steps, manual tasks, automated calculations, and handoffs required to completely handle one business transaction or customer request.
- **UML Activity Diagram**: A graphical model that describes the sequential and concurrent activities of a workflow, the specific agents or subsystems responsible for each step, and the conditional decision logic governing execution.
---
### 2.7.2 UML Activity Diagram Standard Notation & Symbols (Figure 2-14)
```mermaid
flowchart LR
StartNode([● Initial State]) --> ActionNode["Activity State
(Rounded Rectangle)"]
ActionNode --> DecisionNode{"Decision Diamond"}
DecisionNode -- [Guard: Valid] --> ForkBar["=== Synchronization Bar (Fork / Split) ==="]
ForkBar --> Act1["Parallel Activity 1"]
ForkBar --> Act2["Parallel Activity 2"]
Act1 --> JoinBar["=== Synchronization Bar (Join / Merge) ==="]
Act2 --> JoinBar
JoinBar --> EndNode([◉ Final State])
```
| UML Symbol | Component Name | Description and Notation Rules |
|:---|:---|:---|
| `●` | **Initial Pseudo-State (Start)** | Solid black circle denoting where the workflow begins. Exactly one start node per diagram. |
| `[ Action ]` | **Activity State** | Rounded rectangle containing a verb phrase describing a specific user or system action. |
| `──>` | **Transition Arrow** | Directed line indicating the sequential flow of control from one activity to the next. |
| `◇` | **Decision Diamond** | Branching point where incoming flow splits into mutually exclusive paths based on a **guard condition** (e.g., `[stock found]` vs. `[out of stock]`). |
| `◇` | **Merge Diamond** | Recombines mutually exclusive decision paths back into a single sequential flow. |
| `===` | **Synchronization Bar (Split / Fork)** | Heavy solid line that splits a single sequential path into **multiple concurrent (parallel) paths**. |
| `===` | **Synchronization Bar (Join)** | Heavy solid line that synchronizes multiple concurrent paths; flow halts until **all incoming paths finish**. |
| `| Swimlane |` | **Swimlane** | Vertical or horizontal partition representing the specific organizational actor, role, or system component responsible for performing the enclosed activities. |
| `◉` | **Final State (End)** | Bullseye circle (black dot inside circle) indicating that the workflow has concluded. |
---
### 2.7.3 Case Study 1: Sequential Order Fulfillment Workflow (Figure 2-15)
The following activity diagram depicts the multi-participant workflow for fulfilling a customer order after online checkout in RMO's CSMS:
```mermaid
flowchart TD
subgraph OrderSubsystem ["Order Subsystem"]
StartNode([● Start]) --> SelectOrder["Identify and select pending order to process"]
SelectOrder --> LoopStart["For each line item on order:"]
LoopStart --> CheckStock["Query inventory subsystem for sufficient stock"]
CheckStock --> StockFound{"Stock Found in Warehouse?"}
StockFound -- No --> MarkBackorder["Flag item as Backordered
Notify purchasing department"]
StockFound -- Yes --> AllocStock["Allocate item inventory
Generate warehouse pick ticket"]
MarkBackorder --> NextItem{"More line items on order?"}
AllocStock --> NextItem
NextItem -- Yes --> LoopStart
NextItem -- No --> SendToWh["Transmit consolidated pick list to Warehouse"]
UpdateStatus["Update order status to 'Shipped'
Send tracking email to customer"]
UpdateStatus --> EndNode([◉ End])
end
subgraph InventorySubsystem ["Inventory Subsystem"]
DecStock["Decrement available item stock count in central database"]
end
subgraph Warehouse ["Warehouse Operations"]
SendToWh --> ReceiveList["Warehouse receives pick ticket"]
ReceiveList --> PickItems["Warehouse staff picks physical items from warehouse bins"]
PickItems --> PackShipment["Pack items securely into shipping container"]
PackShipment --> GenLabel["Generate courier shipping and tracking label"]
GenLabel --> StagePackages["Stage packages on loading dock for courier"]
StagePackages --> DecStock
end
subgraph Courier ["Shipping Company (FedEx / UPS)"]
StagePackages --> CourierPickup["Courier driver scans and accepts packages"]
CourierPickup --> InTransit["Transport package to regional distribution hub"]
InTransit --> DeliveryScan["Deliver package to customer doorstep & scan confirmation"]
end
DecStock --> UpdateStatus
```
---
### 2.7.4 Case Study 2: Concurrent Processing Workflow (Forks and Joins) (Figure 2-16)
When business activities are independent, executing them sequentially wastes valuable time. Activity diagrams model **concurrency** using **fork** and **join** synchronization bars.
The following diagram models the engineering and manufacturing workflow for custom-ordered mountain bikes:
```mermaid
flowchart TD
subgraph Sales ["Salesperson"]
StartCust([● Start]) --> TakeOrder["Accept customized bike order & specifications from client"]
TakeOrder --> SendEng["Transmit order package to Engineering department"]
end
subgraph Engineering ["Engineering Department"]
SendEng --> ReviewSpecs["Review structural loads & draft CAD manufacturing specifications"]
ReviewSpecs --> ForkBar["=== Synchronization Bar (Fork / Split Concurrency) ==="]
end
subgraph Purchasing ["Purchasing Department"]
ForkBar --> BuyParts["Procure specialized carbon fiber tubing & custom Shimano gearset"]
BuyParts --> JoinBar["=== Synchronization Bar (Join / Wait for Both to Complete) ==="]
end
subgraph Production ["Production Department"]
ForkBar --> WriteCNC["Author CNC program for automated precision frame milling"]
WriteCNC --> JoinBar
end
subgraph Scheduling ["Production Scheduling"]
JoinBar --> AssignSchedule["Schedule frame fabrication on master plant assembly line"]
AssignSchedule --> EndCust([◉ End])
end
```
> **Detailed Concurrency Analysis**:
> 1. After Engineering completes the CAD specifications, the workflow hits a **Fork Synchronization Bar**.
> 2. Control splits into two independent paths that execute **in parallel**:
> - The Purchasing department buys materials from overseas vendors.
> - The Production department programs CNC machines simultaneously.
> 3. Both paths converge on a **Join Synchronization Bar**.
> 4. Execution **strictly halts** at the join bar until *both* Purchasing has received the parts *and* Production has validated the CNC software. Only then does Scheduling assign the build date.
---
### 2.7.5 Guidelines for Constructing Activity Diagrams
To produce clean, readable, and industry-standard activity diagrams:
1. **Identify the Scope**: Clearly define the start trigger (customer request) and final outcome (goods delivered).
2. **Identify the Agents (Swimlanes)**: Determine which internal departments, systems, or external actors participate. Create one swimlane per agent.
3. **Draft the Happy Path First**: Model the typical, error-free path before adding complex exception branches.
4. **Use Action-Oriented Language**: Label activity states with concise `[Verb + Noun]` phrases (e.g., *"Calculate Tax"*, *"Decrement Stock"*).
5. **Enforce Branching vs. Concurrency Rules**:
- Use **Decision Diamonds (`◇`)** for mutually exclusive choices (`[Yes]` vs. `[No]`).
- Use **Synchronization Bars (`===`)** for parallel tasks happening at the same time. Never confuse decisions with forks!
6. **Balance Detail**: Avoid micro-modeling every keystroke. Focus on meaningful business and system transitions.
---
## 2.8 Chapter Summary & Key Terminology Glossary
### Chapter Summary
- **Systems Analysis (Core Process 3)** focuses on uncovering and formally specifying **WHAT** an information system must accomplish to fulfill an organizational need.
- Projects are guided by an enterprise **Technology Architecture Plan** and **Application Architecture Plan**, as illustrated by RMO's Consolidated Sales and Marketing System (CSMS).
- Requirements are classified as **Functional** (activities performed) and **Non-Functional** (quality constraints), systematically captured using the **FURPS+** framework (Functional, Usability, Reliability, Performance, Security, plus Design, Implementation, Interface, Physical, and Supportability constraints).
- Analysts must consult all categories of **Stakeholders**: Internal, External, Operational, and Executive.
- **Information-Gathering Techniques** include Interviews (the most informative), Questionnaires (broad quantitative reach), Document Review, Direct Observation, Vendor Research, and Active User Feedback.
- **Models** reduce complexity through abstraction, facilitate communication, prevent forgotten requirements, and serve as permanent documentation.
- **UML Activity Diagrams** model business workflows, depicting sequential flow, decision diamonds, swimlane organizational responsibilities, and concurrent processing using synchronization bars (forks and joins).
---
### Key Terminology Glossary
- **Activity Diagram**: A standard UML behavioral diagram describing the sequential and concurrent flow of user and system activities within a workflow.
- **Application Architecture Plan**: An organizational strategic document identifying the integrated collection of information systems and applications required to support business goals.
- **Decision Diamond**: An activity diagram symbol representing an either/or conditional branch where incoming flow follows exactly one outgoing path based on a guard condition.
- **Design Constraints**: Non-functional requirements that restrict the hardware, operating systems, or architectural patterns available to software engineers.
- **Executive Stakeholders**: Key personnel who do not interact directly with daily software screens, but who fund the project, rely on summarized reports, or hold executive accountability for project success.
- **Functional Requirement**: A system capability or automated task that the system must perform to satisfy a business need.
- **FURPS+**: A comprehensive requirements categorization framework encompassing Functional, Usability, Reliability, Performance, and Security requirements, plus technical constraints.
- **Interface Requirements**: Technical specifications describing how a system exchanges data with external software applications, legacy systems, or third-party web services.
- **Internal Stakeholders**: Individuals employed within the organization undertaking the systems project.
- **Model**: A purposeful abstraction and representation of selected aspects of a system under development.
- **Non-Functional Requirement**: Operational characteristics, performance metrics, reliability standards, or security rules that constrain how functional requirements are delivered.
- **Open-Items List**: A disciplined tracking log used during fact-finding to record unanswered questions, assigned owners, and resolution deadlines.
- **Operational Stakeholders**: Individuals who regularly interact with the software system on a daily basis to perform their operational business duties.
- **Performance Requirements**: Non-functional requirements specifying transaction throughput, response speed, concurrency thresholds, and storage capacity.
- **Reliability Requirements**: Non-functional requirements defining operational dependability, availability percentages (uptime), error rates, and disaster recovery capabilities.
- **Security Requirements**: Requirements specifying access controls, authentication methods, role-based authorization, data encryption, and audit logging.
- **Stakeholder**: Any individual, group, or external entity who has a legitimate interest in the successful implementation and operation of an information system.
- **Supportability Requirements**: Non-functional requirements governing how easily software can be maintained, configured, updated, and extended over time.
- **Swimlane**: A partitioned visual column or row in an activity diagram representing the specific actor, department, or software component performing an activity.
- **Synchronization Bar**: An activity diagram component (drawn as a heavy bar) that either splits a sequential path into multiple parallel concurrent paths (fork) or recombines parallel paths (join).
- **Technology Architecture Plan**: An enterprise strategic blueprint specifying the hardware infrastructure, networks, databases, and operating platforms to be used.
- **Unified Modeling Language (UML)**: The standardized graphical modeling language and notation used in object-oriented software engineering.
- **Usability Requirements**: Non-functional requirements specifying user interface ease-of-use, ergonomic layout, accessibility standards, and help systems.
- **Workflow**: The end-to-end sequence of operational steps and decisions required to complete a discrete business transaction or customer request.