1 Modern Systems Analysis and Design Hoffer, George & Valacich Chapter 13 Finalizing Design Specifications Course: Physical System Design and Implementation ITBIS395

2 Learning Objectives Discuss the need for system design specifications Define quality requirements and write quality requirements statements Read and understand a structure chart Distinguish between evolutionary and throwaway prototyping Explain the role of CASE tools in capturing design specifications

3 Where do we stand ?

4 Introduction Need for systems to be developed more quickly today The lines between analysis and design and design and implementation are blurring  Traditional approaches allowed for a break between design and implementation  Recent approaches, such as CASE and prototyping, in addition to new system development methodologies have caused overlap between the two phases

5 Finalizing Design Specifications Is the process of transforming all information reached to at this stage (input, output, interface, dialog and database) into a set of final and complete design specifications document, also known as software requirement specification.

6 The Process of Finalizing design specification It is much easier and much cheaper, to detect and correct errors at this point than it is to detect and correct errors during implementation. There are several guidelines you can follow to help you in your conversion from logical to physical design.

7 The Process of Finalizing Design Specifications Two sets of guidelines in conversion from logical to physical:  Writing quality specification statements (six characteristics)  The quality of the specifications themselves (four characteristics)

8 Characteristics of Quality specification Statements 1- Correct: 1- Correct: should accurately describe the functionality to be developed 2- Feasible: 2- Feasible: must be possible based on the environment and the system 3- Necessary: 3- Necessary: must be something the users really need 4- Prioritized: 4- Prioritized: should be assigned a priority rating, which reflects its importance 5- Unambiguous: 5- Unambiguous: should be clear with only one way to interpret each statement 6- Verifiable: 6- Verifiable: should be possible to determine if it has been successfully implemented

9 Characteristics of Quality Requirements 1- Complete: 1- Complete: should not miss any key description information. 2- Consistent: 2- Consistent: Do not conflict with other requirements specified for the system. 3- Modifiable: 3- Modifiable: A quality requirement can be altered, with a history kept of the changes that are made. Each quality requirement, then must be unambiguously labeled and kept separate from other requirement. 4- Traceable: 4- Traceable: Can be traced back to origin source

10 Example of a poorly written requirements statement for a low quality requirement. “ the product shall provide status message at regular intervals not less than every 60 seconds ” The statement is ambiguous. We cant tell what “the product” is, The information about timing of message is not at all clear., and The requirement itself is incomplete.

11 Here is a suggested solution: 1. Status Messages. 1.1: The Background Task Manager shall display status message in a designated area of the user interface at interval of 60 plus or minus 10 seconds. 1.2: If background processing is progressing normally, the percentage of the background task processing that has been completed shall be displayed.

12 1.3: A message shall be displayed when the background task is completed. 1.4: An error message, shall be displayed if the background task has stalled.

13 Deliverables and Outcome for Traditional Projects The Design specification include functional descriptions for each part of the system, as well as information about input received and output generated for each program and its component parts. Table 13-3 provides more detailed information on the contents of a design specification.

14

15 Specification Documents Information systems are extremely complicated things, especially in today’s and Internet oriented environment. Fig (13-2) give an example of just how much information needs to be provided in a specification documentation, examine the partial list of information required for such document for the government of the state Maryland.

16

17

18 Traditional Methods For Representing Design Specification Several methods for streamlining(التبسيط) 1.Computer-based requirements tools (Fig 13-3). -Make it easier for analysts to keep requirements documents up-to date. -Add additional information about specification. -Define links between different parts of the overall specification package. 2. Prototyping 3. Visual development environment

19

20 Structure Charts For Representing Design Specification 1. Hierarchical diagram shows how an information system is organized in hierarchical models. 2. Shows how parts of a system are related to one another. 3. Shows breakdown of a system written in third and fourth generation languages. 4. Refines the data and processing of DFDs into a “good programming” design structure

21 Structure Charts Notations Module (method) Module (method)  Small unit of a system that is defined by its function.  One single coordinating module at the root of structure chart  Modules in the middle may call additional modules below  Mostly, a module has a single point of entry and exit.  Modules at the lowest levels do not call any other modules, they only perform specific task. Main menu Main menu opts Additional modules

22 Structure Charts Notations Communicate with each other by passing parameters Data couple: Data couple: A diagrammatic representation of the data exchanged between two modules in a structure chart Flag: Flag: A diagrammatic representation of a control or message passed between two modules Flag Data Couple

23 Structure Charts Notations Special Module Symbols: Diamond: Diamond: Only one subordinate will be called (conditional/selection) Curved Line: Curved Line: Subordinates are called repeatedly until terminating condition is met (looping)

24 Structure Charts Notations Predefined modules: Predefined modules: its function is dictated by a preexisting part of the system (e.g. OS functionality) Hat: Hat: Subordinate module is important logically but code is contained in superior module (code block)

25 1. The system module first calls the Get Valid A module. 2. Get valid A first calls the module Read A, which executes its function and returns the data couple A to its coordinating module (boss module). 3. A is then passed to validate A, which returns the data couple Valid A. 4. Control is returned to get valid A, which then returns the data couple Valid A and control to the boss module. 5. A similar set of steps occurs in connection with the data couple Valid B. 6. Next valid A and valid B are passed to make C, which returns the data couple C and control to the system module. 7. Finally, the system module calls put C and pass C to the module.

26 Structure Charts and Pseudocode Pseudocode: Pseudocode: Method used for representing the instructions inside a module (description), very similar to computer programming code. Has 2 functions: 1. Helps analyst think in a structured way about the task a module is designed to perform 2. Acts as a communication tool between analyst and programmer

27 Example of Pseudocode while not at end of list compare adjacent elements if second is greater than first switch them get next two elements if elements were switched repeat for entire list

28 Prototyping Construction of the model of a system Allows developers and users to  Test aspects of the overall design  Check for functionality and usability Iterative process Two types  Evolutionary Prototyping  Throwaway Prototyping

29 Evolutionary Prototyping Begin by modeling parts of the target system If successful, evolve rest of the system from the prototype Prototype becomes actual production system Often, difficult parts of the system are prototyped first Prototyping usually lacks support for security, networking and scalability Exception handling must be added to prototype, exceptions are 90% of system function

30 Throwaway Prototyping Prototype is not preserved Developed quickly to demonstrate unclear aspect of system design Fast, easy to use development environment aids this approach Best developed with the aid of CASE tools or Automated Development

31 Rapid Appln Development (RAD) Has Four life cycle phases: 1. Planning 2. Design 3. Construction 4. Cutover

32 Agile Methodologies Requirements  functional design  code  Test Design specifications come from code instead of verbal text descriptions Example: eXtreme Programming’s Planning Game  Two techniques:  Simple design: uncomplicated program component to solve current (not anticipated) problem  Refactoring: make a program simpler after adding a new feature