Graphical User Interface Standards

Graphical User Interface Standards
1. Fonts

With graphical user interfaces you have more choices in how to display text. This section summarizes good font decisions.

1.1 Use a sans serif font
Use a sans serif font for text and labels. Sans serif is easier to read on screen. Times New Roman is an example of a serif font. It has "feet" on the letters. Arial is an example of a sans serif font. It does not have "feet" on the letters.

1.2 Do not use italics or underlining
Italics and underlining can make text hard to read on a screen.

1.3 Avoid using colored fonts
The easiest type to read is black type on a white or gray background. If you mix colors of fonts on one screen, the colored text will be harder to read than the black text. If you do use a colored font for a special purpose, consider bolding it to make it easier to read. A red font can be used to identify required fields.

1.4 Use bold for emphasis
Use bolding to emphasize certain body text. Do not use color for emphasis because users typically assume color is a cue for text with a different or specific purpose, such as a label or a hypertext link.

1.5 Avoid changing font size
Avoid using font size to get attention. Many different font sizes on one screen can be distracting.

1.6 Use at least an eight-point font
Many people have a hard time seeing fonts less than eight-points. An eight-point sans serif font is the minimum for screen legibility, assuming a seated user at normal viewing distance.

1.7 Minimize the number of different fonts
Limit the number of font types. Try to use one font type for the whole text.

1. Color Choices and Combinations

You now have the capability of using color in your interfaces. Often, however, color decisions distract users rather than enhancing usability.

Use color to get attention
Putting something in a different color on a screen is attention getting. Use color when it is critical that users notice a certain part of the screen.

Use color purposefully
Color is a powerful attention-getting technique. Use it sparingly or it loses its effectiveness. Do not use it only for aesthetic purposes. Every time you use color it should be for a specific attention-getting reason.

Combine color with redundant highlighting
You cannot rely on users recognizing a particular color—for instance, some people have impaired color perception or can change their color palettes. Therefore, you should always combine color with redundant highlighting. For example, make a part of the screen blue and boxed.

Be aware of color blindness
Nine percent of men and two percent of women have some form of color blindness or color confusion. Do not rely on color alone to provide critical cues.

Watch out for color customizing
People can often change their color palettes. Do not refer to parts of the screen by specific color, for instance, "Enter data that is required into the green box." You cannot be sure that the box will always be green.

Use colors consistently
Decide on the specific meanings of colors within an application and use them and their redundant highlighting consistently.

Use color in toolbars sparingly
Because of their typically small size, using color in toolbar graphics is often more of a distraction than it is useful. Use color in toolbar graphics only to distinguish certain aspects of the graphic (different bars on a bar chart icon) or to establish a particular meaning (red in a stop sign).

Follow cultural color meanings
Be aware of the cultural meanings of colors for your particular users. In the United States, for example, some colors have particular meanings.

Color Meaning
Red: Danger, stop, hot, or financial loss
Yellow: Warning or caution
Green: Go or OK
Blue: Cool
Black: Financial profit

Do not violate these meanings and make sure you follow any additional meanings your users have. Be aware of international color associations—they vary from culture to culture.

Use light backgrounds for main areas
The best colors to use for screen and window backgrounds are off-whites and light grays. If you need to use a color other than these, use a pale yellow or pale blue.

Avoid red and blue combinations
Red and blue together, either as background/foreground or in adjacent areas, is very hard on the eyes. The combination of red and blue should be avoided.

Avoid blue text
Recent research shows that saturated blue text is hard to read. Use black text on a light screen.

Use enough contrast
Choose colors for your background and foreground that have enough contrast between them. For example, do not use a light blue background with medium blue text.

Avoid light text on dark
Avoid using light-colored text on a dark background. This combination appears to blue. It is better to use light-colored backgrounds with dark foregrounds. For example, use a light gray background with black text.

Use grayware first
Design in grayware first, adding color as needed. Use light colors for backgrounds and black for text. Although developers often consider this boring, it is best for users over the long run. Save color for when you really need to get someone’s attention. Different shades of gray can be very effective in delineating areas on a screen.

Let users customize color
It is OK to let users customize the colors of an application, but do not use this as a reason for not choosing good color combinations. Users should not have to customize their screen appearance just because you picked poor colors.

Use color palettes
Provide a few color palette choices for users. This enables them to change all the colors quickly, and ensures that general principles for color use are not violated.

Provide a reset
If you let users customize colors make sure you have an obvious and easy way for them to return to the original (default) colors.

Consider showing results before setting
In some cases it may be beneficial to show users the results of their color decisions before they apply them. You can do this by providing a preview function with which they can see the color changes on a small sample screen before finishing the color dialog.
3. Screen Layout
Screen layout principles have been with us for many years. Instead of becoming outdated, however, they have become even more important as more and more visual elements are added to screens. Make sure you follow the basics of good screen layout in your design. Users may decide that an entire application is unfriendly if the major screens are cluttered and hard to follow.

Standard Screen Size
All screens should be developed keeping in mind the target hardware. Typically, today, this should be a minimum of 800 pixels by 600 pixels (800x600).

Form Name Convention
Each form should have a unique name displayed on the top row of the form and should be descriptive in nature. The display of additional titles and/or names elsewhere on the form is redundant and should not occur.

Label all text boxes
Assign a descriptive label to every text box. Avoid acronyms or abbreviations unless you are sure all users will understand them. It is okay to use multiple-word text box labels; however, keep them concise. Capitalize the first letter of the initial word of a label.

Place labels to the left
Place labels for text boxes to the left of the box. Avoid placing labels on top of text boxes.

Align text box labels to the left
Align text box labels on the left. Do not right-align labels. Right-aligned labels produce a ragged left margin, which is hard to scan.

Place a colon after text box labels
Use a colon after text box labels to distinguish between the label and the data that follows. Allow two spaces between the colon and the text box for the longest label. Do not use colons after group frame names or column headings.

Organize windows and dialogs to match work flow
Which windows you have, how much they do, and the order they are in, should match how the users are doing their work.

Use an appropriate amount of information
Each window or dialog should represent one task or subtask in the user’s workflow. If a task is complicated, use more than one window—one for each subtask.

Find a home base
A home base is the screen or window users come back to again and again while working on a particular task. Decide on a window that will serve as the user’s home base. The home base might be a screen of data, a list, or a form with or without data. Home base is not necessarily the first window they see when they enter the application or a particular task. Users might go through a series of selection and list screens before reaching the home base. If at all possible, do not make home base a blank screen with a menu bar. It should be a screen with meaningful information for the task they are performing, for example, a list of contracts or a blank invoice form, ready to be filled in. Having a home base helps users remember what to do, gives them a concrete and visual anchor point, and helps them to alleviate the feeling of being lost in the interface.

Organize information within a window
Information should be placed in a window or dialog box so that it flows well with the task the users have to perform. The most common or critical information should be at the top left of the window or dialog. The flow of the window should then move from top to bottom or left to right.

Choose a horizontal or vertical flow
Decide whether you will use a horizontal or vertical flow of information for each window or dialog. Not every window or dialog has to have the same flow—decide separately for each window or dialog box. However, do not use a mix of horizontal and vertical flows on one window or dialog box. The most common or critical information appears in the top row. Less common or critical information appears in a second row. Buttons to control the window or dialog box are on the top right. Use white space between rows to show the horizontal flow.

The most common or critical information appears in the left column. Less common or critical information appears in a second column. Buttons to control the window or dialog box are centered on the bottom. Use white space between columns to show the vertical flow.

Group similar data
Group similar data together and use frames and white space to show the groupings. Label the groups.

Minimize different margins
Line up data elements and groups to minimize the number of different margins on the screen.
3. Designing or Choosing Graphics


Is a picture worth a thousand words? Only if it is well designed and well used. Here are some ways to make graphics powerful and effective.

Use graphics for a purpose
Decide how a graphic will be used before designing or choosing the graphic itself. Three common uses are:
1. Application icons. These usually appear on the desktop. Clicking them launches the application.
2. Button images. These are simple pictures that are placed on buttons, usually grouped together on a toolbar. Clicking them starts an action in the application, such as printing.
3. Descriptive graphics. These graphics describe and support the user’s task, for example, a picture of a house in a real estate application.

Use button images as shortcuts
Use graphics on command buttons when you want users to find critical or frequently used objects or actions without searching through menus.

Use graphics when a picture is worth…
Some ideas are best and most quickly portrayed with a picture rather than words, for instance, drawing tools or text justification commands.

Use graphics for international use
If you are designing for international and multilingual audiences, consider using graphics to eliminate the need to translate words. However, there are some guidelines to keep in mind when selecting graphics for international audiences:
1. Make sure the graphics are widely understood. Test them with different groups.
2. Do not use any offensive gestures. For example, a pointing finger is considered offensive in some cultures.
3. Use representations that are universally held. For example, scales to show balancing are not a universal representation.

Watch out for picture size
Often pictures that are easily identifiable when they are large become incomprehensible when they get turned into a smaller than postage stamp size picture on a toolbar.

Use standard graphics
If possible, use standard graphics that have already been tested. Check your platform’s guidelines book and your programming tools for standard graphics.

Consider changing the graphic’s state
Consider having a button image change to represent a new idea. For example, a closed file folder representing a file, which then changes to an open file folder representing an open file.

Be consistent
Once you have chosen or designed a graphic, use it consistently. For example, do not use different representations of a phone in different places in your application.

Avoid words
A well-designed button image should not need a label. If users can’t decipher the pictures, you may need to fix the pictures rather than just adding words. If you do use labels, here are your placement choices:
1. Use tool tips. If possible, have the tool tip appear when the cursor passes over the icon.
2. Use a label underneath the picture.
3. Use a label in micro help (line at the bottom of the screen). Use this only if you cannot use either of the above choices.

Get appropriate help
Consider bringing in a graphic artist experienced in design for computer screens and the type of picture you need to create. People who are used to designing corporate brochures might not have the skill set and experience to create tiny pictures for toolbars.

Test your graphics
Make sure you test the graphics you design or choose. There are two basic ways to test:
1. Give users a particular task and ask them to pick the graphic that they believe performs the task.
2. Give users graphics in context and ask them what actions the graphics represent.
3. Charts and Graphs
Graphical user interfaces allow you to show data visually using charts and graphs.

Use graphs to show relationships
If you need to show relationships among different categories or over time, use graphs rather than tables with specific values. People can grasp trends faster from a graph than from interpreting data in a table.

Use bar graphs for categories
If you have discrete categories and are trying to show the relationship between them, use a bar graph. Bar graphs can also show multiple relationships between categories.

Use special effects carefully
Use 3-D effects only if they help communicate the information. Avoid fancy formats if they don’t help the user understand the data.

Use pie charts for part-to-whole relationships
If you want to show part-to-whole relationships, use a pie chart.

Use line charts for continuous data
If you have continuous data, use a line chart rather than a pie or bar chart. A line chart better shows the cumulative effect.

Choose appropriate scales
Choose an appropriate scale for both the X and Y axes of graphs. If the scale is too expanded, you may be exaggerating the effect. If the scale is too small, you may be underreporting the effect.

Consider displaying specific values
If users need to see a specific value as well as a general trend or relationship, show the exact values on the graph itself.

Use visual coding on graphs
Use color, highlighting, shading, or patterns to distinguish parts of a graph.

Use legends for complicated graphs
If graphs have a lot of data and a lot of visual coding, use a legend.

Label graphs and data
Label the graph with terminology users will understand. Consider the following labels:
1. Graph title
2. Lines, bars, or parts of the pie
3. X axis
4. Y axis

Use primary colors to show differences
Use primary colors like green, blue, and yellow in charts and graphs to make sharp distinctions. For example, use a different color for each bar in a bar chart, or each slice in a pie chart.

Use red cautiously
Avoid using red in a chart or graph unless you mean to imply trouble, danger, stop, or loss.

Use close colors to show transition
Use colors that are close to each other, like medium and light blue, to show a transition, for example, sales increasing step by step from month to month.

Use light backgrounds for tables
Use off-white or light gray as the background for data in a table. Use black text for the foreground. Use color only when you need to highlight a particular cell, row, or column.

Use monochromatic backgrounds for graphs
If colors are used in graphs, use a white, gray, or black background.
3. User Controls

Command Buttons
Command buttons are the primary way that users take action within dialog boxes. Use command buttons to convey to users the major actions of a particular box. Users should be able to glance at a dialog box and know what to do there and what to do next, based on the names and placement of the command buttons.

Use command buttons only for frequent or critical immediate actions
Use command buttons when users are going to take immediate action that is frequent or critical. Command buttons act as reminders of what actions can and should be taken. Limit command buttons to a maximum of six on a window. Command button actions can also appear as menu items. If an action is not frequent and not critical, place it on a drop-down menu.

Label buttons carefully
Make sure the label you use for a command button is clear and concise. Use labels with multiple words when they are needed to clearly convey the meaning of the button. Follow book title capitalization rules—capitalize the first letter of all major words.

Label buttons consistently
Choose specific labels for certain functions and use these labels throughout an application and from one application to another. For example, use List to display a table of choices, rather than sometimes List and sometimes Search.

Use industry standards for labels
Some labels have become standard across graphical user interfaces. Use these standard labels if you are performing the functions.

Label Action Keyboard Equivalent
OK Makes changes and closes the window The Enter key

Cancel Does not make changes and closes the window The Escape key

Close Closes the window when changes can’t be made or canceled C

Reset Resets to defaults, leaves window open R
Apply Makes changes, leaves window open A
Help Opens online help H




Consider replacing the OK button with a specific term

If the OK command button results in a specific function such as printing or deleting, consider using the specific term instead of the generic OK.

Size buttons relative to each other
If the length of text for a series of command buttons in a dialog box is similar, make all the buttons in the dialog box the size of the largest button. If the text length for a series of command buttons in a dialog box varies, use two button sizes—one for shorter text and another for longer text. This allows you the button size you need while avoiding too many different sizes. Do not use more than two different button sizes in a dialog box.

Separate buttons from the rest of the dialog box
Use white space to set off the buttons that pertain to the entire dialog box. Don’t crowd buttons with the rest of the controls in the dialog box.

Group buttons together
If you have more than three buttons, use white space to group buttons together. Group buttons to identify:
1. Buttons with similar functions
2. Buttons to leave the window (OK, Cancel)
3. Destructive actions (Delete)

Place buttons consistently
Use one of these locations for buttons:
1. Top right of the window.
2. Bottom right of the window.
3. Do not place buttons in both bottom and right locations in one window.

Match button position to the use of the window
Choose either a vertical or a horizontal design for a particular window and position the buttons to match the design. A horizontal design should have buttons on the top right. A vertical design should have buttons on the bottom. The grouping and layout of data in the window plays a role in determining which design to use. The length and number of buttons are also factors. If you have long button names or a lot of buttons, you may want to use a horizontal design with top right buttons. Careful consideration should be given to the number of buttons placed on the screen. You can make these decisions on a window-by-window or box-by-box basis. Window flow designs do not need to be the same across all windows or boxes.

Position limited action buttons where needed
If a command button pertains to only one part of the dialog box, place the button where it is needed.
Order buttons consistently
Whenever possible, place buttons in the following order:
1. Affirmative buttons to leave the window (OK)
2. Canceling actions to leave the window (Cancel)
3. Unique buttons for the window

Use ellipses (…) to indicate that input is needed
If more input will be required to complete a button action, use ellipses (…) after the button name.

Gray out unavailable buttons
If a button is disabled, display the text as grayed out. For instance, certain actions might not be available in order to restrict a user’s actions until another step is taken. Graying out implies that there is an action the user can take to make the button available. If in fact there is no action the user can take to change the button’s state (the button will never be usable) do not include the button.

Assign a nondestructive default button
Choose one button on the window as the default. If the user presses the Enter key, that button is invoked. Make the most common or important action on that window the default, for example, Print on a print window. Do not use a destructive button, such as Delete, as a default, even if it is the most common or important action for the window.
Option buttons, also known as radio buttons, replace many data entry actions.

Use option buttons for one choice
Use option buttons when users should pick one mutually exclusive choice from a list of options, for example, choosing a pay period in a personnel application.

Label option buttons descriptively
Pick a clear and descriptive label for each option button. For example, send Course Description rather than Course.

Group options buttons together and label them
Place option buttons together in a group. Use a frame to show the group. Use a descriptive label for the entire group.

Align option buttons vertically
Line up option buttons vertically if you have the space, rather than horizontally to make them easier to scan.

Limit option buttons to six or fewer
Limit option buttons to six or fewer choices. If you have more choices, consider using a single selection list box or drop-down list box instead. List boxes are discussed later in this chapter.

Choose an order
Decide on the best order for the option buttons. Some ordering methods include:
1. By frequency—most frequently used options at the top
2. By task—if there is a usual order in which parts of a task are performed
3. BY logic—if there is a logical order, for instance a list of dates


4. By alphabet—only use alphabetical order if the labels match the way your users think about the items.

Avoid binary option buttons
If users need to make yes/no or on/off choices, use a single check box rather than option Buttons. However, use two option buttons for distinct, mutually exclusive choices, such as Male/female.


3. Check Boxes
Check boxes replace some data entry actions and provide a quick way to make multiple choices.

Use check boxes for choosing more than one option
Use check boxes when users can choose one or more options.

Use check boxes for toggling
Use check boxes when users are toggling a feature on or off. It is okay to have just one check box.

Label check boxes descriptively
Pick a clear descriptive label that users will understand for each check box. For example, use Reverse Print Order, not reverse.

Group and label check boxes
Place check boxes together in a group. Use a frame to show the group. Use a descriptive label for the entire group.

Align check boxes vertically
Line up check vertically, if you have the space, rather than horizontally to make them easier to scan.

Limit check boxes to ten or fewer
Limit check boxes to ten or fewer choices. If you have more choices consider using a multiple select list box instead.

Choose an order
Decide on the best order for check boxes. Some ordering methods are:
1. By frequency—most frequently used options at the top
2. By task—if there is a usual order in which parts of a task are performed
3. By logic—if there is a logical order, for instance a list of dates
4. By alphabet—only use alphabetical order if the labels match the way your users think about the items.

Do not use Select All or Deselect All check boxes
If you anticipate users will want to select all of a set of check boxes, or turn them all off, consider using a multiple selection list box with Select All and Deselect All buttons instead of check boxes.
3. Text Boxes

Text boxes are the main way for users to type in data.

Use a border to indicate data entry
Use a text box with a border to indicate that a user can enter or edit data.

Show display-only data without a box
If data is for display only and cannot be changed or added, do not place a box around it.

Gray out temporarily protected fields
If a particular text box is temporarily protected, gray out the box and label to signify that data cannot be entered or changed at this time. For calculated fields, consider using a boxed text box with a gray background and read only access.

Use box length to signify approximate data length
Size text boxes to indicate the approximate length of the field.. If you have text boxes of similar length, make them the same length unless you need to show the exact size of the field. If the length of the field can vary, use text boxes of the same length to minimize the number of unique margins on the screen

Align text boxes
Left align text boxes on the screen to minimize the number of different margins. If a particular text box has a long label, use a different margin for that text box. Limit the number of unique margins to two.

Group text boxes
If you have text boxes that all pertain to similar information, group them together in a frame and label the entire group.
3. List Boxes

List boxes are an alternative to long option button lists. They are also an alternative to data entry and they ensure data integrity.

Use list boxes for long lists
Use list boxes rather than option buttons when you have a lot of options. When you have more than six option buttons use a single select list box.

Use list boxes for dynamic data
If data is likely to change over time, use a list box rather than option buttons. It is easier to change the choices that appear in a list box.

Show three to eight items at a time
Show at least three, but no more than eight items in a list box at a time. If you have more items use a scroll bar to view the rest of the items. See the guidelines on drop-down list boxes later in this chapter.

Label each list box
Choose a label for the entire list box that describes the items inside the box, for example Available Printers. Place the label on the top of the list, left justified, followed by a colon.

Use filters for large lists
If there are more than 40 items in a list, provide a way for users to filter the list to narrow down the number of options from which they must choose.

Use drop-down list boxes to save space
Drop-down list boxes allow you to save window space. Use a drop-down list box if most users will select the first item. However, list boxes hide all but the first option from the users. Users have to go through an extra step to get to the rest of the list. Do not use a drop-down list box if it is important for users to see all the options all the time.

Use a combination list box to allow users to type in an option
A combination list box lets users type in a choice as well as pick it from the list. Use a combination list box when most users know what they want and prefer just typing it in. A combination list box is also useful when the list is long and users could skip down to a lower point in the list by typing in one or more letters. Do not allow users to add items to a list by using a combination list box.

Multiple Selection List Boxes
Multiple selection list boxes are an alternative to long check box lists. Multiple selection list boxes, however, can be hard for users to use. You may need to compensate for their usability problems by following the guidelines below.



Use a multiple selection list box instead of check boxes
Consider using a multiple selection list box instead of check boxes if you have more than five options or your list is likely to change over time.

Consider instructions for multiple selection list boxes
Many users are not familiar with multiple selection list boxes. They might not know that they can choose more than one option or might not know how to choose more than one option. Consider including a line of instruction or a prompt that tells users that they can choose more than one Instructions are particularly important when one window contains both a single selection list box and a multiple selection list box.

Consider a selection summary box
If you use a scrolling multiple selection list box, consider also displaying a box with a summary of what the user is selecting. This way, the user does not have to continually move up and down the list to see what has already been chosen.

Consider multiple selection checklists
Another way to show what the user is selecting is a multiple selection checklist. This combines a multiple selection list box with check boxes that the user can select.

Consider Select All or Deselect All buttons
If you have a set of options and anticipate that users will either want to select them all or turn them all off, consider using a multiple selection list box with Select All and Deselect All buttons, rather than check boxes.
10. Dialog Boxes

Dialog boxes allow users to complete a set of actions for a particular task.

Use modal dialogs for closure
A user must respond to a modal dialog box before they can perform work in any other box or window. Use modal dialog boxes for form filling and small, discrete tasks.

Use modeless dialogs for continuing work
A modeless dialog box is a dialog that can remain open and active even while users perform work in other windows or dialogs. Use a modeless dialog box for tasks that need to be repeated or monitored over time, for displaying different objects at the same time, or when the user needs to have access to menus or toolbars while the dialog box is open.

Use a master window or dialog box
A set of tab cards should reside on a window or dialog box (a "master") that also contains any buttons that affect the entire set of cards. Table 8.1 shows buttons that are commonly found on a master window.

Place buttons appropriately
If a button action pertains only to a specific tab card, place the button on the specific tab card. If a button action applies to the whole tab set, place the button on the master window.

Be consistent
Tab controls should be consistent within and across applications. If you use a master tab window and include OK, Cancel, and Apply buttons in one instance, you should use the same setup in the next instance.

Choose a horizontal or vertical flow
Decide whether you will use a horizontal or vertical flow of information for each tab card. Not every card in a set has to have the same flow—decide separately for each card.

A horizontal flow starts in the upper left and moves to the right. The most common or critical information appears in the top row. Less common or critical information appears in a second row. Buttons to control the window are on the top right. Use white space between rows to show the horizontal flow.

Vertical flow starts in the upper left and moves down. The most common or critical information appears in the left column. Less common or critical information appears in a second column. Buttons to control the window are centered on the bottom. Use white space between columns to show the vertical flow.

Navigation in Secondary Windows
With the mouse and pen, navigation to a particular field or control involves the user pointing to the field and clicking or tapping it. For button controls, this action also activates that button. For example, for check boxes, it toggles the check box setting and for command buttons, it carries out the command associated with that button.

The keyboard interface for navigation in secondary windows uses the TAB and SHIFT+TAB keys to move between controls, to the next and previous control, respectively. Each control has a property that determines its place in the navigation order. Set this property such that the user can move through the secondary window following the usual conventions for reading: in western countries, left-to-right and top-to-bottom, with the primary control the user interacts with located in the upper left area of the window.

You need not provide TAB key access to every control in the window. When using static text as a label, set the control you associated with it as the appropriate navigational destination, not the static text field itself.

In addition, combination controls such as combo boxes, drop-down combo boxes are considered single controls for navigational purposes. For a group of check boxes, provide tab navigation to each control because their settings are independent of each other.

Optionally, you can also use arrow keys to support keyboard navigation between controls in addition to the tab navigation technique wherever the interface does not require those keys. For example, you can use the up arrow and down arrow keys to navigate between single-line text boxes or within a group of check boxes or command buttons. Always use arrow keys to navigate between option button choices and within list box controls.

OK and Cancel command buttons are typically not assigned access keys if they are the primary transaction keys for a secondary window. In this case, the ENTER and ESC keys, respectively, provide access to these buttons.

Pressing ENTER always navigates to the DEFAULT command button, if one exists, and invokes the action associated with that button. If there is no current DEFAULT command button, then a control can use the ENTER key for its own use. Likewise, pressing ESC always navigates to the CANCEL command button, if one exists, and invokes the action associated with that button.

11. Tables and Grids

Tables and grids allow users to enter or view larger amounts of information at a time.

Use tables for comparisons among data
Display a table if users need to compare two or three pieces of data and you can’t predict ahead of time, which they need.

Use grids for multiple data entry
Use grids to allow users to enter several pieces of data at a time.

Label columns
Choose labels for columns that accurately reflect the data.

Use row labels if necessary
If rows contain different data, label each row.

Left justify labels
Left justify column and row labels. Do not use a colon after the label.

12. Tab Control

The keyboard interface for navigation in secondary windows uses the TAB and SHIFT+TAB keys to move between controls, to the next and previous control, respectively. Each control has a property that determines its place in the navigation order. Set this property such that the user can move through the secondary window following the usual conventions for reading: in western countries, left-to-right and top-to-bottom, with the primary control the user interacts with located in the upper left area of the window. Order controls such that the user can progress through the window in a logical sequence, proceeding through groups of related controls. Command buttons for handling overall window transactions are usually at the end of the order sequence.

You need not provide TAB key access to every control in the window. When using static text as a label, set the control you associated with it as the appropriate navigational destination, not the static text field itself. In addition, combination controls such as combo boxes, drop-down combo boxes, and spin boxes are considered single controls for navigational purposes. Because option buttons typically appear as a group, use the TAB key for moving the input focus to the current set choice in that group, but not between individual options -- use arrow keys for this purpose. For a group of check boxes, provide tab navigation to each control because their settings are independent of each other.

Optionally, you can also use arrow keys to support keyboard navigation between controls in addition to the tab navigation technique wherever the interface does not require those keys. For example, you can use the up arrow and down arrow keys to navigate between single-line text boxes or within a group of check boxes or command buttons. Always use arrow keys to navigate between option button choices and within list box controls.

You can also use access keys to provide navigation to controls within a secondary window. This allows the user to access a control by pressing and holding the ALT key and an alphanumeric key that matches the access key character designated in the label of the control. A group box is a special control you can use to organize a set of controls. A group box is a rectangular frame with an optional label that surrounds a set of controls. Group boxes generally do not directly process any input. However, you provide navigational access to items in the group using the TAB key or by assigning an access key to the group label.
13. Pop-up Menus and Messages


Pop-up menus provide shortcuts for expert users.

Use pop-up menus for specific options
Pop-up menus appear when users click the right mouse button. Use them for a subset of actions specific to the place or action. For example, if a user clicks the right mouse button on text in a word processing application, the pop-up menu would contain actions that could be taken on that text, such as Cut, Copy, Paste, and Formatting.

Use redundant interactions
Don’t make a pop-up menu the only place an action appears. Also provide a menu item, command button, or toolbar button for the action.

Message Boxes
A message box is a secondary window that displays a message or information about a particular situation or condition. Messages are an important part of the interface for any software product. Messages that are too generic or poorly written frustrate users, increase support costs, and ultimately reflect on the quality of the product. Therefore, it is worthwhile to design effective message boxes..

Message Box Types
Message boxes typically include a graphical symbol that indicates what kind of message is being presented.

Most messages can be classified in one of the categories shown below:
Information Provides information about the results of a command. Offers no user choices; the user acknowledges the message by clicking the OK button.

Warning Alerts the user to a condition or situation that requires the user's decision and input before proceeding, such as an impending action with potentially destructive, irreversible consequences. The message can be in the form of a question -- for example, "Save changes to My Report?”

Critical informs the user of a serious problem that requires intervention or correction before work can continue. The system also includes a question mark message symbol. You can include your own graphics or animation in message boxes. However, limit your use of these types of message boxes and avoid defining new graphics to replace the symbols for the existing standard types. Once the user activates the application, the message box can be displayed. Display only one message box for a specific condition. Displaying a sequential set of message boxes tends to confuse users.

Message Box Text
The message text you include in a message box should be clear, concise, and in terms that the user understands. This usually means using no technical jargon or system-oriented information.
In addition, observe the following guidelines for your message text:
• State the problem, its probable cause (if possible), and what the user can do about it – no matter how obvious the solution may seem to be. For example, instead of "Insufficient disk space," use "'Sample Document' could not be saved, because the disk is full. Try saving to another disk or freeing up space on this disk."
• Consider making the solution an option offered in the message. For example, instead of "One or more of your lines are too long. The text can only be a maximum of 60 characters wide," you might say, "One or more of your lines are too long. Text can be a maximum of 60 characters in Portrait mode or 90 wide in Landscape. Switch to Landscape mode now?" Offer Yes and No as the choices.
• Avoid using unnecessary technical terminology and overly complex sentences. For example, "picture" can be understood in context, whereas "picture metafile" is a rather technical concept.
• Avoid phrasing that blames the user or implies user error. For example, use "Cannot find filename" instead of "Filename error." Avoid the word "error" altogether. Make messages as specific as possible.
• Avoid mapping more than two or three conditions to a single message. For example, there may be several reasons why a file cannot be opened; provide a specific message for each condition.
• Avoid relying on default system-supplied messages, such as MS-DOS® extended error messages and Kernel INT 24 messages; instead, supply your own specific messages wherever possible.
• Be brief, but complete. Provide only as much background information as necessary. A good rule of thumb is to limit the message to two or three lines. If further explanation is necessary, provide this through a command button that opens a Help window.
• Informative messages that do not require interaction from the user can be placed in the status bar and a beep issued to alert the user to the message. For example, upon leaving a particular field an automatic update to the database may take place. The user needs to be notified of the situation but need not respond to a message.


14. Primary and Secondary Windows

Windows are the backgrounds that the rest of your interface controls sit on.
Use cascading windows
Cascading windows keep users focused on one task at a time. However, if by cascading you cover up information that needs to be viewed simultaneously, allow for the use of tiling.

Tiling windows allows users to display multiple windows at one time without covering up other windows. However, the more windows the user opens, the more the windows shrink to accommodate the additional windows. Therefore information can also be hidden when using tiling.

Avoid horizontal scrolling
Avoid having users scroll horizontally to see information in a window or dialog box. Instead of horizontal scrolling, try one or more of the following:
1. A larger window
2. Breaking the information up into more than one window or using tabs
3. Allow expanding, zooming in, and collapsing to show only some information at a time

Size secondary windows to fit data
Size secondary windows to best fit the information in them. Do not rely on users to resize windows, even if the window allows it. All secondary windows do not have to be the same size.

Place pop-up windows in the center of the action
Place pop-up windows and dialogs in the center of the area they relate to in the application window.
15. Menus and Menu Bars

Menus play two critical roles in graphical user interfaces. They are a major method of navigation through the interface and they convey the mental model to the user in a snapshot. Giving attention to the design of usable menus is time well spent.

Word menu titles and items carefully
Pick names and test them to ensure that they make sense to users. It is not easy to pick labels that users will understand.

Change menus, as you need
It is okay for menu bars and their drop-down menus to change as users move through an application.

Use initial capitals
Menu bar titles and items should have an initial capital letter with the rest of the word in lower case. For drop-down menu items, follow book title capitalization rules—capitalize the first letter of all major words.

Follow industry standards for menus
Follow industry standards on menu bars and drop-down menus. You do not have to use these menu bar titles or their drop-down menus if you do not have these tasks in your menu, but if you do use them, follow the standards. If appropriate, provide shortcuts (hot keys) for frequent users. Use of hot keys will be consistent within the system. If you have any questions regarding a menu title or the sequence that they should be arranged, you can refer to any of the Microsoft Office products.

Menu items are the individual choices that appear in a menu. Menu items can be text, graphics -- such as icons -- or graphics and text combinations that represent the actions presented in the menu. The format for a menu item provides the user with visual cues about the nature of the effect it represents. Always provide the user with a visual indication about which menu items can be applied. If a menu item is not appropriate or applicable in a particular context, then disable or remove it. Leaving the menu item enabled and presenting a message box when the user selects the menu item is a poor method for providing feedback.

In general, it is better to disable a menu item rather than remove it because this provides more stability in the interface. However, if the context is such that the menu item is no longer or never relevant, remove it. For example, if a menu displays a set of open files and one of those files is closed or deleted, it is appropriate to remove the corresponding menu item.

If all items in a menu are disabled, disable its menu title. If you disable a menu item or its title, it does not prevent the user from browsing or choosing it. If you provide status bar messages, you can display a message indicating that the command is unavailable and an explanation why.

The system provides a standard appearance for displaying disabled menu items. If you are supplying your own visuals for a disabled menu item, follow the visual design guidelines for how to display it with an unavailable appearance.

Menu Bars

Menu bars point to major functionality in the application. Choose, organize, and name menu bar titles carefully.

Match menu bars to the users’ workflow
When users look at a menu bar it should match how they think of their work. Spend time deciding on and testing menu categories to make sure they fit the users’ mental model.

Give critical or frequent tasks even weight
Make sure all critical or frequent tasks are represented equally on the menu bar. Avoid grouping all critical or frequent items under one category, and then using the remaining five or six titles on the menu bar for different, but nonessential tasks.

Place application-specific menu titles where they fit
Place menu bar titles that are specific to your application where they best fit, for example, Jobs and Preferences before Help.

Use only one word for menu bar titles
Titles on the menu bar must be one word only. If they are more than one word, or use hyphens or dashes, it is hard to tell whether they are one item or two.

Use only one line for the menu bar
Menu bars must be only one line long. If you have too many titles on your menu bar for one line, then collapse some of your titles into one.

Do not gray out menu bar titles
Do not use graying out to make menu bar titles temporarily unavailable. Instead you should either not show the item at all or place the item on a drop-down menu where it is appropriate to use graying out.

Menu bar titles should always activate a drop-down menu
Menu bar titles should not initiate actions directly. Items on drop-down menus can initiate actions.

Drop-Down Menus
Drop-down menus reveal more detailed information to the user. Word and order them carefully.

Use more than one drop-down menu item
Drop-down menus should have more than one item on them. If you have a menu bar title that has one or no drop-down items, it should not be a separate menu bar category. Combine it with another menu title.

Use unique drop-down menu items
Do not start each drop-down item with the same word that is on the menu bar. Drop-down items should be unique.

Limit drop-down menus to one screen in length
Drop-down menus can go from the top of the screen to the bottom of the screen. Do not use scrolling. If you have more items than will fit on the screen, you will need to combine some items and use cascading drop-downs, or separate some items into an additional menu bar item.

Put frequent or critical items at the top
Place the most frequent or critical items at the top of the drop-down menu.

Use separator bars
Whenever a menu contains a set of related menu items, you can separate those sets with a grouping line known as a separator. The standard separator is a single line that spans the width of the menu. Avoid using menu items themselves as group separators. Use separator bars in two ways—to group related items and to separate destructive items

Use no more than two levels of cascading
It is okay to use cascading drop-down menus, but do not use more than two levels of cascading. Use the right arrow symbol (>) to the right of the drop-down menu item to denote that the item has a cascading menu.

Use ellipses (…) to denote dialogs
If more input will be required to complete an action, use ellipses (…) after the drop-down item

Use industry standard keyboard equivalents
A keyboard equivalent allows users to choose a menu item without using the mouse. A keyboard equivalent requires that the drop-down menu be open when it is used. All drop-down menu choices should have keyboard equivalents.

Use accelerators sparingly
Accelerators are combinations of keystrokes that allow users to choose a menu item when the drop-down menu is not open, as shown in Figure 8.23. Use accelerators only for those drop-down menu items that you think users will want to use without pulling down a menu, for example, Ctrl+V to paste from the clipboard.

Use consistent accelerators
Use consistent accelerators in your enterprise-wide applications. Place the accelerators in the drop-down menus to the right of the drop-down menu item.
16. Tools Bars

Toolbars serve as a menu shortcut, or as a way to present controls that would be hard to convey in words, like drawing tools.

Make toolbars consistent
If you use a toolbar throughout the application, or between applications, make sure you use the same button graphics for the same functions throughout.

Make only active items available
Only toolbar items that are currently available should display. It is okay for some toolbar items to not show at all and for others to display as users move from one part of the application to another. It is all right for some items on a toolbar to be grayed out if they are only temporarily unavailable.

Allow users to move some toolbars
Allow users to move some toolbars to different locations on the screen to ensure they are out of the way of the work the users are performing.

Allow users to toggle toolbars on and off
Let users turn toolbars on and off through a dialog box or an option on a drop-down menu. This is
Especially important if you are providing more than one toolbar.

Allow customizing
Consider allowing users to customize their toolbars by deciding what to put on or take off the toolbar. You should, however, make decisions on what should be on the toolbar and provide that as the default. Most of the time, users should not have to customize a toolbar for it to be usable.

Use buttons with a purpose
Pay attention to the number of buttons on a toolbar. Too many buttons create visual and cognitive strain. Users will not see some of the buttons if there are too many.

Group like items
If you have a lot of buttons on a toolbar, consider grouping them. For example, place all editing graphics together. Use white space to group them.
17. Relationship between Tools Bars, Command Buttons, and Menus

You will need to decide which actions go in the menu system, which go on the toolbar, and/or which actions should be buttons on a window.

Use toolbars for frequent actions across screens
Toolbars should contain actions that users need to take frequently and need to access across several screens. Do not use toolbars instead of command buttons.

Action Type Proper Placement
Most frequent and critical Command buttons
Fairly frequent and across several screens. Toolbars

All actions: frequent, critical, and infrequent Menu bar and drop-down menus

Use toolbars to supplement menus
Some toolbar items are used in conjunction with menu bars when users need a shortcut for certain actions. In these cases the toolbar items also appear on the menu bar.

Use toolbars in place of some menu items
Some toolbar items can be used in place of menu items. For instance, some drawing tools cannot be described with words and would be difficult to place on a drop-down menu.

PROJECT PLAN TEMPLATE

PROJECT PLAN TEMPLATE
< INSERT ISSUING ORGANIZATION >
< INSERT PROJECT NAME >
Document Revision #:
Date of Issue:
Project Manager:

Approval Signatures


Approved by: Business Project Leader Approved by: IM/IT Project Leader



Prepared by: Business Project Manager Prepared by: IM/IT Project Manager



Reviewed by: Quality Assurance Manager



Table of Contents
1. Project Overview 1
1.1 Purpose, Scope, and Objectives 1
1.2 Assumptions and Constraints 1
1.3 Project Deliverables 2
1.4 Schedule and Budget Summary 2
1.5 Evolution of the Plan 2
1.6 References 2
1.7 Definitions and Acronyms 3
2. Project Organization 4
2.1 External Interfaces 4
2.2 Internal Structure 4
2.3 Roles and Responsibilities 4
3. Managerial Process Plans 5
3.1 Start up Plan 5
3.1.1 Estimates 5
3.1.2 Staffing 5
3.1.3 Resource Acquisition 5
3.1.4 Project Staff Training 6
3.2 Work Plan 6
3.2.1 Work Breakdown Structure 6
3.2.2 Schedule Allocation 7
3.2.3 Resource Allocation 7
3.2.4 Budget Allocation 7
3.3 Project Tracking Plan 8
3.3.1 Requirements Management 8
3.3.2 Schedule Control 8
3.3.3 Budget Control 8
3.3.4 Quality Control 9
3.3.5 Reporting 9
3.3.6 Project Metrics 9
3.4 Risk Management Plan 9
3.5 Project Closeout Plan 10
4. Technical Process Plans 11
4.1 Process Model 11
4.2 Methods, Tools, and Techniques 11
4.3 Infrastructure 11
4.4 Product Acceptance 12
5. Supporting Process Plans 13
5.1 Configuration Management 13
5.2 Verification and Validation 13
5.3 Documentation 14
5.4 Quality Assurance 14
5.5 Reviews and Audits 14
5.6 Problem Resolution 15
5.7 Subcontractor Management 15
5.8 Process Improvement 15
6. Additional Plans 16
Annex A 18
Annex B 19


Document Change Control
This section provides control for the development and distribution of revisions to the Project Charter up to the point of approval. The Project Charter does not change throughout the project life cycle, but rather is developed at the beginning of the project (immediately following project initiation approval, and in the earliest stages of project planning). The Project Charter provides an ongoing reference for all project stakeholders. The table below includes the revision number (defined within your Documentation Plan Outline), the date of update/issue, the author responsible for the changes, and a brief description of the context and/or scope of the changes in that revision.
Revision Number Date of Issue Author(s) Brief Description of Change



1. Project Overview
This section of the IM/IT Project Management Plan provides an overview of the purpose, scope and objectives of the project for which the Plan has been written, the project assumptions and constraints, a list of project deliverables, a summary of the project schedule and budget, and the plan for evolving the IM/IT Project Management Plan.
1.1 Purpose, Scope, and Objectives
• Define the purpose and scope of the project.
• Describe any considerations of scope or objectives to be excluded from the project or the deliverables.
• Ensure that the statement of scope is consistent with similar statements in the business case, the project charter and any other relevant system level or business level documents.
• Identify and describe the business or system needs to be satisfied by the project.
• Provide a concise summary of:
− the project objectives,
− the deliverables required to satisfy the project objectives, and
− the methods by which satisfaction of the objectives will be determined.
• Describe the relationship of this project to other projects.
• If appropriate, describe how this project will be integrated with other projects or ongoing work processes.
• Provide a reference to the official statement of project requirements (e.g.: in the business case or the project charter).
1.2 Assumptions, Constraints and Risks
• Describe the assumptions on which the project is based.
• Describe the imposed constraints and risks on the project such as:
− schedule,
− budget,
− resources,
− quality,
− software to be reused,
− existing software to be incorporated,
− technology to be used, and
− external interfaces.
1.3 Project Deliverables
• Identify and list the following, as required to satisfy the terms of the project charter or contract:
− project deliverables (either directly in this Plan, or by reference to an external document),
− delivery dates,
− delivery location, ands
− Quantities required.
• Specify the delivery media.
• Specify any special instructions for packaging and handling.
1.4 Schedule and Budget Summary
• Provide a summary of the schedule and budget for the IM/IT project.
• Restrict the level of detail to an itemization of the major work activities and supporting processes (e.g.: give only the top level of the work breakdown structure).
1.5 Evolution of the Plan
• Identify the compliance of this Plan to any standards.
The structure of this Project Plan is in compliance with the recommendations of IEEE Std 1058 1998.
• Specify the plans for producing both scheduled and unscheduled updates to this Plan.
• Specify how the updates to this Plan shall be disseminated.
• Specify how the initial version of this Plan shall be placed under configuration management.
• Specify how changes to this Plan shall be controlled after its issue.
1.6 References
• Provide a complete list of all documents and other sources of information referenced in this Plan.
• Identify each referenced document by title, report number, date, author and publishing organization.
• Identify other referenced sources of information, such as electronic files, using unique identifiers such as path/name, date and version number.
• Identify and justify any deviations from the referenced standards or policies.
1.7 Definitions and Acronyms
• Define, or provide references to documents or annexes containing the definition of all terms and acronyms required to properly understand this Plan.


2. Project Organization
2.1 External Interfaces
• Describe the organizational boundaries between the project and external entities.
• Identify, as applicable:
− the parent organization,
− the customer,
− subcontracted organizations, and
− other organizational entities that interact with the project.
• Use organizational charts or diagrams to depict the project's external interfaces.
2.2 Internal Structure
• Describe the internal structure of the project organization.
• Describe the interfaces among the units of the IM/IT development team.
• Describe the interfaces between the project and organizational entities that provide supporting processes, such as configuration management, quality assurance, and verification and validation.
• Use organizational charts or diagrams to depict the lines of authority, responsibility and communication within the project.
2.3 Roles and Responsibilities
• Identify and state the nature of each major work activity and supporting process.
• Identify the organizational units that are responsible for those processes and activities.
• Consider using a matrix of work activities and supporting processes vs. organizational units to depict project roles and responsibilities.


3. Managerial Process Plans
This section of the IM/IT Project Management Plan specifies the project management processes for the project. This section defines the plans for project start up, risk management, project work, project tracking and project close out.
3.1 Start up Plan
3.1.1 Estimates
• Specify the estimated cost, schedule and resource requirements for conducting the project, and specify the associated confidence levels for each estimate.
• Specify the methods, tools and techniques used to estimate project cost, schedule and resource requirements;
• Specify the sources of estimate data and the basis of the estimation such as: analogy, rule of thumb, standard unit of size, cost model, historical database, etc.
• Specify the methods, tools, techniques to be used to re estimate the project cost, schedule and required resources.
• Specify the schedule for re estimation, which might be regular, a periodic or event driven (e.g.: on project milestones).
3.1.2 Staffing
• Specify the number of required staff, providing the following details:
− number of personnel by skill level,
− numbers and skill levels in each project phase, and
− duration of personnel requirement.
• Specify the sources of staff personnel (e.g.: internal transfer, new hire, contracted, etc.)
• Consider using resource Gantt charts, resource histograms, spreadsheets and tables to depict the staffing plan by skill level, by project phase, and by aggregations of skill levels and project phases.
3.1.3 Resource Acquisition
• Specify the plan for acquiring the resources and assets, in addition to personnel, needed to successfully complete the project.
• Describe the resource acquisition process.
• Specify the assignment of responsibility for all aspects of resource acquisition.
• Specify acquisition plans for equipment, computer hardware and software, training, service contracts, transportation, facilities, and administrative and janitorial services.
• Specify when in the project schedule the various acquisition activities will be required.
• Specify any constraints on acquiring the necessary resources.
• If necessary, expand this subsection to lower levels, to accommodate acquisition plans for various types of resources.
3.1.4 Project Staff Training
• Specify the training needed to ensure that necessary skill levels in sufficient numbers are available to successfully conduct the IM/IT project.
• Specify the following training information:
− the types of training to be provided,
− numbers of personnel to be trained,
− entry and exit criteria for training, and
− the training method, for example: lectures, consultations, mentoring, computer assisted training, etc.
• Identify training as needed in technical, managerial and supporting activity skills.
3.2 Work Plan
3.2.1 Work Breakdown Structure
• Define a Work Breakdown Structure (WBS) to specify the various work activities to be performed in the IM/IT project, and to depict the relationships among these work activities.
• Decompose the work activities to a level that exposes all project risk factors, and that allows accurate estimation of resource requirements and schedule duration for each work activity.
• Specify the following factors for each work activity:
− necessary resources,
− estimated duration,
− products or deliverables of the activity,
− acceptance criteria for the work activity products, and
− predecessor and successor work activities.
• The level of decomposition internally within the WBS may vary depending on the quality of the requirements, familiarity of the work, applicable level of technology, etc.
3.2.2 Schedule Allocation
• Specify the scheduling relationships among the project work activities in a manner that depicts the time sequencing constraints and illustrates opportunities for concurrent work activities.
• Identify the critical path in the schedule.
• Indicate any constraints on the scheduling of particular work activities, that are caused by external factors.
• Identify appropriate schedule milestones to assess the scope and quality of project work products and of project achievement status.
• Techniques for depicting schedule relationships may include milestone charts, activity lists, activity Gantt charts, activity networks, critical path networks and PERT charts.
3.2.3 Resource Allocation
• Provide a detailed itemization of the resources allocated to each major work activity in the project WBS.
• Specify the numbers and required skill levels of personnel for each work activity.
• Specify, as appropriate, the allocation of the following resources:
− personnel (by skill level),
− computing resources
− software tools
− special testing and simulation facilities, and
− administrative support.
• Use a separate line item for each type of resource for each work activity.
3.2.4 Budget Allocation
• Provide a detailed breakdown of the necessary resource budgets for each of the major work activities in the WBS.
• Specify the estimated cost for activity personnel, and include as appropriate, the costs for the following items:
− travel,
− meetings,
− computing resources,
− software tools,
− special testing and simulation facilities, and
− administrative support.
• Use a separate line item for each type of resource in each activity budget.
3.3 Project Tracking Plan
3.3.1 Requirements Management
• Specify the process for measuring, reporting and controlling changes to the project requirements.
• Specify the processes to be used in assessing the impact of requirements changes on product scope and quality, and the impacts of requirements changes on project schedule, budget, resources and risk factors.
• In the configuration management processes, specify change control procedures and the formation and use of a change control board.
• In the processes for requirements management, include traceability, prototyping and modeling, impact analysis and reviews.
3.3.2 Schedule Control
• Specify the schedule control activities by identifying the processes to be used for the following purposes:
− to measure the progress of work completed at the major and minor project milestones,
− to compare actual progress to planned progress, and
− to implement corrective action when actual progress does not conform to planned progress.
• Specify the methods and tools that will be used to measure and control schedule progress.
• Identify the objective criteria that will be used to measure the scope and quality of work completed at each milestone, and hence to assess the achievement of each schedule milestone.
3.3.3 Budget Control
• Specify the budget control activities by identifying the processes to be used for the following purposes:
− to measure the cost of work completed,
− to compare the actual cost to the planned and budgeted costs, and
− to implement corrective action when the actual cost does not conform to the budgeted cost.
• Specify when cost reporting will be done in the project schedule.
• Specify the methods and tools that will be used to track the project cost.
• Identify the schedule milestones and objective indicators that will be used to assess the scope and quality of the work completed at those milestones.
• Specify the use of a mechanism such as earned value tracking to report the budget and schedule plan, schedule progress, and the cost of work completed.
3.3.4 Quality Control
• Specify the processes to be used to measure and control the quality of the work and the resulting work products.
• Specify the use of quality control processes such as quality assurance of conformance to work processes, verification and validation, joint reviews, audits and process assessment.
3.3.5 Reporting
• Specify the reporting mechanisms, report formats and information flows to be used in communicating the status of requirements, schedule, budget, quality, and other desired or required status metrics within the project and to entities external to the project.
• Specify the methods, tools and techniques of communication.
• Specify a frequency and detail of communications related to project management and metrics measurement that is consistent with the project scope, criticality, risk and visibility.
3.3.6 Project Metrics
• Specify the methods, tools, and techniques to be used in collecting and retaining project metrics.
• Specify the following metrics process information:
− identification of the metrics to be collected,
− frequency of collection, and
− processes for validating, analyzing, and reporting the metrics.
3.4 Risk Management Plan
• Specify the risk management plan for identifying, analyzing, and prioritizing project risk factors.
• Specify plans for assessing initial risk factors and for the ongoing identification, assessment, and mitigation of risk factors throughout the life cycle of the project.
• Describe the following:
− procedures for contingency planning,
− procedures for tracking the various risk factors,
− procedures for evaluating changes in the levels of the risk factors and responding to changes in the levels of the risk factors,
− risk management work activities,
− procedures and schedules for performing risk management work activities,
− risk documentation and reporting requirements,
− organizations and personnel responsible for performing specific risk management activities, and
− procedures for communicating risks and risk status among the various customer, project and subcontractor organizations.
• Identify and describe the applicable impact of any of the following risk factors:
− risks in the customer project relationship,
− contractual risks,
− technological risks,
− risks caused by the size and complexity of the product,
− risks in the development and target environments,
− risks in personnel acquisition, skill levels and retention
− risks to schedule and budget, and
− risks in achieving customer acceptance of the deliverables.
3.5 Project Closeout Plan
• Identify the plans necessary to ensure orderly closeout of the IM/IT project.
• Specify the following:
− a staff reassignment plan
− a process for archiving project materials,
− a process for capturing project metrics in the business projects database,
− a process for post mortem debriefings of project personnel, and
− a plan for preparation of a final report to include lessons learned and an analysis of project objectives achieved.
4. Technical Process Plans
4.1 Process Model
• Define the relationships among major project work activities and supporting processes.
• Describe the flow of information and work products among activities and functions.
• Specify the timing of work products to be generated.
• Identify the reviews to be conducted.
• Specify the major milestones to be achieved.
• Define the baselines to be established.
• Identify the project deliverable to be completed.
• Specify the required approvals within the duration of the project.
• In the process model for the project, include project initiation and project termination activities.
• Use a combination of graphical and textual notations to describe the project process model.
• Indicate any tailoring of your organization's standard process model for a project.
4.2 Methods, Tools, and Techniques
• Specify the development methodologies, programming languages and other notations, and the processes, tools and techniques to be used to specify, design, build, test, integrate, document, deliver, modify and maintain the project deliverable and non deliverable work products.
• Specify the technical standards, policies, and procedures governing development and/or modification of the work products.
4.3 Infrastructure
• Specify the plan for establishing and maintaining the development environment (hardware, operating system, network and software), and the policies, procedures, standards, and facilities required to conduct the IM/IT project. These resources may include workstations, local area networks, software tools for analysis, design implementations, testing, and project management, desks, office space, and provisions for physical security, administrative personnel, and janitorial services.
4.4 Product Acceptance
• Specify the plan for customer acceptance of the deliverables generated by the IM/IT project.
• Specify objective criteria for determining acceptability of the deliverables.
• Reference a formal agreement of the acceptance criteria signed by representatives of theIM/ITorganization and the customer.
• Specify any technical processes, methods, or tools required for deliverable acceptance, such as testing, demonstration, analysis and inspection.
5. Supporting Process Plans
5.1 Configuration Management
• Specify or reference the configuration management plan for the IM/IT project, providing the information identified in the following lines.
• Specify the methods that will be used to perform the following activities:
− configuration identification,
− configuration control,
− status accounting,
− evaluation, and
− release management.
• Specify the processes of configuration management including procedures for the following activities:
− initial baselining of work products,
− logging and analysis of change requests,
− change control board procedures,
− tracking of changes in progress, and
− procedures for notification of concerned parties when baselines are established or changed.
• Identify the automated configuration management tools used to support the configuration management process.
5.2 Verification and Validation
• Specify or reference the verification and validation plan for the IM/IT project, providing the information identified in the following lines.
• Specify the scope, tools, techniques and responsibilities for the verification and validation work activities.
• Specify the organizational relationships and degrees of independence between development activities and verification and validation activities.
• Specify the use of verification techniques such as traceability, milestone reviews, progress reviews, peer reviews, prototyping, simulation and modeling.
• Specify the use of validation techniques such as testing, demonstration, analysis and inspection.
• Identify the automated tools to be used in verification and validation.
5.3 Documentation
• Specify the plans for generating non deliverable and deliverable project documentation.
• Specify the organizational entities responsible for providing input information, and for generating and reviewing the project documentation.
• Specify the following information or object identification:
− list of documents to be prepared,
− controlling template or standard for each document,
− who will prepare each document,
− who will review each document,
− due dates for review copies,
− due dates for initial baseline versions, and
− a distribution list for review copies and baseline versions and quantities required
5.4 Quality Assurance
• Specify or reference the quality assurance plan for the IM/IT project, containing the information identified in the following lines.
• Specify the plans for assuring that the IM/IT project fulfills its commitments to the IM/IT process and the IM/IT product as specified in the requirements specification, the IM/IT Project Management Plan, supporting plans and any standards, procedures, or guidelines to which the process or the product must adhere.
• As applicable, specify the quality assurance procedures to be used, such as analysis, inspection, review, audit, and assessment.
• Indicate the relationship among the quality assurance, verification and validation, review, audit, configuration management, system engineering, and assessment processes.
5.5 Reviews and Audits
• Specify the schedule, resources, and processes, and procedures to be used in conducting project reviews and audits.
• Specify the plans for joint customer project reviews, management progress reviews, developer peer reviews, quality assurance audits, and customer conducted reviews and audits.
• List the external agencies that approve or regulate any project deliverable.
5.6 Problem Resolution
• Specify the resources, methods, tools, techniques and procedures to be used in reporting, analyzing, prioritizing and processing IM/IT problem reports generated during the project.
• Indicate the roles of development, configuration management, the change control board, and verification and validation in problem resolution work activities.
• Provide for separate tracking of effort expended on problem reporting, analysis and resolution, so that rework can be tracked and process improvement accomplished.
5.7 Subcontractor Management
• Specify or reference the plans for selecting and managing any subcontractors that may participate in or contribute to the IM/IT project.
• Specify the criteria for selecting subcontractors.
• Generate a separate management plan for each subcontract, using a tailored version of this Project Plan, and include all items necessary to ensure successful completion of each subcontract as follows:
− requirements management,
− monitoring of technical progress,
− schedule and budget control
− product acceptance criteria,
− risk management procedures,
− additional topics as needed to ensure successful completion of the subcontract, and
− a reference to the official subcontract and subcontractor/prime contractor points of contact.
5.8 Process Improvement
• Specify the plans for periodically assessing the project, for determining areas for improvement, and for implementing the improvement plans.
• Ensure that the process improvement plan is closely related to the problem resolution plan.
• Include in the improvement plan, a process to identify the project processes that can be improved without serious disruption to an ongoing project, and to identify the project processes that can best be improved by process improvement initiatives at the organizational level.
6. Additional Plans
• Specify or reference any additional plans required to satisfy product requirements and contractual terms, which may include:
− plans for assuring that safety, privacy, and security requirements are met,
− special facilities or equipment specification,
− product installation plans,
− user training plans,
− integration plans,
− data conversion plans,
− system transition plans,
− product maintenance plans, or
− product support plans.
7. Project Evolution
7.1 Project support and maintenance
• Specify or reference to the support, maintenance and operational model for the project when the project will be used by the potential customers
7.2 Follow-up projects
• Identify potential follow-up projects which will use this project
• Identify potential follow-up projects which will supersede this project


Annex A
Annex B

Glossary of Software Testing/QA Terms

Glossary of Software Testing/QA Terms

audit. (1) (IEEE) An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria. See: functional configuration audit, physical configuration audit. (2) (ANSI) To conduct an independent review and examination of system records and activities in order to test the adequacy and effectiveness of data security and data integrity procedures, to ensure compliance with established policy and operational procedures, and to recommend any necessary changes. See: computer system audit, software audit.
boundary value. (1) (IEEE) A data value that corresponds to a minimum or maximum input, internal, or output value specified for a system or component. (2) A value which lies at, or just inside or just outside a specified range of valid input and output values.
boundary value analysis. (NBS) A selection technique in which test data are chosen to lie along "boundaries" of the input domain [or output range] classes, data structures, procedure parameters, etc. Choices often include maximum, minimum, and trivial values or parameters. This technique is often called stress testing. See: testing, boundary value.
branch coverage. (NBS) A test coverage criteria which requires that for each decision point each possible branch be executed at least once. Syn: decision coverage. Contrast with condition coverage, multiple condition coverage, path coverage, statement coverage. See: testing, branch.
bug. A fault in a program which causes the program to perform in an unintended or unanticipated manner. See: anomaly, defect, error, exception, fault.
cause effect graph. (Myers) A Boolean graph linking causes and effects. The graph is actually a digital-logic circuit (a combinatorial logic network) using a simpler notation than standard electronics notation.
cause effect graphing. (1) (NBS) Test data selection technique. The input and output domains are partitioned into classes and analysis is performed to determine which input classes cause which effect. A minimal set of inputs is chosen which will cover the entire effect set. (2) (Myers) A systematic method of generating test cases representing combinations of conditions. See: testing, functional.
code inspection. (Myers/NBS) A manual [formal] testing [error detection] technique where the programmer reads source code, statement by statement, to a group who ask questions analyzing the program logic, analyzing the code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards. Contrast with code audit, code review, code walkthrough. This technique can also be applied to other software and configuration items. Syn: Fagan Inspection. See: static analysis.
code review. (IEEE) A meeting at which software code is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Contrast with code audit, code inspection, code walkthrough.
code walkthrough. (Myers/NBS) A manual testing [error detection] technique where program [source code] logic [structure] is traced manually [mentally] by a group with a small set of test cases, while the state of program variables is manually monitored, to analyze the programmer's logic and assumptions. Contrast with code audit, code inspection, code review. See: static analysis.
coverage analysis. (NIST) Determining and assessing measures associated with the invocation of program structural elements to determine the adequacy of a test run. Coverage analysis is useful when attempting to execute each statement, branch, path, or iterative structure in a program. Tools that capture this data and provide reports summarizing relevant information have this feature. See: testing, branch; testing, path; testing, statement.
crash. (IEEE) The sudden and complete failure of a computer system or component.
criticality. (IEEE) The degree of impact that a requirement, module, error, fault, failure, or other item has on the development or operation of a system. Syn: severity.
cyclomatic complexity. (1) (McCabe) The number of independent paths through a program. (2) (NBS) The cyclomatic complexity of a program is equivalent to the number of decision statements plus 1.
error. (ISO) A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition. See: anomaly, bug, defect, exception, and fault
error guessing. (NBS) Test data selection technique. The selection criterion is to pick values that seem likely to cause errors. See: special test data; testing, special case.
error seeding. (IEEE) The process of intentionally adding known faults to those already in a computer program for the purpose of monitoring the rate of detection and removal, and estimating the number of faults remaining in the program. Contrast with mutation analysis.
exception. (IEEE) An event that causes suspension of normal program execution. Types include addressing exception, data exception, operation exception, overflow exception, protection exception, and underflow exception.
failure. (IEEE) The inability of a system or component to perform its required functions within specified performance requirements. See: bug, crash, exception, fault.
fault. An incorrect step, process, or data definition in a computer program which causes the program to perform in an unintended or unanticipated manner. See: bug, defect, error, exception.
quality assurance. (1) (ISO) The planned systematic activities necessary to ensure that a component, module, or system conforms to established technical requirements. (2) All actions that are taken to ensure that a development organization delivers products that meet performance requirements and adhere to standards and procedures. (3) The policy, procedures, and systematic actions established in an enterprise for the purpose of providing and maintaining some degree of confidence in data integrity and accuracy throughout the life cycle of the data, which includes input, update, manipulation, and output. (4) (QA) The actions, planned and performed, to provide confidence that all systems and components that influence the quality of the product are working as expected individually and collectively.
quality assurance, software. (IEEE) (1) A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. (2) A set of activities designed to evaluate the process by which products are developed or manufactured.
quality control. The operational techniques and procedures used to achieve quality requirements.
review. (IEEE) A process or meeting during which a work product or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include code review, design review, formal qualification review, requirements review, test readiness review. Contrast with audit, inspection. See: static analysis.
risk. (IEEE) A measure of the probability and severity of undesired effects. Often taken as the simple product of probability and consequence.
risk assessment. (DOD) A comprehensive evaluation of the risk and its associated impact.
software review. (IEEE) An evaluation of software elements to ascertain discrepancies from planned results and to recommend improvement. This evaluation follows a formal process. Syn: software audit. See: code audit, code inspection, code review, code walkthrough, design review, specification analysis, static analysis
static analysis. (1) (NBS) Analysis of a program that is performed without executing the program. (2) (IEEE) The process of evaluating a system or component based on its form, structure, content, documentation. Contrast with dynamic analysis. See: code audit, code inspection, code review, code walk-through, design review, symbolic execution.
test. (IEEE) An activity in which a system or component is executed under specified conditions, the results are observed or recorded and an evaluation is made of some aspect of the system or component.
testability. (IEEE) (1) The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met. (2) The degree to which a requirement is stated in terms that permit establishment of test criteria and performance of tests to determine whether those criteria have been met.
test case. (IEEE) Documentation specifying inputs, predicted results, and a set of execution conditions for a test item. Syn: test case specification. See: test procedure.
test case generator. (IEEE) A software tool that accepts as input source code, test criteria, specifications, or data structure definitions; uses these inputs to generate test input data; and, sometimes, determines expected results. Syn: test data generator, test generator.
test design. (IEEE) Documentation specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests. See: testing functional; cause effect graphing; boundary value analysis; equivalence class partitioning; error guessing; testing, structural; branch analysis; path analysis; statement coverage; condition coverage; decision coverage; multiple-condition coverage.
test documentation. (IEEE) Documentation describing plans for, or results of, the testing of a system or component, Types include test case specification, test incident report, test log, test plan, test procedure, test report.
test driver. (IEEE) A software module used to invoke a module under test and, often, provide test inputs, control and monitor execution, and report test results. Syn: test harness.
test incident report. (IEEE) A document reporting on any event that occurs during testing that requires further investigation.
test item. (IEEE) A software item which is the object of testing.
test log. (IEEE) A chronological record of all relevant details about the execution of a test.
test phase. (IEEE) The period of time in the software life cycle in which the components of a software product are evaluated and integrated, and the software product is evaluated to determine whether or not requirements have been satisfied.
test plan. (IEEE) Documentation specifying the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, responsibilities, required, resources, and any risks requiring contingency planning. See: test design, validation protocol.
test procedure. (NIST) A formal document developed from a test plan that presents detailed instructions for the setup, operation, and evaluation of the results for each defined test. See: test case.
test report. (IEEE) A document describing the conduct and results of the testing carried out for a system or system component.
test result analyzer. A software tool used to test output data reduction, formatting, and printing.
testing. (IEEE) (1) The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component. (2) The process of analyzing a software item to detect the differences between existing and required conditions, i.e. bugs, and to evaluate the features of the software items. See: dynamic analysis, static analysis
testing, acceptance. (IEEE) Testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. Contrast with testing, development; testing, operational.
testing, alpha []. (Pressman) Acceptance testing performed by the customer in a controlled environment at the developer's site. The software is used by the customer in a setting approximating the target environment with the developer observing and recording errors and usage problems.
testing, assertion. (NBS) A dynamic analysis technique which inserts assertions about the relationship between program variables into the program code. The truth of the assertions is determined as the program executes.
testing, beta []. (1) (Pressman) Acceptance testing performed by the customer in a live application of the software, at one or more end user sites, in an environment not controlled by the developer. (2) For medical device software such use may require an Investigational Device Exemption [IDE] or Institutional Review Board [IRB] approval.
testing, boundary value. A testing technique using input values at, just below, and just above, the defined limits of an input domain; and with input values causing outputs to be at, just below, and just above, the defined limits of an output domain. See: boundary value analysis; testing, stress.
testing, branch. (NBS) Testing technique to satisfy coverage criteria which require that for each decision point, each possible branch [outcome] be executed at least once. Contrast with testing, path; testing, statement. See: branch coverage.
testing, compatibility. The process of determining the ability of two or more systems to exchange information. In a situation where the developed software replaces an already working program, an investigation should be conducted to assess possible comparability problems between the new software and other programs or systems.
testing, exhaustive. (NBS) Executing the program with all possible combinations of values for program variables. Feasible only for small, simple programs.
testing, functional. (IEEE) (1) Testing that ignores the internal mechanism or structure of a system or component and focuses on the outputs generated in response to selected inputs and execution conditions. (2) Testing conducted to evaluate the compliance of a system or component with specified functional requirements and corresponding predicted results. Syn: black-box testing, input/output driven testing. Contrast with testing, structural.
testing, integration. (IEEE) An orderly progression of testing in which software elements, hardware elements, or both are combined and tested, to evaluate their interactions, until the entire system has been integrated.
testing, interface. (IEEE) Testing conducted to evaluate whether systems or components pass data and control correctly to one another. Contrast with testing, unit; testing, system. See: testing, integration.
testing, mutation. (IEEE) A testing methodology in which two or more program mutations are executed using the same test cases to evaluate the ability of the test cases to detect differences in the mutations.
testing, operational. (IEEE) Testing conducted to evaluate a system or component in its operational environment. Contrast with testing, development; testing, acceptance; See: testing, system.
testing, parallel. (ISO) Testing a new or an altered data processing system with the same source data that is used in another system. The other system is considered as the standard of comparison. Syn: parallel run.
testing, path. (NBS) Testing to satisfy coverage criteria that each logical path through the program be tested. Often paths through the program are grouped into a finite set of classes. One path from each class is then tested. Syn: path coverage. Contrast with testing, branch; testing, statement; branch coverage; condition coverage; decision coverage; multiple condition coverage; statement coverage.
testing, performance. (IEEE) Functional testing conducted to evaluate the compliance of a system or component with specified performance requirements.
testing, qualification. (IEEE) Formal testing, usually conducted by the developer for the consumer, to demonstrate that the software meets its specified requirements. See: testing, acceptance; testing, system.

testing, regression. (NIST) Rerunning test cases which a program has previously executed correctly in order to detect errors spawned by changes or corrections made during software development and maintenance.
testing, statement. (NIST) Testing to satisfy the criterion that each statement in a program be executed at least once during program testing. Syn: statement coverage. Contrast with testing, branch; testing, path; branch coverage; condition coverage; decision coverage; multiple condition coverage; path coverage.
testing, storage. This is a determination of whether or not certain processing conditions use more storage [memory] than estimated.
testing, stress. (IEEE) Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements. Syn: testing, boundary value.
testing, structural. (1) (IEEE) Testing that takes into account the internal mechanism [structure] of a system or component. Types include branch testing, path testing, statement testing. (2) Testing to insure each program statement is made to execute during testing and that each program statement performs its intended function. Contrast with functional testing. Syn: white-box testing, glass-box testing, logic driven testing.
testing, system. (IEEE) The process of testing an integrated hardware and software system to verify that the system meets its specified requirements. Such testing may be conducted in both the development environment and the target environment.
testing, unit. (1) (NIST) Testing of a module for typographic, syntactic, and logical errors, for correct implementation of its design, and for satisfaction of its requirements. (2) (IEEE) Testing conducted to verify the implementation of the design for one software element; e.g., a unit or module; or a collection of software elements. Syn: component testing.
testing, usability. Tests designed to evaluate the machine/user interface. Are the communication device(s) designed in a manner such that the information is displayed in a understandable fashion enabling the operator to correctly interact with the system?
testing, volume. Testing designed to challenge a system's ability to manage the maximum amount of data over a period of time. This type of testing also evaluates a system's ability to handle overload situations in an orderly fashion.
traceability matrix. (IEEE) A matrix that records the relationship between two or more products; e.g., a matrix that records the relationship between the requirements and the design of a given software component. See: traceability, traceability analysis.
usability. (IEEE) The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component.
validation. (1) (FDA) Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes. Contrast with data validation.
validation, verification, and testing. (NIST) Used as an entity to define a procedure of review, analysis, and testing throughout the software life cycle to discover errors, determine functionality, and ensure the production of quality software.
verification, software. (NBS) In general the demonstration of consistency, completeness, and correctness of the software at each stage and between each stage of the development life cycle. See: validation, software.
Source: The following definitions are taken from GLOSSARY OF COMPUTERIZED SYSTEM AND SOFTWARE DEVELOPMENT TERMINOLOGY

Traceability Matrix

Traceability matrics:

A method used to validate the compliance of a process or product with the requirements for that process or product. The requirements are each listed in a row of the matrix and the columns of the matrix are used to identify how and where each requirement has been addressed.

Description

A table that traces the requirements to the system deliverable component for that stage that responds to the requirement.

Size and Format
For each requirement, identify the component in the current stage that responds to the requirement. The requirement may be mapped to such items as a hardware component, an application unit, or a section of a design specification.


BASELINE TRACEABILITY MATRIX


Description
A table that documents the requirements of the system for use in subsequent stages to confirm that all requirements have been met.

Size and Format
Document each requirement to be traced. The requirement may be mapped to such things as a hardware component, an application unit, or a section of a design specification.

Traceability Matrix Table (Sample)
Identifier Requirement Priority (e.g., (M)andatory, (D)esirable, or (O)ptional) Change Requests Module (or Hardware Component, Application Unit, Deliverable Section, e.g., Design Specification)