Evolution of Requirements


At the beginning of a project, the requirements analyst is concerned with understanding the business the product is intended to support. We call this business area "the work." At this stage, the analysts are working with scenarios and other models to help them and the stakeholders come to an agreement on what the work is to be. You can think of these as "high-level requirements"; however, we find the term "high-level" to be subjective and hence fairly meaningless, so we avoid using it.

As the understanding of the work progresses, the stakeholders decide on the optimal product to help with the work. Now the requirements analysts start to determine the detailed functionality for the product and write its requirements. The nonfunctional requirements are derived at about the same time and written along with the constraints. At this point, the requirements are written in a technologically neutral mannerthey specify what the product is to do for the work, not which technology is used to do it.

You can think of these requirements as "business requirements," meaning that they specify the product needed to support the business. Once they are adequately understood, they are given to the designer, who adds the product's technological requirements before producing the final specification for the builders. This process is illustrated in Figure 1.3.

Figure 1.3.

The requirements evolve as development of the product progresses. They start out as fairly vague ideas as the analysts and stakeholders explore the work area. As the ideas for the product emerge over time, the requirements become precise and testable. They remain technologically neutral until the designer becomes involved and adds those requirements needed to make the product work in its technological environment.





Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net