0% found this document useful (0 votes)
427 views

Classical Analysis

This document discusses various techniques for requirements specification, including informal, formal, and semiformal techniques. It focuses on structured systems analysis as a semiformal technique. Structured systems analysis involves converting system requirements into specifications, programs, hardware configurations, and procedures. Key aspects of structured systems analysis include data flow diagrams (DFDs) and data dictionaries. DFDs provide a graphical representation of how data flows through a system. Data dictionaries define and describe all data elements used in system models.

Uploaded by

Thamarai Kannan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
427 views

Classical Analysis

This document discusses various techniques for requirements specification, including informal, formal, and semiformal techniques. It focuses on structured systems analysis as a semiformal technique. Structured systems analysis involves converting system requirements into specifications, programs, hardware configurations, and procedures. Key aspects of structured systems analysis include data flow diagrams (DFDs) and data dictionaries. DFDs provide a graphical representation of how data flows through a system. Data dictionaries define and describe all data elements used in system models.

Uploaded by

Thamarai Kannan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

CLASSICAL ANALYSIS

Specification document must satisfy two mutually contradictory requirements


1. It must be clear and intelligible to client
 Client probably not a computer expert
 Client must understand it in order to authorize
2. It must be complete and detailed - Sole source of information available to the design team

Classification of Requirement specification techniques


(1) Informal: Written in a natural language
(2) Formal: Techniques such as Petri nets and Z
(3) Semiformal: Techniques between informal and formal.eg. structured system analysis

2.14. STRUCTURED SYSTEMS ANALYSIS


- technique in which the system requirements are converted into specifications and then into
computer programs, hardware configurations and related manual procedures.
- data flowing through it -> view
- function -> is described by processes that transform the data flows.
- advantage of information hiding

DATA FLOW DIAGRAM


• A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data through an
information system.

• System Context Diagram first which shows the interaction between the system and outside
entities.

• The DFD is designed to show how a system is divided into smaller portions and to highlight the
flow of data between those parts.

• Level 0 DFD i.e. Context level DFD should depict the system as a single.

• Primary input and primary output should be carefully identified.

• Information flow from continuity must be maintained from level to level


symbol of structured system analysis

External Entity: External entities are objects outside the system, with which the system communicates.
External entities are sources and destinations of the system’s inputs and outputs.
Process : A process tranforms incoming data flow into outgoing data flow
Data Store: Data store are repositories of data in the system. They are sometimes also referred to as
files or databases.
Transition: It represents the flow of information from one entity to another

Rules for Designing DFD:


1. No process can have only outputs or only inputs. The process must have both Outputs and
inputs.

2. The verb phrases in the problem description can be identified as processes in the system.
3. There should not be a direct flow between data stores and external entity. This flow should go
through a process.

Data store labels should be noun phrases from problem description.


5. No data should move directly between external entities. The data flow should go through a
process.
6. Generally source and sink labels are noun phrases
Step 1: Draw the Data Flow Diagram (DFD)
• A pictorial representation of all aspects of the logical data flow
✓Logical data flow — What happens
✓Physical data flow — How it happens
• Any non-trivial product contains many elements
• DFD is developed by stepwise refinement
• For large products a hierarchy of DFDs instead of one DFD
• Constructed by identifying data flows: Within requirements document or rapid prototype
Step 2: Decide what sections to computerize and how (batch or online)
Depending on client’s needs and budget limitations
✓ Cost-benefit analysis is applied
Step 3: Determine details of data flows
✓ Decide what data items must go into various data flows

✓ Stepwise refinement of each flow

✓ For larger products, a data dictionary is generated.

✓ Data dictionary - keeps track of all data element.

- A data dictionary is a collection of data about data.


It maintains information about the definition, structure, and use of each data element
that an organization uses.
Step 4: Define logic of processes
✓ Determine what happens within each process

✓ Use of decision trees to consider all cases


Step 5: Define data stores
✓Exact contents of each store and its representation (format)
Step 6: Define physical resources
✓ File names, organization (sequential, indexed, etc.), storage medium, and records

✓ If a database management system (DBMS) used: Relevant information for each table
Step 7: Determine input-output specifications
✓ Input forms and screens

✓ Printed outputs
Step 8: Determine sizing
✓ Computing numerical data to determine hardware requirements

✓ Volume of input (daily or hourly)

✓ Frequency of each printed report and its deadline

✓ Size and number of records of each type to pass between CPU and mass storage

✓ Size of each file


Step 9: Determine hardware requirements
✓ Use of sizing information to determine mass storage requirements

✓ Mass storage for backup

✓ Determine if client’s current hardware system is adequate


After approval by client: Specification document is handed to design team, and software process
continues
DATA DICTIONARY
• Data dictionaries are generally useful when developing system models and may be used to manage all
information from all types of system models.
• A data dictionary is an alphabetic list of the names included in the system models. As well as the name,
the dictionary should include an associated description of the named entity and, if the name represents a
composite object, a description of the composition.
• Other information such as the date of creation, the creator and the representation of the entity may also
be included depending on the type of model being developed.

Name of data element Description Narrative


Order Record comprising fields ,the field contain all details of an order
Order identification
Customer name
Customer address
.
.
Package name
Package price
.
Advantages:
1. It is a mechanism for name management.
2. It serves as a store of organizational information.

As the system is developed, information that can link analysis, design, implementation and evolution
is added to the data dictionary, so that all information about an entity is in one place.
PETRINET
Petri nets are a basic model of parallel and distributed systems. The basic idea is to describe state
changes in a system with transitions.
• Petri nets — Formal technique for describing concurrent interrelated activities
• Invented by Carl Adam Petri, 1962

Petri net Consists of four parts


(1) A set of places
(2) A set of transitions
(3) An input function
(4) An output function

You might also like