Systems Analysis and Design, Tenth Edition End of Chapter Solutions. CHAPTER 8 User Interface Design

Document Content and Description Below

Chapter Exercises s Questions 1 Provide an overview of the systems design phase. Systems design is the third of five phases in the systems development life cycle. In the previous phase, systems an ... alysis, you developed a logical model of the new system. Now you will work on a physical design that will meet the specifications described in the system requirements document. Your tasks will include user interface design, data design, and system architecture. The deliverable for this phase is the system design specification. (Page 300) 2 Explain IBM’s view of user interface design. As Figure 8­3 suggests, industry leader IBM believes that the best interfaces are the ones that users do not even notice — they make sense because they do what users expect them to do. (Page 302) 3 Describe the habits of successful interface designers. Although IT professionals have different views about interface design, most would agree that good design depends on seven basic principles: Understand the Business The interface designer must understand the underlying business functions and how the system supports individual, departmental, and enterprise goals. Maximize Graphical Effectiveness Studies show that people learn better visually. The immense popularity of Apple Mac OS and Microsoft Windows is largely the result of their graphical user interfaces that are easy to learn and use. Think Like a User A systems analyst should understand user experience, knowledge, and skill levels. If a wide range of capability exists, the interface should be flexible enough to accommodate novices as well as experienced users. Use Models and PrototypesSystems Analysis and Design, Tenth Edition Page 2 of 32 From a user’s viewpoint, the interface is the most critical part of the system design because it is where he or she interacts with the system — perhaps for many hours each day. It is essential to construct models and prototypes for user approval. An interface designer should obtain as much feedback as possible, as early as possible. Focus on Usability The user interface should include all tasks, commands, and communications between users and the information system. The opening screen should show the main options Each screen option leads to another screen, with more options. The objective is to offer a reasonable number of choices that a user easily can comprehend. Too many options on one screen can confuse a user — but too few options increase the number of submenu levels and complicate the navigation process. Invite Feedback Even after the system is operational, it is important to monitor system usage and solicit user suggestions. You can determine if system features are being used as intended by observing and surveying users. Document Everything You should document all screen designs for later use by programmers. If you are using a CASE tool or screen generator, number the screen designs and save them in a hierarchy similar to a menu tree. User­approved sketches and storyboards also can be used to document the user interface. (Pages 305­307) 4 List the eight main rules for user interface design. How would you rank them in order of importance? Explain your answer. The rules are listed and explained starting on page 307. Ranking them is another matter, and answers certainly will vary. This might make a very interesting topic for a class debate. (Pages 307­319) 5 How has input technology changed in recent years? Provide examples of traditional, evolving, and emerging input technology. Figure 8­22 on page 328 offers examples that students can use, or build upon. Input technology has changed dramatically in recent years, and businesses are using the new technology to speed up the input process, reduce costs, and capture data in new forms, such as digital signatures. (Page 328) 6 What are input masks? What are validation rules? Why are they important? Input masks are like templates that only permit certain combinations of characters in order to reduce errors as early in the data entry process as possible. Data validation rules are explained in detail starting on page 316. Validation rules can help ensure that inappropriate data does not enter the system. These checks can include data sequence, existence, range and limit, reasonableness, and validity, among others. (Pages 314­316) 7 What is the difference between a detail report, a summary report, and an exception report?  A detail report produces at least one line of output for every record processed.  A summary report displays only subtotals and totals.Systems Analysis and Design, Tenth Edition Page 3 of 32  In an exception report, only those records that satisfy a specific condition are reported. (Page 322) 8 What are the main principles of source document design? Principles of source document design include the following:  Provide enough space, both vertically and horizontally, for users to enter the data.  Indicate data entry positions clearly using blank lines or boxes and descriptive captions.  Use a heading zone that contains the company name or logo and the title and number of the form.  Use a control zone that contains codes, identification information, numbers, and dates that are used for storing completed forms.  Use an instruction zone that contains instructions for completing the form.  Use a body zone that contains captions and areas for entering variable data. If totals are included on the form, place them in a totals zone.  Use an authorization zone if any signatures or approvals are required.  Provide an information flow from left to right and top to bottom, to match the way users read documents naturally. (Pages 319­320) 9 Provide suggestions for reducing input volume. Four guidelines for reducing input volume are:  Input necessary data only. Do not input a data item unless it is needed by the system.  Do not input data that the user can retrieve from system files or calculate from other data.  Do not input constant data. If orders are in batches with the same date, then a user should enter the order date only once for the first order in the batch. If orders are entered online, then the user can retrieve the order date automatically using the current system date.  Use codes whenever possible. Codes are shorter than the data they represent, and coded input can reduce data entry time. (Pages 318­319) 10 Describe modular design, and explain the two main prototyping methods. In a modular design, you create individual components, called modules, which connect to a higher­level program or process. Each module represents a specific process, which can be represented in a graphical model, and documented in a process description. Modular design is especially important in designing large­scale systems because separate teams of analysts and programmers can work on different areas and then integrate the results. Systems analysts generally use two prototyping methods, system prototyping and design prototyping. System prototyping produces a full­featured, working model of the information system. A system prototype that meets all requirements is ready for implementation, as shown in Figure 8­26. Because the model is “on track” for implementation, it is especially important to obtain user feedback, and to be sure that the prototype meets all requirements of users and management.Systems Analysis and Design, Tenth Edition Page 4 of 32 Design prototyping is a method for verifying user requirements, after which the prototype is discarded and implementation continues, as shown in Figure 8­27. The approach is called design prototyping, or throwaway prototyping. In this case, the prototyping objectives are more limited, but no less important. The end product of design prototyping is a userapproved model that documents and benchmarks the features of the finished system. Design prototyping makes it possible to capture user input and approval while continuing to develop the system within the framework of the SDLC. Systems analysts typically use design prototyping as they construct outputs, inputs, and user interfaces. (Pages 331­332) Discussion Topics 1. Some systems analysts maintain that source documents are unnecessary. They say that all input can be entered directly into the system, without wasting time in an intermediate step. Do you agree? Can you think of any situations where source documents are essential? The answer depends on the business processes involved. In many situations, a source document is the only way to capture and record data. In other situations, a source document is unnecessary. For example, if a school adopts an online registration system, data can be entered directly into the system. Even when not required, a source document might be desirable as a working document that allows a user to review data before entering it into the system. During interviews, observation, and other forms of fact­finding, many people find it quicker and easier to take handwritten notes, which become source documents for later data entry. Given the trend toward handheld computers, automated data capture, and voice recognition software, traditional keyboard data entry might disappear. 2. Some systems analysts argue, “Give users what they ask for. If they want lots of reports and reams of data, then that is what you should provide. Otherwise, they will feel that you are trying to tell them how to do their jobs.” Others say, “Systems analysts should let users know what information can be obtained from the system. If you listen to users, you’ll never get anywhere, because they really don’t know what they want and don’t understand information systems.” What do you think of these arguments? Neither of these arguments, which present two extreme viewpoints, is totally justifiable. The best policy probably is somewhere between these two views. The first argument has some truth because information systems are designed for the users. When a user really needs information in the form of a long printed report, then that information must be provided. The implication about user attitudes is unfair. Users and IT professionals have a common goal — to serve the organization. The second viewpoint is even weaker. A systems analyst should always be willing to offer suggestions. It is true that users sometimes do not know what information to ask for, and a business­oriented systems analyst can help them define their requirements. 3. Suppose your network support company employs 75 technicians who travel constantly and work at customer sites. Your task is to design an information system that provides technical data and information to the field team. What types of output and information delivery would you suggest for the system? Answers will vary. This type of organization probably would require an information system capable of providing remote access on a 24/7 basis. Automated facsimile would give the representatives the ability to obtain printed reports, and e­mail would allow them to keep in touch. Technical support representatives would need access to an online technical librarySystems Analysis and Design, Tenth Edition Page 5 of 32 with links to relevant documents and information. An Internet­accessible knowledge base would provide strong support for the field service team. Using a Web­based system, technical support representatives could input technical data and symptoms, receive suggestions, determine parts availability, and receive service assignments. This system might be enhanced by wireless technology. Encourage students to research real­world practices, and to contact firms that provide field service to learn more about current technology applications. 4. A user interface can be quite restrictive. For example, the interface design might not allow a user to exit to a Windows desktop or to log on to the Internet. Should a user interface include such restrictions? Why or why not? The answer depends on security issues. In a high security environment, it might be desirable to have the information system launch automatically when a user powers up a workstation. The design also might prevent users from exiting to Windows or obtaining Internet access, due to sensitive data or security concerns. This is the same type of built­in security that a diskless workstation offers. If user options are limited by hardware or software configuration, then fewer security concerns exist. Of course, no system is foolproof, and system administrators constantly must be vigilant. Ask students whether they ever worked in situations where their workstation processing or data access options were limited purposely, and how that affected their work. Projects 1. Visit the administrative office at your school or a local company. Ask to see examples of input screens. Analyze the design and appearance of each screen, and try to identify at least one possible improvement. Using the guidelines in the chapter, students should be able to suggest various improvements to the output documents they find. It might be interesting to ask students to submit their suggestions to the class and see whether other students agree or disagree with the recommendations. 2. Search the Web to find an especially good example of a user interface that includes guidelines in this chapter. Document your research and discuss it with your class. Answers will vary. It might be interesting to ask students what criteria they think are important in determining whether an interface is “attractive” to them. Another approach might be to have the instructor choose a site and have students rate the design, using the criteria explained in this chapter. 3. Review Figure 8-6 on page 304 and the accompanying text about EHR usability. During 2012, The U.S. Department of Health and Human Services launched an initiative to focus on this issue, with more input from medical professionals. Research the current status of EHR usability, and describe all noteworthy developments. As the textbook points out, many physicians feel that EHR software is difficult to use and does not meet their needs. Also, physicians often multi task, answering a question about one patient while writing a prescription for another, and EHR software was not designed around that type of workflow. We expect that there will be many articles and comments about EHR in the coming months, and it might be interesting to have students, or team, follow the developments and trends.Systems Analysis and Design, Tenth Edition Page 6 of 32 4. Suggest at least two good examples and two bad examples of source document design. Answers will vary. It might be interesting to ask students what criteria they think are important in determining whether an interface is “good” or “bad.” Another approach might be to have the instructor choose a site and have students rate the design, using the criteria explained in this chapter. The important thing is to share individual viewpoints and reasons. One student might see an attribute or design element that another student might ignore. If the entire class analyzes a specific software package, most design strengths and weaknesses will come to light. It might be especially interesting to review documents that are familiar to the entire class, such as reg [Show More]

Last updated: 2 years ago

Preview 1 out of 32 pages