ARGUABLY the most well-known categorisation of requirements is the Functional and Non-Functional dichotomy. So ubiquitous is this classification that one can refer to them with the acronyms F and N/F and people know what you mean.
F is about what the system must be able to do, and N/F is about characteristics that the system must exhibit to some specified level, such as being “available for use 99% of the time” or ‘of yellow colour’.
Another major classification of requirements is that between business and system requirements. The vast majority of projects in the IT and Telecoms field will produce two requirements documents: the BRD (Business Requirements Definition / Document), and the SRD (System Requirements Definition / Document). The key distinction between a business requirement and a system requirement is that the former is about what the ‘business’ (or organisation) needs from the system, whereas the system requirement is about what the solution system needs to be able to do (functionality), and exhibit (non-functional requirements), in order to meet the business requirement.
If a system project is aware of only these two classifications of requirements, then serious gaps exist and it is very likely that the resulting system will not meet the business objectives to the degree promised in the business case.
One way to look at the requirements is that they form a hierarchy which is more than merely the business and system requirements.
Mission Requirements
At the top of the requirements hierarchy lie the mission requirements. An organisation has objectives that need to be met, such as ‘improve processing speed’, ‘reduce cost per part’, ‘meet regulatory requirements’. A concept of a solution is developed and mission level requirements are developed. These requirements specify what is needed from the solution in order that it will meet the business objectives. The concept solution, if it is to deliver the objectives of the organisation, must meet the mission level requirements.
These requirements may include such things as interoperability with existing organisational systems, availability by a certain future date, or cost only a certain amount.
Stakeholder Requirements
Next come the stakeholder requirements. What do each of the stakeholders need to be able to do, in order to meet the mission requirements? If the mission is to 'improve processing speed by 100%’, what does stakeholder A, B, C, etc. need? These requirements are written in the language of the stakeholders (for it originated from them, and since they need to confirm the cleaned-up version).
Although these requirements originated from the stakeholders, they almost always need to be elicited from them through capable facilitation. They also need to be reviewed for completeness. Stakeholders tend to provide only the most salient requirements prominent in their mind.
Derived Requirements
The Stakeholder Requirements are analysed and reviewed to produce the Derived Requirements. Derived Requirements are the input to the Design process and the Verification process and therefore are written both in more precise language (e.g., “the system shall…”) and in more technical language. Since these requirements are derived, there must be some form of written justification as to how a derived requirement meets a stakeholder requirement. From an administrative point of view, we also need to maintain traceability links back to the stakeholder or mission requirements.
System Requirements
System Requirements are Derived Requirements which specify system-level functionality or characteristics of the desired system.
Component Requirements
Component Requirements are Derived Requirements which specify what specific components must meet. For example, for a web-based system, components might include requirements for web servers and database management systems.
There are other ways to classify requirements, but they are orthogonal to the above. For example, there are things such as Input Requirements, or Operational Requirements, and Schedule Requirements, but each of these also fall within one of the above hierarchy.
No comments:
Post a Comment