2.5.11 Analysis Techniques and Deliverables

Manual Transmittal

October 09, 2020

Purpose

(1) This transmits revised Internal Revenue Manual (IRM) 2.5.11, System Development, Analysis Techniques and Deliverables.

Background

This IRM 2.5.11 authorizes the standards, techniques, and other controls for Structured Analysis and Structured Design (SA/SD) which is currently the system development techniques for all IRS IT related government employees and contractual workers. This manual was developed to establish analysis techniques and deliverable descriptions for system development.

Material Changes

(1) Changed Chief Information Officer, Terence H. Lutes to Acting Chief Information Officer, Nancy Sieger

(2) In the Material Transmittal for Effect on Other Documents, added a period after the whole sentence

(3) In the Material Transmittal for Purpose, added “This transmittal revised Internal Revenue Manual (IRM) 2.5.11, System Development, Analysis Techniques and Deliverables”

(4) 2.5.11.1, Added Program Scope and Objectives

(5) 2.5.11.1.1, Added Background, moved information from 2.5.11.2

(6) 2.5.11.1.2, Added Authority

(7) 2.5.11.1.3, Added Roles and Responsibilities

(8) 2.5.11.1.4, Added Program Management and Review

(9) 2.5.11.1.4 (1), Added a list under Program Reports

(10) 2.5.11.1.5, Added Program Controls

(11) 2.5.11.1.6, Added Terms/Definitions/Acronyms

(12) 2.5.11.1.7, Added Related Resources

(13) 2.5.11.1.7 (1), Added Object Management Group (OMG), https://www.omg.org/

(14) 2.5.11.1.7 (2), Added Tutorialspoint, https://www.tutorialspoint.com/system_analysis_and_design/system_analysis_and_design_structured.htm

(15) ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

(16) ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

(17) 2.5.11.2, Added Model-Driven Architecture

(18) 2.5.11.2.1, is moved to 2.5.11.1 “Purpose”

(19) 2.5.11.2.2, is moved to 2.5.11.1 "Scope”

(20) 2.5.11.2.2.1, Changed at 2) Capitalize all the bullets first letter 3 & 4) Add period at the end

(21) 2.5.11.2.5.1, Changed “input” to “output”

(22) 2.5.11.2.8.1, Changed Steplist to Alphalist

(23) 2.5.11.3, Added Structured Analysis Overview

(24) 2.5.11.3 (1), Added description of Structured Analysis Method and included alpha list for development method features

(25) 2.5.11.4, Structured Analysis Tools, made grammatical correction to remove extra period in first bullet

(26) 2.5.11.4, Structured Analysis Tools, changed title from “Structured English” to “Structured English for Programming Languages” for bullet #5

(27) 2.5.11.4.1, Data Dictionary/Data Definition Matrix, Changed title from “Data Dictionary” to “Data Dictionary/Data Definition Matrix”

(28) 2.5.11.4.1 (1), Added definition for Data Dictionary

(29) 2.5.11.4.1 (1a), Added definition for Active Data Dictionary

(30) 2.5.11.4.1 (1b), Added definition for Passive Data Dictionary

(31) 2.5.11.4.2, Added Data Flow Diagrams

(32) 2.5.11.4.2.1, Added IRS Business Process Model and Notation (BPMN) Overview

(33) 2.5.11.4.2.2, Added Developing Data Flow Diagrams

(34) 2.5.11.4.2.2.1, Added Identifying a Data Flow Diagram

(35) 2.5.11.4.2.2.2, Added Naming a Data Flow Diagram

(36) 2.5.11.4.2.2.3, Added Numbering a Data Flow Diagram

(37) 2.5.11.4.2.2.4, Added Balancing Data Flow Diagrams

(38) 2.5.11.4.2.2.5, Added Types of Data Flow Diagrams

(39) 2.5.11.4.2.2.5.1, Added Current Physical Data Flow Diagram

(40) 2.5.11.4.2.2.5.2, Added Current Logical Data Flow Diagram

(41) 2.5.11.4.2.2.5.3, Added New Logical Data Flow Diagram.

(42) 2.5.11.4.2.2.5.4, Added Depicting Files on Logical Data Flow Diagrams

(43) 2.5.11.4.2.2.5.5, Added New Physical Data Flow Diagram

(44) 2.5.11.4.2.2.5.6, Added Depicting Files on Physical Data Flow Diagrams

(45) 2.5.11.4.2.3, Added Leveling Data Flow Diagrams

(46) 2.5.11.4.2.4, Added Parent/Child Process Relationships

(47) 2.5.11.4.2.5, Added Leveling Conventions/Standards

(48) 2.5.11.4.2.6, Added Elements of a Data Flow Diagram and explanation

(49) 2.5.11.4.2.6.1, Added Data Stream

(50) 2.5.11.4.2.6.1.1, Added Naming Data Streams/Modifiers

(51) 2.5.11.4.2.6.1.2, Added Routers and Collectors

(52) 2.5.11.4.2.6.1.3, Added Split Data Stream

(53) 2.5.11.4.2.6.2, Added Process

(54) 2.5.11.4.2.7, Added Data Store

(55) 2.5.11.4.2.7.1, Added Accessing/Updating a Data Store

(56) 2.5.11.4.2.7.2, Added Updating Re-circulating Data Stores

(57) 2.5.11.4.2.8, Added Access Key

(58) 2.5.11.4.2.9, Added Source/Sink

(59) 2.5.11.4.2.10, Added Sorts.

(60) 2.5.11.4.2.11, Added Off-Page Connector

(61) 2.5.11.4.2.12, Added Developing Data Definitions

(62) 2.5.11.4.2.12.1, Added Types of Data Definitions

(63) 2.5.11.4.2.12.2, Added Components of Data Definitions

(64) 2.5.11.4.2.12.3, Added Attributes and Cross-References

(65) 2.5.11.4.2.12.4, Added Data Streams/Elements

(66) 2.5.11.4.2.12.4.1, Added Naming Data Streams/Modifiers

(67) 2.5.11.4.2.12.5, Added Data Streams/Groups

(68) 2.5.11.4.2.12.6, Data Stores

(69) 2.5.11.4.2.12.7, Added External Entities

(70) 2.5.11.4.2.12.8, Added Avoiding Redundant Data Definitions

(71) 2.5.11.4.2.12.9, Added Defining the Contents of Data

(72) 2.5.11.4.2.12.10, Added Data Name Aliases

(73) 2.5.11.4.2.12.11, Added Approved Aliases

(74) 2.5.11.4.3, Added Transition to Design

(75) 2.5.11.4.3.1, Added Partitioning the Data Flow Diagrams

(76) 2.5.11.4.3.2, Added Packaging the Data Flow Diagrams

(77) 2.5.11.5, Reorganized

(78) 2.5.11.5.1, Reorganized

(79) 2.5.11.5.2, Reorganized and added description references

(80) 2.5.11.5.2.1, Reorganized

(81) 2.5.11.5.2.2, Reorganized

(82) 2.5.11.5.2.3, Reorganized

(83) 2.5.11.5.2.4, Reorganized

(84) 2.5.11.5.2.5, Reorganized

(85) 2.5.11.5.3, Reorganized

(86) 2.5.11.5.4, Reorganized

(87) 2.5.11.5.5, Reorganized

(88) 2.5.11.5.5.1, Reorganized

(89) 2.5.11.5.5.2, Reorganized

(90) 2.5.11.5.7.1, Corrected punctuation and grammar

(91) 2.5.11.6.4, Changed title to Structured English for Programming Languages Overview

(92) 2.5.11.6.4.1, Changed title to Structured English for Programming Languages Vocabulary

(93) Figure 2.5.11-1, Added descriptive content

(94) Figure 2.5.11-2, Added descriptive content

(95) Figure 2.5.11-3, Added descriptive content

(96) Figure 2.5.11-4, Added descriptive content

(97) Figure 2.5.11-5, Added descriptive content

(98) Figure 2,5,11-6, Added descriptive content

(99) Figure 2.5.11-7, Added descriptive content

(100) Figure 2.5.11-8, Added descriptive content

(101) Figure 2.5.11-9, Added descriptive content

(102) Figure 2.5.1-10, Added descriptive content

(103) Figure 2.5.1-11, Added descriptive content

(104) Figure 2.5.11-12, Added descriptive content

(105) Figure 2.5.1-13, Added descriptive content

(106) Figure 2.5.11-14, Added descriptive content

(107) Figure 2.5.11-15, Added descriptive content

(108) Figure 2.5.11-16, Added descriptive content

(109) Figure 2.5.11-17, Added descriptive content

(110) Figure 2.5.11-18, Added descriptive content

(111) Figure 2.5.11-19, Added descriptive content

(112) Figure 2.5.11-20, Added descriptive content

(113) Figure 2.5.11-21, Added descriptive content

(114) Figure 2.5.11-22, Added descriptive content

(115) Figure 2.5.11-23, Added descriptive content

(116) Figure 2.5.11-24, Added descriptive content

(117) Figure 2.5.11-25, Added descriptive content

(118) Figure 2.5.11-26, Added descriptive content

(119) Figure 2.5.11-27, Added descriptive content

(120) Figure 2.5.11-28, Added descriptive content

(121) Figure 2.5.11-29, Added descriptive content

(122) Figure 2.5.11-30, Added descriptive content

(123) Figure 2.5.11-31, Added descriptive content.

(124) Exhibit 2.5.11-5, Corrected spelling in title, “Acronyms”

(125) Exhibit 2.5.11-5, Listed additional Acronyms and Terms

(126) Exhibit 2.5.11-6, Listed additional Terms and Definitions

Effect on Other Documents

This IRM supersedes IRM 2.5.11 dated 04-01-2005, and supplements IRM 2.5.1 System Development.

Audience

The audience intended for this transmittal is personnel responsible for engineering, developing, and maintaining Agency software systems identified in the Enterprise Architecture. This engineering, development, and maintenance include that performed by government employees as well as contractors.

Effective Date

(10-09-2020)

Nancy Sieger
Acting Chief Information Officer

Program Scope and Objectives

  1. Scope: The guidelines, standards, techniques, and other controls established in this manual apply to all software developed for the Internal Revenue Service. This development includes work performed by government employees as well as contractors. For system development purposes, the controls established in this manual may be used with any agency approved life cycle, e.g., Software Development Life Cycle (SDLC) and/or Enterprise Architecture (EA), Enterprise Life Cycle (ELC).

  2. Purpose: This manual describes techniques for modeling processes/data flows among these processes, defining data, and specifying processes. This manual is distributed to promote the development of business models that are easy to understand, change, and maintain.

  3. Audience: This manual applies to Information Technology (IT) managers and personnel responsible for engineering, developing, or maintaining agency software systems identified in the Enterprise Architecture. This engineering, development, and maintenance include that performed by government employees as well as contractors.

  4. Policy Owner: The Acting, Chief Information Officer is the authority for this IRM.

  5. Program Owner: The Information Technology, Application Development (AD) Director of Technical Integration is responsible for the administration, procedures, and updates related to the program.

  6. Primary Stakeholders: The software developers and business owners of Internal Revenue Service are stakeholders for the guidelines, standards, techniques, and other controls established in this manual.

  7. Program Goals: The attached IRM establishes standards, techniques, and other controls for analyzing business processes and data. This manual was updated to reflect revised guidance for techniques and deliverable descriptions for systems development.

Background

  1. Structured analysis is a technique that involves analysis, description, specification, and decomposition of business processes and data to derive a result that is: graphic and concise, non-redundant, top-down partitioned, and logical instead of physical. This technique uses logical models to enhance communication by emphasizing what (logically) needs to be designed, and not how (physically) to design it.

  2. Data flow diagrams, data definitions, and process specifications are the tools used in structured analysis. The primary deliverable that results from applying structured analysis is the functional specification package. This deliverable comprises data flow diagrams, data definitions, and process specifications.

Authority

  1. IRM 2.5.1 System Development, is the overarching IRM for all System Development programs within the IRS

  2. IRM 10.5.1 Security, Privacy and Assurance, Privacy and Information Protection, Privacy Policy

  3. IRM 10.8.6 Security, Privacy and Assurance, Information Technology (IT) Security, Application Security and Development

  4. Clinger-Cohen Act of 1996

  5. Federal Information Security Modernization Act of 2014, FISMA 2014

  6. The Office of Management and Budget (OMB)

  7. Government Performance Results Act, 1993

  8. Treasury Inspector General Tax Administration (TIGTA)

3. Responsibilities or Roles and Responsibilities

  1. Information Technology (IT), Cybersecurity: Cybersecurity manages the IRS IT Security program in accordance with the Federal Information Security Management Act with the goal of delivering effective and professional customer service to business units and support functions within the IRS. These procedures are done as the following:

    1. Provide valid risk mitigated solutions to security inquisitions.

    2. Respond to incidents quickly and effectively in order to eliminate risks/threats.

    3. Ensure all IT security policies and procedures are actively developed, and updated.

    4. Provide security advice to IRS constituents, and proactively monitor IRS robust security program for any required modifications or enhancements.

  2. Director, Enterprise Operations (EOps), Data Management Services & Support (DMSS): Directs and oversees reliable database and storage operations by pioneering improvements in data services. Other responsibilities are as follows:

    • Plan, build, operate, and maintain the IRS’s data management technologies/processes

    • Ensure level 2 and 3 support is administered to address customer database requirements

  3. Applications Development (AD): AD is responsible for building, testing, delivering, and maintaining integrated information applications systems, e.g., software solutions, to support modernized systems and production environment to achieve the mission and objectives of the Service. Additional, AD is responsible for the following:
    • AD works in partnership with customers to improve the quality of and deliver changes to IRS information systems products and services
    • Establishes and maintains rigorous contract and fiscal management, oversight, quality assurance, and program risk management processes to ensure that strategic plans and priorities are being met
    • Maintains the effectiveness and enhance the integration of IRS installed base production systems and infrastructure while modernizing core business systems and infrastructure
    • Provides quality assessment/assurance of deliverables and processes. Application Development’s (AD) chain of command and responsibilities include:

    1. Commissioner: Oversees and provides overall strategic direction for the IRS. The Commissioner’s and Deputy Commissioner’s main focus is for the IRS’s services programs, enforcement, operations support, and organizations. Additionally, the Commissioner’s vision is enhance services to the nation’s taxpayers, balancing appropriate enforcement of the nation’s tax laws while respecting taxpayers’ rights.

    2. Deputy Commissioner, Operation Support (DCOS): Oversees the operations of Agency-Wide Shared Services: Chief Financial Officer, Human Capital Office, Information Technology, Planning Programming and Audit Oversight and Privacy, and Governmental Liaison and Disclosure.

    3. Chief Information Officer (CIO): The CIO leads Information Technology, and advises the Commissioner on Information Technology matters, manages all IRS IT resources, and is responsible for delivering and maintaining modernized information systems throughout the IRS. Assisting the Chief Technology Officer (CTO) is the Deputy Chief Information Officer for Operations.

    4. Application Development (AD) Associate Chief Information Officer (ACIO): The AD ACIO reports directly to the CIO; oversees and ensures the quality of: building, unit testing, delivering, and maintaining integrated enterprise-wide applications systems to support modernized and legacy systems in the production environment to achieve the mission of the Service. AD works in partnership with customers to improve the quality of and deliver changes to IRS information systems products and services.

    5. Deputy AD Associate CIO (ACIO): The Deputy AD ACIO reports directly to the AD ACIO, and is responsible for:
      • Leading strategic priorities to enable the AD Vision, IT Technology Roadmap and the IRS future state
      • Executive planning and management of the development organization which ensures all filing season programs are developed, tested, and delivered on-time and within budget

  4. AD has the following Domains:
    • Compliance Domain
    • Corporate Data Domain
    • Customer Service Domain
    • Data Delivery Service (DDS) Domain
    • Delivery Management; Quality Assurance (DMQA) Domain
    • Identity & Access Management (IAM) Organization Domain
    • Internal Management Domain
    • Submission Processing Domain
    • Technical Integration Organization (TIO) Domain

  5. Director, Compliance: Provides executive direction for a wide suite of Compliance focused applications, and oversee the IT Software Development organization to ensure the quality of production ready applications. Directs and oversees an unified cross-divisional approach to compliance strategies needing collaboration pertaining to the following:

    1. Abusive tax avoidance transactions needing a coordinated response

    2. Cross-divisional technical issues

    3. Emerging issues

    4. Service-wide operational procedures

  6. Director, AD Corporate Data: Directs and oversees the provisioning of authoritative databases, refund identification, notice generation, and reporting.

  7. Director, Customer Service: Directs and oversees Customer Service Support for the IT Enterprise Service Desk ensuring quality employee to customer relationship.

  8. Director, Data Delivery Services: Directs, oversees, and ensures the quality of data with repeatable processes in a scalable environment. The enterprise data strategy is to transform DDS into a data centric organization dedicated to deliver Data as a Service (DaaS) through:

    • Innovation - new methods and discoveries

    • Motivate - incent and enable individuals

    • Renovation - streamline or automate

  9. Director, Delivery Management; Quality Assurance (DMQA): Executes the mission of DMQA by ensuring AD has a coordinated, cross-domain, and cross-organizational approach to delivering AD systems and software applications. Additionally, the DMQA Director reports to the AD ACIO, and chairs the AD Risk Review Board.

  10. Director, Identity & Access Management (IAM) : Provides oversight and direction for continual secure online interaction by verifying and establishing an individual's identity before providing access to taxpayer information “identity proofing”, while staying compliant within federal security requirements.

  11. Director, Internal Management: Provides oversight for the builds, tests, deliveries, refund identification, notice generation, and reporting.

  12. Director, Submission Processing: Provides oversight to an organization of over 17,000 employees comprised of: a headquarters staff responsible for developing program policies and procedures, and five Wage& Investment processing centers. Additionally, the Director, Submission Processing is responsible for processing over 500 million individual and business tax returns through both electronic and paper methods.

  13. Director, Technical Integration: Provides strategic technical organization oversight ensuring applicable guidance, collaboration, consolidation of technical integration issues and quality assurance for the Applications Development portfolio.

Program Management and Review

  1. Program Reports:

    • Model driven requirement document

    • Customer requirement

    • Business requirement decomposition

    • Business physical data flow diagram

    • Business logical data flow diagram

  2. Program Effectiveness:

    • Using special conventions on Model Data Flows

    • Leveling Data Flow Diagrams

    • Identify and balancing Data Flow Diagrams

Program Controls

  1. The Requirements Engineering Program Office of Business Planning and Risk Management (BPRM) is the IRS authority on providing standards and guidance to Requirements Engineering activities, process modeling, and requirements-related solutions.

  2. This office oversees Requirements Development and Requirements Management efforts on all business change, software development, systems integration, and legacy system upgrades throughout IRS Information Technology.

Terms/Definitions/Acronyms

  1. For Acronyms/Terms, see Exhibit 2.5.11-5

  2. For Terms/Definitions, see Exhibit 2.5.11-6

Related Resources

  1. Object Management Group (OMG), https://www.omg.org/

  2. Tutorialspoint, https://www.tutorialspoint.com/system_analysis_and_design/system_analysis_and_design_structured.htm

  3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  4. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

Model-Driven Architecture

  1. Model Driven Architecture (MDA) was launched by the Object Management Group during 2001, and is an approach to separating business-level functionality from technical specifications of implementations. The objective of this methodology is to permit business-level functionality to be modeled using standards such as Unified Modeling Language (UML), and Business Process Modeling Notation (BPMN) to allow the models to exit without platform constraints and requirements; then instantiate the models into specific runtime executions.

Structured Analysis Overview

  1. The Structured Analysis method is based on a meticulous style consisting of using graphical tools that analyze and perfect the objectives of an existing system while developing new system specifications. This development method has the following features:

    1. It is graphical and describes the presentation of application

    2. It identifies each process flow of the system

    3. It is logical not physical

    4. It provides high-level overviews to lower-level elements

Structured Analysis Tools

  1. During the Structured Analysis phase diverse tools and techniques are used for system development. The tools are the following:

    • Data Dictionary

    • Data Flow Diagrams

    • Decision Trees

    • Decision Tables

    • Structured English for Programming Languages

Data Dictionary/Data Definition Matrix

  1. The Data Dictionary or Data Definition Matrix is an effective textual description of data objects, their information such as a descriptive name, the data type, allowed values and units. The Data Dictionary is an effective and concise tool for obtaining the elements within the dataset. Types of Data Dictionaries are:

    1. Active Data Dictionary: Automatically updated by the Database Management System (DBMS) when changes are updated in the database.

    2. Passive Data Dictionary: This Data Dictionary must be manually updated to reflect the database, or the database and dictionary will not be unison.

Data Flow Diagrams

  1. Data flow diagrams provide a general picture of the data transformations (processes), and their interfaces (data streams) in a system. Data streams, stores, and processes are defined to make the data flow diagrams more precise. Data definitions add precision to a system by capturing the details of the data streams and data stores. Since the means to catalogue these definitions will vary by site, the exact form they take will vary. Whether this method is manual, automated, or a combination of the two, standards dictate that project managers ensure consistency within their systems.

IRS Business Process Model and Notation (BPMN) Overview
  1. The Business Process Modeling Notation is a graphical symbol that depicts the steps in a business process. Within the BPMN a flow chart describes the steps of a planned business process from end to end and provides a detailed sequence of business activities and information flows.

  2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

Developing Data Flow Diagrams (DFDs)
  1. A Data Flow Diagram (DFD)is a structured analysis and design graphic tool that illustrates the system as a continuous stream of ongoing data, but does not address physical concerns, i.e., decisions or loops like the traditional flow chart. A data flow diagram emphasizes the flow of data, but not the flow of control.

  2. DFDs present a logical view of the system, unlike flowcharts, which introduce many physical constraints too early in system development. At a very early stage, DFDs provide a graphic model of the system being developed which can be easily understood by the customer. Areas of misunderstanding are resolved early in system development rather than in a later development stage where changes have much more impact.

  3. DFDs break-up a system into functional subcomponents. This partitioning aids in identifying and isolating the various functions of a system.

  4. At a higher level, DFDs present system overviews suitable for management briefings, and provide valid information for communicating with the system designer.

  5. DFDs are developed by studying the data from the user's point of view, and then creating different logical and physical system models. DFDs include the key characteristics:

    1. Support the Analysis and Requirements stage of System Design

    2. A diagramming technique with annotations

    3. Graphically depict the boundaries between the system itself, and the external entities where data comes from, or goes to that can represent (humans, systems, or subsystems)

    4. Display the target system into a network of activities/processes, their interfaces together with origins, destinations, and stores of data

    5. Provide Stepwise Refinement through hierarchical decomposition of processes

  6. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    1. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡"≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡" ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

Identifying a Data Flow Diagram
  1. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡

  2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

Naming a Data Flow Diagram
  1. Title each data flow diagram with the name of its "parent' bubble. The context diagram within a data flow diagram set has no "parent" diagram; it is the highest-level diagram that identifies the system name, inputs, and outputs.

Numbering a Data Flow Diagram
  1. Except for the context diagram, each data flow diagram is labeled with the diagram number of its parent bubble. This diagram number is carried over into the numbering of the individual bubbles by taking the diagram number, placing a decimal point after it, and then placing a sequential number after the decimal point to give each bubble a unique identifier.

  2. The diagram number retains the bulk of the numbering and the bubbles are numbered with only the last decimal point number. Figure 2.5.11-18 illustrates the numbering, i.e., the actual process reference numbers of diagram 2.4.5 are 2.4.5.1, 2.4.5.2, and 2.4.5.3.

    Figure 2.5.11-1

    This is an Image: 36327018.gif

    Please click here for the text description of the image.

  3. Exhibit 2.5.11- 1 illustrates a properly numbered data flow diagram.

Balancing Data Flow Diagrams
  1. Keep data flow diagrams in balance. Represent in the associated bubbles in the child diagram all data streams shown entering and exiting a parent diagram. There are exceptions to the balance rule-minor error paths and trivial inputs (e.g., error messages, system date) need not be in balance.

  2. Show a data store (file) on the first data flow diagram level where all system references to it are shown. Apply this concept at all levels. If a file is used primarily by the system represented in the context diagram, there is no need to show the file at the context diagram level, however, if the file is external to the system, show it on the context diagram.

  3. As an example, Figure 2.5.11-20 illustrates a data store or file not shown in Diagram 0. This is because the file is internal to the processing in process 3 (as though it is concealed inside the bubble). The file and all its data streams are shown when process 3 is diagrammed.

    Figure 2.5.11-2

    This is an Image: 36327020.gif

    Please click here for the text description of the image.

  4. Figure 2.5.11-21 is for Diagram 0 and illustrates a file being used by processes 2 and 3.

    Figure 2.5.11-3

    This is an Image: 36327021.gif

    Please click here for the text description of the image.

Types of Data Flow Diagrams
  1. In applying structured analysis, develop and use the following types of data flow diagrams:

    1. Current physical data flow diagram, see IRM 2.5.11.4.2.2.5.1

    2. Current logical data flow diagram, see IRM 2.5.11.4.2.2.5.2

    3. New logical data flow diagram, see IRM 2.5.11.4.2.2.5.3

    4. New physical data flow diagram, see IRM 2.5.11.4.2.2.5.5

Current Physical Data Flow Diagram
  1. Use this type of data flow diagram to model the current physical environment. This type of data flow diagram models the physical characteristics of an existing system such as: department names, physical location, organizations, people's names, and mechanical or operational devices.

  2. Use this type of data flow diagram when modeling a system for the first time. Since the user is more familiar with the physical terminology, get the user's approval of the accuracy of the model of the existing system before continuing analysis.

Current Logical Data Flow Diagram
  1. Make a current physical data flow diagram by removing physical considerations and constraints. For instance, replace department names with the actual processing functions within that department. The logical model must depict how the data is being transformed, not who or what is transforming it.

New Logical Data Flow Diagram
  1. To accommodate required changes to a system, examine and modify the current logical data flow diagram. Reexamine the rationale behind the why and way processes are done. This model is still logical, and becomes the candidate for the final aspect of data flow diagram development.

Depicting Files on Logical Data Flow Diagrams
  1. When designating files on logical data flow diagrams in which data from an old version of a file is being transformed into data for a new version of that same file, show the old and new versions of the file. Figure 2.5.11-13 illustrates a data transformation.

    Figure 2.5.11-4

    This is an Image: 36327013.gif

    Please click here for the text description of the image.

New Physical Data Flow Diagram
  1. The data flow diagrams that result from this technique are the actual maintainable documentation required within the functional specification package.

  2. In the final aspect of data flow diagram development, balance the implementation of the ideal system (as represented by the new logical data flow diagrams) against the realities of time and cost constraints. Consider feasibility and impact studies, cost/benefit analysis, and other variables until an appropriate compromise physical model is selected.

  3. Make physical decisions, e.g., which data stores will be data bases as opposed to sequential files, and consider "packaging."

  4. Do not allow the data flow diagrams to become too physical, because this will limit the choices available to the designer. Depict functional processes as opposed to organizational entities affecting the system, e.g., departments or divisions.

Depicting Files on Physical Data Flow Diagrams
  1. If a decision is made during creation of the physical data flow diagram to use a single random access file, designate it on the new physical data flow diagram (but not on the logical data flow diagram). Figure 2.5.11-14 illustrates random file access depicted on a data flow diagram.

    Figure 2.5.11-5

    This is an Image: 36327014.gif

    Please click here for the text description of the image.

  2. If the file is to be sequentially processed, or there is uncertainty how it will be processed, depict the file on the new physical data flow diagram as Figure 2.5.11-15 illustrates.

    Figure 2.5.11-6

    This is an Image: 36327015.gif

    Please click here for the text description of the image.

Leveling Data Flow Diagrams
  1. Leveling is the partitioning of a large system into manageable units, resulting in system documentation that is easier to comprehend. Top-down analysis and reanalysis of processes and data (partitioning and re-partitioning) produce a high level overview for management and lower, more detailed levels for the designer and users. A leveled data flow diagram set comprises:

    1. The top-level diagram, called the context diagram, which defines the boundary of the system and consists of only one bubble that is labeled with an overall system descriptor. The system sources, sinks, inputs, and outputs are depicted; and the input and output data streams are shown to define the domain of the system.

    2. Middle-level data flow diagrams are used when it is necessary to represent the system processes within the context diagram broken down into a more detailed level. They are the intermediate level between a context diagram and the functional primitives.

    3. The lowest-level data flow diagram, called a functional primitive, represents a process that cannot be further decomposed. A functional primitive has no internal data streams and usually only a single input and single output.

  2. Exhibit 2.5.11- 1 Illustrates the format for a leveled data flow diagram.

Parent/Child Process Relationships
  1. A diagram for which there is a lower level diagram(s) is termed a "parent" diagram. For instance, in Exhibit 2.5.11-1, the context diagram is parent to Diagram 0 which is termed a "child" diagram. Diagram 0 also assumes the role of a parent to Diagram 2, which is the child of Diagram 0. Therefore, a diagram can be both a child of a higher-level data flow diagram and a parent to a lower level data flow diagram. However, a lowest level (Functional Primitive) data flow diagram can only be a child diagram because it cannot be further decomposed.

Leveling Conventions/Standards
  1. Each level of the data flow diagram is to reside on a separate page. The reader can follow the diagram leveling using the diagram and bubble numbering system as a guide.

  2. There is no set number of levels. However, there is always at least a context diagram level and an associated lowest level. The number of middle level diagrams is dependent upon the complexity of the system being defined.

  3. In the interest of readability, partition levels into about seven bubbles (plus or minus two bubbles).

Elements of a Data Flow Diagram (DFD)Overview
  1. Data flow diagrams have four main elements as the following:

    1. External Entity also known as (actors, sources or sinks, and terminators): Produce and use data that flows between the entity and the system being diagrammed. The data flows are the inputs/outputs of the DFD, and are normally placed at the boundaries of the diagram because they are external to the system.

    2. Process: For explanation see IRM 2.5.11.4.2.6.2

    3. Data Store: For explanation see IRM 2.5.11.4.2.7

    4. Data Flow: For explanation see IRM 2.5.11.4.2

Data Stream
  1. A data stream is one or more elements of data. A data stream is used to indicate a sharing of data. A data stream is graphically represented by an arrow that shows the direction for which data is being shared. Figure 2.5.11- 1 depicts a data stream.

Naming Data Streams/Modifiers
  1. Label all data streams with meaningful names and applicable naming standards. When a data stream has been logically transformed and this needs to be distinguished, do not create a new data name. Use a modifier to qualify the name and place it in parentheses after the data stream name. Figure 2.5.11-7 depicts data streams with modified names.

    Figure 2.5.11-7

    This is an Image: 36327002.gif

    Please click here for the text description of the image.

Routers and Collectors
  1. A router is used to subdivide a data stream or decompose data. A router is graphically represented by a right half circle. Figure 2.5.11- 3 depicts a router.

    Figure 2.5.11-8

    This is an Image: 36327003.gif

    Please click here for the text description of the image.

  2. A collector is used to rebuild data streams or recompose data. A router is graphically represented by a left half circle. Figure 2.5.11- 4 depicts a collector.

    Figure 2.5.11-9

    This is an Image: 36327004.gif

    Please click here for the text description of the image.

Split Data Stream
  1. A split data stream divides the routing of data. Unlike the case with the logical router and logical collector, no decomposing or recomposing of the data stream takes place. A split arrow is used to show the routing of a data stream to two or more destinations. A split data stream is graphically represented by a multi prong arrow. Figure 2.5.11- 5 depicts a split data stream as seen below.

    Figure 2.5.11-10

    This is an Image: 36327005.gif

    Please click here for the text description of the image.

Process
  1. A process represents a logical transformation of an incoming data stream(s) into an outgoing data stream(s). A process is a type of object that represents activity and constitutes a data flow diagram. A process name must consist of a transitive verb followed by a subject. Show a process by an ellipse or circle with a process name inside. Figure 2.5.11-12 shows these conventions as seen below.

    Figure 2.5.11-11

    This is an Image: 36327006.gif

    Please click here for the text description of the image.

  2. For decomposition purposes, three types of processes are acknowledged:

    1. Context process: A context process represents the scope of activity being analyzed and modeled. A context process represents the first level of decomposition for a related set of data flow diagrams. A context process is a process that comprises other processes and does not constitute another process. As a rule, a context process may not constitute another process.

    2. Parent process: A parent process is a process that comprises other processes. As a rule, a parent process must constitute another process and comprise other processes

    3. Elementary process: An elementary process is a process that constitutes another process and does not comprise other processes. As a rule, an elementary process must not comprise other processes.

Data Store
  1. A Data Store (Database, File, and Table), represented by parallel lines, is a data stream, which is at rest (i.e., a temporary repository of data). Place the data store name between the parallel lines. Figure 2.5.11-13 illustrates a data store.

    Figure 2.5.11-12

    This is an Image: 36327007.gif

    Please click here for the text description of the image.

Accessing/Updating a Data Store
  1. Use the arrows to represent reads, writes, or other accesses to a data store and may be used in any appropriate combination. Figure 2.5.11-14 illustrates the accessing of or reading from a data store.

    Figure 2.5.11-13

    This is an Image: 36327010.gif

    Please click here for the text description of the image.

  2. Figure 2.5.11-15 illustrates the updating of or writing to a data store.

    Figure 2.5.11-14

    This is an Image: 36327011.gif

    Please click here for the text description of the image.

  3. When diagramming a file key accessing a data store, the key is optional. Only show the key on a physical data flow diagram (i.e., after it is decided that the file media will be direct access). Figure 2.5.11-12 illustrates a file key accessing a data store.

    Figure 2.5.11-15

    This is an Image: 36327012.gif

    Please click here for the text description of the image.

Updating Re-circulating Data Stores
  1. When developing logical or physical data flow diagrams, some situations will require the modeling of re-circulating data stores.

Access Key
  1. An access key is an optional figure that is represented by a dashed line with a name; and is only used to represent a key accessing a random access disk file. Figure 2.5.11-8 illustrates an access key to a data store.

    Figure 2.5.11-16

    This is an Image: 36327008.gif

    Please click here for the text description of the image.

Source/Sink
  1. Represent a Source/Sink (e.g., External Entity, External Input and Output) by a rectangle. A source or sink is a person or organization, external to the context of a system that is a net originator or receiver of system data. Place the source/sink name inside the rectangle. Figure 2.5.11-9 illustrates a source/sink.

    Figure 2.5.11-17

    This is an Image: 36327009.gif

    Please click here for the text description of the image.

Data Sorts
  1. Introduce a sort as a process bubble only when it is logically required. If the sort process is being shown as a bubble is sorting an input file, and putting out a sorted file, then show these files on the data flow diagram. Name the data stores only, not the data streams.

  2. Figure 2.5.11-16 provides an example (of a sequential file update or an update where the decision as to whether it will be random or sequential has not been made) that illustrates a sort.

    Figure 2.5.11-18

    This is an Image: 36327016.gif

    Please click here for the text description of the image.

Off-Page Connector
  1. An off-page connector is represented by a circle and arrow. Avoid continuation pages because they make the data flow diagram less readable. When a data flow diagram must be continued onto another page and the diagram remains at the same level of decomposition, then, the off-page connector may be used. Write the sending and receiving page numbers within the respective circles. To avoid confusion, make the circles smaller than the process bubbles on your data flow diagram. Figure 2.5.11-17 illustrates the conventions used to depict off-page connectors.

    Figure 2.5.11-19

    This is an Image: 36327017.gif

    Please click here for the text description of the image.

Developing Data Definitions
  1. Develop a definition for each data stream and data store on the data flow diagram, and is maintained in a system glossary. Ensure all the data definitions are defined as follows:

    1. Data elements

    2. Data streams and groups of data elements contained within these

    3. Data Stores and all components referenced in the process specifications

    4. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    5. Use agency guidelines for the use of enterprise data dictionary, see reference in this subsection under d).

Types of Data Definitions
  1. Define data in terms of its components and their relationship in the hierarchy. Define the following four types:

    • Data Element: This is the smallest piece of data that is not further decomposed.

    • Data Group: This is a data structure that consists of other data groups and/or data elements.

    • Data Stream (also called data flow): This is a pipeline along which information of known composition is passed, also termed as data in motion/data in transit.

      Note:

      Data streams are not defined as separate entities in the system glossary; each data stream is a flow consisting of either a data group or a data element.

    • Data Store: This is a temporary repository of data, and is termed as data at rest. Data at rest also refers to data that is not actively moving from device to device, or network to network after the data arrives at its final destination.

  2. External entities (sources and sinks) are not data, but must also be described in the system glossary or data dictionary.

Components of Data Definitions
  1. The components of data definitions consist of two separate database definitions:

    1. Data Attributes (DATA_ATTRIBUTES): This defines the appearance and behavior of the data type.

    2. Data Criteria (DATA_CRITERIA): This is used to assign the object type to a file or directory, as seen in the example below:

    Figure 2.5.11-20

    Data Criteria

    Criteria Description
    File name The file name must match a specified pattern. Use the NAME_PATTERN field for naming requirements.
    File location The path must match a specified pattern. Use the PATH_PATTERN field.
    File contents A portion of the file’s contents must match specified data. Use the CONTENT field.
    File mode The file must possess the specified permissions (read, write, execute, directory). Use the MODE field for required permissions.

    Note:

    Normally used in combination with name-based, location-based, or content-based data typing.

    Symbolic links The typing is based on the file to which the object is linked.

Attributes and Cross-References
  1. The following attributes describe and define the system components. They provide information critical to understanding the system under description:

    • Constraints

    • Contains

    • Description

    • Values/Meanings

  2. Use the following cross-references to describe the relationships between system components, and provide information that enhances system understanding and maintainability:

    • Access Key To

    • Accessed By

    • Aliases/Modifiers

    • Input To

    • Output Of

    • Part Of

    • Provides

    • Receives

    • Updated By

    • Additional cross-references for common Process Specifications

Data Streams/Elements
  1. A single data element may constitute a data stream; this is indicated on a data flow diagram when the element name is assigned to an arrow.

    Figure 2.5.11-21

    This is an Image: 36327001.gif

    Please click here for the text description of the image.

  2. The following attributes define the data streams/elements:

    • Description: a narrative description of the element.

    • Values/Meanings: a list of valid values for an element and the meanings of those values.

  3. Use the following cross-references to describe the relationships with other system components:

    • Access Key To: An alphabetical listing of data stores for which this data element is an access key.

    • Aliases/Modifiers: An alphabetical listing of other names for the same element (aliases), or qualifiers for the element name (modifiers).

    • Input To: If the element is a data stream, an alphabetical listing of processes that, as input accept the data stream.

    • Output Of: If the element is a data stream, an alphabetical listing of processes which are sources of the data stream.

    • Part Of: An alphabetical listing of data groups which contain this element.

Naming Data Streams/Modifiers
  1. Label all data streams with meaningful names and applicable naming standards. When a data stream has been logically transformed and this needs to be distinguished, do not create a new data name. Use a modifier to qualify the name and place it in parentheses after the data stream name. Figure 2.5.11- 2 depicts data streams with modified names.

  2. For more guidance on naming data, see IRM 2.152.3 Information Technology, Data Engineering, Naming Data Element(s)/Object(s).

Data Streams/Groups
  1. A group may be a data stream, or it may be a component part of a larger group, data stream, or data store. The following attributes define the data streams/groups:

    • Description: A narrative description of the group.

    • Contains: A list of the elements and/or subordinate groups which constitute the data stream/group being defined; symbols are used to show the relationships between the contents.

  2. Use the following cross-references to describe the relationships with other system components:

    • Access Key To: An alphabetical listing of data stores for which this data group is an access key.

    • Aliases/Modifiers: An alphabetical listing of other names for the same group (aliases), or qualifiers for the group name (modifiers).

    • Input To: If the group is a data stream, an alphabetical listing of processes that, as input, accept the data stream.

    • Output Of: If the group is a data stream, an alphabetical listing of processes which are sources of the data stream.

    • Part Of: An alphabetical listing of larger data groups which contain this group.

Data Stores
  1. The following attributes define the data store:

    • Description: A narrative description of the data store.

    • Constraints: A narrative description of items, rules, regulations, etc. affecting the data store; e.g., required password security or response time criteria for database access.

    • Contains: A list of the elements and/or groups which constitute the data store; symbols are used to show the relationships between the contents.

  2. Other data store definition related information:

    • Accessed By: This is an alphabetical listing of processes or external entities which use this data store as a source; the data store is shown as an input to these processes or external entities on the data flow diagram.

    • Updated By: This is an alphabetical listing of processes or external entities which change or reorder the contents of the data store.

    • Aliases/Modifiers: This is an alphabetical listing of other names for the same data store (aliases), or qualifiers for the data store name (modifiers).

    • Part Of: This is an alphabetical listing of larger data stores (such as a database) which contain this element.

External Entities
  1. External entities are defined by the following:

    • Description: This is a narrative description of the external entity.

    • Provides: This is an alphabetical listing of data stream(s), which the external entity provides as input to the system.

    • Receives: This is an alphabetical listing of data stream(s), which the external entity receives as output from the system.

Avoiding Redundant Data Definitions
  1. When a system is using both a glossary and data dictionary, some data will be defined in both. This is most likely to occur in the case of data streams on the context diagram that enter and exit the system, and with data elements. If it happens that the data is defined in both and any attributes are the same, state in the system glossary, see Data Dictionary.

Defining the Contents of Data
  1. Define the contents of data in the "Contains" attribute. Data, except for data elements, is composed of and defined by lower level data components. Show the relationships between these data components in the "Contains" attribute using a symbol convention.

  2. Unless the use of an automated data dictionary precludes usage, then refer to Figure 2.5.11-22 for the symbols to be used to list the contents of data.

    Figure 2.5.11-22

    This is an Image: 36327022.gif

    Please click here for the text description of the image.

  3. Exhibit 2.5.11- 2 provides the symbols used to define data.

Data Name Aliases
  1. An alias is a data name that is synonymous with a more commonly accepted data name of a data stream, data store, data group, or data element. An alias is created when the same data is labeled with more than one data name (i.e., the commonly accepted name and the alias name(s)). See IRM 2.152.3 Information Technology, Data Engineering, Naming Data Element/Objects for more data naming guidance.

Approved Aliases
  1. Aliases generally occur for three reasons:

    • Different users have different names for the same form, etc.

    • An analyst inadvertently introduces an alias in the data flow diagram.

    • Two analysts working independently with the same data stream give it different names.

Transition to Design

  1. This section provides guidance on using the results from analysis as the basis for software design.

Partitioning the Data Flow Diagrams
  1. If a data flow diagram has not been evenly partitioned, the diagram will combine some detail and some higher levels of abstraction. In this case, perform a top-down partitioning of the data flow diagram by:

    1. Replacing any problem bubble by its "child" network and then connecting the data flows.

    2. Grouping into sets to minimize interfaces.

    3. Allocating one top-level bubble per set.

    4. Renumbering and renaming everything.

Packaging the Data Flow Diagrams
  1. As the new physical data flow diagrams are being developed, both the analyst and the designer must consider certain physical details. Unless a data flow diagram is small and limited in function, it will need to be "packaged". Packaging is the process of subdividing the data flow diagram processes into related groups of processes; and each of these related groups of processes evolves into a separate structure chart that will be created during the software design. The following physical boundaries and constraints have a bearing on the packaging of a data flow diagram set:

    • Man/machine boundary-separates manual processes from those performed on computer equipment.

    • Hardware boundary-separates processes, which must be performed on different types of computer equipment.

    • Batch/on-line/real time boundary-various functions of a system may be on-line, real time, or batch mode depending on the speed requirements for data retrieval, display, availability, etc.

    • Cycle or timing boundary-some processes must be run daily, while others only need to be run once a week, month, or year.

    • Commercial software-some processes may be accomplished using vendor-supplied software.

    • Security/safety needs-security and safety requirements may cause the addition of otherwise unnecessary boundaries and intermediate data stores. Other needs of this type include audit, back-up, recovery, and checkpoint/restart requirements.

    • Resources-some processes may not be able to be run at the same time because of limited resources, (e.g., the job is too large for computer capacity).

Developing Process Specifications

  1. All systems, whether structured or not, require descriptions of the procedures that determine how inputs are to be transformed into outputs. As these procedures increase in complexity, English narrative descriptions become a more ambiguous and less acceptable means to specify these transformations.

  2. Structured analysis introduces the process specification, a written description, and explanation of the processing which takes place within a data flow diagram process bubble.

  3. Only use structured English, decision tables, or decision trees to write the procedures section of a process specification.

Process Specification Attributes

  1. The three attributes associated with all process specifications are (in appropriate order):

    1. Description: A narrative describing the purpose and objective of the process.

    2. Constraints: A narrative description of the process constraints. This section usually is not needed, but may be used to specify nonprocedural requirements. An example is a timing requirement such as a report that must be generated only on the last day of the month. Pertinent characteristics of the process, e.g., input and output volumes, peaks and seasonality of the input and output data flows are other possible constraints.

    3. Procedures: Use structured English, decision tables, or decision trees to describe in detail the criteria governing the transformation of input data streams into output data streams. Convey what has to be done, not how it is to be accomplished.

Type of Process Specifications

  1. There are two types of process specifications:

    1. Primitive Level Process Specifications, see IRM 2.5.11.5.2.1

    2. Higher Level Process Specifications, see IRM 2.5.11.5.2.2

Primitive Level Process Specifications (mini specs)
  1. This type of process specification defines primitive level (lowest level; not further decomposed) data flow diagram process bubbles. This specification must contain: the description, procedure(s) attribute(s), and as applicable constraint(s) attribute(s).

Higher Level Process Specifications
  1. This type of process specification defines higher level "parent'' data flow diagram process bubbles. This type of specification must contain the description attribute; and as applicable contain the constraints attribute.

General Rules for Writing Process Specifications

  1. Do not address physical requirements, e.g., telecommunications devices, in the written description. Describe physical information in the constraints section, but only when essential.

  2. Ensure that the process specifications stress what needs to be accomplished, not how it is to be accomplished.

  3. Develop a process specification for each bubble.

  4. Entitle each process specification with the process name and number of its associated bubble on the data flow diagram.

  5. Define the transformation of input data into output data for process specification.

  6. Avoid redundancy between the process specification, and other tools in the functional specification package.

  7. Use the data names as shown in the data flow diagrams, and the date definitions in the process specification.

  8. Use Structured English decision table, or decision tree format to write the procedures attribute.

Structured English for Programming Languages Overview

  1. Structured English is English-like instructions with a limited selection of sentence structures that reflect processing actions. An algorithm can be written in English-like programming syntax without consideration to the actual programming language for future use. Structured English is used to verify the business logic, which can then be coded in any programming language. Common terms are used, such as IF-THEN-ELSE.

Structured English for Programming Languages Vocabulary
  1. Structured English uses a limited vocabulary consisting of:

    • Strong action verbs

    • Direct and indirect objects that are defined in a glossary/data dictionary

    • As few adjectives and adverbs as possible

  2. Do not write process specifications from a physical code-like perspective (i.e., in the worst case they contain detailed instructions as to control, working storage, physical media considerations, switch settings, etc.) as this will cause a significant decrease in "user friendliness".

  3. Structured English that is simply pseudocode for program source code defeats the purpose of analysis, limits design options and flexibility, and creates a maintenance headache for analysts.

Logical Constructs of Structured English
  1. Structured English also uses a limited statement syntax consisting of simple imperative sentences, closed-end decisions, closed-end repetitions, or any combinations of the above.

  2. Constructs have only one entry point and one exit point; they create a linear presentation (one construct is done completely before another construct is begun), thus avoiding the confusion inherent in narratives that skip around. Procedures written in Structured English must be numbered in a consistent manner for readability and referencing purposes. Numbering the constructs helps facilitate citing, or referencing within the Procedures Section of a process specification.

  3. All Process Specification functions must be described using only the three constructs discussed below.

Sequence Construct
  1. Use this construct to present a sequence of steps to be taken in order. It consists of imperative sentences, each of which is ended with a period and is indented equally in the construct. Indentation signifies the relationships and dependencies of statements within the various constructs. Figure 2.5.11-23 provides an example of a sequence construct.

    Figure 2.5.11-23

    This is an Image: 36327023.gif

    Please click here for the text description of the image.

Decision Construct
  1. Use this type of construct to select an action from among mutually exclusive alternative actions based upon the outcome of a specific condition. There are two versions of this construct, the If-Then-Else format and the Select-Case format.

    1. Use the "If-Then-Else" format when there are only two alternatives.

    2. Write the "Else" or the "Then" statement of the decision showing no action when there is no action to be taken.

    3. The "Else" statement may be omitted (unless it is being used as an end marker for readability).

  2. Figure 2.5.11-24 illustrates the If-Then-Else format.

    Figure 2.5.11-24

    This is an Image: 36327024.gif

    Please click here for the text description of the image.

  3. Figure 2.5.11-25 provides an example of an If-Then-Else Decision Construct.

    Figure 2.5.11-25

    This is an Image: 36327025.gif

    Please click here for the text description of the image.

  4. Use the "Select-Case" format when there are more than two alternatives, each mutually exclusive. Number each case, enclose in parentheses, and end with a comma. Once a case is selected and its action taken, ignore the subsequent case statements. Figure 2.5.11-26 provides an example of a Select-Case Decision Construct.

    Figure 2.5.11-26

    This is an Image: 36327026.gif

    Please click here for the text description of the image.

Repetition Construct
  1. Use the "Repetition Construct" to show action performed until some condition occurs to cause the action(s) to cease. Figure 2.5.11-27 illustrates a Repetition Construct.

    Figure 2.5.11-27

    This is an Image: 36327027.gif

    Please click here for the text description of the image.

Decision Tables

  1. Decision tables are a concise, and efficient way of specifying processes which have numerous combinations of conditions in order to perform a specific action. Figure 2.5.11- 28 illustrates the format of a decision table. Exhibit 2.5.11- 3 illustrates a procedure, and a decision table that expresses the same procedure.

    Figure 2.5.11-28

    This is an Image: 36327028.gif

    Please click here for the text description of the image.

  2. Figure 2.5.11- 29 provides an example of a decision table.

    Figure 2.5.11-29

    This is an Image: 36327029.gif

    Please click here for the text description of the image.

  3. A decision table comprises four types of sections, the following explains these sections:

    • Conditions Section: Lists the conditions or statements that affect the process being specified and must be considered in performing the process being specified.

    • Condition Entries Section: Indicates whether the condition is met or not. This section is subdivided into vertical columns that are generally numbered, and are known as rules. The blocks within the condition entries section, when filled in, contain the responses to the conditions listed in the conditions section.

    • Actions Section: Lists those actions that may be taken in order to perform the process.

    • Action Entries Section: This section is also subdivided into the same vertical columns or rules as the condition entries section. The blocks contain either an "X" (meaning perform the action) or either a " " or a "=" (meaning the action does not apply).

  4. Exhibit 2.5.11- 3 illustrates the use of a narration and a decision table to describe the same procedure. For the purposes of this exhibit, a procedure to determine who will approve the selection and acquisition of contractual services is being used.

Decision Tree

  1. A decision tree is a graphic representation of a decision table; it communicates the same information in a different form. Figure 2.5.11- 29 provides an example of a decision table. Figure 2.5.11- 30 depicts a decision tree that expresses the decisions expressed in Figure 2.5.11- 29.

    Figure 2.5.11-30

    This is an Image: 36327030.gif

    Please click here for the text description of the image.

Common Process Specifications

  1. Some processes are shared by different systems, or are used more than once within a single system. These common processes are designated by adding the suffix "(COMMON)", capitalized and placed in parentheses, to the end of the process name.

Attributes and Cross-References
  1. In addition to the three attributes which apply to all process specifications, there are three cross-references associated with common process specifications:

    • Maintained by the organizational identification (branch, section, etc.) of those who have maintenance responsibility

    • Last Revision month, day, and year of the latest revision

    • Used By organizations that use the Process Specifications

  2. The first appearance of the common process specification in a data flow diagram set must list the "Description" attribute; may list the "Constraints" and "Procedures" attributes; and must list the "Maintained By" and "Last Revision" cross-references. Any subsequent occurrences of the common process specification need only list the "Description" attribute.

Maintenance
  1. Each common process specification is the maintenance responsibility of one project team or organizational area, and only those responsible are authorized to make changes to a specification. Any organizational area may use the specification, but the group with the maintenance responsibility must notify the users of any changes and revisions.

  2. Exhibit 2.5.11- 4 provides an example of the first and then subsequent occurrence of a common process specification.

Functional Specification Package (FSP)

  1. The primary deliverable that results from structured analysis is a functional specification package. After a system is defined using the tools of structured analysis, the resulting documentation must be packaged to derive the functional specification package.

  2. Naming standards must be applied. Names, numbers, and all other identifiers must be consistent among deliverables where applicable.

  3. Standard identifying information must be provided on every page of the analysis documents. Include the following types of information when applicable:

    • System name

    • Functional Specification Package number

    • Responsible organization (e.g., branch/section)

    • Operational/Revision date

    • Project Name/Project Number

  4. A functional specification package comprises one context diagram. The scope of the functional specification package must be consistent with the scope of the context diagram. The functional specification package comprises:

    • Data flow diagrams, which graphically depict business processes and the data interfaces among these processes

    • Data definitions, which define and document the interfaces on the data flow diagrams

    • Process specifications, which specify the data transformations among the business processes

Data Flow Diagrams and Process Specifications

  1. The two allowable ways of ordering the data flow diagrams and process specifications within a functional specification package. The data flow diagrams must be sequenced in ascending numeric order, and the process specifications placed immediately behind their associated data flow diagram or grouped together behind the entire data flow diagram set.

  2. To maintain constancy among functional specifications packages developed for a system, one of the following methods must be used for sequencing:

    • Sequence the Process Specification in the same sequential order they would appear in if they were interspersed with the data flow diagrams

    • Sequence the Process Specifications in ascending numeric order (e.g., 1.0, 2.0, 2.1, 2.1.1, 2.1.2, 2.2, 3.0, 3.1, 3.2, 3.3, 4.0).

Data Definitions

  1. Enter all data definitions into a system glossary, and/or data dictionary. If a manual system glossary is being used, packaged it into the functional specification package.

Screen Displays

  1. In order to fully document a system, add other sections to a functional specification package. Graphics for projects that use terminals for processing must be organized into a "Screen Display" section.

Reports/Layouts

  1. Organize graphic formats for printed inputs and outputs such as reports, e.g., error registers into a "Print Report Layouts" section.

Table of Contents/Cross References

  1. Add a "Table of Contents" and/or "Cross-Referencing" material to aid the reader in understanding, and following the Functional Specification Package (FSP). Develop an alphabetical index of names of external entities, processes, data groups, and data elements; or a listing of external inputs and outputs, and processes to organize a Functional Specification Package.

Format for a Leveled Data Flow Diagram

This is an Image: 36327031.gif

Please click here for the text description of the image.

Symbols Used to Define Data

This is an Image: 36327032.gif

Please click here for the text description of the image.

A Procedure described using a Narration, then using a Decision Table

This is an Image: 36327033.gif

Please click here for the text description of the image.

Common Process Specification Example

This is an Image: 36327034.gif

Please click here for the text description of the image.

Acronyms/Terms

Acronyms Terms
ACIO Acting Chief Information Officer
ACIO AD Associate Chief Information Officer, Application Development
AD Application Development
BPMN Business Process Modeling Notation
DaaS Data as a Service
DBMS Database Management System
DCOS Deputy Commissioner, Operation Support
DFD Data Flow Diagrams
DMQA Delivery Management & Quality Assurance
EA Enterprise Architecture
ELC Enterprise Life Cycle
FISMA Federal Information Security Modernization Act of 2014
FSP Functional Specification Package
IAM Identity & Access Management
OMB The Office of Management and Budget
OMG Object Management Group
MDA Model Driven Architecture
SA/SD System Analysis/System Development
REPO Requirements Engineering Process Office
SDLC Software Development Life Cycle
TIGTA Treasury Inspector General Tax Administration
UML Unified Modeling Language

Terms/Definitions

Terms Definitions
Business Process Modeling Notation Provides a graphical notation for creating business processes in a Business Process Diagram, based on a flowcharting technique similar to UML.
Bubble Chart Bubble charts are graphs used to compare the relationships between data objects in three numeric-data dimensions: the X-axis data, the Y-axis data, and data represented by the bubble size. Bubble charts are similar to XY scatter graphs.
Constraints Restrictions or limitations on possible solutions.
System Designer A person who creates a detailed design documentation for the development and integration of the computer systems.
Object Management Group This is an international nonprofit technology and industry standards consortium. The mission of OMG is to establish and revise technology standards that provide real-world value for international end-users, vendors, government agencies, universities, and research institutions as needed.
Requirements Engineering Process Office The Requirements Engineering Program Office (REPO) of Business Planning and Risk Management (BPRM) is the IRS authority on providing standards and guidance to Requirements Engineering activities, process modeling, and requirements-related solutions.
System Analyst A person who uses analysis and design techniques to solve business problems using information technology.
Unified Modeling Language Industry-standardized modeling language or collection of modeling techniques for visualizing, creating, and documenting artifacts of a system’s process.