Systems Analysis: Investigating System Requirements and Modeling Workflows

Chapter 2: Investigating System Requirements and Learning Objectives

  • Activities of Systems Analysis: Understanding how to describe and execute the core activities involved in the analysis phase of the System Development Life Cycle (SDLC).

  • Requirement Types: Distinguishing between functional and non-functional requirements to ensure all system needs are met.

  • Stakeholder Identification: Identifying different kinds of stakeholders and understanding their unique contributions to the requirements definition process.

  • Information-Gathering Techniques: Describing various techniques and determining the optimal context for applying each one.

  • Role of Models: Explaining why models are used in systems analysis and the different types available.

  • Unified Modeling Language (UML): Developing UML activity diagrams specifically to model business workflows.

Overview of Ridgeline Mountain Outfitters (RMO)

  • Operational Context: RMO maintains an elaborate set of information systems to support its management and operations.

  • Drivers for Change: Customer expectations, modern technological capabilities, and competitive pressures identified a need for RMO to upgrade its support for sales and marketing.

  • The Proposed Solution: A new Consolidated Sales and Marketing System (CSMS) was proposed as a major project stemming from the RMO strategic planning process.

  • RMO Information Systems Strategic Plan:

    • Technology Architecture: The set of computing hardware, network hardware, network topology, and system software employed by the organization.

    • Application Architecture: The specific information systems that support the organization’s needs, including subsystems and supporting technology.

  • Existing Application Architecture at RMO:

    • Supply Chain Management (SCM): Approximately 5 years old; built using Java and Oracle. The new Tradeshow system will interface with this.

    • Phone/Mail Order System: 12 years old; built with Visual Studio and MS SQL. It has reached its capacity and offers minimal integration.

    • Retail Store System: An older package solution with minimal integration.

    • Customer Support System (CSS): A web-based system that has evolved over several years but suffers from minimal integration.

The Consolidated Sales and Marketing System (CSMS)

  • Sales Subsystem: Designed to integrate online, phone, and retail store sales channels.

  • Order Fulfillment Subsystem: Functions to track shipments and allow for the rating of products and services.

  • Customer Account Subsystem: Manages shopping history, linkups, and the "Mountain Bucks" rewards program.

  • Marketing Subsystem: Handles promotional packages, partner relationships, merchandise information, and reporting.

  • Complexity: The CSMS requires discovering and understanding extensive and complex business processes and rules.

  • SDLC Context: While Chapter 1 covered identifying problems, obtaining approval, and project planning, Chapter 2 focuses on core process 33: analysis activities.

Core Systems Analysis Activities

  • Gather Detailed Information: Utilizing interviews, questionnaires, document reviews, observation of business processes, vendor research, and user comments/suggestions.

  • Define Requirements: Formally modeling both functional and non-functional requirements.

  • Prioritize Requirements: Categorizing requirements into groups such as "Essential," "Important," or "Nice to Have."

  • Develop User Interface Dialogs: Modeling the flow of interaction between the user and the system.

  • Evaluate Requirements with Users: Ensuring user involvement and feedback to adapt to necessary changes.

Defining System Requirements: FURPS+

  • System Requirements Definition: These are divided into functional and non-functional categories.

  • Functional Requirements: The specific activities a system must perform based on business uses and functions users carry out (often represented as use cases).

  • Non-functional Requirements: Characteristics of the system other than specific activities, focusing on constraints and performance goals.

  • The FURPS+ Acronym:

    • F: Functional requirements.

    • U: Usability requirements.

    • R: Reliability requirements.

    • P: Performance requirements.

    • S: Security requirements.

    • +: Additional categories including design constraints, implementation, interface, physical, and supportability requirements.

  • Additional Requirement Categories:

    • Design Constraints: Specific restrictions regarding hardware and software choices.

    • Implementation Requirements: Mandatory programming languages, tools, or protocols.

    • Interface Requirements: Specific links and protocols required to connect to other systems.

    • Physical Requirements: Requirements related to physical facilities and equipment constraints.

    • Supportability Requirements: Methods for automatic updates and system enhancements.

Stakeholder Identification and RMO Context

  • Stakeholder Definition: Any person who has an interest in the successful implementation of the system.

  • Stakeholder Classifications:

    • Internal Stakeholders: Persons within the organization.

    • External Stakeholders: Persons outside the organization.

    • Operational Stakeholders: Persons who interact with the system on a regular basis.

    • Executive Stakeholders: Persons who do not interact directly with the system but use its information or have a financial interest in its success.

  • RMO CSMS Specific Stakeholders:

    • Phone/mail sales order clerks.

    • Warehouse and shipping personnel.

    • Marketing personnel (online catalog maintenance).

    • Managers (Marketing, Sales, Accounting, Financial).

    • Senior executives.

    • Customers.

    • External shippers (e.g., UPS, FedEx).

Information Gathering Techniques

  • Interviewing Overview: Preparing detailed questions, meeting with individuals or groups, documenting answers, and following up.

  • Questionnaires: Distributing forms to collect wide-scale data.

  • Document Review: Reviewing inputs, outputs, and existing documentation (e.g., an existing Customer Order Form).

  • Observation: Documenting business procedures by watching them in action.

  • Vendor Research: Researching existing solutions, white papers, and competitor offerings.

  • User Feedback: Collecting active comments and suggestions regarding models and tests (the "I'll know it when I see it" principle).

Interviewing Themes and Checklists

  • Themes for Questions:

    • Business Operations: "What do you do?"

    • Process Performance: "How do you do it? What steps do you follow? How could it be done differently?"

    • Information Needs: "What information/inputs do you use? What outputs do you produce?"

  • Interviewing Checklist:

    • Before: Establish objectives, determine participants (users and team members), build a list of questions, review related materials, and set the time/location.

    • During: Arrive on time, look for exceptions/errors, probe for details, take notes, and identify open questions.

    • After: Review notes for accuracy, transfer data to models, identify areas for clarification, thank participants, and follow up on open items.

  • Interview Agenda Example (RMO Commissions):

    • Objective: Determine processing rules for sales commission rates.

    • Participants: William McDougal (VP Sales/Marketing) and staff; Mary Ellen Green and Jim Williams (Project Team).

    • Key Questions: Eligibility, basis for rates, returns handling, special incentives, variable scales/quotas, and exceptions.

Open Items List Management

  • Tracking Issues: Essential for recording unresolved questions during the analysis phase.

  • Data Fields: ID, Issue Title, Date Identified, Target End Date, Responsible Project Person, User Contact, and Comments.

  • Example RMO Items:

    1. Partial shipments (Jim Williams/Jason Nadold): Decide if the system should ship partials or wait for full orders.

    2. Returns and commissions (Jim Williams/William McDougal): Determine if commissions are recouped on returns.

    3. Extra commissions (Mary Ellen Green/William McDougal): Handling special promotions.

Questionnaires and Document Review Examples

  • RMO Questionnaire Structure:

    • Part I (Quantitative): Frequency of calls, orders vs. info-only calls, out-of-stock frequencies, back-order percentages, expired catalog usage, and credit denials.

    • Part II (Likert Scale 1-7): Gauging agreement on the need for product descriptions, purchase history availability, accessory info, and system response time.

    • Part III (Qualitative): Open-ended comments on current system problems.

  • Review of Inputs/Outputs: Analyzing documents like the Ridgeline Mountain Outfitters Customer Order Form, which includes fields for shipping/billing addresses, item numbers, descriptions, monograms, payment methods, and FedEx shipping calculations.

Models and Modeling

  • Definition: A representation of some aspect of the system being built.

  • Types of Models:

    • Textual Models: Written descriptions.

    • Graphical Models: Diagrams and schematics (often using UML).

    • Mathematical Models: Formulas, statistics, and algorithms.

  • Reasons for Modeling:

    • Facilitates learning from the process.

    • Reduces complexity through abstraction.

    • Acts as a memory aid for details.

    • Supports communication with team members and stakeholders.

    • Provides documentation for future maintenance.

Workflows and UML Activity Diagrams

  • Workflow: The sequence of processing steps required to completely handle a single business transaction or customer request.

  • Activity Diagram: A UML diagram that describes user or system activities, the person (or entity) responsible for those activities, and the sequential flow.

  • Steps to Create an Activity Diagram:

    1. Identify Participants: Create "swimlanes" for each participant.

    2. Identify Start Point: Use a starting pseudo-activity symbol.

    3. Draw Activities: Place activity ovals in the appropriate swimlanes.

    4. Define Flow: Connect ovals sequentially.

    5. Decision Points: Include diamonds for "OR" conditions where paths split.

    6. Synchronization Bars: Use for "AND" conditions (concurrent paths) and loops.