A marketing experts understand what is needed or desired by the
customers who will buy the product. Among other judgements, these experts
should know what minimum feature sets are necessary to achieve the corporate
goals.
Aesthetic experts are expected to focus on the appearance and usability of the product.
Both the marketing and the aesthetic experts are responsible for having their finger on the pulse of the end users.
Technical experts inject implementation feedback regarding technological risk and feasibility, rough schedule estimates, and implementation phasing suggestions, that reduce or prevent impossible or prohibitively expensive products from being specified.
Management arbitrates the process, provides input related to project funding and human resource issues, and is ultimately responsible for evaluating issues regarding various tradeoffs, and making the timely decisions that keep the process moving ahead.
The following is a collection of attributes for each requirement.
That a requirement must be testable is most often stated by those responsible for product testing and verification. This excellent maxim encourages those responsible for requirements capture to focus on the quantitative aspects of the system, and to unambiguously capture details, eliminating the fuzzy fluff often contained within requirements documents. However, while fluff is eliminated, adhering to this policy has the result of increasing the volume of detail, exposing the true scope and impact of each requirement from a development and testing point-of-view.
It is the responsibility of the requirements capture process to describe what the system is to do. The responsibility for describing how the requirements will be realized is the responsibility of the design team. The requirements indirectly constrain the implementation by describing the physical and logical external components and systems with which the system must interact and the required response of the system to these interactions, but the design process is responsible for realizing those requirements.
Describing a system in terms of its externally observable behavior is a means of identifying and establishing the physical and logical boundaries of a system. As an example of the difference between the physical and logical boundaries, consider a system with an external 10/100 etherenet port. The ethernet port is a physical connection to the system, but over this physical boundary may pass an almost infinite number of connections to other systems and processes, each with its own layer of protocols.
Expressing a behavior as a FSM diagram exposes many details and interactions which otherwise go unnoticed and unresolved during requirements capture. These issues inevitably result in system implementations that are unstable, unsatisfactory or impossible. Issues such as errors handling and other exceptional conditions must be captured for such models to be accurate.
While FSM diagrams describe the logical behavior of a system, there are other behaviors and constraints which are equally important that must be captured in more traditional ways. Performance requirements are among the most widely recognized, often specified, mis-understood and mis-represented of all requirements.
Simply stating that a system must be fast is worthless. What does it mean to be fast? What are the units of fast? How important is it to be fast? What is the impact of not being fast enough? Clearly, we need to be a bit more rigorous in our specification.