Problems of Scope-Requirement Elicitation

Elicitation techniques need to be broad enough to establish boundary conditions for the target system, yet still should focus on the creation of requirements as opposed to design activities. Avoiding contextual issues can lead to requirements which are incomplete, not verifiable, unnecessary, and unusable. Focusing on broader design activities improperly emphasizes developers’
issues over the users’ needs and may result in poor requirements as well. Requirements elicitation must begin with an organizational and context analysis to determine the boundary of the target system as well as the objectives of the system. Less ambitious elicitation techniques not addressing this concern run the risk of producing requirements which
are incomplete and potentially unusable, because they do not adhere to the user’s or organization’s true goals for the system. Performing an organizational and context analysis allows these goals to be captured, and then used to verify that the requirements are indeed usable and correct.
Elicitation techniques can be overly ambitious as well. Elicitation must focus on the creation of requirements, not design activities, in order to adequately address users’ concerns and not just developers’ needs. Elicitation strategies which produce requirements in the form of high level designs run the risk of creating requirements which are ambiguous to the user community.
These requirements may not be verifiable by the users because they cannot adequately understand the design language. Also, requirements expressed as a design are much more likely to incorporate additional decisions not reflecting user or sponsor needs, i.e., the requirements will not be precise and necessary.
There are at least three broad contexts which affect the requirements and the requirements engineering process for a proposed system:
• organization
• environment
• project
Requirements elicitation necessitates an understanding of the organization in which the system under development will be placed, as well as an understanding of the system’s mission within the organizational context: “the primary interest of customers is not in a computer system, but rather in some overall positive effects resulting from the introduction of a computer system in their environment” . This view is not well reflected in current practice, where requirements elicitation concentrates on the computer system without much concern for organizational factors. Organizational factors include:
• submitters of input to the target system
• users of the target system’s output
• ways in which the target system will change the organization’s means of doing business