Process Modeling and Data Flow Diagrams

Study Notes

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.