STRUCTURED ANALYSIS
  • Requirements process – steps to produce the SRS
  • Contains three basic activities –
  • Problem analysis
  • Informal Approach
  • Structured Analysis
  • Prototyping
  • Requirement specification
  • Requirement validation
  • Structured system analysis is a method for problem analysis.

PROBLEM ANALYSIS

  • Basis purpose to fully & clearly understand the system
  • Includes inputs, outputs, constraints, behavior, etc.
  • This understanding leads to specification.
  • Analysis involves interviewing people, reading documents, studying procedures, etc.
  • Users & clients may not fully understand their needs
  • Analyst should help them understand
  • Should act as a consultant.
  • During analysis a lot of information collected
  • Proper organization of the information is therefore important
  • Analyst has to ensure that the information is complete & consistent
  • Ensuring consistency may require conflict resolution.
  • Communication & people skills very important for analyst.
  • Basic principle: divide & conquer
  • All analysis techniques use partitioning.

DATA FLOW DIAGRAMS AND DATA DICTIONARY

  • Structured analysis (SA) uses data flow diagrams & data dictionary
  • A data flow diagram (DFD) shows the flow of data in the system
  • It is a general technique used in many areas.
  • A DFD views a system as transforming inputs to outputs.
  • Generally the input is not transformed to output in a single step
  • Inputs go through many transformations before becoming the output
  • DFD is a means to represent this transition of data.
  • A DFD has two major elements – processes & dataflows
  • A process, also called a bubble, represents a transformation.
  • Inputs & outputs of a process are data flows
  • A process is generally represented by a circle
  • Data flows are the named arrows entering or leaving a bubble
  • A rectangle represents a source or a sink. i.e., originator or final consumer of data.
  • A source or a sink is typically outside the system under study.

CONVENTIONS

  • All external files shown as labeled lines
  • AND relationship represented by*
  • OR relationship represented by +
  • DFD represents flow of data not flow of control
  • Not a flow-chart.

DRAWING A DFD

  • DFD does not represent procedural info.
  • Specify WHAT are the transformations.
  • Not HOW the transformations are done.
  • No set of rules for drawing dfd.
  1. Start with identifying the inputs and ouputs.
  2. Work your away from inputs to outputs, or vice versa

If stuck, reverse direction

Ask: “What transformations will convert the inputs to outputs”

3.Never try to show control logic.

If thinking about loops, if-then-else

STOP. Start again.

  1. Label each arrow carefully.
  2. Make use of * and, show sufficient detail.

6.Ignore minor functions in the start.

7.For complex system, make dfd hierarchical.

8.Never settle for lst dfd.

LEVELED DFD

  • DFDs can be hierarchically organised
  • A bubble at a higher level DFD is exploded in a DFD
  • Such a set of DFDs is called a leveled DFD
  • For consistency, inputs & outputs of a process are same as for the DFD for the process.
  • Refinement may refine the data flows also.

DATA DICTIONARY

  • In a DFD, data flows are shown by labeled arrows
  • DFD does not specify structure of data.
  • Data dictionary states the structure of the data flows
  • Data defined in a DD using regular expression notation
  • Sequence or composition – represented by +
  • Selection represented by 1
  • Repetition by *

EXAMPLE OF DD

  • weekly time sheet=

Employee_name +

Employee_id +

(Regular_hours + Overtime_hours)*

  • pay_rate=

(Hourly / daily / weekly) +

Dollar_amount

  • Employee_name=

Last + First + Middle_initial

  • Employee_Id=

Digit + digit + digit + digit

COMMON ERRORS IN DFD

  • Unabled data flows
  • Insufficient data for a bubble to produce outputs
  • Extraneous data flows
  • Lack of consistency while exploding
  • Effort to include control information
  • Too little or too much detail

STRUCTURED ANALYSIS METHOD

  • Structured analysis uses DFD for problem in req. analysis
  • It starts with identifying inputs & outputs
  • Tracks data through the system-from inputs to outputs
  • Sees the states the data undergoes while getting converted from inputs to outputs.
  • Uses DFD to represent data states and transformation.
  • First step is to define the context diagram
  • Context diagram views the entire system as one process
  • Specifies inputs, outputs sinks, & sources
  • Context diagram defines the overall system
  • Starting from Context diagram, the DFD of the physical system is drawn.
  • Models actual data items in the existing system & how they are processed.
  • The physical system model is converted to logical system model
  • The logical model, data flows & processes are replaced with logical data & logical processes.
  • So far, we have modeled the existing system
  • The next step is to convert the DFD to logical model of the eventual system
  • Complete DFD is shown – no separation between automated & non-automated is made.
  • No general rules for constructing this DFD
  • This is a creative transformation, analyst uses his experience.
  • In next step, man-machine boundary is specified
  • This identifies portion to be implemented in software
  • All data flows are specified in data dictionary.
  • Sometimes, processes are specified as minispecs.
  • This completes the analysis part
  • The final DFD, and its details, form input to design.
  • Supplies_file=

(date +

(item_no + quantity + cost)*)*

  • Orders_file

(date +

(menu_item_no + quantity + status)*))

  • Status = satisfied / unsatisfied
  • Order = (menu_item_no + quantity)*
  • Menu =

(manu_item_no + name + price + supplies_used)*

  • Supplies_used =

(supply_item_no + quantity)*

  • Bill =

(name + quantity + price)* +

total_price +

sales_tax +

service_charge +

grand_total

  • Discrepancy_report =

(supply_item_no + amt_ordered +

amt_left + amt_consumed + descr)*

SUMMARY

  • Req analysis requires problem an alysis & specification
  • During problem an alysis, the problem is understood & during req. specification problem is specified.
  • Problem snalysis involves studying existing systems, reading documents, interviewing, etc.
  • Finally the requirements of the system should be clear.
  • Structured analysis is one method of doing problem analysis.
  • SA uses DFDs & DD
  • DFDs represent flow of data in the system.
  • DDs specify the structure of data.
  • In SA, we start with context diagram of the existing system
  • Context diagram shows all inputs, outputs
  • A DFD is drawn for the system showing major data flows.
  • It is converted to logical DFD.
  • Then logical DFD for the final system is drawn
  • Man-machine boundary is identified
  • Top down refinement is employed by using leveled