I'm finally to the point where I can't code in a vacuum anymore. So.. upshot is that I'm producing honest-to-goodness requirements doumentation now, and not sad about it neither. Maybe we need a software management forum? Nah.

OK, what prompted this particular post was a small subsection of a Vision and Scope document which I'm working on, with which I'm rather pleased. Feel free to rip into me it. Basically, I'm balking at the common analyst practice of taking a user's perception of Time (la la la) and shoehorning it into management's perception of Time (tick..tick..tick). So I came up with the following subsection to throw into the latest V&S doc:

4.2 Project Priorities

4.2.1 Acceptable user-interaction times
A high priority for the system is that all users' interaction with data take place in a timeframe which is perceived to be acceptably fast. Specific minimum response speeds in repeatable, measurable time values are not to be specified in this document, or in any subsequent requirements or design document. Instead, the speed requirements for any part of this specification shall conform to the following named categories, roughly in order of total time taken. Keep in mind throughout that any Time category is specified by a maximum set of perceptual constraints; it is perfectly acceptable for any activity to come to completion in less time. Such a time scheme places the burden of measurement firmly on the perception of the end-user, where it should be; however, policy regarding acceptable timeframes remains in the hands of management and similar stakeholders in the requirements process. In particular, this frees measurement of system time from the vagaries of underlying networks, operating systems, and hardware, since these differing subsystems will in turn be factored into the user's perception of the acceptability of the time taken to perform the event or activity. In other words, users on slow links should have lower expectations about system responsiveness, within reason; however, this does not significantly alter the category into which each activity falls.


4.2.1.1 Immediate Time.
Events and activities which conform to Immediate Time shall complete in such a manner that the user is not able to distinguish their progress; that is, the response time tolerance shall fall squarely below that which is measurable by unaided human inspection. No indication of progress shall be deemed a requirement for the system. Examples of Immediate Time activities include:

• Displaying a character on-screen following a keystroke.


• Highlighting selected text (of moderate length)


• Repainting discovered windows.

4.2.1.2 Page Time.
Events and activities which conform to Page Time shall complete in such a manner that the user may notice a delay; however, any such delay shall not measurably affect work speed of the user. The amount of time added to a significant work process shall not measurably increase due to the delay introduced by Page Time events. This is quite common for human-interactive subsystems; the total time taken does not increase due to instinctive and parallel workflow-process improvements made by the end-user. Such activities shall offer an indication that processing is underway. Examples of Page Time activities include:

• Opening a new window in a web browser and populating its view.


• Updating a data objects' primitive properties.


• Password verification.

4.2.1.3 Analysis Time.
Events and activities which conform to Analysis Time shall complete in such a manner that the user may (probably will) notice a delay; however, any such delay shall be perceived by the user as reasonable and necessary to complete a complex task demanded of the system. Such activites shall offer an indication that processing is underway, with an indication of relative progress where possible. Examples of Analysis Time activities include:

• Retrieval of large or complex tables for display.


• Updates to multiple similar or interrelated objects.


• Spell-checking or find-and-replace applied to a large document.

4.2.1.4 Background Time.
Events and activities which conform to Background Time shall complete in such a manner that the user may notice a delay; however, any such delay shall not impede the user's workflow due to the ability of the user to complete parallel activities while the Background Time activity progresses. Such activities shall provide an indication of processing, and an indication of relative progress where possible. Examples of Background Time activities include:

• The actual time between a user clicking 'Send' on an email, and the time that email is delivered.


• Background printing; that is, the actual time between a user clicking a 'Print' button associated with a document, and the time that document begins or completes printing.


• The processing of a request which is relegated in a web interface to a "popunder", or background window.

4.2.1.5 Warehouse Time.
Events and activities which conform to Warehouse Time shall complete in such a manner that the user is logically but not tangibly aware of such a delay. For example, the user may have knowledge that the activity occurs once every evening, but is able to work without regard to the exact time that activity executes, except in limited situations. Such activities should have published time specifications, but do not need to indicate their progress to end users while underway. Server-side processing shall provide system administrators with indications of relative progress where possible. Examples of Warehouse Time activities include:

• Data warehousing activites, in which low-level details are summarized for management-level analysis, usually in another datastore designed specifically for that purpose.


• Hourly "batch" processes, such as garbage collection, integrity checks, or child property summation for a parent's consumption.


• Daily "batch" processes, such as automatic payments via credit card, or automated email reminders based on dated triggers.

4.2.1.6 Moderated Time.
Events and activities which conform to Moderated Time shall be limited to those activities which require the action of a human party besides the originating user to complete. Such activites shall indicate to the user the responsibility of the third party, and assume that the most significant delay in the process will be due to the behavior of the moderator; that is, the user shall expect to affect the completion of the process by interacting with the human moderator, and not with the system per se. Examples of Moderated Time include:

• Temporary access to subsystems to which the user does not normally have permission.


• The "posting" of a forum message on a forum which requires all posts be approved by a moderator.


• "Two-actor" systems which require that users act in concert to perform an activity. Such systems are commonly used to combat fraud.

I'd be especially interested to know if anyone has come across a similar spec, since I pretty much pulled this outta my *** this evening; I haven't researched or casually encountered anything like it. I'd also be interested in individual feedback with respect to the categories I've established, any events which fall outside those categories, or pitfalls one might see in translating this through the SRS to the design docs.

Too much Shakespeare, lately.. :)

4.2.2 Acceptable user-interaction times
It is highly important that users find the speed of the system acceptable. However, user perception is highly subjective, and system responsiveness depends on many things outside of developer control. Therefore, this and other design documents will not specify exact clock limits. Instead, each time requirement will specify a category of timeliness, one of the following:

4.2.2.1 Immediate Time.
Users perceive Immediate Time processes as instantaneous. Humans cannot measure them unaided. They do not indicate processing or progress. Examples of Immediate Time activities include:

• Displaying a character on-screen following a keystroke.


• Highlighting selected text (of moderate length).


• Repainting discovered windows.

4.2.2.2 Page Time.
Users notice Page Time processes; however, any delay does not measurably affect their work speed. In most cases, the user offsets any delays with instinctive workflow improvements. Page Time processes must indicate that processing is underway. Examples of Page Time activities include:

• Opening a new window in a web browser and populating its view.


• Updating a data objects' primitive properties.


• Password verification.

4.2.2.3 Analysis Time.
Users notice Analysis Time processes and categorize them as delays; however, they accept the delay, considering it reasonable and necessary to complete a complex task. Analysis Time processes must indicate that processing is underway, and indicate relative progress where possible. Examples of Analysis Time activities include:

• Retrieval of large or complex tables for display.


• Updates to multiple similar or interrelated objects.


• Spell-checking or find-and-replace applied to a large document.

4.2.2.4 Background Time.
Background Time processes are not always noticed by the user, since they do not interrupt their work. They allow other user actions to be performed simultaneously. They must unobtrusively indicate that processing is underway, and indicate relative progress where possible. Examples of Background Time activities include:

• The actual time between a user clicking 'Send' on an email, and the time that email is delivered.


• Background printing; that is, the actual time between a user clicking a 'Print' button associated with a document, and the time that document begins or completes printing.


• The processing of a request which is relegated in a web interface to a "popunder", or background window.

4.2.2.5 Warehouse Time.
Users understand Warehouse Time processes but are not normally affected by them. For example, the user may have knowledge that a process occurs once every twenty-four hours, but is usually able to work without regard to the exact time that process occurs. Such processes have published time specifications, but do not indicate their progress to end users while underway. Server-side processes indicate relative progress where possible to system administrators. Examples of Warehouse Time activities include:

• Data warehousing activites, in which low-level details are summarized for management-level analysis, usually in another datastore designed specifically for that purpose.


• Hourly "batch" processes, such as garbage collection, integrity checks, or child property summation for a parent's consumption.


• Daily "batch" processes, such as automatic payments via credit card, or automated email reminders based on dated triggers.

4.2.2.6 Moderated Time.
Moderated Time processes require the action of a human to complete. They indicate to the user who is responsible for the next step. They either notify the next party or inform the user how they may be notified. Examples of Moderated Time include:

• Temporary access to subsystems to which the user does not normally have permission.


• The "posting" of a forum message on a forum which requires all posts be approved by a moderator.


• "Two-actor" systems which require that users act in concert to perform an activity. Such systems are commonly used to combat fraud.