Requirements Definitions
Critical Requirements
A criticial requirement is one that a system MUST have if it is to be considered a successful system.
Critical requirements and objectives should be selected for tracking the status of technical performance and should be used to identify deficiencies that jeopardise the ability of a system to meet a performance requirement.
Critical Requirements are important because they are the criteria that drive the system solution that is found. They are critical because all the stakeholders - engineers, management, users and operators - must agree on them or there will be future problems. If the requirements are not both correct and agreed to, then the system development will be plagued with costly requirements changes and may miss its market. These requirements are extremely useful in reviews with management, users and operators who do not want to know all of the technical engineering detail but do want to know about progress on critical system functions.
To avoid project risk, remove requirements that represent uncertainty and high risk (probability or consequence). Avoidance includes trading off risk for performance or other capability, and it is a key activity during requirements analysis. Avoidance requires understanding of priorities in requirements and constraints. Are they project critical, project enhancing, "bells and whistles," or nice to have?
Critical requirements are traditionally expressed using the word "shall".
Non-Critical Requirements
A non-criticial requirement is one that a system does not need to have in order to be considered a successful system.
Such a requirement is one that is not essential to the functionality of the developed system and that could be considered as "nice to have".
For example, supporting different languages. The system will work without supporting other languages, but language support would be a bonus.
Non-critical requirements are traditionally expressed using the word "should".
User Requirements
Users are the operators and supporters of system end items, and the trainers that train the operations and support personnel. Users execute the operations, support, training, and disposal functions associated with system end items.
User requirements are the first step towards defining a system. Every system needs to satisfy its end users to be successful. It is important therefore to define who they are and what they want expressed in their own terms.
A user requirement is a requirement that a user needs to see implemented in order to be satisfied with the finished product.
User requirements are statements of fact and assumptions that define the expectations of the system in terms of mission or objectives, environment, constraints, and measures of effectiveness. They should be expressed in the terminology of the problem domain, defining what the users want to do with the system.
In other words, user requirements are defined from an operational point of view, not in terms of system functionality or equipment. They must be short and non-technical.
User and system requirements must be kept separate, with the former driving the latter. This often does not happen, and the requirements are often a single entity, mixing up user needs with box-drawings of the solution, background material, system functions, design elements and unverifiable wishes.
The diagram below shows how user requirements are defined, starting by defining the user types, and capturing requirements from them. These must be structured into a coherent set, which is then reviewed and agreed by users, and updated, and issued as a User Requirements Document.
It is essential to understand exactly what the users want from the product.
System Requirements
A system is an integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective.
A system requirement is a requirement that a system must have to be a successful system. For example, hardware and environment requirements such as a camera that must be able to function in extremely cold conditions.
System requirements explore the solution, but ideally avoid commitment to any specific design. They show what the system will do, but not how it will be done.
System requirements contain both formal requirements and descriptive information. They have several distinct uses:
-
giving an abstract view of the system;allowing trade-offs, exploration and optimisation before committing to design;demonstrating to users that their needs are reflected in the development;providing a solid foundation for design;providing a basis for testing the final system;
-
communicating previous decisions to developers.
The diagram below shows the overall process for defining system requirements.
|
