Requirements Gathering and Systems Modeling

Requirements gathering and systems modeling have a significant degree of overlapthe requirements gatherer uses models to help find the requirements, and the modeler uses the requirements to help model the functionality and data. Both produce artifacts used to understand and specify requirements.

In the beginning, the requirements-gathering activity is dominant. The only models being built are a context diagram and perhaps an exploratory data model and a stakeholder map. The requirements analysts are busy discovering the business goals, the stakeholders, the work (or business domain), and the desired outcome.

As the knowledge of the work increases and the business use cases evolve from fuzzy intentions to known quantities, the models become more precise and provide valuable feedback to the requirements gathering. Similarly, the growing knowledge of the requirements feeds the modeling process, enabling the modeling to be more productive. This relationship is illustrated in Figure 1.2.

Figure 1.2.

The overlap between Requirements Gathering and Systems Modeling varies as the development of the product progresses. Initially, very little modeling is done, and the majority of the effort focuses on gathering and verifying requirements. As development continues, the modeling activity expands to occupy a continually greater proportion of the effort.

Models can be used to specify the product, or at least its functionality. Provided that the model is complete and is supported by a data dictionary and any needed process descriptions or scenarios, it makes a suitable alternative to the textual specification.

The craft of systems modeling is well documented. Several books cover this area, including those mentioned in the margin. We encourage you to build models of your proposed product and to understand the work by building models of it. We will not cover, except in a very rudimentary way, how to build these models. That is for you to explore. We will, however, bring you to a complete understanding of what a requirement is, how to write one, and how requirements connect to models.

Robertson, James, and Suzanne Robertson. Complete Systems Analysis: The Workbook, the Textbook, the Answers. Dorset House, 1998.

Jacobson, Ivar, et al. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1992.