InfoPath Requirements

Contents 1 About Requirements 2 Problem Domain 3 User Stories 4 Use Cases

About Requirements

Application requirements should express what functions a system is expected to provide within the context of a well understood problem domain. They address the what, the when, and the why of a problem, while avoiding the particulars of the how. We'll take a user-centric approach to the requirements, writing user stories and use cases.

As used here, a user story explains the user’s intent, what they would like the system to do for them. The associated use case elaborates how the user interacts with the system, providing a narrative with an outcome that fulfills the functional requirement summarized by the user story.

The user story should speak from the user's perspective, avoiding any reference to existing or proposed technology. It can be casual and general, but should make sense on its own terms.

The use cases do have knowledge about system components, though only on a conceptual level. They should also be user-centric, more concerned with describing a workflow than how that work is enabled.

The user-centric approach to planning is helpful for tackling issues within the problem domain. This focus keeps everyone thinking about what the user is trying to accomplish. The answer may not be a technological solution, it could be procedural. Another benefit is that the planning documents provide an excellent starting point from which user documentation can be derived.

Problem Domain

work-in-progress

(From what I've been told,) Infopath is used to create rich GUI electronic forms and faithful representations of those forms on paper. The technical richness of Infopath electronic forms (the widgets, control structures and layout) assists the user in coding and recording his or her observations, judgements and decisions accurately and unambiguously in a standardized lexicon. These forms, when used by the clinician, can directly enable decision support. The coded records, however they are recorded, enable automated analyses and feedback.

Because of its static two-dimensional nature, the paper form has less power of suggestive guidance for the clinician. Through its field selection, grouping and prominence and its use of labels and notes, the form can be used to encourage thoroughness and to suggest relevance; however, its primary function is to accurately record the clinical encounter in a way that can be accurately transcribed.

The current problem domain has two sub-domains, differentiated by the medium used by the clinician. In the ideal case, the clinician records the encounter in the system by use of an electronic form that can be programmed to react in helpful ways to his or her entries. In the other case, the clinician records the encounter on paper for transcription by a clerk. In this later case, a primary design criteria of the paper form and the sole purpose of the electronic form are to facilitate fast and accurate data entry by the transcriptionist.

User Stories

work-in-progress

Use Cases

Direct clinician entry

Clinician

Paper form and its transcription

standard practice:

• batch control of forms
• "heads-down" double-entry
• error resolution using mimiced form

-Clinician

Data-entry clerk

Data editor