Chapter 1: Requirements Analysis with Use Cases

Overview

Developing large-scale software solutions reminds us of the many different perspectives that different stakeholders have about the end product. At the outset, there is nothing concrete to visually depict the semantics and mechanics of the end product. At this juncture of the project, we have an abstract view of the software to be developed. As such, it is imperative to find a common ground for all stakeholders to agree upon, without which we run the risk of creating a product that tends to lend itself to the vision of only a certain interest group. It is necessary to ensure creation of a product that is a representation of the organization's business needs and the needs of all its users and sponsors. Therefore, we must resort to providing a requirements vocabulary that is easily understood by all stakeholders. This chapter's focus is to assist the readers in creating such a vocabulary using use cases, activity diagrams, and flow of events.

However, before we begin, there has to be an expectation about the level of impact the artifacts in this chapter will have on defining a project's requirements. Use cases are at the center of this effort. Use cases can be created at different levels of abstraction. A use case diagram can be used to model the behavior of an entire system, subsystem, or a class. Getting too detailed in the first iteration could result in a lot of rework if the requirements are not well understood. Therefore, it is important to remain at a level of abstraction that clearly captures the requirements from the point of view of business domain experts, project sponsors, end users, customers, and executive management. We will call this group collectively stakeholders. For this group, we want to avoid too much, too fast, too early in the project. You will experience that just getting to agree on high-level requirements takes several iterations. This is not unusual since the process of requirements definition is evolutionary, and with every iteration we have opportunity to discover and improve. The requirements team is made up of stakeholders and one or more members of the technical staff; use cases are a contract between these two groups, and therefore appropriate representation from both sides is critical to the success of the project. Special needs of the project can be met by augmenting the requirements team with appropriately skilled members; for example, if the system is going to interface extensively with a CRM solution, it will be helpful to have assistance from a person experienced in the CRM space and CRM software.

Another viewpoint that we would like to suggest is that all through the process think reuse and think decomposition. This mode of thinking helps us factor common behavior into use cases, and finally package a set of related use cases into subsystems. The next chapter is a logical progression from this chapter and helps us map the requirements of this chapter in terms of information architecture that provides a prototype of the end product to the stakeholders and developers. Use cases will be elaborated during information architecture, therefore our endeavor for completely capturing functional requirements will conclude in Chapter 2. Use case realization is the focus of Chapters 5 through 8.