Despite the trend in software development that thinks of requirements as old hat many people still do and always will work with requirements. This fact makes the observations that follow relevant and likely to remain of relevance.

An interesting thing about requirements is that people generally think about them as a single homogenous layer. Conceptually in people’s minds there is not much distinguishing one level of requirements from another. Requirements sit in a single layer above which there is not much whilst below them sits either functional definition or a direct entry into design and implementation. It is rare to see a clear recognition on the widely different breaths, domains and concerns that different requirements can address. Hence almost inevitably there is little thought given to what form of requirements are appropriate and how they might be partitioned. The consequence of this is often a muddled set of requirements; some addressing high level concepts and some minute system details. To illiterate this take a look at two examples:

• Requirement A - Operational practice shall ensure no information associated with transactions processed for a client organisation nor knowledge of the existence of individual transaction being handled for that organisations is available to the staff of any other client organisation.
  • Requirement B - Users of the system only have visibility of transactions owned by operational entities that their user account is mapped into.

Both are driven by the same underlying need for confidentiality. The first is a true business practice requirement. It can be used to judge the operation of a system, a family of systems, how communication and reporting must work and what people can see when they walk into a room. It is agnostic to the nature of any system used in the activities of the operation. The second is really a system requirement. Furthermore it is a dependent system requirement that only makes sense in the context of some decisions that have already been made about how the system will work.

It is fair to say that if someone were writing a requirement set for this space then it is possible that they might address this topic in Requirement-A style, in Requirement-B style or might include both. Both have validity and it is not a problem to have requirement at either end of the spectrum or at points in between. However when they are all mixed in together then this leads to difficulties maintaining and working from requirements.

It is better to explicitly separate out the different layers of requirements, to handle each layer separately and where requirements are found in the wrong place to move them to the correct place. This many sound like lots of extra work but it is not, rather it is being organised and disciplined; the reward for being so is more efficient and effective communication of critical knowledge across teams.

A fairly generic, though not universal, layering would be:

• Business Operational Performance Requirements
• Business Operational Practice Requirements.
• Business Practice and Process Requirements
• Intrinsic System Requirements.
  • Dependent System Requirement.

Organising requirements around this or some similar layering model provides for better more maintainable requirements. It also allows, well actually encourages, staggering of requirements generation and eliminates the waterfall bias of a monolithic requirements view. This layering model allows good requirements engineering practices to be integrated into modern iterative / incremental delivery practices.