3 Get requirements to build the right application

 

This chapter covers

  • Functional and nonfunctional requirements of an application
  • What are good requirements and how to obtain them
  • Use cases
  • The functional specification
  • Analyzing the requirements to obtain the initial application classes

Before we start worrying about building an application right (make it well-designed), we must ensure that we’re going to build the right application. An application that doesn’t do what the client wants is a failed, unsuccessful application, no matter how well designed it may be. The client of an application can be a future end user (including yourself), your manager who requested you to write the application, the person who hired you as a software consultant or contractor, or any other stakeholder who wants a successful application.

In this chapter, we’ll learn how to get good requirements for an application. Then, we’ll see how to analyze them to obtain the initial set of classes. Remember that requirements can change, and we must design accordingly and develop iteratively.

3.1 The overture to application design

Figure 3.1 shows a timeline of the major activities and milestones during the application development. The activities with the bold outlines, which are covered in this chapter, are the crucial overture to application design.

3.2 Functional requirements: What must the application do?

3.3 Nonfunctional requirements: Constraints on the application

3.4 How to get requirements

3.4.1 A short requirements case study

3.4.2 Stated and implied requirements

3.5 Unified Modeling Language diagrams for creating and documenting design

3.6 Use cases provide context for the requirements

3.6.1 UML use case diagram

3.6.2 Use case description

3.7 The functional specification and software validation

3.8 Where do classes come from?

3.8.1 Textual analysis: Nouns can become classes

3.8.2 Textual analysis: Verbs can become methods

3.9 Summary