CS 220 Project System Analysis Remember to submit

CS 220 Project System Analysis Remember to submit your system proposal Project Supervisor: Timothy Au Email: timothykfau@yahoo. com URL: www. geocities. com/timothykfau/pj available now 1

System Development Life Cycle 1. Problem Definition / Project Initiation 2. Requirement Study 3. System Analysis 4. System Design 5. System Development, Implementation & Deployment 6. Testing and Maintenance 7. Post Implementation Review and Evaluation 2

Documentation System Analysis Report l l l 1. 2. Cover letter Cover page and/or title page of the project Confidentiality, Distribution Control, Revision History Table of contents Executive summary Introduction Fact Finding (15 marks) l l 3. Description of the current system (25 marks) l l l 4. Justification of fact finding techniques used (5 marks) Completeness and quality of fact-finding and analysis of information gathered (10 marks) Narrative (5 marks) Illustrations supporting narrative (5 marks) Process flow (5 marks) Problem and limitations of current system (5 marks) Scope and constraints (5 marks) Requirement Specification of new system (10 marks) 3

Documentation Cover letter, memo or email: l As a formal business communication and a documentation completeness. Cover page l It may contain the following items: l l l l Document Name Document ID / Product ID / Inventory ID Status e. g. Draft, First Release, Review Version 1. 0 (first level - critical or major changes, second level – minor changes, third level or alphabet - slight changes) Company Name, Project, Team, Author Copyright Date Issued 4

Documentation Confidentiality l Top Secret, Internal, Business Confidential Distribution Control l List the name of the official distribution of the document Revision History l l Modified Date Version / Revision Modified By Changes / Remarks 5

Documentation Table of Contents: l List the contents of the main document and the appendices. It is mentioned in the student manual that this is a required item, without a table of contents should have a 5% deduction in the total marks awarded to be submitted. 6

Documentation Executive Summary: l l A summary of all pages to appear in the rest of the document for managers in one A 4 page. For the final documentation, an executive summary should be: l l completed at the end of the development, and consists of the entire development effort for management purposes. approx. 1000 words (2 to 3 pages). 7

Documentation Introduction: l l l A broad introduction pertaining to the relevance, initiation of the project, brief description of the organization in question. A brief description of the company background What kind(s) of business your customer is doing? What products and services it provides? What challenge the company is facing? 8

Documentation Fact Finding (25 marks) : l l Justification of fact finding techniques used (5 marks) Completeness and quality of fact-finding and analysis of information gathered (10 marks) 9

Documentation Description of the current system (25 marks): l l l Narrative (5 marks) Illustrations supporting narrative (5 marks) Process flow (5 marks) Problem and limitations of current system (5 marks) Scope and constraints (5 marks) 10

Tools and Techniques Requirement: l UML l l l Use Case Sequence Diagram Structured Analysis l Fact Finding 11

Fact-finding Overview During requirement modeling, you will use various fact-finding techniques, including: interviews, documentation review, observation, questionnaires, sampling and research. 12

Fact-finding Overview The first step is to identify the information you need. You begin by asking a series of questions such as: 1. What business functions are supported by the current system? 2. What strategic objectives and business requirements must be supported by the current system? 3. What transaction will the system process? 4. What information do users and managers need from the system? 5. Must the new system interface with legacy systems? 6. What security issues exist? 7. What risks are acceptable? 8. What budget and timetable constraints will affect system development? 13

Who, what, when, where and how? Fact-finding involves answers to FIVE familiar questions: who, what, when, where, and how. For each of those questions, you must also ask another very important question: Why. Some examples are: Who? Who performs each of the procedure within the system? Why? What is being done? What procedure must be followed? Why is the process necessary? Where are operations being performed? Why? Where could they be performed? When is a procedure performed? Why is it performed in that time? How is a procedure performed? Why is it performed in that manner? 14

Fact-finding Techniques Interview. It consists of the following steps: 1. Determine the people to interview; 2. Establish objectives for the interview; 3. Develop interview questions; 4. Prepare for the interview; 5. Conduct the interview; 6. Document the interview; 7. Evaluate the interview. 15

Fact-finding Techniques Document Review. To understand how the current system is supposed to work Documentation may [is] sometimes [usually] out of date. Obtain sample forms and operating documents currently in use. Review blank form and samples actual completed forms. If it is a software package, you should review the documentation of the software package. 16

Fact-finding Techniques Background reading. l Organizational chart; l Administrative procedure; l Job description; l Training manual and relevant memorandum; l Sales literature. 17

Fact-finding Techniques Observation. To see the current system in action gives you additional perspective and a better understanding of the system procedures. Personal observation also allows you to verify statements made in interviews and determine whether procedures really operate as they are described. Observation can provide knowledge needed to test or install future changes. Observation can help building relationship with the users who will work with the new system. Hawthrone effect. Researcher concluded that productivity seemed to improve whenever workers knew they were being observed. 18

Fact-finding Techniques Questionnaires and surveys. When it is desirable to obtain input from a large number of people, a questionnaire can be a valuable tool. A questionnaire is a document containing a number of standard questions that can be sent to many individuals. Questionnaires are used to obtain information about workloads, report received, volume of transactions handled, types of job duties, difficulties and opinion of how the job could be performed better. 19

Fact-finding Techniques Sampling. When studying an information system, you should collect example of actual documents using a process called sampling. The samples might include records, reports, operation logs, data entry documents, complaint summaries, work requests and various types of forms. Sampling technique includes: Systematic sampling; Stratified sampling; and Random sampling. 20

Fact-finding Techniques Research can include reviewing journals, periodicals and books to obtain background information, technical material and news about the industrial trends and developments. The Internet is an extremely valuable research tool. Web, newsgroup and email. Research also can involve site visit. 21

Documentation Keeping accurate records of interviews, facts, ideas and observation is essential to successful systems development. The need for recording the facts. As you gather information, the importance of a single item can be overlooked or complex system details may be forgotten. Write it down! You should document your work according to the following principles: Record information as soon as you obtain it; Use the simplest recording method possible; Record your finding in such a way that they can be understood by someone else; Organize your documentation such that related material located easily. 22

Tools and Techniques Analysis: l UML l l Class Diagram Interaction Diagrams l Sequence Diagram l Collaboration Diagram l l l Activity Diagram State Diagram Structured Analysis l l l Context Diagram Data Flow Diagram (Level 0 DFD) Process Specification / Structured English / Narrative / Mini-specification Structure Chart Decision Tree / Table Data Dictionary 23

Structured Analysis Tools Information Flow: Data Flow Diagram (DFD) Information Structure: Data Dictionary (DD) Function Hierarchy: l Structured Chart l Function Tree Processing Logic: l Decision Tree l Decision Table l Pseudo Code l Structured English l Nassi-Shneiderman Chart 24

Process Modeling involves graphical representation of functions or processes which capture, manipulate, store and distribute data between system and its environment and between components within a system. A common form of a process model is a data flow diagram (DFD). We will focus on data flow diagrams, the process modeling technique of structured analysis. 25

Data Flow Diagrams A data flow diagram is a network representation of a system. The system may be automated [computer], manual or mixed. The data flow diagram portrays [make a picture of] the system in terms of its components pieces, with all interfaces among the components associated. The data flow diagram shows flow of data, not of control. DFD portrays a situation from the point of view of the data. Loops and decisions are control considerations that do not appear in DFDs. So, you can’t tell from DFD which path will be followed. You can’t tell what initiates a given process. The prompting and timing of information does not show on DFDs. 26

Data Flow Diagrams ~ An important advantage of DFDs: l “When a Data Flow Diagram is wrong, it is glaringly [ obviously, clearly], demonstrably, indefensibly wrong. ” Other advantages of DFDs: l Leveled DFDs allow a top-down approach to system analysis. Readers can read the different levels of DFD according to their level of interest. For example, manager can read the few top level DFDs to get the big picture. Implementers and end users can read the abstract to the detailed, narrowing to the particular areas of interest. l There is not true page connectors. Each page is a complete presentation of the area of work allocated to it. l DFDs usually fit in one page (A 4 or letter size) 27

Data Flow Diagrams ~ What have we accomplished? What have we accomplished with DFDs? l To come up with a meaningful portray [picture] of the system. l Be a model of the real situation. l Results in conceptual documentation and modeling l Gives a highly useful partitioning of the system. l A partitioning may be considered as functional when the interfaces among pieces are minimized. 28

Data Flow Diagrams ~ Purpose and Objective The purpose of data flow diagrams is to provide a semantic communication medium between users and system implementers. The diagrams are: l graphical, eliminating thousands of words; l logical representations, modeling WHAT a system does, rather than physical models showing HOW it does it; l hierarchical, showing systems at any level of detail; and l jargonless, allowing user understanding and reviewing. 29

DFD characteristics ~ The inversion of viewpoints In classical analysis, l we first try to see operations from user’s point of view ie. We interview them to learn how things work. l Then we spent the rest of the time trying to find out and document the working of modified operations from the system’s point of view. The inversion of viewpoints occasioned in structured analysis is that , l we present the workings of a system as seen by the data, not as seen by the data processors or operators. l The advantages of this structured approach is that data sees the big picture while various people, machines and organization work on the data see only small portion of what happens on the system. 30

Data Flow Diagrams There are TWO versions of data flow diagram notations: l Yourdon and Coad / Tom De. Marco l Gane and Sarson Other variation of data flow diagram notations are: l Ward and Mellor l SSADM IV 31

Data Flow Diagrams ~ An example 32

Data Flow Diagrams ~ Four Basic Components A data flow diagram (DFD) shows how data moves through system. A data flow diagram is made up of FOUR basic elements: l Process which takes data as input, do something on it, and output it. l Data Flows which may either be incoming or outgoing, may be computer or manual items. l Data Stores which represents stores may be computer stores such as database and files, or manual stores such as files, cabinets and documents. l External Entities (source/sink) which are sources and destinations of data. 33

Data Flow Diagrams ~ Comparison Process Gane and Sarson Coad and Yourdon Data store Data flow External entity (source/sink) 34

Process A process is a ‘transformation’ of incoming data flows into outgoing data flows. Represented by rounded corner rectangle (bubble in Coad and Yourdon / Tom De. Marco). Each process is given a unique number within the diagram. Leveled of diagrams are shown in decimal notation. For example, the top level process 1 may contain processes 1. 1, 1. 2 and 1. 3. Should general move from top to bottom and left to right. Appears as a ‘Black box’ where the inputs, outputs and general function of the process are know; but the underlying details are not shown. A process should be given a process name which identifies the specific function and consists of verb + singular noun. Examples: Process order, Verify customer credit, Ship Order 35

Data Flows A data flow is a path (or pipeline) through which information of known composition flow from one part of the system to another. Represented by lines and arrows on one end (or both ends? ). The diagram does not show the structure and the detailed contents of a data flow. Should represents data and not control. Avoid using the words ‘data’ and ‘information’. A data flow name consists of a adjective (if needed) + singular noun. Example: customer request, acknowledgement, accepted order, processed order. 36

Data Stores A data store or file is a temporary repository of data. The physical implementation of a file is not important. It may be database, tape, disk, computer file, physical file, cabinet, document. The direction of the arrows to or from the data store is important, which shows the data moving into or out of the store A data flow moving into a data store means update. A data flow moving out from a data store means retrieve. Represented by a flat rectangle open on the right side and closed on the left side. A data store name consists of an adjective (if needed) + plural noun. Examples: inventory, customers, employees. 37

External Entities An external entity is a person or organization outside the context of the system, that is the source or destination (originator or receiver) of the system data (input or output). External entities determine the system boundaries and how the system interacts with the outside world. They are often beyond the influence of the systems analyst. External entities are called terminators because they are the origin and destination of data (a. k. a. source/sink). Represented by a box shaded to look like three-dimensional. They are usually placed around the edge or the margin of the diagram. An entity name is the singular form of the person, department, party, organization, other system or subsystem. Examples: customer, supplier, bank, accounting department, payroll system. 38

Steps for Drawing DFDs 1. Identify all net input and output data flows. 2. Work your way from inputs to outputs, backwards from outputs to inputs, or from the middle out. 3. Label all interface data flow. 4. Label all processes in terms of their inputs and outputs. 5. Ignore initialization and terminations. 6. Focus on the good transaction. Omit details of trivial error paths right now. 7. Do not show flow of control or any control information. 8. Be prepared to start over. 39

Rules for Drawing DFDs (1/4) There are TWO DFD rules that apply most of the time: A. Inputs to a process must always different from the outputs. B. Each symbols must have unique names. Process 1. No process can have only outputs (miracle). If an object has only outputs, it must be a source. 2. No process can have only inputs (black hole). If an object has only inputs, it must be a sink. 3. A process has a verb phrase label. Data Store 4. Data stores cannot be moved from one to another directly. Data must be moved by a process. 40

Rules for Drawing DFDs (2/4) Data Store (continued) 5. Data cannot move directly from outside source to a data store. Data must be moved by a process which receives data from the source and places the data into the data store. 6. Data cannot move directly to an outside sink from a data store. Data must be moved by a process. 7. A data store has a [plural] noun phrase label. External Entity (Source/Sink) 8. Data cannot move directly from a source to a sink. It must be moved by a process if the data are of any concern of our system. Otherwise, the data flow is not shown on the DFD. 9. A source/sink has a [singular] noun phrase label. 41

Rules for Drawing DFDs (3/4) Data Flow 10. A data flow has only one direction of flow between symbols. It may flow between both directions between a process and a data store to show a read before an update. The latter is usually indicated by two separate arrows since these happen at different instances. 11. A fork in a data flow diagram represents data goes from a common location to two or more destinations (processes, data stores or sources/sinks) – this usually indicates different copies of the same data going to different locations. 12. A join in a data flow diagram means exactly the same data comes from any of two or more different source (processes, data stores or sources/sinks) to a common location. 42

Rules for Drawing DFDs (4/4) Data Flow (continued) 13. A data flow cannot go directly back to the same process it leaves. There must be at least one other process which handles the data flow, produces some other data flow, and returns to the original data flow to the beginning process. 14. A data flow to a data store means update (delete or change). 15. A data flow from a data store means retrieve or use. 16. A data flow has a noun phrase label. More than one data flow noun phrase can appear on a single arrow as long as all of the flows on the same arrow move together. 43

Leveled DFDs When a system is too large for its DFD to be shown on a single page, we must do an initial partitioning into subsystems. If the subsystems are still too large, we will divide them into sub-subsystems. And so on. Eventually, we will arrive at subsystems with components that can be portrayed with simple, understandable and manageable DFDs with primitive functions. This is called top-down analysis – which is the concept of leveling data flow diagrams. 44

Leveling Conventions At the top of the hierarchy of a leveled set is the Context Diagram. It is the ‘parent’ of the first-level breakdown diagram. The diagram is , in turn, the parent of its child diagrams, which make up level 2. There a many level 2 diagrams. And so on. 45

Functional Decomposition Functional decomposition is: l a repetitive process l going from one system to many decomposed subsystem with component processes l until the lowest level called the primitive DFD*. * see later slide on Primitive DFD. 46

Data Flow Diagrams The lump law: “If we want to learn anything, you mustn’t try to learn everything. ” At least not at the beginning. 47

Context Diagram A data flow diagram of the scope of the organizational system show the system boundaries, external entities that interacts with the system and the major information flows between the entities and the system. The context diagram is a ‘de-partitioned’ version of the top-level breakdown of Diagram 0 – it shows only the net inputs and outputs. Drawing the context diagram servers one purpose – it is to define or outline the domain of the study formally. 48

Level 0 Diagram A data flow diagram that represents the major processes, data flows and data stores of the system at a high level of details. 49

Level-N Diagrams Level-N diagrams: l A DFD that is the result of the n-nested decompositions l of a series of subsystem l from a process on level 0 diagrams. 50

Balancing DFDs Data flows into and out of a process on parent DFD are equivalent to net inputs and outputs to and from a child diagram. This equivalence is called balancing. All data flows shown entering a child diagram must be represented on the parent by the same data flow into the associated process. Outputs from the child diagram must be the same outputs from the associated process on the parent (with one exception of the reject path). That is, when decomposing a DFD, you must preserve inputs to and outputs from a process at the next level of decomposition. 51

Types of DFD In SSADM, the DFDs are used in THREE stages of the system development process: l Current Physical DFDs. These record the result of the conventional fact findings. l Current Logical DFDs. These describe the logical information processing of the current system. l Required Logical DFDs. These show the logical information processing requirements of the proposed system. 52

Logical and Physical Models While structured analysis tools are used to develop a logical model for a new information system. Such tools can also be used to develop physical model for an information system. A physical model shows HOW the system requirements are implemented. During the system design phase, you create physical model of the new system that follows from the logical model and involves operational tasks and techniques. Logical model describes WHAT the system does. Physical model describes HOW the system does. Current system refers to as ‘as is’ system. Required system refers to as ‘to be’ system. 53

Guidelines for Drawing DFDs We will consider some guidelines for drawing DFDs: 1. Completeness. It refers to whether you have included in your DFDs all of the components necessary for the system you are modeling. 2. Consistency. It refers to whether the representation of the system at one level of a leveled set of DFDs in compatible with the representation at another level. 3. Timing Consideration. There is no indication of the period of the data flow occurs, whether it is real time or batch processing. [State-Transition Diagram] 4. The iterative nature of drawing DFDs. The first-cut DFD you draw will sparingly perfectly capture the system you are modeling. You should continue on drawing the same diagram over and over again to get the closest approximation of the system you are modeling. System modeling is an iterative process. 54

Guidelines for Drawing DFDs 5. Primitive DFDs. One of the most difficult decision you need to make when drawing DFDs is when to stop functional decomposition. One simple rule is to stop drawing when you have reached the lowest logical level. When you have reduced each process to a single decision or calculation or to a single database operation such as create, retrieve, update. When each data store represents data about a single entity, such as customer, employee and product or order. When the system user does not care to see any more details or when you have documented sufficient detail to so subsequent system development tasks. When you believe that you have shown each business form or transaction, computer display and report as a single data flow. When you think there is a separate process for each choice on all lowest level menu options for the system. 55

Bottom level consideration How do we decide where to stop partitioning – what constitutes an acceptable bottom level? How do we mark the bottom level? Since the bottom level will not further documented by decomposition, how shall we describe their contents? How do the bottom level diagrams relate to each other? 56

Determination of the Bottom level Tom De. Marco suggests three criteria for deciding when a partitioning effort has gone far enough: 1. To stop partitioning when you believe the insides of the lowest level processes can be completely described in a mini-spec about one page. 2. Some analyst try continue partitioning down to the point where the processes have single input data flow and single output data flow. You should not count the trivial error paths. You should allow some number of un-partitioned processes have more than one single entry and single exit. 3. Students and readers of Michael Jackson’s work have suggested the concept of boundary clashes may be applicable to determining the bottom level A clean One-to-one relationship. 57

Documentation of Process Since there is no further DFD description for the lowest level, you have to document them in some way other than DFD description. You have to write a narrative or Structured English, Decision Table or Decision Tree or Flowchart. These descriptions you write to document the primitive DFDs refer to as minispecs. There must be one mini-spec for each primitive DFD which is not further decomposed. Minispecs should be marked / referenced with the process numbers of the related processes. 58

Data Dictionary James Martin: “A data dictionary (DD) is a repository of data about data. ” The DD is an integral part of the structured specification, without DD, DFDs are just beautiful pictures telling something happens on a system. It is only when each and every element of the DFD has been rigorously defined that the whole constitute a specification. The set of rigorous definitions of all DFD elements is the data dictionary. 59

Correlating Data Dictionary to the DFDs Data Flow Diagrams and Data Dictionary have to be considered together. Without a DD, DFDs lack rigor; without DFDs, a DD is of no use to anyone. There is one DD entry for each unique data flow that appears anywhere in the DFD set. There is one DD entry for each file referenced on any diagram in the DFD set. There is one DD entry for each functional primitive in the DFD set. 60

Classes of elements to be defined They are the classes that describe the components of Data Flow Diagrams: l Data flow l Data store l Process l Data element l Record or Data structure l External Entity 61

Relationships of the elements of Data Dictionary A data element (data item, or field) is a special kind of data flow that cannot be further decomposed into subordinate data flow. Data elements are combined into records or data structures. A record is a meaningful combination of related data elements that is included in a data flow or retained in a data store. Chris Gane and Trish Sarson “Data flows are data structures in motion; data stores are data structure at rest” 62

Data Dictionary Operators AND EITHER OR BUT NOT BOTH IS EQUIVALENT TO OPTIONAL ITERATIONS OF CASE IF THEN ELSE DO-WHILE REPEAT UNTIL 63

Data Dictionary Notations = means IS EQUIVALENT TO + means AND [] means EITHER-OR; select one option from enclosed brackets {} means ITERATIONS OF the components enclosed in the braces () means OPTIONAL components enclosed in the parenthesis * comments * to annotate the definition with comments enclosed within a pair of asterisks. 64

Data Dictionary Documenting the Data Elements Data element name or label. Must be meaningful to users. Alternate Name or Alias. Any synonyms and aliases of the same data element. Type and length. Numeric, alphabets or character. Maximum and minimum value; maximum and minimum value number of digit, characters. Output format (or mask). The arrangement of data represented on output screen or report. For example: account number in 999 -999999 -9 or money in $99, 999, 999. 99 Default value. The value of the data element when no value is entered for it. Prompt, column heading, caption. The default display screen prompt or column heading appears on report for the data element. 65

Data Dictionary Documenting the Data Elements (continued) Source. The origination point of the data element. Security. Identification for the individual or department that has the access or update privileges for each data element Responsible users. Identification for the users responsible for entering and changing values for each data element. Acceptable values and validation. Specification of the domain (permitted set of values) of the data element and the validity rules associated with the data element. Derivation formula. If the value of the data element is the result a calculation, the formula should be specified including the significant digit and rounding operation. Description or Comments. Provide additional definitions, descriptions and notes. 66

Data Dictionary Documenting the Data Flows Data flow name or label. The name appear on the DFDs. Alternate Name or Alias. Any synonyms and aliases of the data flow names. Description. Describe the data flow and its purpose. Origin. The DFD beginning or source for the data flow; the origin can be a process, a data store or an external entity. Destination. The DFD ending for the data flow; the origin can be a process, a data store or an external entity. Record. Each data flow represents a group of data elements called a record or data structure. Volume and frequency. Describe the expected number of occurrences for the data flow per unit of time. 67

Data Dictionary Documenting the Data Stores Data store name or label. The data store name appear on the DFDs. Alternate Name or Alias. Any synonyms and aliases of the data store names. Description. Describe the data store and its purpose. Input data flows. The DFD name of the data flows coming into the data store. Output data flows. The DFD name of the data flows going out from the data store. Record. The record name in the data dictionary. Volume and frequency. Describe the estimate number of records in the data store, and the growth rate, change statistics and retention of the data store. 68

Data Dictionary Documenting the Processes Process name or label. The process name appear on the DFDs. Purpose or Description. A brief description of the process. Process Number. A reference number that identifies Input data flows. The DFD name of the data flows coming into the process. Output data flows. The DFD name of the data flows going out from the process. Process Description. For functional primitive only, this section describes the processing steps and business logic * * see next section on process modeling to learn how to write process description. 69

Data Dictionary Documenting the External Entities Entity name. The entity name appear on the DFDs. Alternate Name or Alias. Any synonyms and aliases of the entity name. Description. Describe the external entity and its purpose. Input data flows. The DFD name of the data flows coming into the external entity. Output data flows. The DFD name of the data flows going out from the external entity. 70

Data Dictionary Documenting the Records Record or data structure name. The record name appear on the DFDs anad data store entries in the DD. Alternate Name or Alias. Any synonyms and aliases of the record name. Definition or Description. A brief definition of the record. Record content or composition. A list of all data elements included in the record. The data elements must exactly match what you entered in the DD. Identify any data element that will serve as a primary key. Primary key is a data element in a record that uniquely identified a record. A primary key may consist of one data element or a combination of two or more data elements. 71

Data Dictionary Reports The data dictionary (DD) serves as a central storehouse (repository) of documentation of an information system. In addition to describing the data stores, data flows, processes, data elements, records and external entities, the DD documents the relationships of these components. A DD includes: An alphabetical list of all data elements by name; A report by user departments of data elements that must be maintained by each department; A report of all data flows and data stores that use a particular data element; A detailed report showing all characteristics of data elements, records, data flows, or any other selected item stored in the DD. 72

Processing Logic Modeling Process modeling involves representing the internal structure and functionality of the processes represented in the data flow diagrams. These process appear on DFDs are little more than ‘black boxes’ such that we can only tell the general function of the process; we cannot tell precisely what is done and how it is done. Processes must be clearly described before they can be translated into programming a language. The process modeling focus on more precise, language-like logic modeling. The course book wrote ‘A process description documents the details of a functional primitive, which represents a set of processing steps and business logic. ’ 73

Structured English is a modified form of English that is used to specify the contents of the process boxes in a DFD. Structured English is a specification language that make use of a limited vocabulary and a limited syntax. The construct of Structured English has THREE possibilities: l Sequence l Conditional or Decision Statement l Repetition 74

Structured English The vocabulary of Structured English consists only of : imperative (very important, needing) English language verbs such as SET, GET, READ, PRINT; terms defined in the data dictionary; reserved words for logic formulation such as IF. . THEN, CASE, DO WHILE, REPEAT UNTIL, FOR EACH, AND, EITHER OR. 75

Structured English An Example Reorder a Stock item FOR EACH order-request, do the following: 1. SEARCH for an inventory-list with the reference-number = the requestnumber in the order-request. 2. IF there is no match, ignore the order-request ELSE OUTPUT a purchase-order for the ordered-item. SELECT a supplier FROM the supplier-list having the ordered-item. MOVE the supplier-name and supplier-address to the purchase-order. MOVE the purchase-order-number to the orderrequest. UPDATE order-request with the inventory-list. 76

Decision Table The advantages of using decision table when the sub-policy selection depends on a combination of conditions. Steps: 1. Place a heading on the table; 2. Enter the conditions under the heading; one condition per line; 3. Enter all possible combination of Y (Yes) and N (No) for the conditions. Each column is called a rule. Mark an X in the action entries area for each rule to indicate the it is applied. 77

Decision Table An Example RULES CONDITIONS 1 2 3 4 5 6 7 8 1 Domestics Y N Y N 2 VIP Y Y N N 3 Spending Over $1000 Y Y N N Y ? N ? ACTIONS 1 Free Appetizers Y N Y 2 Free Y Y Y 78

Decision tree A decision tree is a graphical representation of the conditions, actions and rules found in a decision tables. A decision tree show the logic structure in a horizontal form that resembles a tree with the root at the left and the branches at the right. A decision tree shows conditions form left to right along various branches and the corresponding actions at the far right. 79

Tasks for last two weeks Please start group your project team, and identify roles among team members. Submit your Project Group Member List (Downloadable from the web site) Discuss and submit your Project Title and Summary for each group for approval. (Downloadable from the web site) Plan your project, schedule project meeting and breakdown tasks, distribution of work. Prepare your Project Proposal. Keep track your project and prepare a biweekly Progress Report In the next week Saturday 17 January, 2004, you will submit Project Proposal for First Review either office counter (hardcopy) OR email to me at timothykfau@yahoo. com (softcopy). The final submission Project Proposal is Saturday 31 January, 2004. The next lecture Saturday 31 January, 2004 you will learn about systems analysis. 80

Tasks for next two weeks You should arrange your team meeting. Keep track your project and prepare a biweekly Progress Report Breakdown tasks and subtasks. Requirement gathering: Fact finding - interviewing, prepare questionnaires, … Conduct analysis: DFD, Structure Chart, … Prepare your System Analysis Documentation. Remember to book your consultation sessions on First-Come-First-Serve for Saturday 7 / 14 / 21 February, 2004. You should submit your System Analysis Documentation for First Review either office counter (hardcopy) OR email to me at timothykfau@yahoo. com (softcopy) on Saturday 14 February, 2004. The final submission System Analysis Documentation is Saturday 28 February, 2004. The next lecture Saturday 28 February, 2004 you will learn about systems design. 81

Q&A Any Question? See your group on Saturday 7 / 14 / 21 February, 2004 for group consultation, please do so in advance booking through email (First-Come-First-Serve) and will confirm your group in reply. See you ALL on Saturday 28 February, 2004 for the lecture on Systems Design Note Remember to register your project at the office counter Deadline of Booking Project Demonstration (tentatively, Saturday 26 June 2004) Project Demonstration (tentatively, Saturday 3 July 2004) Deadline for submission of Final Project Documentation (tentatively, Saturday 10 July 2004) Thank you! Project Supervisor: Timothy Au Email: timothykfau@yahoo. com URL: www. geocities. com/timothykfau/pj available now 82