CPSC 333 --- Lecture 13 --- Monday, February 5, 1996 Later Steps in Requirements Analysis Additional things that must be done before we're ready to spend much time on "design:" - Develop and model the system interface - Produce a human-computer interface to be used for communication with (terminators that represent) human beings. You will need to - Develop "forms" corresponding to any paper input and output. - Develop display screens that will be used to receive and display information using a terminal or monitor, keyboard, and (perhaps) mouse and other I/O devices - For communication with other systems, identify the interfaces that were agreed to during "systems analysis" --- or the *standards* that are to be adhered to. Interface development is beyond the scope of this course. See CPSC 481 for more information about this topic. - Identify Important Performance and Other Non-Functional Requirements These include such things as necessary bounds on a system's response times for various requests (and these can be *quite* important for certain types of systems), upper bounds on the size of data tables, on the size of reports to be generated, etc. More information about performance requirements, and how the specification of functional requirements (ERD, DFDs, data dictionary) can be used to determine *what* requirements to ask about, can be found in M. Page-Jones The Practical Guide to Structured Systems Design Prentice-Hall (Yourdon Press Computing Series), 1988 Section 9.1: "Collecting System Statistics," pp. 184-190 ... on reserve for course Non-functional requirements can *also* include requirements relating to security, fault-tolerance, and other "non-functional" requirements that are not related to efficiency. These "nonfunctional requirements" are needed before system design can begin --- but it's easier to ask about them after essential "functional" requirements have been identified. Some additional information about these non-functional requirements can be found in the chapter on "Software Quality Assurance" in Pressman's "Software Engineering: A Practitioner's Approach" (Note, in particular, the discussion of "software quality factors) --- and, in CPSC 451. - Begin design of tests The specification can be used to design "black box" tests, that will be used to check for errors in an implemented system later on. Testing will be covered later in the course. - Produce a (draft) user manual, or man page --- Much of the information this should include has already been identified and included in the requirements specification. Producing user documentation this early on provides another way to check that the requirements specifications is sufficiently "complete." Once again, let's consider version two of the "Student Information System." A set of data flow diagrams, along with a data dictionary and process specifications for this, corresponding to the "functional requirements" for this system has already been made available. Performance requirements related to this system could include specifications of *volumes of data* that the system should be required to support. For example, we might specify (maximum) numbers of instances of each entity, and so on, in the ERD --- corresponding to number of rows in data tables --- that the system should be required to support. We will "require" that the system should be able support information about at least five thousand students, and one hundred courses, at a time. If bounds on lengths of any attributes haven't been determined already, then (if possible) maximal lengths that the system should be able to support should be determined at this time, as well. Minimal acceptable response times for operations could be specified at this point, too. We will be "generous" and say that response time is not an issue (because this is becoming more complicated than necessary as it is). We will also be unrealistic, and allow access of the program to anyone who has access to the computer on which it is run, so that no "login" and "password" system needs to be supported. We'll also be unrealistic about the amount of memory the program is allowed to use: In particular, we'll pretend that the system can keep its entire "data base" in main memory at once. See CPSC 461 and 471 for information that would be helpful if we were trying to meet more realistic memory requirements. We will use a very simple, menu-based interface for this system. Part of this will be specified below. * Note: This is *not* supposed to be an example of a "good" * * interface! In particular, it isn't something you should emulate * * outside of this course! Human interface design is studied in * * the course CPSC 481, and is not a part of CPSC 333. * * * * The process used here (essentially, picking an interface "out of * * the air" to make development simple is also *not* a good way to * * develop an interface. Instead, system users should be consulted * * and *participate in* interface development. Again, see CPSC 481 * * for more information. * When the system is activated, it begins by looking for and reading a text file (with previous student, course, and registration information), in order to initialize various data structures. We'll pretend that it looks for a system with name "SIS_data" in the same directory in which it resides. If this isn't found, then the system displays the message "Student Information was not found. Would you like me to create a new, empty, data base? Please answer Y for yes, or N for no. Selection (Y or N): __ " If "Y" is returned, then a new file will be created, and the regular "main menu" (given below) is displayed. If a "N" is received, then a message explaining that the system data should be named (and located) as described above, is displayed, and the system terminates. If some other command is entered, then a message explaining that the command was understood (and that "Y" or "N" should be entered, or possibly "Q" to quit) should be displayed, along with another prompt for a command. If the file is found, but is not readable and/or not writable, then a short error message is displayed to explain this problem. This ends with the request, "Press return to exit." Once a "return" has been detected, the system terminates. If the file is found and is both readable and writable, but it isn't in the expected format, then an exchange similar to the first one described occurs. This time, the system offers to replace the file with an empty one (or to make no changes if the user answers "N"). Finally, if the file is found *and* is readable, then the following message appears while data structures are initialized... Reading in student data. Please wait. (and, if we were dealing with a more complicated system, with a more helpful interace, some sort of *progress indicator* would be displayed). Once initialization is completed the main menu is displayed: Student Information System Please choose one of the following commands, or type "?" to read information about them. 1) Access or Modify Student Information 2) Access or Modify Course Information 3) Access of Modify Registration Information Q) Quit Selection (1, 2, 3, ? or Q): __ If "1" is selected after the main menu is displayed, then the following menu is displayed. Access or Modify Student Information Please choose one of the following commands, or type "?" to read information about them. 1) Enter a New Student 2) See Information about a Student 3) Return to Main Menu Q) Quit Selection (1, 2, 3, ? or Q): If "1" is selected at this point, then the user is prompted for each of the following. After each prompt, the syntax of the user's input is checked. If the input is semantically incorrect then a polite error message, describing the expected format of the input, is displayed. This probably ends with something like, "Press return to enter a new input, or M followed by return to return to the previous menu." - ISBN number. The system will also check that the ISBN number isn't in use (and will reject it if it is). - Student's name After this, the user's input will be displayed, along with the choices to accept the input, edit the input, or go back to the previous menu without making any change. If "2" is selected, then in a similar way, the user is asked to enter an ISBN number, followed again by a name. This time, the ISBN number will be rejected if it *doesn't* correspond to an existing record. If "3" is selected then the main menu is displayed again. If "?" is selected then a brief message, explaining the effects of the first three commands, is displayed (followed by, "Press return to see menu again"). If "Q" is selected then "system shutdown," as explained below, begins. If anything else is selected then a polite error message is displayed, ending with "press return to see menu again." If "2" is selected after seeing the main menu, then the following menu is displayed. Access or Modify Course Information Please choose one of the following commands, or type "?" to read information about them. 1) Enter a New Course 2) Change Course Information 3) Delete a Course 4) See Information about a Course 5) Return to Main Menu Q) Quit Selection (1 - 5, ? or Q): __ Selections between 1 and 4 will lead to a series of prompts for inputs, validation of inputs (with error messages, etc., similar to the ones already described). Selection of "5" results in display of the main menu, "?" displays a short help screen, "Q" causes system shutdown, and anything else leads to an error message and redisplay of the above menu. If "3" is selected after seeing the main menu, then the following menu is displayed. Access or Modify Registration Information Please choose one of the following commands, or type "?" to read information about them. 1) Register a Student in a Course 2) Remove a Registered Student from a Course 3) Pass a Student in a Course 4) Return to Main Menu Q) Quit Selection (1-4, ? or Q): __ You should already have a reasonable idea of the effects each possible selection by a user, at this point (except for "system shutdown"). Once "Quit" has been selected, the system's data is written back to the file that was accessed to start things off. A short message is displayed while this happens, and the system quits once this "write" is complete. If the "write" fails (possibly, for example, because the disk is full) then an error message is displayed and the user is asked whether (s)he would like to quit without making changes, or return to main menu. Presumably, the user can go into another window, suspend the process, etc., and then make room for student data, at this point, before trying again to write the new information and quit. It is *also* necessary at this point to specify - an acceptable format for the *file* that is read in order to start things off, and written to on system termination - Formats for all outputs back to the user. As well as display on a computer screen, it would be reasonable (at least) to allow the user to store any output to a file, and the format of such a file should be specified, too. Quite a few changes will be made to the system's DFDs (and data dictionary and process specification) in order to incorporate these additional requirements. Another set of data flow diagrams, etc., that includes these for version two of the Student Information System, will be made available if (and, as soon as) possible. Moving Toward Design We're now skipping past later requirements analysis activities that are beyond the scope of the course, such as described above, as well as - specification of necessary "startup" and "shutdown" activities - "system packaging" --- including splitting the system into subsystems that may be used at different times by different (groups of) users Some of these activities will produce changes in the data flow diagrams (and, perhaps, ERD) you've produced for the system: - additional processes supporting the human computer interface will probably be added, and the specification for some existing processes may also be developed in more detail - processes for startup and shutdown activities may be added - additional data flows may be added as well - if it's necessary to split the system into several subsystems (used at different times and/or different users) then the the data flow diagrams might be "split up" in order to produce sets of diagrams for the separate subsystems --- typically with each bottom level process allocated to one of the subsystems (or, if necessary, to several of them) - it may be possible to purchase (and, perhaps, make modifications to) a commercial system instead of building the system (or, a large part of it) "from scratch." This may be another reason to "split off" part of the DFDs --- and, perhaps, to replace part of them by a terminator ... so, you'll probably find that data flow diagrams used in later examples look a bit different than the ones we've been developing so far. We'll now move to the next major development activity --- software design. Introduction to Software Design References: Pressman's "Beginner's Guide:" Chapter 4 ("Designing the Solution") Pressman's Practitioner's Guide: Chapter 10: Software Design Fundamentals Chapter 11: Data Flow Oriented Design For more information about "structured design," see also M. Page-Jones, "The Practical Guide to Structured Systems Design," Yourdon Press (a division of Prentice Hall), 1988 QA 76.9 S88 P34 --- on reserve in library --- Note, in particular, the material in Chapters 3--7 At this point, we want to use the requirements specification in order to produce a model or representation that can easily be implemented using a programming language ("coded"). Software Design is frequently broken into two major steps; in this course, I'll spending most of my time (on software design) on the first of these. 1) Architectural Design --- the requirements specification is used to produce a software architecture. If the system is to be implemented using a high-level procedural language like Pascal or (arguably, C) then this would include identification of a set of *modules* (corresponding to functions and procedures in Pascal, and procedures in C) and data areas; a control hierarchy for these modules; and clearly defined interfaces between modules (and for data areas) and specifications or the requirements for each module. 2) Detailed Design --- an algorithm is chosen for each module in the system; a data structure (and algorithms used to access it) is chosen for each data area. At the end of "Detailed Design" you should have produced pseudocode for each module in the system and each part of the interface for each data area. Therefore the "implementation" or "coding" process should be *very* straightforward --- almost mechanical --- as it should "almost only" involve translating pseudocode into readable, well structured, source code in a high level programming language. Some Software Design Principles: - The software design should clearly be consistent with the requirements specification --- though it will "refine" this specification by adding additional detail For example, the "structured design" process we'll study will map bottom level processes in the system's data flow diagrams to modules or sets of modules in the software design, and it will map data stores in the DFDs to data areas in the design. - A design should be *modular*: That is, the software should be logically partitioned into components that perform specific functions and subfunctions - A design should contain *distinct* and *separable* representations of data and procedure. - A design should lead to *interfaces* that reduce the complexity of connections between modules and with the external environment. We'll come back to these later on, after a design method has been discussed, in order to check that the method follows these principles.