From: Andrew Gabb (agabb@tpgi.com.au)
Date: Sat Apr 24 2004 - 16:34:09 EST
Pnina Soffer wrote:
> I'm looking for information about RE methods that take a
> bottom-up approach (or some combination of top-down and
> bottom-up). Most RE methods suggest a top-down approach, which is
> a natural approach for an outsider who wants to systematically
> learn, understand, and analyse the needs. However, information
> obtained from users who state their needs may address very
> low-level details. Is anybody familiar with a method that
> systematically addresses such low-level details in a bottom-up
> (or mixed) process?
Generally I've found that users state their needs in a mixture of high level and low level, and never solely at a low level. Most common is a mishmash of high level needs and low level *implementation* features. In all cases, the needs as stated are incomplete.
In any case I try to reverse engineer the initial 'needs', through analysis and discussion, scenarios and use cases, to discover the operational concept, and derive the operational requirements from there. This doesn't have to be long-winded for a small project, and might be as short as an hour or two, with experience. I've seen this type of approach described as the inverse of functional decomposition, and called 'upward levelling', a term I dislike because it's misleading.
In terms of process, this really means postulating the operational concept (or more commonly elements of it) and then checking it agains the stated needs and discussing it with the users. If the stated needs don't map onto the OpConcept, it may mean that the OpConcept is wrong or incomplete, or the needs are wrong or out of scope.
To me, this is the most critical activity in a project, because it happens on day 1 (and several times later in a large project) and drives the project scope and product shape. If you don't do it (noting that many people do it almost implicitly), it's likely you'll miss unstated requirements which can only really be detected at the level of the operational concept.
Another advantage of this approach is that often you find that different users are actually asking for the same functionality in different ways, but will cling to their solution-distorted 'requirements' until you can show them something which meets their needs at the operational level. So I guess you could call it user-levelling as well. :=)
Andrew
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Mon Apr 26 2004 - 09:00:17 EST