Laynetworks  
Web laynetworks.com Google
Home | Site Map | Tell a friends
Journal of Management
Management Tutorials
Download
Tutorials
History
Computer Science
Networking
OS - Linux and Unix
Source Code
Script & Languages
Protocols
Glossary
IGNOU
Quiz
About Us
Contact Us
Feedback
 
Sign up for our Email Newsletter
 
Get Paid for Your Tech Turorials / Tips

 

 

Home > Computer Science > Elements of System Analysis and Design
 
CS 01 CS 02 CS 03 CS 04 CS 05 CS 06 CS 07 CS 08 CS 09 CS 10 CS 11 CS 12 CS 13 CS 14 CS 15 CS 16 CS 17
Page : 1 2 3 4 5 6 7
Elements of System Analysis and Design
 

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)

Example of Data flow diagram

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.

An example of use case diagram

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.

Page : 1 2 3 4 5 6 7
 
Other related subject which might interest you