1 / 26

The Structured Specification

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

filia
Download Presentation

The Structured Specification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Structured Specification

  2. 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

  3. 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

  4. Components of Structured Specification • Data flow diagram (DFD) • Data dictionary • Tools to specify processes • Structured English • Decision tree/table • Information model

  5. Name(s) # Name Name Name 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)

  6. 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.

  7. Example DFDContext level Data Flow 1 0 system Data Flow 6 Sink Source Data Flow 2

  8. Example lower level DFD 2 Process Data Flow 1 Data Flow 6 Data Flow 2 Data Flow 3 Data Flow 5 1 Process Data Flow 4 Data Store

  9. Name Name Name Name DFD’s: Component Variations • File operations: • Read • Update • Add new info. • Delete info.

  10. Name Name Name 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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)

  16. 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]

  17. Data Dictionary:Graphic Forms of Composite Data Telephone Number • Sequence: • Repetition: • Selection Area Code Office Code Number Passenger List Passenger Name Customer Order Part I Part II

  18. 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*

  19. 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 rating VALUES/MEANINGS A good B acceptable C poor D bad DESCRIPTION: creditworthiness of customer...

  20. 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

  21. 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

  22. 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

  23. Structured English Example 6.4.7 PRODUCE CUSTOMER INVOICE For each customer order form, do the following: 1. Enter customer name and address on invoice 2. If customer category is “SPECIAL” 2.1 Get discount from discount file using a special indicator 2.2 Otherwise set discount to 0% 3. For each sales item on customer order form, do the following: 3.1 3.2 3.3

  24. Specification Tools:Decision Trees/Tables • Allow for deeper nesting than structured English • Separates independent conditions and shows actions resulting from different combinations A B C A B C

  25. Information Model:Entity-Relationship Diagrams • Shows relationships between stored data of a system Employee Works On Project Entity Type Relationship Type

  26. 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

More Related