Wednesday, January 11, 2017

Data Flow Diagram


Data Flow Diagram – Case Study

This Case Study states the project background and describes Data Flow Diagram(DFD) for following levels, as part of the requirement gathering process
  • Define level 0 DFD, to capture data transfers between systems.
  • Define level 1 DFD for major business processes for all input and output data for each processes, representing appropriate data stores


Project Background

NGO Life is one of the largest Insurance Provider in US. NGO had set up a project team to work on policy admin system, which involves complex data processes. Policy Admin Is an integrated system, where data transformations happens between their upstream and downstream applications on daily basis.

Caroline – Client manager for the project
Chris – Senior Business Analyst for the project

Problem Statement

Chris is in the process of doing a comprehensive system assessment, understanding, requirement analysis and gathering for their critical Policy Admin system, which involves complex data processes.

At the end of requirement analysis phase, Chris finds that, there are lot of data and technical flaws in the system. Chris needs to prepare Data flow Diagram (DFD), to explain the existing system issues

What are the recommended activities that, Chris should perform with regards to DFD preparation as part of system understanding and requirement gathering process?

Solution Approach
  • Define level 0 (Context Level Diagram) DFD, to capture data transfer between systems.
  • Define level 1 DFD for major business processes with all input and output data for each processes, representing appropriate data stores. During the definition,
o    Ensure each process, data store have at least one data flowing into it and one coming out of it and all data flows either starts or ends in a process
o    Ensure every data item that appears on a DFD originates and is used somewhere within the related DFDs
o    Ensure no entity is allowed to access data store directly, either to read or update
o    Ensure data processing happens before data transfer from one source to another source.
o    Ensure data processing happens before data transfer from one source to another data store and vice versa
o    Ensure data processing happens before data transfer from one data store to another data store
o    Ensure all data that is sent / received, stored, transformed or moved within the  system and externally are captured clearly


LO Data Flow Diagram

Assume that the different systems/data stores mentioned in the diagrams are part of the enterprise which the Policy Admin system interacts with


Benefits
  • DFD helps to identify system flaws, through clear understanding on each processes
  • DFD aids process improvements in the system, by identifying existing system issues.
  • It acts as an easy to understand analysis deliverable for stakeholders
  • DFD depicts overall view with system boundaries and detailed representation of system components
  • DFD helps to verify requirements by stakeholders


Data Flow Diagram Concepts

Data Flow Diagram (DFD) is a flow modeling technique that shows how information flows through a system – how it is input, processed, stored and output from the system.
The components in a DFD and their representations as per different notations are as below;

Component
Description
Gane-Sarson
Yourdon
Entity
Provide or receive data from the system


Process
Transform data

Data Store
Store data within the
System
Data Flow
Move data from / to external entities / processes

  • A Level 0 DFD (Context diagram) defines the system boundaries and shows the movement of data into and out of the system
  • A Level 1 DFD shows the main processes within the project’s scope and the data that is required and produced by each process. Data Stores are depicted in Level 1 DFD.
  • A DFD can be broken down into further levels, depending upon the complexity of the processes involved. This process is called DFD Leveling.
  •  
  • Validation of DFDs is very important at each level. Below checklist of points can be used to make sure the DFD is consistent and correct.
  • Each process must have at least one data flow going into it and one coming out of it.
  • Every data store must have at least one data flow going into it and one coming out of it.
  • All data flows must either start or end at a process
  • Every data item that appears on a DFD must originate and be used somewhere within the related DFDs
  • A process should be named as a verb and a data item as a noun
  • No entity should be allowed direct access to data store, either to read to update


Representations of some common errors in DFD:
Wrong
Right
Description
 
A source or a sink cannot provide data to another source or sink without some processing occurring
Data cannot move directly from a source to a data store without being processed
Data cannot move directly from a data store to a sink without being processed
Data cannot move directly from one data store to another without being processed


Representations of some common errors in DFD – Black Hole, Gray Hole and Miracles

Representations of some common errors in DFD:


Did you know that a DFD can aid in bringing about process improvements?
  • The evaluation process of the DFD may point out a deficiency in the system or a situation in which users are not aware of how certain processes operate
  • A brainstorming session with the below questions for evaluation can help identify issues / improvements in the system
  •  
  • Are there processes that do not receive input / produce output – identify non-value adding processes
  • Are there data stores that are never referenced – identify data stores which are dormant
  • Is a process too busy – if a process is serving multiple purposes, it might need to be exploded further
  • Is the inflow of data adequate / too much for the process – identify whether an interface needs improvement
  • Is each process independent of other processes and dependent only on the data It receives as input – identify whether a process needs to be more loosely coupled
  • Is the wait time for input too much for a process – identify steps to reduce the delays in input
  • Is the processing time too much in any process – identify steps to improve the efficiency of processes

Advantages:
  • Easy to understand.
  • A useful analysis deliverable.
  • Effective tool for communicating on the system to the stakeholders.
  • Defines the system boundary and provides detailed representation of system components
  • Aids in understanding system flaws and bringing about process improvements

Disadvantages:
  • Preparing DFDs for large systems can be time consuming
  • Physical considerations of the system are not included
Quiz
1. External Entities in a data flow diagram are
o    A. Source of input data only
ü  B. Source of input data or destination of results
o    C. Destination of results only
o    D. Repository of data

2. A Data Flow Diagram (DFD) is composed of which elements?
o    Data sources and destinations
o    Data flows
o    Transformation Processes
o    Data stores
ü  All of the listed options

3. Which among the below represents correct DFD notation, matching to the text given within?

ü  A and B
o    B. B and C
o    C. A,B and D
o    D. B,C and D

4.  A DFD process that has inputs but no outputs is a(an:
o    A. Gray hole
o    B. Elementary process
o    C. Basic process
o    D. Function
ü  E. None of the listed options

5.  A context diagram
ü  A. Is a DFD which gives an overview of the system
o    B. Is a detailed description of a system
o    C. Is not used in drawing a detailed DFD
o    D. Has multiple processes

6.  By leveling a DFD we mean
o    A. Reviewing the DFD to remove duplicate processes
o    B. Make the DFD structure uniform
ü  C. Expanding a process into one or more sub-processes giving more detail
o    D. Summarizing a DFD to specify only the essentials

7. Given below is the Level 1 DFD for a system. Is the diagram correct?
ü  A. No, There is no output data flow from the process
o    B. Nom, The entities do not have data flows between them
o    C. No, the entities are not transferring data to the data stores
o    D. Yes, the level 1 DFD looks complete

8. The following portion of DFD is wrong as
o    A. The process has only one input
o    B. The process writes and reads from the same data store
ü  C. The process name is wrong; it should be an active verb
o    D. Output data from the process flows to external entities

9.  Lowest level DFD may add new data flow to represent exception handling like error Messages. State True or False?
ü  A. True
o    B. False

10. Is the below DFD right?
o    A. Yes
ü  B. No



Requirements Traceability Matrix

Overview

v  Scope Verification, which is the process of tracking and ensuring that all the requirements outlined in the functional specification document have been met by the end product/deliverables, can be a cumbersome and laborious process without formal traceability procedures in place.

v  Traceability Matrix is an industry-accepted format for tracking requirements. It provides a convenient format that helps to visually represent associations between user requirements for the system built and the work products (project artifacts) developed and implemented to verify those requirements.


Requirements Traceability Matrix

Scope Verification:
Scope Verification is the process of obtaining the stakeholder’s formal acceptance of the completed project scope and associated deliverables. Verifying the project scope includes reviewing deliverables to ensure that each is completed satisfactorily. Scope verification occurs at the end of each project phase and as part of the project closeout process.

Tools for Verifying Scope:
¨  Inspection
¨  Requirements Traceability Matrix

Requirements Traceability Matrix:
¨  The Requirements Traceability Matrix (RTM) is a tool that is used to trace each requirement back to a specific business case and then forward to the rest of the scope deliverables (like specific WBS work packages) as well as other parts of the project.
¨  The RTM captures all requirements and their traceability in a single document. It is used to record the relationship between the requirements to the design, development and testing artifacts of the software.

Types of Traceability:
¨  Forward Traceability - Mapping of requirements to design, coding and testing artifacts. Also, customer needs are traced forward to requirements so that it is easy to identify which requirements will be affected if customer needs are changed. A user can trace forward from requirements by defining links between individual requirements and specific product elements.
¨  Backward Traceability - Mapping of testing artifacts back to coding, design and requirements. Also, one can trade backward from requirements to customer needs in order to identify the origin of each software requirement. Specific product elements may be traced backward requirements to identify why each item was created.

Different Fields in RTM

Below are the fields in an AD RTM as per standards:

Requirement Clarification
Business Requirements
System Requirements
NFR Requirements
Related Requirements
User Interface Prototype
Clarification ID
Business Requirement ID
System Requirement ID
System Use Case ID
NFR Requirements ID
Related Requirement ID
Screen/ Wireframe ID
Identifier for any clarifications raised mapping to the business requirement
Unique identifier for the business requirement
Unique identifier for the system requirement mapping to the business requirement
Unique identifier for the use case mapping to the system requirement
Unique identifier for the Non Functional Requirement mapping to the system requirement
Requirements mapping to the high level system requirement
Identifier for the wireframe that cover the specific requirements mapped


System Testing
Performance Testing
Design
Document Name (SCI ID)
Test Case ID
Document Name (SCI ID)
Test Case ID
Component/ Class Diagram ID
Sequence Diagram
Use Interface Specification-  Screen ID / Name
Database Tables
System test case document name
IDs for the test cases that map back to the specific requirement
Performance test case document name
IDs for the test cases that map back to the specific requirement
Identifier for the design component or class diagram that covers the requirement
Identifier for the sequence diagram that covered the requirement
Identifier for the screen that covered the requirement
Table names that are referred to cover the requirement

Coding
Unit Testing
Integration Testing
Program / Source Code File Name(s)
Method/ Stored Procedures
Document Name (SCI ID)
Test Case ID
Document Name (SCI ID)
Test Case ID
Code files that cover the mapped requirement
Store procedures that are referenced
Unit test case document name
Test case ID to test the given requirement
Integration test case document name
Test case ID that are referred as part of the given requirement


Workflow & Stakeholders

RTM Workflow:
 A Requirements Traceability Matrix is usually created early on in the project lifecycle during the requirement analysis phase. It has to be kept alive throughout the lifecycle with regular updates. Below is a snapshot of the typical activities across phases and stakeholders.

Phase
Activities
Stakeholder
Requirement Analysis
1. Assign a unique identifier to every business / system / non-functional requirement.
2. Record every requirement in the RTM
Business Analyst
Design
1. Create a design specification document, assign identifiers to class / sequence diagrams, other design artifacts, database tables, user screens, unit / system / performance / integration test case.
2. Record the identifiers for the design artifacts, database tables, user screens, test case document name and test case IDs against the corresponding requirement in RTM
Solution Architect / Lead Developers / Testers
Coding
1. Create code files, record the code module details and stored procedures against the corresponding design artifact and requirement in the RTM
Developers

The regular tracking of RTM helps to identify missed functionalities, control scope creeps, identify impacted items in case of change requests. These ensure complete control over the requirements and its associated work products.


RTM Examples

Example # 1: During the system testing phase, the customer comes up with a change in one of the features. Due to its business criticality, the team decides to go ahead with the change. How does the team easily identify the impacted items?
¨  The existing requirement that is undergoing the change can be forward traced to identify the impacted design artifacts, code files and test cases mapped against it.

Example # 2: The project is currently in UAT and a couple of high priority defects are logged. Before moving the fixed code for retest, how does the team identify the concerned test cases to be executed?
¨  The changed code files can be forward traced to identify unit / system / performance / integration test cases mapped against them.

Example # 3: The customer is doubtful about a particular need being addressed in the finished software, How does RTM help prove that the need is implemented
¨  The functional / non-functional requirements mapped against the business need in an RTM would help to ensure that all needs are addressed.

Example # 4: A project manager decides to enhance a couple of features in a project to exceed customer’s expectations. Is this right? If not, how does RTM help to avoid it?
¨  This is a typical example of ‘Gold Plating’, which should be avoided. Delivering more than what is committed could set wrong expectations with the customer. If there is a low-level element in an RTM without mapping to high-level requirement, then it is apparently because of over engineering.

Benefits / Limitations of RTM

Benefits:
¨  Ideal Scope Verification tool which helps to ensure all requirements are met by the developed software at the end of every phase / during closure.
¨  Detailed mapping of work products to requirements helps to identify the impacted items in case of change request or issues.
¨  It is easy to identify the missed functionalities / scope of creep / ‘Gold Plating using RTM
¨  RTM serves as a guide to test planning
¨  It helps to have a prioritized list of requirements

Limitations:
¨  An RTM, which is not kept alive throughout the lifecycle, does not help. It has to be regularly tracked and updated.
¨  An RTM without unique identifier for requirements will lead to confusion.
¨  Project team with a wrong understanding on the fields and usage of RTM will not be able to leverage its benefits.

Best Practices

¨  An organization must adopt consistent practices in requirements management, including traceability. If all stakeholders and team members buy into a traceability practice, take ownership of it and become accustomed to it, it greatly increases a traceability method’s chances of success.

¨  Unique identifiers must be adopted for requirements and business rules. To permit traceability, each requirement must be uniquely and persistently labeled so that you can refer to it unambiguously through the project.

¨  A responsible party must take ownership of traceability. Whether using a manual method or an automated tool, a knowledgeable analyst must take ownership of the traceability process.

¨  The analyst must practice consistency in updates. This will require a significant commitment on the part of the analyst. “Whenever such changes occur, it is necessary to update the traceability data to reflect these changes.”

¨  When tracing all requirements is simply time-prohibitive, the analyst may be selective based on cost. If the prospect of tracing every requirement is overwhelming, an analyst may choose to only trace the expensive ones.

Quiz

1.       Which of the following BEST describes the purpose of an RTM?
o    A) RTM describes how WBS Dictionary entries are traced to work packages and how work packages are decomposed from deliverables.
ü  B) RTM is used to trace each requirement back to a specific business case and then forward to the rest of the scope deliverables.
o    C) RTM is an ideal tool to define code review standards.
o    D) RTM visually represents the functional decomposition of customer’s business needs.

2.       Your team is nearing the completion of the design phase and the design document is being reviewed. There is a new joiner in the team who is new to software development. He raised a query that few design aspects documented in the detailed design artifact is out of project scope. Which of the following documents will help trace the requirements to design?
o    A) Project Plan
o    B) Project scope statement
ü  C) Requirements traceability matrix
o    D) High level design document

3.       Which one of the following statement is False?
o    A) RTM is created early on in the project life cycle.
o    B) RTM is a live document which needs to be tracked and updates regularly through out of the project lifecycle.
ü  C) RTM document should be signed off by the customer once the requirements are frozen and should not be updated after that.
o    D) RTM have multiple stakeholders updating information in it.

4.       Which one of the following statement is False?
ü  A) Accepted Deliverables
o    B) Project Management Plan
o    C) Validated Deliverables
o    D) Requirements Traceability Matrix
Note: The INPUTS to Verify Scope process are project management plan, requirements documentation, requirements traceability matrix and validated deliverables. Accepted Deliverables is an OUTPUT of the Verify Scope process.

5.       After delivering a release, the customer raises concerns that certain features do not have any business value. Which among the following is the BEST way to prove the business significance of delivered features?
o    A) Provide a walkthrough of the project charter to the customer.
ü  B) Use the RTM to map the implemented features back to the business needs.
o    C) Map the implemented features to the signed off requirements and explain to the customer.
o    D) Map the implemented features to the acceptance criteria defined.

6.       Which of the following are the advantages of RTM?
o    A) RTM helps to assess the impact of change request and identify impacted work products.
o    B) RTM helps to identify scope creeps and gold plating.
o    C) RTM helps to verify scope during the end of each phase and during project closure.
ü  D) All of the above.