Chapter 15 Finalizing Design Specifications
Chapter 15
Finalizing Design Specifications
Chapter Objectives
Chapter 15 introduces students to several approaches for finalizing and delivering design specifications to programmers and other IT specialists, including structure charts, evolutionary prototyping, throwaway prototyping, eXtreme programming, and RAD. In the past, design specifications were primarily paper-based, completed at the end of the design phase, and then given to programmers at the beginning of the implementation phase. Newer approaches to finalizing design specifications have blurred the transition from design to implementation.
A set of design specifications for the system is the primary deliverable for the finalizing design specifications stage; these design specifications serve as blueprints for the new physical information system. Design specifications can take several forms and provide functional descriptions and detailed specifications for each part of the system. Additionally, these design specifications must provide information about the input received and the output generated by each program and its component. The authors discuss the importance of writing quality specification statements and describing quality requirements. Tables 15-1 and 15-2 summarize the characteristics of quality requirements statements and quality requirements.
In the “Traditional Method” section, the authors show that design specifications are often very detailed. As a case in point, you may want to focus on Figure 15-2. Requirement management tools are available to facilitate management of these design specifications. Quality Systems and Software Inc.’s DOORS Enterprise Requirements Suite is an example of a requirement management tool. In this section, the authors also explain how to prepare structure charts, related structure chart symbols, and the functions of pseudocode.
Evolutionary and throwaway prototypes are beneficial techniques for capturing and documenting design specifications. To demonstrate the effectiveness and speed of prototyping, an example from Oracle’s Designer CASE tool is presented. This example effectively illustrates the ease with which system requirements are captured and documented.
RAD and eXtreme programming are two radical methods for specifying software details. While RAD is discussed in more detail in Chapter 19, an explanation of eXtreme programming is given. Features of eXtreme programming include short cycles, uses an incremental planning approach, focuses on automated tests, and relies on an evolutionary approach to development. During eXtreme programming, Business and Development prepare “Story Cards” during the “Planning Game” phase. During the “Iteration Planning Game,” programmers prepare “Task Cards.”
For Internet-based electronic commerce applications, throwaway and evolutionary prototypes are beneficial. The chapter’s last section demonstrates this concept. In the PVF WebStore running case, Jim uses a throwaway prototype to demonstrate the “look and feel” of the WebStore’s web pages.
Instructional Objectives
Specific student learning objectives are included at the beginning of the chapter. From an instructor's point of view, the objectives of this chapter are to:
1. Discuss the importance of design specifications.
2. Teach students guidelines for good design and have them explain their purpose.
3. Discuss and differentiate between quality requirement statements and quality of requirements.
4. Discuss the contents of design specifications.
5. Discuss the various forms a design specification can take.
6. Discuss the benefits of requirement management tools.
7. Introduce students to structure charts and have them learn more about structure charts and their organization by drawing them.
8. Have students turn a data flow diagram into a structure chart.
9. Show students how to refine an initial structure chart into a more detailed design.
10. Discuss the functions of pseudocode.
11. Demonstrate the ability of CASE tools to quickly generate working prototypes.
12. Discuss the advantages of eXtreme programming.
13. Show how evolutionary and throwaway prototypes are beneficial when finalizing design specifications for Internet-based electronic commerce applications.
Classroom Ideas
1. Using Tables 15-1 and 15-2 as a guide, have your students prepare a set of requirements statements for a fictitious system. You can use Pine Valley Furniture’s WebStore, a hotel registration system, or a hospital’s admitting system as examples.
2. Figures 15-4 through 15-6 introduce students to structure charts. Work several examples in class, showing how you can use DFDs to prepare structure charts.
3. Use a CASE tool in class to demonstrate the creation of structure charts.
4. Provide students with a structure chart that ignores several guidelines for good system design. Have them identify bad design choices and create a modified chart that takes good design principles into account.
5. Ask students to investigate requirement management tools. During a subsequent class period, ask your students to share their findings with the class. For instance, what features does the requirements management tool provide?
6. If you have access to a CASE tool, demonstrate how to generate a working prototype. You may want to use the textbook’s example.
7. If you have access to a computer lab and Oracle’s Designer, have each student work through the Oracle Designer example from the chapter. Next, have your students prepare working prototypes for either a situation that you provide to them or prepare a working prototype for their current class project.
8. Have your students identify organizations that are using eXtreme programming. Ask your students to present their findings to the class.
9. Have students write pseudocode for each of the modules contained in one or more structure charts in the chapter (see Problems and Exercises 3 and 4). Have your students compare each others’ representations, either by forming teams or by having students place their work on the board for the class to see.
10. Ask your students to discuss or prepare student essays on one or more of the following areas: How do CASE tools enforce good design guidelines in systems design? How might CASE tools interfere with creativity in design? On balance, are CASE tools helpful or hurtful in the design process? Why?
Answers to Key Terms
Suggested answers are provided below. These answers are presented top-down, left to right.
5. Structure chart / 1. Data couple3. Module / 4. Pseudocode
2. Flag
Answers to Review Questions
1. Design specifications provide functional descriptions of each part of the new system. The design specifications provide information about the input received and the output generated for each program and its component parts. Table 15-3 provides an outline for a design specification document. The design specification document has sections that contain information about the overall system description, interface requirements, system features, nonfunctional requirements, other requirements, and supporting diagrams and models. The design specification serves as a blueprint for the new physical information system. It also helps you transition from logical design to physical design. Programmers use the information contained in the design specifications to code and test the new system.
2. Table 15-1 summarizes the characteristics of quality requirement statements. Quality requirement statements are correct, feasible, necessary, prioritized, unambiguous, and verifiable. Table 15-2 summarizes the characteristics of quality requirements. Quality requirements are complete, consistent, modifiable, and traceable. A requirement identifies a feature or function of the new system. A requirements statement describes the requirement.
3. Requirement management tools help you gather, manage, and track user requirements through the systems development process. Requirement management tools enable the sharing of requirements information among interested parties and also provide features that facilitate the activities performed by those individuals involved with the project. Information about requirement management tools is available on the Web. Encourage your students to visit a requirement management tool vendor’s Web site to obtain more information.
4. A structure chart provides the general, overall organization of an information system for the physical design process. It illustrates what all of the system’s modules are, how they are related to each other, and the data and other parameters they pass back and forth. In addition to providing such an overview, structure charts help analysts determine how to logically package systems into smaller pieces that can be further developed by teams of programmers.
5. A data couple is a diagrammatic representation of the data exchanged between two modules in a structure chart. A flag represents information the system needs for processing, such as a message indicating the end of the file or that a value is out of range, but the information itself is never processed.
6. Figure 15-5 identifies seven basic symbols; these are rectangles, data couples, flags, conditional calls, repetitive calls, predefined modules, and embedded modules. A rectangle represents a module; a descriptive name, describing the module’s function, is placed inside the rectangle. A hollow circle with an arrow coming out represents a data couple, and a darkened circle with an arrow coming out represents a flag. In both instances, the arrow indicates the direction of travel. Condition calls are represented by diamonds, indicating which subordinate module is called. Repetitive calls are indicated by a curved line drawn through the arrows connecting the subordinate modules to its boss module. A predefined module has vertical bars drawn down its sides. A predefined module indicates that the function already exists as part of the system. A “hat” connects an embedded module to its superior module. Although an embedded module appears separately on the structure chart, its code will be part of the superior module.
7. Pseudocode is a method for representing the instructions in a module with language very similar to computer programming code. According to the textbook, pseudocode helps an analyst think in a structured way about the task a module is designed to perform and acts as a communication tool between the analyst and the programmer.
8. An evolutionary prototype serves as the basis for the new system. In contrast, a throwaway prototype is used as a reference for the construction of the system, but is discarded after it is used.
9. If your students have access to Oracle’s Designer CASE tool, ask them to work through the example provided in the chapter. Then, ask your students to describe their experience with Oracle’s Designer CASE tool. This exercise is a great way to demonstrate how valuable CASE tools are. An overview of the steps includes transforming the ERD into database design elements, creating a server model diagram, generating physical database tables, running DDL scripts to create the database tables on the server, transforming a functional hierarchy diagram into a set of software modules, creating module diagrams, and generating, saving, compiling, and running forms and reports.
10. Design specifications are captured on Story Cards, refined on Task Cards, and captured in the programming code of the new system.
11. RAD emphasizes speed, so the requirements are often not formally represented. Requirements are captured during JAD sessions, and CASE tools are used to create prototypes.
12. Throwaway and evolutionary prototypes are especially useful for capturing design requirements for Web-based information systems.
Answers to Problems and Exercises
1. You should consider assigning this exercise as a group activity. Since several of the activities listed in the outline may be unclear to some of your students, you should preview this outline in class before assigning this activity. You should ask your students to submit related diagrams, such as a structure chart, with their outline.
2. A suggested answer is provided below.
Hoosier Burger’s Inventory Control System
Structure Chart
A = CountsB = Request
C = Invoice
D = Minimum order quantity / E = New quantity
F = Item No.
G = Inventory level
H = Payment / I = Formatted query results
J = Order
3. Sample pieces of pseudocode for the update inventory added and generate payment modules are provided below. Stress to your students that each student has his own version of pseudocode. Your students’ answers should be logical and understandable, but not necessarily perfect. Also, your students may need to make several assumptions; ask your students to provide any assumptions to you that they make.
Update Inventory Added
Sample Pseudocode
Begin
PERFORM READ-INVOICE
PERFORM READ-PRODUCT
UNTIL InvNo = ProdNo
Or EOF
IF InvNo = ProdNo
PERFORM Update-Inv
Else DISPLAY “No Matching Product Found”
STOP
Update-Inv
Compute NProdQ = CProdQ + UQuantity
Move NProdQ to CProdQ of ProductR
Rewrite ProductR
Generate Payment
Sample Pseudocode
Generate Payment
PERFORM Read-Vendor
IF CurrentBalance > 0
PERFORM Prepare-Check
4. Sample pseudocode for this exercise’s scenario is provided below.
Payroll System
Sample Pseudocode
Begin
PERFORM Hours-Check
UNTIL EOF
STOP
Hours-Check
READ EMPLOYEE
IF HrsWorked > 40
THEN PERFORM Overtime-Calc
ELSE PERFORM Regular-Pay
IF HrsWorked <= 70
THEN PERFORM Print-Check
ELSE DISPLAY “Excessive Hours”
Overtime-Calc
IF HrsWorked > 70
PERFORM Flg-Routine
ELSE
COMPUTE OvertimeHrs = HrsWorked - 40
COMPUTE AddIncome = OvertimeHrs * (BaseSalaryRate * 1.5)
COMPUTE CurrentPay = (BaseSalaryRate * 40) + AddIncome
5. This is a great exercise to assign along with Problem and Exercise 6. If you prefer using entity relationship diagrams that are available in the textbook, Figures 10-17, 10-18, 10-20, 10-21, and 10-23 are good entity relationship diagrams to use for this exercise. Figures 10-21 and 10-23 are associated with Chapter 10’s Problems and Exercises 8 and 15 respectively. However, students do not need to have previously worked these exercises in order to use the diagrams. An interesting approach to this exercise is to use Figure 10-20, since this figure is associated with Pine Valley Furniture’s WebStore. The entity relationship diagram is simple and not as complex as several of the other recommended figures.
6. As mentioned above, this is a great exercise to assign in conjunction with the previous Problem and Exercise. If you prefer to use data flow diagrams or functional hierarchy diagrams from the textbook, Chapter 8 provides several examples. As mentioned previously, Pine Valley’s WebStore is a good example to use. The data flow diagram associated with Pine Valley’s WebStore is located in Figure 8-25; this figure is also replicated in Figure 10-19.
Guidelines for Using the Field Exercises
1. The nature of the finalization of design process in which the analysts are involved varies depending on the size of organization and the nature of the systems projects. For example, analysts that work on fairly large, complex systems involving database processing and management are likely to follow procedures much like those described in this and other chapters. If the analysts work for relatively smaller organizations and/or they work on relatively small, simple systems, then they might not employ all of the procedures discussed in the text. For example, if the analyst is involved in primarily providing PCs for employees for their personal work and connecting the PCs on a local area network for fairly routine office automation tasks, then he probably does not use structure charts or pseudocode, as much as would an analyst working on, say, a purchasing fulfillment system or an inventory control system for a relatively large organization.