Use the inquiry pattern to define a screen display function that shows specified information to the user. The word "inquiry" implies that the information being displayed is not modified by this function.

Inquiries are the pinnacle of a system, in the sense that you've gone to great trouble and expense to gather valuable information—and now you finally get to show it to people. Specifying a requirement for an inquiry is straightforward enough, though there's potentially quite a lot to say, which is described in the list of content that follows. But there's also the question of how to decide what inquiries we need. This is all too often a hit-and-miss affair, a wish-list of anything anyone can think of.A free-for-all can leave us with some inquiries that no one ever uses, while others that are needed are missed. Inquiry requirements are numerous, so it's hard to tell whether something's been forgotten. One way to be more systematic is to start with pervasive requirements demanding that every item of information be viewable on at least one inquiry (as described in the Extra Requirements section later in this pattern). This means we needn't worry about simple and mundane inquiries. We can then concentrate on inquiries for a specific business purpose. If we forget anything, there will be an inquiry of last resort to show us what we want, even if it's not ideally suited to the task at hand.

The bulk of inquiries are for stored information (data from the database), but they can also be for dynamic information about the state of the system's hardware and software components, or information from attached devices (card readers or credit card payment devices, for example) or any other source of information.

This book spells inquiry with an "i" consistently (rather than enquiry). This was an arbitrary choice, but having decided, it's useful to stick to it rigidly. It enables you search on "inquiry" and be reasonably confident of finding every one.

A requirement that defines an inquiry should specify the following:

This is quite a long list, with too many topics to cover in a single requirement—though few inquiry requirements involve more than half of them. As soon as an inquiry requirement grows unduly large, divest the rest into separate refinement requirements. Each of the last three topics often deserves its own refinement requirement if there is enough to say about it.

This summary form is preferred to a verb-phrase form such as "View «Inquiry purpose summary»." This is because each inquiry needs a name—which the latter form doesn't provide, thus leaving an unknown someone, later in the project, to name it, and leaving us with no tie between that name and this requirement.

Here's a refinement requirement that defines the refresh characteristics of an inquiry:

A single requirement (plus any refinement requirements) usually suffices for an inquiry—which is just as well, because inquiries are numerous and we don't want the number of requirements about them to explode. But there are a couple of topics for which pervasive requirements can usefully be specified, and these are discussed in the following subsections:

The aim in both cases is to specify only once something we want, in general terms, rather than lots of times for individual cases. This both saves considerable specification effort and leaves out no part of the system.

Comprehensive Inquiries The premise of this section is that all the information in the system should be viewable, one way or another. This sounds like a sensible goal for every system, but it's rarely asked for. Who knows how many systems actually achieve it: not many, probably. A system having information that no one can get at—or which none of its users knows is there—can be dangerous. Once an omission of this sort is discovered, it's often resolved by means of an ad hoc addition, without normal validation and security controls. These requirements act as insurance if we fail to specify a comprehensive set of inquiries, and demand a comprehensiveness of inquiry coverage rarely found in requirements specifications. Here are a few sample pervasive requirements of this kind:

Note that if you have access control, there's still the possibility the system contains data to which no one has access—but that's a separate question.

These requirements cover business information, but one could, in theory, write similar requirements covering other kinds of things that are amenable to display in an inquiry—such as the status of hardware and software components. But this book does not attempt to go beyond business information because it's impractical to figure out just what constitutes all information for them, let alone whether it's worthwhile.

Requirements of this sort have wide-ranging implications—for developers, testers, and when estimating overall development effort: roughly speaking, for each kind of information (that is, each database table), an inquiry must be built.

Common Inquiry Characteristics Specify only once any characteristic that you want all inquiries (or all inquiries of a particular type) to share, rather than requesting it repeatedly for each one. It saves time and avoids the risk of individual requirements differing. Ask for characteristics that are good practice or that you want to standardize across all inquiries in the system. Here's an example that insists that every inquiry not only show information, but also make clear what information it shows:

Check that the information is available.

Consider whether there are potential performance concerns.

If the display is to automatically refresh itself, how easy is it to achieve that in the prospective user interface environment?

Testing that an inquiry requirement is satisfied must include displaying the inquiry to verify that it shows what it's supposed to.

Pay special attention to pervasive inquiry requirements, because they mean you must scour the system for all the inquiries they apply to—and then you must test that each inquiry complies. If there's a requirement that insists that every type of information in the system must be viewable by at least one inquiry, you have to go one step further and start by identifying all the types of information (which usually means all the database tables).

Use the report requirement pattern to define a report that shows specified information to the user. The information being displayed is not modified by the report—although it might involve some background generation of data.

A report is a way of presenting information—it's very much like an inquiry, in fact, so we must begin by explaining the distinction. Back in the old days, it was clear: an inquiry was something you looked at on the screen, and a report, something you printed on paper. But no longer. Scrolling lets us manipulate large quantities of information onscreen, and reports are viewed increasingly onscreen rather than printed out. This is a trend we should encourage, to reduce use of paper, wear and tear on printers, time waiting for printing, and the security risks of papers falling into the wrong hands.

When you need to show some information to a user, decide whether to specify it as an inquiry or as a report. Make that decision on a sound, rational basis, rather than arbitrarily just because someone had one or the other in mind. Factors to consider are:

If you get conflicting answers to these questions, consider specifying both an inquiry and a report for the same information.

The reporting needed for a serious business system is often—and perhaps nearly always—inadequately specified up front. It's hard enough to figure out the transactions that drive the system, so it's not surprising that there's little enthusiasm for working through lots of secondary and less frequent activities. With new views of the business wanted regularly, reporting for management, sales and marketing, and other areas remote from day-to-day operations is frequently the most volatile part of a system. So don't expect the requirements to be able capture them all. But the clearer the picture you can paint, the better: give it your best shot. At least eke out all the sorts of reporting that are needed, and get a reasonable idea of the number of reports. Ways to go about this are to examine the following:

It's not acceptable to write a sweeping requirement that covers multiple reports, especially if it's open-ended. Something like "a full set of finance reports" or "all reports required by the government regulator" are at best a hint that a lot is missing and are useless as requirements. If the specific reports cannot be pinned down, say so in informal text, not in a requirement.

Pay attention to special occasions on which reporting is especially important (especially ends of month, quarter, calendar year, or financial year). Don't make the mistake of getting the day-to-day reporting right and neglecting infrequent reporting tasks. Specifying "obvious" needs in a cursory manner could lead to reports that are unwieldy in practice and impose too great a workload on users during these busy times. Also, attempting to add these reports just before they are needed could unearth other omissions in the underlying system that cannot be fixed in time.

When investigating what reports are needed, you will gather much valuable information about who should receive them, how often, how many copies, how long they should be retained, and so on. These details don't belong in requirements because they are liable to change—and you should demand a system in which they can be changed at any time. But retain all the reporting information that is gathered, and use it when configuring the initial system. Concrete decisions on report production and distribution should be made in the lead-up to the system being installed, probably while it's being tested. If possible, let users experiment with a test system, to familiarize themselves with it. They can refine the reporting set-up and decide operational matters at that time.

Some organizations regularly print reports and file them away, or file away electronic copies so they can refer to them later as a last resort. This suggests the system itself isn't properly and reliably retaining information—that it has holes in its database design, often relating to historic data. It can also be a sign that users lack confidence in the system. Designing better systems diminishes this role for reports, so fewer reports might be needed. If you're specifying a replacement for an existing system, keep your eyes open for reports being used in this way.

A traditional report prints numeric and textual values in a formatted manner. But reporting products are typically able to produce various kinds of charts, so don't limit your thinking to conventional presentation. Equally important, though, don't introduce charts just because you can and they're pretty—constraining developers by mandating a chart when they might find a more effective way of achieving the goal. Concentrate on the purpose and content, not on the presentation.

An important factor to consider when specifying a report is how many pages it's likely to contain when it's run in practice. When you have a large database, it's easy to devise huge reports with more pages than anyone can ever wade through. (Sometimes users are interested only in the grand totals at the bottom.) Reports that allow the user to specify selection criteria can turn out to be unexpectedly large due to the selection values entered. It's useful to be able to specify the maximum number of pages that are allowed and to warn users beforehand of potentially long or slow reports.

A requirement that defines a report should specify the following:

The first five of these items are as described in the inquiry requirement pattern.

There are quite a few ways in which we might want to standardize all the reports created for a system. We can specify a pervasive requirement for each one we wish to insist upon. Here is a list of such requirements to consider including, some of which should be tailored to suit your environment:

A further pervasive requirement can serve as a catch-all, to avoid having to laboriously specify in the requirements lots of rarely-used reports while at the same time demanding the creation of reports for data not explicitly specified in the requirements (for example, derived data generated for performance reasons):

If a report writer product is used to deliver reports (which is usually the sensible thing to do), the development of each individual report is solely a matter of using the report writer's design tool. (If you're using an open source reporting product, the design tool—or tools—might come from different developers.)

First, identify all the circumstances in which the report can be run, and then simulate all those cases. For example, different types of users might run a report in different ways, or a report might be run in a different way on the last day of the month or following a public holiday.

Testing that a report requirement is satisfied involves running the report for each identified test case to verify that it shows what it is supposed to.

Also test reports against the pervasive requirements that apply to all reports. This can be sometimes be simplified: if the reporting product used is able to guarantee that a pervasive requirement is always satisfied, then it doesn't need to be tested for each individual report.

For any report for which selection criteria can be specified, entry of those criteria should be tested in a similar manner to a data entry function. Test that each value is validated appropriately. Then test that the expected entities were actually selected.

Testing a report needs to go beyond verifying that it satisfies its original requirement. A report might achieve its business purpose but still be impractical to use. If it contains extra information, it'll probably still satisfy the requirement, but it might render it hard to read the important values. Selection criteria might add flexibility, but if users end up typing in the same values every time, it's inefficient. View the report from user's point of view. Does it fit well into their workflow?

Simulate all days on which additional reporting is performed (year-end, quarter-end, month-end, and so on).

Use the accessibility requirement pattern to specify the extent to which the system (or part of it) must be accessible by people with a certain kind of disability or other specific need—that is, how convenient it must be for them to use. This requirement pattern takes such a broad view of "specific needs" that some apply to everyone, and it thus covers those aspects of usability (general user-friendliness) that are amenable to being defined in requirements.

Accessibility is generally taken to mean providing access for people who have disabilities of various kinds and degrees of severity (ranging, for example, from color blindness through low vision to blindness). That's certainly the motivation for accessibility legislation and standards. The people affected are often regarded by businesses and by builders of systems as a small minority who can be safely ignored. But people who can benefit from accessibility features in systems constitute fully 60 percent of adults of working age (according to studies cited at the end of the Example(s) section later in this pattern). And taking steps to help those who have difficulties or impairments can make such a difference to them that they deserve consideration out of proportion to their numbers. Providing accessibility for those who need it also improves usability for everyone. So this requirement pattern talks in terms of "specific needs" and takes an open and inclusive view of who has them. They go beyond people with disabilities to embrace people who aren't computer literate; people who lack linguistic skills (such as people with cognitive difficulties or speakers of English as a second language); people who could suffer eye, hand, or brain strain when using the system; people who have never used the system before; or people who are experienced "power users" of the system. In short, accessibility embraces everybody in one way or another. This is a novel way of looking at some of these situations.

When discussing disabilities, terminology is a very sensitive issue. It is easy to sound demeaning or patronizing even without realizing it. Terms for a particular disability, or for the subject in general, often acquire negative associations and new terms are then introduced. This book even introduces the term "specific need" to avoid the more common "special need," which is itself beginning to be regarded as condescending. When writing about this subject, take care to treat every group of people with respect.

The poor accessibility of the vast majority of systems is a powerful sign that there isn't a strong enough business case for doing better. Another factor is low awareness of the need for systems to be accessible—which means the case for accessibility isn't being made as well as it might, a situation that better requirements specifications can help remedy. There are several sound arguments for a business to make a system more accessible: (1) a law says you must; (2) it will attract more customers; (3) fewer people will raise customer service issues; (4) it will make employees more productive. Not all apply to every system. Getting management support can be a hard sell, and even then resources for accessibility might be the first to be cut when development is under pressure. Merely helping people isn't a motivation for a hard-nosed business—though I suspect it's likely to motivate developers more than any of these business reasons will, which is important because it will give them more interest in doing a good job.

There is no usability requirement pattern in this book: it is deemed not to deserve one. That's partly because our broad treatment of accessibility covers many aspects of usability, and partly because attempts at guaranteeing usability via requirements fail miserably. A couple of sensible steps are covered in the "Usability" subsection of the Extra Requirements section of this pattern, along with more on the drawbacks of usability requirements.

All accessibility-related requirements apply both to the software we develop and to the technology we use—most importantly, to third-party products that deliver parts of our user interface. If you specify requirements for any infrastructure that the system needs, include a requirement (as per the refer-to-requirements requirement pattern in Chapter 5) that states that all our accessibility requirements apply to it, too. We can also ask that more fundamental technology (especially the operating system and Web browsers) offer accessibility features that help satisfy our accessibility goals (or, at least, don't render them unachievable).

Accessibility-related requirements can be specified at three levels:

The second level is a more detailed picture of the implications of the first level, as the third level is of the second. You can therefore write as informal material (rather than requirements) any level that's spelled out in more detail. It saves everyone's time and avoids contention between the levels. For example, testers don't have to worry how to test against a type of specific need if all its implications are covered in specific requirements. Nevertheless, if a system must comply with a particular law, that, too, is a concrete requirement and should be presented as such—though you can indicate that it doesn't need to be tested in detail because its implications have their own requirements.

If a law has detailed stipulations, represent them at Level 3. You could therefore omit Level 2, but I suggest this equates to satisfying the letter of the law and ignoring its spirit. To me, Level 2 is important because it's the one concerned with the people we're trying to assist and thus motivates developers more than requirements whose purpose is less obvious.

Here are a few representative Level 1 requirements:

Observe that each of these examples cites the year that the applicable law was enacted, or a version of a standard, to make it clear the system won't automatically be aware of subsequent amendments (if there were to be any).

Whenever we break down a requirement into lower level requirements that represent its implications, we want a systematic way to do it—to give us confidence that we haven't missed something. So how can we go about finding the kinds of specific needs we want to deal with? For this purpose—and stepping away from our gentle concern for people for a moment while still looking at a system from the user's point of view—we can treat a human being as a typical system with three main kinds of components: input, processing, and output:

We're interested in disabilities here only to the extent that they create distinctions that affect the steps that a system must take to assist. As a result, these categories are inexact and a little arbitrary. For example, a user might be slow to respond because of dexterity difficulties rather than because they're slow to make decisions. But if one response is for the system to give users as much time as they need, the reason is immaterial.

Some people with specific needs can only use computers with the aid of specialized devices and/or software products—called assistive technology— of which there's a wide and growing range, designed to help in diverse ways. We don't need to discuss them here, though analysts and developers concerned with accessibility will benefit from an understanding of the most significant types. (Information about types of assistive technology, products, and manufacturers can be found at http://www.microsoft.com/enable/at.) One of the most important aspects of making a system accessible is allowing assistive technology to work effectively. Anyone who uses assistive technology relies upon a chain of support that utilizes special features of the operating system, Web browser, and more. It would be a shame if that chain broke because the last link was an HTML page, from your system, that was written in a careless manner.

The first step in making a system accessible is awareness. Analysts, in particular, need to understand the issues in order to write good accessibility requirements. A company then needs to create accessibility-related guidelines and/or standards that suit its way of developing systems. Much of this requirement pattern is written as if achieving accessibility is an overhead, but if it becomes second nature, that overhead is significantly reduced. When software and other elements of the user interface are built with accessibility in mind from the outset, less extra work is needed.

An accessibility requirement should contain the following.

Separating accessibility into several Level 2 requirements allows those areas with the greatest impact to be prioritized higher if we don't have the resources to make the whole system fully accessible from the start. It might seem harsh to postpone accessibility for one class of users (say, employees), but if we have a thousand times as many customers as employees using the system and the organization can't afford to implement all accessibility requirements right away, it maximizes the benefit. On the other hand, if a law says our system must be accessible to employees, but the law doesn't apply to customers, we'd probably do the reverse. But again, legislative changes might impose higher accessibility demands throughout the system.

This summary format is a little long-winded, but that's to make it clear that the purpose of such requirements is to benefit real people; a more concise "«Specific need name» accessibility" sounds too impersonal to me.

The specific need percentages cited in the preceding examples come from the following two research studies conducted by Forrester Research, Inc. on behalf of Microsoft Corporation:

The bulk of the requirements in this section are for features that contribute to satisfying one or more accessibility requirements; that is, they are requirements at Level 3 as described in the Content section earlier in this pattern. They are divided into the topics that follow, and each is dealt with in its own subsection that follows. ("Specific need steps," however, has a separate subsection for each of four types of specific need.)

This section doesn't pretend to satisfy all the provisions of any particular accessibility law but uses the provisions of Section 508 of the U.S. Rehabilitation Act as its starting point, because that's the most prominent such law and the one whose stipulations go into the greatest detail (at the time of writing). This section addresses all the main demands as they apply to the software of a system. But this section isn't comprehensive: it ignores other clauses that don't affect typical commercial systems, such as the captioning of instructional videos, special environments (for instance, user interaction via a telephone), or embedded systems. Check what's relevant to your system, and write requirements on any additional topics that apply to it. The underlying principle is that everything that you present to your users should be accessible. Any requirement relating to a law or standard should identify which clause (and which law or standard) it satisfies or contributes to satisfying. If you're building a system for multiple jurisdictions, you might need to mention more than one law.

Many of the examples that follow contain a statement that they are "intended to satisfy" particular clauses of Section 508. These are indicative only; they represent only my (non-legal) opinion. When you specify real requirements yourself, however, you should make stronger statements: write that they are "deemed to satisfy" or that they "satisfy" the relevant clauses. But if you do so, you must verify thoroughly that each requirement does achieve what it claims. Whenever a system must comply with a law, the steps needed to achieve compliance must be identified, identified as early as possible, and seen by the widest possible audience. To achieve those goals, the requirements are the place to identify the steps, and the place to state categorically that you believe that each requirement is sufficient to satisfy the part of the law to which it relates.

All the examples that follow are, as all requirements should be, as technology-independent as possible. Even those stipulations of Section 508 that are specifically for HTML are expressed here in general terms. This section uses the term presentation unit to mean a self-contained set of information that is intended to be displayed together, such as an HTML page. However, where relevant, each example explains the implications when HTML is indeed the medium. Some technologies contain features that make it easier to implement accessibility, but this isn't the place to discuss them. If you're using a particular technology (say,a browser-based user interface), you can write requirements for specific ways in which it must be used to improve accessibility.

General Accessibility In examples that are self-explanatory enough not to need further introduction, this section covers a few good practices and matters that apply to more than one kind of specific need.

The following are two alternative ways of approaching the matter of users having to respond in a given length of time. Avoid the first whenever you can, because it involves a more complex user interface for the user and the building of additional functionality.

A related matter is screens that automatically refresh without the user asking:

People with specific needs must be able to authenticate themselves when biometric means are in use (that is, when a uniquely distinctive body part, such as a fingerprint, is used to identify the user). (See the user authentication requirement pattern in Chapter 11 for more.) The following example insists on that users who are unable to use a biometric reader must still be able to authenticate themselves:

Specific Vision Needs The vast bulk of information presented by commercial systems is designed to be visual, which is why this subsection has the most subjects for requirements. Many of them are intended to help assistive technology to present information in an alternative way, which is difficult enough at the best of times. Take a look at the source of an HTML page and try to pick out the bits that a user is interested in: for a rich page, it's not easy, even without the myriad tricks that page writers use to get just the right appearance. Or imagine explaining the contents of a Web page to someone who can't see it, when at the same time you can't see any of the graphics in it.

Let's start with the biggest single driver of assistive technology, which affects the building of every part of the user interface:

Don't be a nuisance when users with specific needs have less free screen space than other users:

The following two examples relate to the screen focus. You might think that you needn't worry about screen focus matters because standard user interface technologies take care of this themselves, and to a large extent they do. For example, a browser displaying HTML pages can be expected to do so. But these requirements are still important as instructions to developers not to break them (if there are ways to do so—for example, using scripts embedded scripts in HTML pages). In addition, when choosing a user interface infrastructure, add these to the requirements that it must satisfy.

If you have text to display, then display it as text; don't use graphics or anything else that assistive technology can't make sense of. Even attaching the text itself to an image of a piece of text is tedious to present non-visually.

Here's a rule to insist on universally:

Now for a few rules on using color responsibly:

Presenting an image to a user and inviting them to interact with it is impossible in most cases if the user can't see it. Section 508 focuses on a specific case for which special provision can be made: what are called "image maps," where clicking on a nominated region initiates an action associated with that region. Situations where a user is asked to point to a position on the screen (such as on a geographical map or when using a graphics editor) are monumentally hard to present non-visually; either avoid them altogether, or recognize that this part of your system is not accessible. Here are a couple of alternatives to choose from:

Whenever software dynamically generates what the user sees (as in a script embedded in an HTML page), assistive technology might not be able to keep track of what's going on—so neither will the user. A script is generally either purely cosmetic (to make the display prettier) or it does some real processing. In the first case, we can ask for a non-script textual alternative for users with a visual disability or impairment—most of whom won't benefit from the extra prettiness. It's unreasonable to ask for a non-script alternative in the second case, because that means duplicating the functionality; it's better to demand that the script use standard user interface components that accessible technology can detect and interact with. These complementary approaches are reflected in the following two requirements:

Specific Sound Needs Sound is very much a secondary output medium in most systems, especially commercial systems (except for sound produced by assistive technology such as screen readers). Making a system convenient for a person with hearing difficulties to use should therefore be easy enough. But bear in mind that removing sound outputs altogether can cause difficulties for other users (particularly those with visual impairments). Here are two alternative ways to deal with the use of sound for alerting the user:

And here's one other method that gives users some control over sound:

Specific Cognition Needs Our aim here is to make the system easier to understand. It's hard to demand this in requirements, because the most important aspects are subjective—such as to write all text in clear language (mentioned in the equivalent Level 2 requirement in the Example(s) section). Section 508 makes one narrow demand:

One further aspect is covered in the preceding "General Accessibility" section: giving users all the time they need to respond.

Specific Dexterity Needs Manual dexterity is relevant to us only as far as it relates to instructing the computer to do something. The contemporary devices of choice are a keyboard and a pointing device (typically a mouse). It's reasonable to assume that control over any assistive technology used to perceive computer output can be achieved using the keyboard, mouse, or a means built into the technology. Requirements need not be concerned with how assistive technology might achieve this (though analysts, developers, and testers would benefit from knowing). Here's a requirement to make input easier for some:

Tailoring to an Individual User There are three ways to make a screen in a system accessible to users with specific needs:

These three approaches are not mutually exclusive. The first way should always be implemented to its fullest extent, even if the second and/or third ways are needed, too.

Tailoring our system for each user gives us much flexibility. There are two parts: providing a way for a user to specify their preferences, and then taking those preferences into account when presenting the user interface to them. For a Web-based system, we can create lean HTML pages devoid of any baggage that the current user doesn't want. Here are a few things for which we could beneficially define user preferences:

Alternatively, for some of these factors, you can use values that are chosen by the user and recorded as operating system settings (such as system colors and fonts). This saves users the trouble of having to express their preferences more than once.

Be sensitive in what you ask users. Don't ask about disabilities directly. Each item in this list is a way in which the system can be tailored, and if you ask in these terms, people are unlikely to be offended. Offer an "I don't care," "no preference," or "no response" option if the question is a matter of any sensitivity at all. Also, never ask for preferences that aren't implemented; it can be very frustrating.

Just for completeness, here's a requirement for the option that Section 508 permits to offer an accessible alternative for each part of the user interface that isn't accessible:

Documentation and Support There's no point in going to the trouble of making your system accessible if no one knows about it or no one knows how to take advantage of its accessibility features. More generally, users with specific needs should be able to obtain general assistance as well as anyone else. The following requirements convey these goals:

Certifying Compliance It isn't always enough for a system to comply with a law. Sometimes, you have to document how well it complies. In the case of Section 508, companies wishing to sell electronic and IT products to the U.S. government must fill in a Voluntary Product Accessibility Template (VPAT). It's handy to know in advance whether a document of this nature is expected, because parts of it can then be written while the system is being built. As examples, completed VPATs for Microsoft products can be found at http://www.microsoft.com/industry/government/section508.mspx.

Here's an example requirement:

Usability Usability is important, but it is a matter of good user interface design and not something that requirements can guarantee. No matter how hard the requirements might try, it's always possible to build an unfriendly system that satisfies them: there's no magic prescriptive way to prevent it. It depends on using good user interface designers and involving user representatives. Conducting usability studies with people with disabilities can also provide valuable insights on the practical usability of a system.

Usability requirements often ask for user interface characteristics that sound attractive, but which are define in such imprecise terms that they're meaningless to developers and testers. They ask for the user interface to be "easy to learn" or "intuitive," to have a "logical flow of input," to "use softly saturated colors," or to "group information by subject." They sometimes mandate particular user interface constructs—drag-and-drop, check boxes, drop-down lists, toolbars, for example—without indicating in what circumstances they should be used; these are all part of the design, and requirements have no business getting involved at this level. Leave the user interface designers and developers to pick the best user interface component and technique for each task. Unhelpful or unnecessarily constraining usability requirements do nothing but reduce developers' confidence in whoever specified them.

That leaves little for example usability requirements to say, but here are a couple of token efforts:

To do a good job developing accessibility capabilities, there are three areas that a software engineer should as a starting point have a working knowledge of:

Developing to help assistive technology, then, involves providing as much semantic information as possible—that is, to signal, as far as you can, the role and purpose of each item that you present on the user interface.

IBM's developer guidelines for accessibility—at http://www.ibm.com/able—contain implementation suggestions for popular technologies (including HTML, Java, Windows, and Unix). The guidelines themselves mirror Section 508 to a large extent.

Before doing anything else, testers should gain an appreciation of accessibility issues and an understanding of all relevant laws and regulations (such as Section 508).

Some accessibility features are amenable to a certain degree of automated testing, and there are many available resources that can help you test the accessibility of a system. In fact, accessibility features built into the operating system itself and standard applications such as Web browsers can themselves drive automated testing. Get to know the tools that are most suitable. For a start, there are several (some of which are free) that analyze HTML pages and tell how accessible they are and how to improve them, including

In addition, some browsers allow you to see a text-only view of any Web page you visit.

Verify that user interface resources (such as HTML pages) adhere to guidelines and standards (for example, that they both use accessibility-friendly tags and do so in the correct manner). This is easier than testing the user interface's accessibility.

Try using the system with a few different types of assistive technology, both those built into the operating system (such as a screen magnifier and screen reader) and dedicated products. Use the system without the mouse for a day or two. Put yourself in the shoes of each type of user with specific needs. Ideally, involve people with disabilities in your testing; they will give you a better picture of your system's accessibility than anything else. Testing accessibility thoroughly is expensive and time-consuming.

One approach to putting yourself in various users' shoes is to invent a range of "personas." This is a concept that Alan Cooper describes in his book "The Inmates are Running the Asylum," 1999, and the idea is that you create a handful of fictitious people as realistically as you care to and then imagine how they would react when they use your system. In effect this takes the notion of "actors" one step further, so you create several personas for an actor. It's impractical to do this for more than one or two actors, so pick those that are the most important—say,a customer. Then devise a persona for each kind of specific need that you want to test, give them a name, a brief life history, and a personality: Chris is color-blind, Martine is hard-of-hearing, Nelson has one arm, Great-Uncle Augustus is computer illiterate, and so on.

IBM's developer guidelines for accessibility (mentioned in the Considerations for Development section) contain detailed testing advice for each guideline.

A user interface infrastructure is a coherent set of components that together enable a user to interact with the system, excluding anything developed as part of a specific system, general underlying software (such as an operating system), and hardware. That is, a user interface infrastructure is what's left if you take away the system and everything it needs to run that isn't wholly related to the user interface. For instance, the user interface infrastructure for a simple Web system might comprise a browser and a Web server. Unfortunately the pieces we're left with are usually tied to a particular technology, which we want to avoid as far as we can. A Web server is usually an implementation detail that requirements needn't worry about—but a Web browser is visible to our users, so we can't ignore it. This leads us into a dilemma about how much to say about a user interface infrastructure. Four possible approaches are as follows:

The user interface is an area for which we might need more than one instance of an infrastructure. We might have different classes of users who have very different user interface demands. This is particularly true if we have specialized end-user devices—for example, in the case of a payment processing system with EFTPOS terminals for users in stores and PCs for internal users.

The subject of user interface infrastructures is often ignored completely in requirements specifications—usually without noticeable impact, no doubt because adopting a user interface technology is such an obvious need that projects take it in their stride. However, any area of functionality for which we have no explicit requirements is liable to be tackled in an ad hoc, unsystematic, and uncontrolled manner, perhaps according to the whims and prejudices of a senior member of our development team. As a result, the chosen solution might not be the most suitable for our problem—even if the person who makes the choice is competent to decide—because some important factors might be unknown to them at the time. A better solution might be overlooked.

User interface invocation requirements do two things: first, they constrain the technology that can be used; and second, they state capabilities that the user interface must support (that is, things users can perceive when using the system's functions).

Technology constraints don't need to mention specific technologies or products but can include factors that influence the choice of technology. These can include salient characteristics of devices from which the system must be accessible. Here are a few examples:

It's important to strike the right balance between a broad sweep and being too narrow—which is often not easy. For instance, the "Access via Web browser" requirement carefully avoids committing the system to working with every version of every browser every developed, while at the same time not mentioning specific products or version numbers. It introduces a "rolling window" that automatically keeps up with the latest releases. Write these requirements to be timeless: as far as possible, we want them to be valid in five years' time, and we can't predict what product versions will be in common use then (or even what products).

Here are a few examples of capabilities to be supported by a user interface:

Commercial systems typically make use of user interface infrastructures built by someone else, outside the scope of the system. (That is untrue only for truly exceptional systems that require the building of their own specialized hardware devices, which we won't worry about here.) Usually, our user interface implementation requirements are limited to extensions to existing third-party products—if any. These requirements are typically relatively limited in their scope—for example, some special-purpose graphical widgets or an application programming interface (API) wrapper to make a product easier for developers to use or to mask implementation details. As a result, a user interface infrastructure is unusual in that its invocation requirements are usually more extensive than its implementation requirements.

We only need to consider detailed user interface implementation requirements if we want to undertake a rigorous process for the selection of a solution product (for a Web server, say), in which we want to perform detailed comparisons of alternative options.

A reporting infrastructure produces reports for us and usually lets us design new reports. You might decide to broaden this scope in various ways—such as to include matters relating to the database(s) on which the reports are produced, to add access control requirements not accommodated by off-the-shelf products, and to distribute and store reports after they have been produced.

The core of a reporting infrastructure is invariably a mainstream product built for the purpose. However, this might need to be augmented by extra capabilities we must build for ourselves, particularly if our infrastructure's scope goes beyond simply producing reports. Conceivably, our reporting requirements might be too onerous for a single reporting product to satisfy, and we might have to employ two or more products (for example, one for producing reports and one for designing them). If you specify requirements that cannot be satisfied by the known capabilities of commercial reporting products, be prepared for your reporting infrastructure to become a major undertaking.

Occasionally, organizations expect their reporting infrastructure to compensate for deficiencies in their database design, and therefore ask too much of it—especially its ability to cope with grotesquely complicated queries and joins. Be alert to this possibility. The result can be reports that are fragile and inefficient.

This section uses the term report to mean the definition of one type of report, and report instance to mean the results obtained by running a report at a particular time.

A database usually acts as the primary interface between a system and the reporting infrastructure that produces its reports: the system places data in the database, and reports then read it. The first invocation requirements we must consider are those that give us all the database access capabilities we need. For example, if we have multiple databases, we might need to let our users choose which database to run a report on, or to run reports across more than one database. We might want to introduce a new database solely to run reports on, so they have no performance impact on the rest of the system. Requirements of this sort can become extensive and complex—and could justify turning them into a separate infrastructure in its own right. Strictly speaking, the types of requirements cited for database access could be considered implementation requirements, since they are features internal to the reporting infrastructure. But databases certainly act as an interface, and if we regard any interface as invocation-related, it is correct to class these as invocation requirements.

Other types of invocation requirements to consider are as follows:

The major areas to consider in the implementation requirements of a reporting infrastructure are: