Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Human Computer Interface
This material was covered during lectures on February 19, 1997.
Several kinds of ``nonfunctional'' requirements must be identified during requirements analysis. Most of these are easier to consider after ``functional requirements'' have been specified. However, we've seen that - at least for object-oriented analysis - it's necessary to make some decisions about the human-computer interface before modeling of functional requirements can be completed (in particular, it's difficult to allocate ``services'' to classes and objects, without making some decisions about the interface).
During software development, we must identify and specify the interface that our system will use for communication with the human beings that use it. This might include
Interfaces must also be chosen for communication with other systems that the system we're developing will interact with. This may involve identification of pre-existing communication ``standards'' that are to be followed.
Interface design is beyond the scope of this course. It is discussed in Computer Science 481, which you may take after passing CPSC 333.
Software engineering texts may include a small amount of information on this topic. For example, Chapter 14 of the Third Edition (and, part of Chapter 14 of the Fourth Edition) of Pressman's Software Engineering: A Practitioner's Approach includes some information about interface modeling, and some design guidelines.
Note, again, that human-computer interface design is beyond the scope of this course. The following example will be used to show how the introduction of an interface, along with startup and shutdown processes, etc., can change the models we've developed so far. It isn't supposed to be a guide that you can use when you design your own interfaces later on, and it is not complete.
At this point, we'll return to ``structured development.'' Object-oriented development will be continued, later on in the course.
Now, suppose that a simple menu-based interface will be used for Version One of the Student Information System.
The system will need to perform a startup process when it is initialized. We won't worry about what this involves until after performance requirements for the system have been identified, and some ``design'' decisions have been made. Therefore, we can't say precisely what error conditions might arise (or how they should be reported) during this initialization. However, we can say that, if all goes, well, but the time needed for system initialization might be noticeable to the user, then some sort of message, like
Initializing student data. Please wait...
might be displayed until the system is ready to receive commands from the instructor. When the system is ready, a menu like the following is displayed.
Student Information System
Please choose one of the following commands:
1: Register New Student
2: Pass Student
3: Withdraw Student
4: Display Information about a Student
5: List All Registered Students
6: List All Students Who Have Passed
7: Delete Old Information
Q: Quit
Selection (1-7, or Q): _
If ``1'' is selected at this point, then the user is prompted for the student's ID number. After one is typed in, its syntax is checked, and (if it is syntactically correct), then the system checks whether the ID number is already in use - at least, we'll assume for the moment that it will be possible to do this quickly enough to check this at this point whether the ID number is new.
If there is a syntax error, or the ID number is in use, then an error message is used to inform the user of the problem, and the user is invited either to type in a different ID number or to cancel the operation.
If there is no error (or, the user tries again and eventually enters an ID number that can be used), then the user is prompted for a student's first name(s), middle initial, and last name. Again, the syntax of each is checked, and an error message is displayed if a syntax error is noted. The user should be given the option of either trying again, or canceling the request, whenever an error message is displayed.
Once a complete set of information is obtained, then the resulting ``student info'' is displayed to the user, who is given the option of either accepting it, entering it again, or canceling the operation.
If ``2'' is selected, then the user is prompted for an ID number. When one is entered, its syntax is checked and it's checked whether it corresponds to a registered student. If it does, then the corresponding student information is displayed, and the user is prompted for confirmation that this is the correct student (given the choices of accepting, trying again, or canceling the operation). On the other hand, if the input wasn't a syntactically correct ID number for a registered student, then an error message is displayed and the user is given the options of trying again or canceling the request.
If ``3'' is selected then a similar set of exchanges of prompts, information, and status messages occurs (as for ``2''). If ``4'' is selected then a similar, but simpler and shorter, exchange takes place.
Commands ``5'' and ``6'' differ, in that they require (almost) no input from the user, and cause reports to be prepared. We'll assume that these are to be generated as text files, which the user can view without using this system. Now, the only input that is required in each case is a file name, to be used as the name of the text file containing the report that will be generated. The syntax of this should also be checked, the user should be able to try again or cancel if an unusable file name is supplied, and so on. It's also possible that an attempt to create a new file may fail, even if a correct file name is supplied; some reasonable error message should be returned to the user, if this is the case.
If ``7'' is selected, then the user will be prompted for an ID number in much the same way as above. Let's assume that the ``old info'' deleted from the system will be written to a text file (as above), so that the user will be prompted for a file name for a text file, in the same manner as for commands ``5'' and ``6.''
If ``Q'' is selected, then the user should probably be asked whether he ``really'' wants to quit (and, he should be prompted for a new command, if the answer is no). If he really does, then any required ``shutdown'' processes should be performed, and the system should terminate.
Finally, if some other ``selection'' is made then a polite error message should be displayed, and the menu should be shown again. As well, at the end of each command (except, of course, for ``Quit''), the menu should be displayed again, and the user should be prompted for his next choice.
Quite a few changes to the system's data flow diagrams and process specifications will be needed to incorporate this interface. At least one new process will be needed - to display the command menu, accept and validate menu selections, and ``activate'' whatever subsystem the user's selection corresponds to. Several more may be needed, for system ``startup'' and ``shutdown'' activities. We'll need to change the process specifications for existing processes, in order to include the above new information about the display of prompts, and additional data display and options for the user that have been mentioned. We may find that the resulting process specifications have become complicated enough to add additional levels to the data flow diagram, so that the old ``bottom level'' processes can be refined with lower level diagrams, as well.
A new set of data flow diagrams for this system reflecting these (and a few more) changes, will be made available, and will be used as an example when ``structured design'' is discussed.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Human-Computer Interface