One of the system analyst's primary responsibilities is the identification and logical representation of the systems they design. Analysts must understand a system's functions, data, behaviour, and structure, and effectively communicate each component with developers and stakeholders. Typically, the analysis process results in a set of models used to achieve this goal. For example, a data flow diagram (DFD) describes the system's functions and processes, while an entity relationship diagram (ERD) describes the system's data.
DFDs and ERDs are created for different reasons. A data flow diagram models the flow of information through a system and consists of processes, flows, data, and terminators. A DFD describes how data enters a system, is transformed in a system, and is stored in a system. An entity relationship diagram models people, objects, places, and events (also called entities) for which data is stored in a system, and generally, a system's database. The ERD also shows the relationships and cardinality between the system's entities.
DFDs and ERDs model different things. Systems analysis involves identifying system processes, flows, inputs, and outputs. The resulting DFD model is a multi-levelled representation of the system that starts with the most abstract information (context diagram), and includes multiple decomposed levels. Systems analysis also involves the identification of data within the system, including what data is stored and how the data relates to other data. The resulting ERD model is a representation of the system data and includes detailed descriptions of the relationships between the data.
DFDs and ERDs are created using different notations. DFD processes are represented by circles, ovals, or rectangles and named with a single word. Arrows with descriptive names represent flows, and parallel lines or ovals represent stores. Named rectangles represent terminators. A rectangular box represents ERD entities, and relationships between entities are represented by diamonds and named with the relationship's description. Lines and standard notations represent cardinality, or the number of objects participating in an entity relationship.
DFDs and ERDs are drawn following different rules. With a DFD, each process and store must have at least one data flow going into it and one leaving it. All data must go through a process and all processes within the system must be linked to another process or data store. With an ERD, all entities must represent a set of similar things. Relationships may not be redundant, may not be many-to-many, and attributes may not be foreign key attributes. All definitions must be unambiguous.
ERDs and DFDs have different shortcomings. DFDs cannot completely describe a system, and the use of different symbols can confuse users. DFDs cannot specify computations within a process and timing relationships. ERDs do not show interaction between data or model how the data changes within the system. Both ERDs and DFDs may take time to create that stakeholders don't want to dedicate, a problem that can lead to frustration or to a poorly designed system that does not meet the stakeholder's needs.
- Precision Quality Software: Context Diagrams: An Explanation
- Freebytes: DFD Example - General Model Of Publisher's Present Ordering System
- Australian Flexible Learning Framework: DFD Rules
- SearchCRM: entity-relationship diagram (ERD or ER Diagram)
- University of Missouri - St. Louis: Entity-Relationship Diagrams (ERDs)
- docstoc: DFD Construction Process