Requirements Engineering process is categorized into three activities.
2. insure that the needs of all users are consistent and feasible; and
3. validate that the requirements so derived are an accurate reflection of user needs.
This model implies a sequential ordering to the activities, with elicitation done once at the very beginning of the process. In reality, though, the process is iterative, with these activities revisited many times.
Thus, while requirements elicitation consists of the earliest activities in the requirements engineering process, it can not be divorced from the subsequent activities. Elicitation will likely iterate with these other activities during requirements development.
Requirements elicitation itself can be broken down into the activities of fact-finding, information gathering, and integration.
Requirement elicitation process is further decomposed as follows.
1. Identify the relevant parties which are sources of requirements. The party might be an end user, an interfacing system, or environmental factors.
2. Gather the “wish list” for each relevant party. This wish list is likely to originally contain ambiguities, inconsistencies, infeasible requirements, and untestable requirements, as well as probably being incomplete.
Thus, while requirements elicitation consists of the earliest activities in the requirements engineering process, it can not be divorced from the subsequent activities. Elicitation will likely iterate with these other activities during requirements development.
Requirements elicitation itself can be broken down into the activities of fact-finding, information gathering, and integration.
Requirement elicitation process is further decomposed as follows.
1. Identify the relevant parties which are sources of requirements. The party might be an end user, an interfacing system, or environmental factors.
2. Gather the “wish list” for each relevant party. This wish list is likely to originally contain ambiguities, inconsistencies, infeasible requirements, and untestable requirements, as well as probably being incomplete.
3. Document and refine the “wish list” for each relevant party. The wish list includes all important activities and data, and during this stage it is repeatedly analyzed until it is self-consistent. The list is typically high level, specific to the relevant problem domain, and stated in user-specific terms.
4. Integrate the wish lists across the various relevant parties, henceforth called viewpoints, thereby resolving the conflicts between the viewpoints. Consistency checking is an important part of this process. The wish lists, or goals, are also checked for feasibility.
4. Integrate the wish lists across the various relevant parties, henceforth called viewpoints, thereby resolving the conflicts between the viewpoints. Consistency checking is an important part of this process. The wish lists, or goals, are also checked for feasibility.
5. Determine the nonfunctional requirements, such as performance and reliability issues, and state these in the requirements document.
No comments:
Post a Comment