Requirements methodology

Since I am not sure where the authoritative source for this  
methodology is, I will try to recap it as succinctly as possible.

The aim is to have an adequate forcing function to ensure the capture  
of all the appropriate requirements for any given project. I.e., by  
following the methodology you can have some confidence that you have,  
in fact, captured the right set of requirements.

Levels
======
There are three levels to consider:

Goals
   A goal (not to be confused with a predication ;-)) is an overall  
target that you are trying to reach with the project. Typically,  
goals are hard to measure by themselves.
   Example goals include "widescale adoption", "simplicity", "support  
exchange of rules", etc.
   There should not be more than four or five goals. If you find that  
you are getting more then you are probably expressing something at  
the wrong level.

Critical Success Factors
   A CSF is a property, sub-goal that directly supports a goal and  
there is strong belief that without it the goal is unattainable. CSFs  
themselves are not necessarily measurable in themselves.
   For example, a CSF for "widescale adoption" can be "low cost of  
entry". Without a low cost of entry, you can argue that you will not  
get widescale adoption. Another example could be "support Production  
Rule Languages"; which would be a CSF because of the market  
penetration of PRLs.

Requirements
   A requirement is a specific measurable property that directly  
supports a CSF. The key here is measurability: it should be possible  
to unambiguously determine if a requirement has been met.
   For example, we might have a requirement that the RIF supports  
RETE-style PRLs as well as Prolog-style RLs. Such a requirement  
speaks to the "support production rule languages" CSF, which in turn  
supports the "widescale adoption" goal.

Process
=======
The process for arriving at this also has two aspects: generation and  
validation. We are already deep into the generation activity; and  
this should continue.

Validation comes by fitting individual requirements into a  
predetermined hierarchy of Goals and CSFs. I.e., for a random  
requirement, if it cannot be fitted into a particular CSF, the debate  
either widens into "do we need another CSF" or the requirement is  
dropped.

There should be a sign-off on the Goals, and also on the CSFs that  
support those goals. A good source of the goals is the charter itself.

Received on Tuesday, 21 March 2006 19:04:09 UTC