The Structured Specification

26
The Structured Specification

description

The Structured Specification. Why a Structured Specification?. System analyst communicates the user requirements to the designer with a document called the functional specification which... may be full of computer terms the user doesn’t understand - PowerPoint PPT Presentation

Transcript of The Structured Specification

Page 1: The Structured Specification

The Structured Specification

Page 2: The Structured Specification

Why a Structured Specification?

• System analyst communicates the user requirements to the designer with a document called the functional specification which...– may be full of computer terms the user doesn’t

understand– may impose unnecessary constraints on designer

• Result is a specification which…– involves a lot of reading and is difficult to follow– improperly records the users’ needs

Page 3: The Structured Specification

Qualities of Structured Specification

• Graphic and concise– A picture is worth a thousand words– More consistent and takes less time to understand

• Top-down partitioned– Don’t bite off more than you can chew

• Non-redundant– Compact and consistent

• Essential– Focus on what system will do, save how for later

Page 4: The Structured Specification

Components of Structured Specification

• Data flow diagram (DFD)

• Data dictionary

• Tools to specify processes– Structured English– Decision tree/table

• Information model

Page 5: The Structured Specification

Data Flow Diagrams

• Gives structured specification qualities of being graphic, concise, and partitioned

• Composed of four main elements:

– Data flow

– Process (bubble)

– Data store

– Sources and sinks (also called external entities or terminators)

Name(s)

#Name

Name

Name

Page 6: The Structured Specification

DFD’s: Element Descriptions

• Data flow shows directional movement of data – like a conveyor belt

• Process transforms data– modify structure (formatting),– change information (content)

• Data store is place where data is kept (file)– computer files, paper, or anything that holds info.

• Terminator shows external data sources and destinations.

Page 7: The Structured Specification

Example DFDContext level

0system SinkSource

Data Flow 6Data Flow 1

Data Flow 2

Page 8: The Structured Specification

Example lower level DFD

Data Store

2Process

1Process

Data Flow 5

Data Flow 3

Data Flow 6

Data Flow 4

Data Flow 1

Data Flow 2

Page 9: The Structured Specification

DFD’s: Component Variations

• File operations:

– Read

– Update

– Add new info.

– Delete info.

Name

Name

Name

Name

Page 10: The Structured Specification

DFD’s: Component Variations, cont.

• Various flow types:

– Control flow (signal, no data)

– Continuous flow

– Material flow

– Continuous material flow

• Control process

• Material store

Name

Name

Name

Name

#Name

Name

Page 11: The Structured Specification

Leveling a DFD

• Establishes top-down partitioning

• Starts general and gets more specific– break down process into components– continue breaking down until a process can be described

on a single page of paper

• Top level is 0, contextual– One process (main)– Terminators– No data stores

Page 12: The Structured Specification

Leveling a DFD, cont.

• No more than 7 or 8 processes on a level

• Data flows to and from a bubble must all be shown on the diagram for that bubble (the next level down)

• Don’t show error flows on parent level

• Show terminators on top level

• Don’t show data stores on top level

Page 13: The Structured Specification

Guidelines for Drawing DFD’s• Give elements precise names• Make sure everyone agrees with a diagram before

developing more detailed diagrams• Show errors/rejects as short stubs• Don’t flowchart (loop back for more data)• Ignore how files are accessed• Diagram using an iterative process -- start with

something, then improve it• Show data stores only when needed

Page 14: The Structured Specification

Implementation-dependent vs. Essential DFD’s

• Implementation-dependent looks at way in which business happens to be done

• Helps uncover essential functions and data

• Shows actual names of people, forms, etc.

• Allows for initial feel of how business is run

• Not good to develop a system from -- must still make an essential DFD

Page 15: The Structured Specification

The Data Dictionary

• Contains definitions of all data mentioned…– in the DFD– in a process specification– in the data dictionary itself

• Composite data is defined in terms of components

• Elementary data is defined in terms of meanings of each value it can assume

• May have other info (size, response time, etc)

Page 16: The Structured Specification

Data Dictionary:Definition of Composite Data

• Three fundamental ways to construct (shown in long and short forms, respectively):– sequencing data types

• data item A IS data item P AND data item Q

• telephone number = area code + office code + number

– repeating a single data type a number of times• data item B IS ITERATIONS OF data item R

• passenger list = {passenger name}

– selecting one from several types of data• data item C IS EITHER data item S OR data item T

• customer order = [part I order | part II order]

Page 17: The Structured Specification

Data Dictionary:Graphic Forms of Composite Data• Sequence:

• Repetition:

• Selection

TelephoneNumber

AreaCode

OfficeCode

Number

PassengerList

PassengerName

Part IIPart I

CustomerOrder

Page 18: The Structured Specification

Data Dictionary:Definition of Files

• They are just iterations of records– example: customer credit file = {ssn + credit rating}

• Key fields are underlined– customer credit file = {ssn + credit rating}

• May have comments– *organization is sequential by ssn*

Page 19: The Structured Specification

Data Dictionary:Definition of Data Elements

• Piece of data that can’t or won’t be partitioned any further

• Defined in terms of values they can take on

• Example:DATA ELEMENT NAME credit ratingVALUES/MEANINGS A good

B acceptableC poorD bad

DESCRIPTION: creditworthiness of customer...

Page 20: The Structured Specification

Specification Tools:Goals

• Provide one mini-spec for each functional primitive in the DFD

• State how data is transformed

• State what the transformation of the data is

• Minimize redundancy

• Keep simple and standard

Page 21: The Structured Specification

Specification Tools:Structured English

• Vocabulary– imperative English verbs– terms from data dictionary– reserved words to denote logic

• Syntax– simple sentences– closed-end decisions– closed-end repetitions– combinations of the above

Page 22: The Structured Specification

Specification Tools:Structured English, cont.

• One flow in and one flow out

• Nesting

• Uses sequencing, repetition, and selection to build data in the data dictionary

Page 23: The Structured Specification

Structured English Example

6.4.7 PRODUCE CUSTOMER INVOICEFor each customer order form, do the following:

1. Enter customer name and address on invoice2. If customer category is “SPECIAL”

2.1 Get discount from discount file using aspecial indicator

2.2 Otherwise set discount to 0%3. For each sales item on customer order form,

do the following:3.13.23.3

Page 24: The Structured Specification

Specification Tools:Decision Trees/Tables

• Allow for deeper nesting than structured English

• Separates independent conditions and shows actions resulting from different combinations

A B CA

B

C

Page 25: The Structured Specification

Information Model:Entity-Relationship Diagrams

• Shows relationships between stored data of a system

Employee Project

Entity Type Relationship Type

WorksOn

Page 26: The Structured Specification

Putting It All Together

• Leveled data flow diagrams, with context at top and functional primitives at bottom

• Mini-spec for each functional primitive in one of the specification forms

• Data dictionary

• Information model showing entity and relationship types, their definitions, and definitions of their attributes