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 analysis, you develope
...
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 analysis, 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 83 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. Userapproved sketches and storyboards also can be used to
document the user interface. (Pages 305307)
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 307319)
5 How has input technology changed in recent years? Provide examples of traditional,
evolving, and emerging input technology.
Figure 822 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 314316)
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 319320)
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 318319)
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
higherlevel 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 largescale 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 fullfeatured, working model of the information system. A
system prototype that meets all requirements is ready for implementation, as shown in
Figure 826. 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 827. 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 331332)
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 factfinding, 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
businessoriented 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 email 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 Internetaccessible knowledge base would provide strong support for the field service
team. Using a Webbased 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 realworld 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 builtin 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]
.png)
.png)
.png)
.png)
.png)
.png)
