From: Didar Zowghi (didar@it.uts.edu.au)
Date: Tue Nov 27 2001 - 17:28:58 EST
Don Mills wrote:
> At 13:19 16/11/01, Mahmood Niazi wrote:
>
> -----<quote>-----
> >If any body could explain the concept of usability requirements.
> -----<end>-----
>
> I think the concept has been quite well explained by prior respondents, Mahmood, so here's a slightly different perspective. As a tester, my concern with requirements is, "how do I know they've been satisfied?" To determine whether or not they have, I must be able to measure their implementation. For functions -- which are binaries -- this is simple in principle: either the software does what it's supposed to do, or it does something else. (Even here, of course, it's *not* necessarily simple to define "what it's supposed to do", especially in English - just think of the potential problems in English of AND/OR precedence, or of inclusive vs exclusive ORs ...)
>
> USABILITY is a type of requirement generally described as "non-functional", concerned not so much with WHAT the software does as with HOW WELL it does it. Another term for these requirements is "quality attributes". Occasionally, such requirements are binaries, but mostly they're scalars -- for example, "extremely good" vs "okay" vs "barely acceptable" vs "rather poor" vs "unacceptable" vs "disastrous". The quuestion is, how do I (the tester) *measure* points along such a scale?
>
> Tom Gilb (the inventor / discoverer of "software metrics") and his son Kai have done a lot of work in the area of "quantifying qualities", as they call it, and (with the assistance of a number of people in a number of organisations) have evolved a method known as "Planguage" ("Project / Process / Planning Language"). Planguage is central to their "Competitive Engineering" process; you can download the manuscript for Tom's book on this, due for publication shortly, from <http://www.result-planning.com/> -- use the drop-down selection list to "Go directly to" the resource, "Requirements. Practical Advanced Requirements Engineerring Course Slides" (you'll find his most recent course slides there as well).
>
> Central to Planguage is the following idea: "If lack of quality can destroy your project, then you *can* measure it *sometime* -- the only question will be, *how early*."
>
> In Planguage, a Requirement is first *described* in a short sentence sometimes called the GIST (or more recently, the AMBITION or INTENTION), then *defined* via a number of keywords and associated parameters. The entire definition is given a unique identifier called a TAG. I'll provide an example shortly, but first must point out that one of the principles incorporated into Planguage is that "most quality ideas are usefully broken down into several measures of goodness." As an example, measures (scales of measurement) relevant to USABILITY might include:
>
> EntryQualification: Scale: IQ, ...
> LearningEffort: Scale: hours to learn, ...
> Productivity: Scale: Tasks completed per hour, ...
> ErrorRate: Scale: Faults committed per 100 tasks, ...
> Satisfaction: Scale: % of users who like the system, ...
>
> In defining measures or concepts such as these, Gilb proposes a number of other principles. Two of them are:
>
> "The principle of BENCHMARKS: Past history and future trends help define words such as 'improve' and 'reduce'."
>
> "The principle of NUMERIC FUTURE: Numeric future requirement levels complete the quality definition of terms like 'improve'."
>
> In the following "miniaturised" example of a Planguage definition (based on one of Tom's course slides), Planguage keywords are capitalised, and parameters to the keywords (which impose conditions) are enclosed in square brackets.
>
> ------------------------------------------
> Usability.Learning:
> SCALE: Average time to learn task.
> PAST [OldProduct, 1999]: 20 minutes.
> WISH [NewProduct, 2002]: 2 minutes.
> MUST [End 2000, Students]: 15 minutes.
> PLAN [End 2003, Teachers]: 5 minutes.
> ------------------------------------------
>
> The TAG is the two-level term, "Usability.Learning"; the embedded point identifies it as a more detailed component of the higher-level, more general, requirement, "Usability". WISH specifies the level we would like to be able to achieve in our dreams: it's an ambition, *which we'd happily accept* if it actually turns out to be achievable. MUST is a survival level: if we don't achieve this, our product's dead. PLAN is what we intend to achieve (at a minimum!) to provide our *competitive advantage* in the marketplace.
>
> As a miniaturised example, this leaves out many important elements. What's our basis for the PLANned level? How reliable an estimate is it of what's *really* achievable? What mechanism (METER) will we use to *measure* success in learning? What "task" do we mean, and what's the initial level of performance of the people we'll be testing?
>
> Planguage not only allows you to provide answers to questions such as these, it insists you should. This is all part of the process of "specification". I repeat (amended following criticism!) a definition I gave in a posting to SRE (14 August at 11:52):
>
> -----<quote>-----
> >A specification is a document or set of documents that provides specific information as the basis of future work to be done, or of work that has been completed. "Specific" means "Clear, complete, consistent, detailed, and unambiguous; not open to assumptions or multiple interpretations with regard to meaning or use." A document that fails to fit these criteria, fails as a specification.
> -----<end>-----
>
> "If it's not specific, it's not a specification: it's an ification." Another word for "specific" is "definite", which easily morphs into what a specification should do: "define it". Planguage is a vehicle for achieving measurable definitions of non-functional attributes such as USABILITY.
>
> Finally, here's a more complex specification of USABILITY adapted from Tom's course slides. In this example, terms preceded with an asterisk (e.g., *User) are locally-defined terms for which the definitions are appended to the "Usability" specification. The left-pointing arrow ( <- ) shows that the information on the left derives from a source named on the right. The MUST (survival) level of achievement is referred to elsewhere, and so has been given its own tag, "Usability.MinLevel" (the "Usability." prefix is inferred, but must be used in any *external* context). Angle brackets ( < > ) enclose ideas which are not yet firmly defined.
>
> ------------------------------------------------------
> Usability: the relative ease of learning and using a defined product compared to previously used products.
> SCALE: average minutes per [specified *User type] to learn to accomplish [specified Tasks using the product].
> METER: at least 30 users representative of the specified *User type will be monitored doing at least 10 Tasks of specified type.
> PAST [OldProduct "PP", HomeBuyer, Adult, Task: Build telephone number list] 30 minutes.
> RECORD [Product "MM", Adult, Task: DialOut] 10 seconds <- Consumer Reports, January
> TREND [US Market, Children, *Mix] 20 minutes <- Market Analysis, Feb.
> WISH [Our Customers, *Mix] 5 minutes <- Chairman’s Dream in Speech
> MinLevel: MUST [Our Customers, *Mix, New Product] 10 minutes <- marketing minimum
> PLAN [Our customers, Mix, NewProduct, *FirstFieldRelease] 50% of MinLevel? <- Guess by Project Mgr.,
> [within 2 years of First Field Release] 30% of MinLevel <- Guess.
>
> --- Local Definitions of Terms ---
>
> Mix: Defined: <representative mix of common frequent user tasks.>
> User: Defined: person who intends to use the product in the long term, not a test person.
> FirstFieldRelease: Defined: First sold releases to any public market after Field Trials
> ------------------------------------------------------
>
> There is still a substantial amount that could be done to improve the clarity of this example -- what kind of "average" do I have to measure, for example, to determine the "average minutes ... to learn to use" the NewProoduct? If, come testing time, I use a method different from the one the author intended -- (quite likely, since I'm not a mathematician -- what's the difference between geometric mean and arithmetic mean?), I may produce a result of "extremely good" where it should have been "disastrous", and we may launch a product that spells the death-knell of our company. (And whose fault would that be?)
>
> Warm regards to all members of the new, revised, and (I'm sure) improved list,
>
> -- Don
> ______________________________
> Don Mills
> Senior Consultant
> Software Education Associates Ltd
> PO Box 38-998
> 1 Nevis St, Petone,
> Wellington,
> New Zealand.
> ______________________________
> email: <DonM@SoftEd.com>
> website: http://www.softed.com
> ______________________________
> Tel: (64) (4) 568-7806
> 0800-COURSES
> Fax: (64) (4) 568-7920
> Cellphone: 025-222-7684
> ______________________________
> From Australia:
> Tel: 1800-145-152
> Fax: 1800-145-715
> ______________________________
This archive was generated by hypermail 2.1.6 : Fri Feb 21 2003 - 11:30:37 EST