I2
Knowledge Sharing
in an Organization
 

Requirements
L1 Project Establishment
 

Requirements for a project are normally defined under strict time pressure. If then, some earlier defined and tested sets of requirements could be used, it would shorten the required time period and also result in more quality requirements compared to the situation where all requirements have to be defined starting from scratch.

When using existing requirements the intellectual property rights (IPR) must be checked. Some projects might be such that the rights belong to the customers. Those requirements are not allowed to be used unless a permit has been obtained from the customer.

Using existing requirements or use case components will gain a number of benefits. Jacobson et al. (1997, pp. 117-118) have listed the following benefits from the perspective of reusing use case components:

• Effectiveness: using existing components as a toolbox expressing known system functionality -> faster and more accurately capturing of requirements.
• Quality: improving the quality of the requirements capture by reusing "certified" use case components and not missing some less obvious requirements when choosing from "complete" set of use cases.
• Predictability: improving project estimates through reusing use cases of which much is already known.
• Uniformity: reusing use case components ensures consistency of terminology and system.
• Design reuse: reusing use case components makes it possible to reuse the design and implementation of that use case.
• Rapid learning: the use cases provide usage-oriented documentation of the component system and thus the intended use of the component system can be seen by looking at the use cases.

Reuse of requirements can be direct, where a requirement from one system is taken as a requirement with minimal changes, or it can be indirect, where existing requirements are used to prompt users for their specific requirements (Sommerville & Sawyer 1997, pp. 106-107).
 

To use reference requirements:

1. Check for Existing Requirements. When defining requirements check for existing reference requirements: in the organization and external ones.
2. Maintain Reference Requirements. Support projects how to use the existing reference requirements. Study needs and decide maintenance activities to the reference requirements. (See also: Reference Requirements, KSP07)
3. Check IPR and Applicability. Check applicability of potential sets of reference requirements. Check the IPR situation (availability for the project, possible needs for protecting own IPRs).
4. Utilize the Requirements. Check the terms of use and use the requirements according to that. The requirements can be used as is or as a basis when defining the requirements with the customer (Discovered Bones, KSP06).
5. Suggest changes. If changes need to be implemented requirements, check if those would be useful also in the reference requirements. If yes, suggest those changes.
6. Study and Update Changes. Study suggested changes and decide possible actions.
    

Pattern to be used always when defining requirements. Maintenance should be continuous during the lifetime of the reference requirements set.

One potential pitfall is to use a reference requirements set, that is not really applicable but needs a lot of tailoring.