With the explosion of so much software that people use in their daily personal and professional lives, the user interface (UI) is absolutely critical to the successful use of that software. However, I must point out that it is also one of the more challenging areas to define requirements. You will see approaches to help overcome this. I will examine what areas to consider as part of UI requirements, consider using existing standards (which we will talk about more in this chapter), and look at how you need to address people with disabilities. First, let us examine what UI requirements are.
Introducing UI Requirements
On one project, the first exposure to helping define UI requirements started with a stakeholder saying the following statement :
10-1 DRAFT The system shall be user-friendly.
Is this a good requirement, based on what you have learned so far?
Absolutely not! In fact, how many of the attributes does this violate? Frankly, many if not most of them. Yet, you will run into users and stakeholders who will give you needs like this. Your job requires you to be a translator. You have to translate what a user says they need into what they really need.
A bit of philosophy here: people will tell you that SE and specifically requirements engineering (RE) is a science. Yes, requirements engineers apply many scientific principles to SE and RE. However, take the previous example. What scientific principles would you apply to convert that statement into real requirements? You cannot think of any? Absolutely correct.
This translation is an art form. If it were truly scientific, people would teach those principles and it would be much easier to accomplish. That is why translating the user statements into what they realistically need is harder than it looks (hence the title of this book is Writing Requirements for System Engineering). Yes, many needs are relatively easy to capture once you understand the principles that have been discussed. However, the reality of it is that it gets more difficult when you move beyond those easy aspects.
Nowhere is that more manifested than in the definition of user interface requirements. In part, a user interface is an implementation. Of course, what is good is clearly subjective, and requirements cannot capture subjectivity.
How can you capture user interface needs? One approach, and many projects take this, is to define user interface standards.
Real-World Note
I worked with one recent application where one organization we worked with had defined a document with dozens of specifications of how a UI should work. What this did is save me from having to capture a potentially long list of requirements by referencing these standards.
If such a standard exists, write a requirement as follows:
10-2 All applications generated in (Our Office) shall follow the (Specific Project or Organization) User Interface Standard.
Here’s an example:
10-3 All applications generated in BOSS shall follow the BOSS User Interface Standard.
There may be some UI standards on the Internet that you can use and reference. You, or someone, can define UI standards for your organization, and then you can reference that standard in the previous requirement. One example that we will mention again later is the U.S. Navy’s Human Factors Analysis and Classification System (HFACS ) .
One caution about UI requirements: you need to worry about specifying implementation. For example, a standard might be the following:
The dialog must be outlined in medium gray with rounded corners and have a background of color of blue gray.
That is a reasonable standard statement . However, if you specified that as a requirement, clearly you have moved into implementation. Why does this work as a standard? By itself, it does not, but an organization, in its development of the UI standard, had done research into color schemes and crafted a series of related standard statements that had chosen a particular color scheme and used it consistently in throughout the standard. By referencing the standard, you avoid that potential trap of defining implementation.
Another approach that is used extensively is prototyping . This is highly recommended. Here a candidate UI is built, with no real code behind it, to show the users how it looks, and users and stakeholders can view the various screenshots (maybe nothing more than print screens) and decide what they like and what needs improvement. Also important is to demonstrate the navigation paths. In other words, how does the user flow from one element to another? Then, when the UI is agreed upon, it is captured as a design specification.
Many times during agile sprints, user stories (more on these later in the book) can have small aspects of the UI shown as part of the demo at the completion of the sprint.
Failing that, what do you do? You will have to define some UI requirements yourself. That leads to the next section. It should be pointed out that these UI needs affect both the computer systems (for example, the FBI Records Management System) and the hardware systems (again, like the BOSS Radiation Dosimetry system). A device that reads information it has collected needs to present the data in a readable format just like a software application must do. It is just that not all software UI aspects may apply to a hardware device.
Improving the User Interface
The UI describes how the user interacts with the system. That sounds easy. However, it is not as you have already seen. This will continue to be examined throughout this chapter.
The user interface is the implementation of usability. Chapter 5 stated that usability is how effectively users can learn and use a system. This section will cover important topics to consider when you define requirements related to the UI, look at how to ensure error message provide useful information, examine how the sciences of human factors can improve the UI, and even look at an excellent resource the U.S. government provides to optimize the UI, which is next.
Government UI Improvements
The article “Improving the User Experience,” from the Usability.gov web site, is captured in the following “Interface Guidelines from Usability.gov” sidebar. These guidelines provide a good list of items to consider when documenting UI requirements or UI standards.
Candidate UI Topics for Requirements
The “Standards” section in Chapter 5 talked about UI standards. To refresh your memory, standards are rules put in place within an organization or across organizations so operations work consistently. For this section, they are rules or directions for how to handle the user experience. Think of the menus within Microsoft Office and how the same commands are in the same place and the same steps activate it and shortcut keys. These are excellent examples of UI standards. You should consider the following requirement:
10-4 (5-30) The BOSS shall follow this company’s Organizational User Interface Standard.
While a UI standard is not presented in this book, here is a list of topics for that could be used as a foundation a standard. Or if you cannot establish as standard, these are topics for you to use to craft UI requirements:
System feedback: XXX?
Drag and drop: How does the system indicate what you are dragging and where you put it?
Response time: How does the system tell you it is working or when it is done?
System message: What kind of information does the user receive when a message is provided? Does it tell them what to do, instead of just saying something cryptic like 404 error?
Desktop: How is the screen presented to the user?
Icons: What kinds of icons are used, and are they consistent throughout an application and across applications?
Task bars: How do task bars work?
Pop-up windows: How do they open and close, and what can they perform?
Navigation: How can the user move around the screen?
Toolbar: How is the main menu presented?
Drop-down menus: How are drop-down menus presented and used?
Trees: How does the user move around the application from screens and tabs?
Tabs: How does a user move from one field to another?
Grids: How is data laid out on the screen?
Keyboard shortcuts: What are the keystrokes that are used in the system, like Ctrl+C for Cut, for all the operations of the applications?
Forms: How data is entered to the system?
Data entry fields: How are fields presented to the user ?
Push buttons: How are buttons represented, 3D vs. 2D?
Colorscheme: What colors are used on the screen?
Fonts: What fonts are used, and what sizes are allowed?
Help: What help is provided to the user?
Online help: How do people get help about the functions and operations within an application? Think of the ? in the upper-right corner of Microsoft Office applications.
Context-sensitive help: How can some get information about items in the application?
Training: How do people get guidance for training on an application?
Demos: Is there guidance for users to see guided tours of the application, so they understand how to use it?
Notice that the previous list works well for a software program. Does this same list of topics apply to a hardware example, say the Radiation Dosimetry system? Oh, there are some aspects that do apply (such as data entry), but many, if not most, may not apply to a hardware project. However, for each system you must look at it and decide for each case, as there are no specific generalities that apply.
Obviously, the UI standard would be much more specific than the UI requirements would be. For example, you might have the following requirements for help:
10-5 The BOSS shall provide online help for all users describe all functions within the system.
10-6 The BOSS shall provide context sensitive help for all data entry values, screens, and forms within the system.
While it may not have many more requirements, the User Interface Standard could have more specific statements.
Error Conditions
Remember, Chapter 1 talked about translating what users say they need into what they really need. Here is an extract of that:
A stakeholder says, “When this specific error happens <insert their error here>, I need a red flashing button up in the upper-right corner of the screen.” They are telling you how to implement it. What they really mean is, “When an error condition happens, I need a message of what is wrong and how to proceed.” For example, if you have operating system (OS) errors, you might need a different requirement.
As was said before, “But more on that later.” Well, it is later now. Remember earlier in the “Candidate UI Topics for Requirements” section, you saw that a 404 error is not good. You want messages to provide information that is useful to the user, telling them how to continue past the error message, what steps they should take to fix the error, or whatever other rectification steps they should consider. You need to write requirements for error conditions like the following example:
10-7 For the BOSS Date Entry function generates an error condition, it shall present a message of what went wrong and how the user is to proceed.
OS errors were mentioned earlier. How should you handle these? As was said, these error messages can be very cryptic. Then you might need something like the following:
10-8 When the BOSS Date Entry function spawns an Operating System error condition, the system shall intercept the OS condition, translating the condition into a message of what went wrong and how the user is to proceed.
The goal would be a message designed and implemented like the following:
Human Factors
There is one area that significantly affects user interfaces, and that is human factors. Ergonomics is also a synonym for human factors. The International Ergonomics Association explains them this way:
Ergonomics(or human factors) is the scientific discipline concerned with the understanding of interactions among humans and other elements of a system, and the profession that applies theory, principles, data and methods to design in order to optimize human well-being and overall system performance.
You can see from this definition just how much human factors (HF) can affect UI. You may even hear expressions like HCI, which means human computer interface. HF helps to influence and/or direct HCI. Alternatively, you may hear about HFE, human factors engineering. They are all related. What are some of the topics that could be included in HF?
Aesthetics
Consistency in the user interface
Online and context-sensitive help
Wizards and agents
User documentation
Training materials
As you have read this chapter, you have seen some of these topics before. You will now see some additional items that show other elements, both from a positive and a negative perspective. So, look at the following sidebar.
You need to ensure violations such as those in the sidebar do not happen on your project, through either good UI standards or requirements that prevent such an abuse.
Next, you can see some small refinements to the user experience, but they can have an important impact because they can ensure that the application does not either adversely affect the user’s use of the system or dramatically irritate a user who has to wait too long before doing the next step.
As was presented in Chapter 8 on physical requirements, throughput requirementsdeal with how much data passes through a system or a portion of the system. An article called “Throughput Requirements” on the Open Process Framework (OPF) web site ( www.opfro.org ) points out that “Some throughput requirements are based on human psychological limits ” and includes the following list:
The average typist can type continuously if movements between fields are less than 0.2 seconds.
The average typist takes approximately 1.35 seconds to switch gears mentally when moving from one set of typing to another (which usually occurs when data entry clerks move from one screen to the next).
The average person will wait for no more than 20 seconds before looking for something else to do (and less, if you consider an Internet shopper).
What does this mean to you? Somehow either the UI standards help to prevent violations of these guidelines or you need to consider requirements that help to follow such guidelines. Here are some examples:
10-9 The BOSS data entry function shall allow the movement from one field to another to take no more than 0.2 seconds.
10-10 The BOSS data entry function shall allow the movement from one screen to another to take no more than 1 second.
These human factors influence what UI requirements you craft, or given specifications for the UI standard. However, it should not completely drive what you build, but like everything else, influence the design.
User interface topics can fill a book on their own (as many topics in this book), and that is outside the scope of this book. Fortunately, there are many great resources available when you work that particular area. Here are a few (complete references are in the “References” section ):
“Use Cases” from Usability.gov
“Throughput Requirements” from the Open Process Framework (OPF)
“Human Factors Analysis and Classification System (HFACS)” from the United States Navy
That said, there is one more important topic to discuss, Section 508 Compliance.
Section 508 Compliance
The federal government has mandated one aspect of usability to be implemented for most applications used by the U.S. government, especially those that the public accesses, to allow people with various diversity challenges to be able to use those applications and web pages. By “various diversity challenges,” the government means people with some visual impairment to include color blindness, hearing impairment, or physical disabilities that restrict how someone could use a computer or any electronic service that the government provides.
The following excerpt from “Resources for understanding and implementing Section 508” on the government’s www.section508.gov site indicates when it applies:
In 1998, Congress amended the Rehabilitation Act of 1973 to require Federal agencies to make their electronic and information technology (EIT) accessible to people with disabilities. Inaccessible technology interferes with an ability to obtain and use information quickly and easily. Section 508 was enacted to eliminate barriers in information technology, open new opportunities for people with disabilities, and encourage development of technologies that will help achieve these goals. The law applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology. Under Section 508 (29 U.S.C. ‘794 d), agencies must give disabled employees and members of the public access to information that is comparable to access available to others. It is recommended that you review the laws and regulations listed below to further your understanding about Section 508 and how you can support implementation.
Here are the instances where Section 508 does not apply:
In the event that a Federal department or agency determines that compliance with the standards issued by the Access Board relating to procurement imposes an undue burden, the documentation by the department or agency supporting the procurement shall explain why compliance creates an undue burden.
This section shall not apply to national security systems, as that term is defined in section 5142 of the Clinger-Cohen Act of 1996.
What does this mean to you? Obviously, if you fall under a federal agency, you must address 508 compliance. It is required. Do you need to identify each statement as a separate requirement? No. Point to those areas that apply to your project. For example, if there is no web site, that section of compliance does not need to be included as a requirement.
What if your organization does not fall under the jurisdiction of Section 508? Then, you are not required to address it. However, if your management has interest in including some aspects, maybe because of the size of the company or the need to support a diverse workforce, then you may include some aspects. Pick and choice was sections are appropriate based on your stakeholder input. There is no set prescription for what parts of 508 compliance should apply.
The official federal web site on Section 508 compliance is an excellent resource if you need to implement support for those who have disabilities to determine whether you should add requirements to support them. Even if it is not critical or required, it is useful to read about Section 508 requirements because they give some insights on how to support a very diverse user population. Relevant portions from Section 508 are included in Appendix C of this book.
References
International Ergonomics Association. “Definition and Domains of Ergonomics.” http://www.iea.cc/whats/
U.S. government. “Use Cases.” usability.gov. Feb. 2015, www.usability.gov/how-to-and-tools/methods/use-cases.html
“Throughput Requirements.” 27 June 2005. Open Process Framework (OPF) Feb. 2015, www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/ThroughputRequirements.html~Contents
United States Government. Resources for understanding and implementing Section 508. Feb. 2015, www.section508.gov/
US Navy, “Human Factors Analysis and Classification System (HFACS)” Naval Safety Center web site, http://www.public.navy.mil/navsafecen/Pages/aviation/aeromedical/HumanFactorsHFACS.aspx
Exercises
Exercise 1
How many attributes of a good requirement in Chapter 2 does this following requirement violate? Which ones?
10-1 DRAFT The system shall be user friendly.