From: Andrew Gabb (agabb@tpgi.com.au)
Date: Mon Sep 08 2003 - 20:08:42 EST
While I more or less agree with everyone here, I must push my Impurity
Principle again (or is it a Simplicity Principle, along the line of
Mencken's famous statement "For every complex problem there is a simple
solution, and it's wrong!").
Some of this is what I was coming to grips with in my paper "The
Requirements Spectrum", available from
http://www1.tpgi.com.au/users/agabb/. This paper points out that there
is a 'spectrum' of requirements, starting with the business and user
needs, down to the requirements for a component (usually a
specification). It's also why I tend to use the term SoR (statement of
requirements) for user/business requirements and 'specification' for the
hierarchy of system, subsystem, component requirements (mainly in the
solution domain). Don Mills comes at this from another direction with
conceptually similar results. The paper also points out that user
interface design is part of system design, and results in requirements
for a software product.
The original post (as I remember it) was asking in part about the combination of requirements and other characteristics appearing in the product documentation (or something like that), where some of those characteristics are specific to the solution or solution method. To me, this is where the concept of 'feature' becomes useful. The 'requirements' are likely to include a number of 'required functions' (or usages). The product will include a number of features, designed to meet the required functions.
For example, a client may ask me to design a product and we agree on a number of functions, usually as a set of activities or tasks which can be done using the product (in the smaller product commercial world). During analysis and design, I see the need for more functions (and possibly the spectres of other sales), and include more functions than are specifically agreed. This is common anyway in small projects, at least my small projects, because the agreed function list is always incomplete, and there is an unwritten assumption that the product will 'work' for the client. Otherwise you don't get paid. (Not to mention the Trade Practices Act here, which talks about fitness for purpose.)
If I write some promotional material to sell this product to other clients, I'll use both the task-oriented approach and other 'features' which the product addresses, which might include special techniques used to enhance data integrity and privacy, for example. Note that these are *designed* product features, which meet a more general requirement for data integrity. I include them because firstly some clients may value them (they are good selling points), and secondly because they stress features (and enhanced integrity) that my competitors may not have.
But this stuff is *not* requirements, it is a product description and the additional information may be useful to 'sell' the product and for prospective clients to evaluate it.
Which brings me to Donald's comments below, which I agree with in principle, but not always in practice. There are numerous valid situations where design constraints are imposed by the customer. One very common example is software written for a common/standard operating environment (COE/SOE), which may constrain many characteristics of the software (including user interface standards and other architectural issues) just so that it *works* in that environment, and the users see it as just another system component (to them). Hopefully, these constraints should be quite separate from the operational functionality needed. More about this in a subsequent post - this one's getting too long.
Having said that, there are also numerous situations where it's crazy to constrain some things. For example, the requirements for a certain submarine combat system included *requirements* for specific processor types (68030s from memory). There was also a requirement for a triple-redundant bus, rather than more specific requirements for reliability under specific conditions. Not smart at all.
Andrew
From: Donald Firesmith
> I totally agree with Scott and Soren.
>
> User interface architecture (overall structure, major components,
> relationships between these components, and strategic design
> decisions such
> as standard webpage structure) and user interface design
> (e.g., specifics of
> page layout such as location of diagrams and controls,
> selection of check
> boxes vs. radio buttons vs. pulldown menus) are just that,
> architecture and
> design and have no place in the requirements. If they show
> up at all, then
> they are (possibly unnecessary) architecture and design
> constraints and not
> functional requirements. Requirements engineers should leave the user
> interface architecture and design to the information
> architects and the
> usability/design folks who are trained in how to produce such
> products.
>
> This is the same as requirements engineers inappropriately specifying
> security architectural mechanisms (e.g., countermeasures such
> as passwords,
> encryption, firewalls, etc.) when that should be left up to
> the architecture
> and security teams. Thus, specify who you want identified
> and authenticated
> to what degree and under what circumstances instead of how. Maybe the
> architects and security folks will decide to use smart cards, digital
> signatures, and/or biometrics rather than easily cracked user ids and
> passwords.
>
> After all of these years, its embarrassing that we are still
> arguing for the
> removal of unnecessary architecture, design, implementation, and test
> constraints from the requirements.
This archive was generated by hypermail 2.1.6 : Wed Oct 15 2003 - 14:23:02 EST