Despite being a recurring topic of discussions, a comprehensive and formalized approach to requirements should not hold back newcomers: given that requirements are the necessary genesis of any project nothing can be assumed about their emergence; as a consequence they are better dealt with as they come.
For that purpose, and whatever the preferred approach, requirements analysis can be neatly described as an iterative process built from three basic increments: identified individuals, associated features, and classifications.
Individuals
When entering unknown territory, the first thing to do is to set apart recognizable items. Regarding requirements that would be individuals whose identities has to be managed. Such individuals would then further be divided between:
- Objects (persistent identities) and activities (transient identities).
- Activities (managed duration) and events (no managed duration).
- Agents (physical identities) and roles (social identities).
- Actual (physical identities) and symbolic (social identities) objects.
It must be noted that, except for new standalone applications, most of individuals may have been already defined by existing functional architectures.
Features
Contrary to individuals, features have no identity of their own. As a corollary, they can only be considered as possible attachments to individuals. On that basis, analysts have to answer three basic questions:
- Can a feature be shared or transferred (functional), or is it bound to the same individual (structural).
- Does it reflect a state of affairs (attribute) or represent a capability (operation).
- Is there some overlapping with already known features.
The last question brings about the core of requirements analysis, i.e how to deal with variants, consolidate applications, and manage changes.
Classifications
Categories and rules are the dual facets of requirements purpose, namely how to classify objects and operations and deal with variants.
- Categories take a declarative approach that relies on static classifications to describe variants. Starting with partitions, analysts will have to distinguish between structural variants (associated with specific features) and functional ones (associated with the state of the same set of features).
- Rules take a procedural approach with the equivalent of dynamic classifications to deal with variants. As for categories, analysts will have to decide between the equivalent of structural variants (rules to be enforced for the whole of execution paths) and functional ones (rules to be evaluated along execution paths).
Whereas each option may have its benefits depending on the nature of variants, the primary factor when selecting a scheme should be its consistency with regard to existing applications on one hand, between the description of new objects and activities on the other hand.