Process Modeling and Data Flow Diagrams

Introduction

• Process models are a type of visual representation depicting how a business system works.
• Process models can be used to document both the current system (as-is) and the new system (to-be) being developed, regardless of whether the system is computerized or manual.
• Process models have been a key tool in structured systems analysis and design for many years, but their usage has decreased with the rise of use cases.
• Use cases can provide a sufficient understanding of the system being developed for some organizations, while other organizations find process modeling to be a valuable complement to their analysis phase.
• Process models help analysts gain a clear understanding of the system's functionalities before construction.
• The chapter focuses on data flow diagramming (DFD) as a popular process modeling technique.
• DFDs visually represent business processes and the flow of data among them.
• Although DFDs imply a focus on data, the primary emphasis is on the processes or activities performed.
• Process modeling, particularly DFD creation, is a crucial skill for systems analysts.
• The text focuses on logical process models, which describe processes without specifying how they are executed.
• Logical process models do not reveal whether a process is automated or manual, how data is collected, or where data is stored.
• These physical details are addressed during the design phase when logical models are transformed into physical models.
• By initially focusing on logical processes, analysts can concentrate on the desired functioning of the business without being distracted by implementation details.

Data Flow Diagrams

• Figure 5-1 presents a DFD that visualizes the process of a Lawn Chemical Applicator (LCA) requesting a lawn chemical.

Stakeholder Management

• It's crucial to inform management about the project and its impact on their departments.
• When interacting with decision-makers, be mindful of their perspective and how the project can benefit them.
• During project initiation, identify key stakeholders, create a scope statement and define completion criteria.
• Remember to treat everyone as critical to the project, regardless of their position.

Collecting Business Requirements

• Defining a problem doesn't necessarily mean there's something wrong; it could represent an opportunity for improvement.
• Use diverse collection techniques like interviews, job observation, and literature reviews.
• Literature reviews include analyzing books, research papers, and other relevant materials to avoid repeating previous research.
• System reviews involve collecting information from various sources like websites, intranet sites, and company documents.
• Identify overlapping areas for improvement across different departments.

Requirements Gathering

• Understand the project scope from the project manager and sponsor.
• Be mindful of areas outside the scope of the project during stakeholder conversations.
• Offer alternative solutions when a stakeholder cannot make a decision.
• Different requirements gathering methods include:
  • Interviews
  • Brainstorming Sessions
  • Focus Groups
  • Job Observation
  • Surveys
  • Requirements Gathering Workshops

Requirement Analysis

• Ensure a shared understanding during workshops of the project's vision, goals, objectives, and high-level scope.
• Missing requirements late in the project can lead to rework and modifications.
• Accurate business requirement analysis saves rework and involves:
  • Analyzing
  • Summarizing
  • Documenting requirements

Identifying Stakeholders

• A stakeholder is someone who has something to gain or lose from the project, is impacted by the work, or can influence it.
• It's crucial to know what their requirements and interests are.
• In some cases, all users are stakeholders, but due to their large number, a sample group can represent them.