DFDs decision tables and SRS

Data Flow Diagram

A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. DFDs can also be used for the visualization of data processing (structured design).

On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal process.

Basic Symbols
external entity Data flow Data source Process

Creating Data Flow Diagrams

Creating DFDs is a highly iterative process of gradual refinement. General steps: 1. Create a preliminary Context Diagram 2. Identify Use Cases, i.e. the ways in which users most commonly use the system 3. Create DFD fragments for each use case 4. Create a Level 0 diagram from fragments 5. Decompose to Level 1,2, 6. Go to step 1 and revise as necessary 7. Validate DFDs with users.

Context Diagram
A data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system One process, numbered 0. Sources and sinks (external entities) as squares Main data flows depicted No internal data stores are shown
They are inside the system External data stores are shown as external entities

Context Diagram of Order System

Order
CUSTOMER WAREHOUSE

Order Reject Notice Payment Invoice

Picking List

Completed Order

Order System

Commission

Bank Deposit

Cash Receipts Entry

SALES REP

ACCOUNTING

BANK

Level-0 DFD
Shows the systems major processes, data flows, and data stores at a high level of abstraction When the Context Diagram is expanded into DFD level-0, all the connections that flow into and out of process 0 needs to be retained.

Level0 DFD of Order System

Payment

Order CUSTOMER 1.0

Picking List WAREHOUSE

Order Reject Notice

Fill Order

Invoice 2.0 Completed Order

Invoice Accounts Receivable

Create Invoice

D1

Payment Detail

Invoice Detail

3.0

Apply Payment Commission Bank Deposit Cash Receipts Entry

SALES REP

BANK

ACCOUNTING

Strategies for Developing DFDs

Top-down strategy
Create the high-level diagrams (Context Diagram), then low-level diagrams (Level-0 diagram), and so on

Bottom-up strategy
Create the low-level diagrams, then higher-level diagrams

Decision tables
Decision tables are a precise yet compact way to model complicated logic.

Decision tables, like flowcharts and if-thenelse and switch-case statements, associate conditions with actions to perform, but in many cases do so in a more elegant way.
Representation of a user's interaction with the system.

 A Decision table is a table of rows and columns, separated into four quadrants and is designed to illustrate complex decision rules.

Condition Stub upper left quadrant Rules Stub upper right quadrant Action Stub bottom left quadrant Entries Stub - bottom right quadrant

 Standard format used for presenting decision tables.

Decision Stub Action Stub Rules Stub Entries Stub

 Standard format used for presenting decision tables.

Decision Stub Action Stub Rules Stub Entries Stub

Decision Table Example

Printer troubleshooter

Rules
Printer does not print Conditions A red light is flashing Printer is unrecognized Check the power cable Check the printer-computer cable Actions Ensure printer software is installed Check/replace ink X X X X Y Y Y Y Y N Y N Y X X X X X X X Y N N N Y Y N Y N N N Y N N N

Check for paper jam

Developing Decision Tables

Process requires the determination of the number of conditions (inputs) that affect the decision. The set of possible actions (outputs) must likewise be determined

The number of rules is computed

Each rule must specify one or more actions

Software Requirement Specification

A Software requirements specification (SRS), a requirements specification for a software system , is a complete description of the behavior of a system to be developed and may include a set of use cases that describe interactions the users will have with the software. In addition it also contains non-functional requirements . The software requirements specification document enlists all necessary requirements that are required for the project development.

Non Functional Requirement

Non-functional requirements impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints).

The Purpose and Characteristics of a Software Requirements Specification

Feedback to the Customer
The software requirement specification assures the project management stakeholders and client that the development team has really understood the business requirements documentation properly. This also provides confidence that the team will develop the functionality which has been detailed.

 Breaking the Requirements Down

The Software Requirement Specification is documented in such a way that it breaks the deliverables into smaller components. The information is organized in such a way that the developers will not only understand the boundaries within which they need to work, but also what functionality needs to be developed and in what order.

 Facilitating other Documentation

The SRS forms the basis for a load of other important documents such as the Software Design Specification.

Product Validation
It basically helps in validating with the client that the product which is being delivered, meets what they asked for.