Q1. How does a use case report differ from a Data Flow Diagram?

Ans. (Contributed by Prerna Kejriwal)
Data Flow Diagram :

• A data flow diagram is a graphic representation of a system or portion of system. It consists of data flows, processes, sources, destinations, and stores – all described through the use of easily understood symbols. An entire system can be described from the viewpoint of the data it processes with only four symbol. At the same time, data flow diagrams are powerful enough to show parallel activities. When standard symbols limit communication, a presentation graph, which uses symbols of people, files, terminals, and documents, can be used to discuss a system with users.
  
  A data flow diagram are of two types :
  
  · Physical Data flow diagrams
  · Logical data flow diagrams.
  
  Physical data flow diagrams are implementation-dependent. They show the actual devices, department, people, etc., involved in the current system.
  Logical data flow diagrams, in contrast, describe the system independently of how it is actually implemented; that is, they show what takes place, rather than how an activity is accomplished.
  Both types of data flow diagrams support a top-down approach to systems analysis, whereby analysts begin by developing a general understanding of the system and gradually explode components in greater detail. As details are added, information about control can also be included, although upper-level general diagrams are drawn without showing specific control issues to ensure focuses on data and processes.

Rules for drawing Logical Data Flow Diagrams :

1. Any data flow leaving a process must be based on data that are input to the process.
2. All data flows are named; the name reflects the data flowing between processes, data stores, sources, or sinks.
3. Only data needed to perform the process should be an input to the process.
4. A process should know nothing about, that is, be independent of, any other process in the system, it should depend only on its own input and output.
5. Processes are always running, they do now start or stop. Analysts should assume that a process is always ready to function or perform necessary work.
6. Output from processes can take one of the following forms :

a. An input data flow with information added by the process (for example, an annoted invoice)
b. A response or change of data form (such as change of profit dollars into profit percentage)
c. Change of status (from unapproved to approved status)
d. Change of content (assembly or separation of information contained in one or more incoming
data flows)
e. Change in organization (for example, the physical separation or rearrangement of data)

When beginning a systems study in an unfamiliar area, you need to get the lay of the land. Physical elements stand out first: the people, reports and documents, file cabinets and in-baskets, and events. It’s not unusual to remember certain key people or places. Physical data flow diagrams depict these physical elements.

Once you have the lay of the land, the essentials of a task can be studied more carefully. You need to get below the surface, so to speak. That’s what logical data flow diagrams are all about.

Logical data flow diagrams describe data, processes, and events differently. They are more abstract than physical data flow diagrams, but that difference is important. As an analyst, you have to know more about the job that must be done than the people who are actually doing the work. This doesn’t mean that people are not important, for they surely are. But if a key worker becomes ill or chooses to leave the company, the work will remain. Desks, files and computers will change, too. By focusing on the understanding elements – the logical, nonphysical aspects – you gain an understanding of the fundamental structure of the system. Only then can you develop a complete understanding and form a basis for designing the right system.

Use Case Report :

A user case diagram shows you some of the use cases in your system, some of the actors in your system, and the relationships between them. A use case is a high- level piece of functionality that the system will provide. An actor is anyone or anything that interacts with the system being built.

In the above diagram, there are three actors: the customer, the bank officer, and the credit system. There are six major pieces of functionality the system will provide: depositing funds, transferring funds, withdrawing money, changing a PIN, viewing a balance, and making a payment.

One of the major benefits of a Use Case diagrams is communication. Your customers can look at this diagram and receive a great deal of information. By looking at the use cases, they will know what functionality will be included in the system. By looking at the actors, they will know exactly who will be interfacing with the system. By looking at the set of use cases and actors, they will know exactly what the scope of the project will be. This can help them identify up front any missing functionality.