Chapter 7

Chapter 7

Requirements Engineering

CHAPTER OVERVIEW AND COMMENTS

The intent of this chapter is to present requirements engineering tasks and basic requirements analysis concepts and principles. Students must understand that customer communication and requirements elicitation are pivot activities in the software process. Even the best technology will fail if you don’t understand what the customer wants.

Regardless of the process model used by software engineers, requirements engineering is an essential part of a successful software development project. The focus of this chapter is gathering the information needed to build the information, function, and behavioral portions of the analysis model. Creation of use-cases is described. Several UML diagrams useful to analysis modeling are discussed. Dataflow diagrams are introduced, but will be discussed in greater detail in the next chapter.

In this chapter six requirements engineering task are considered—inception, elicitation, elaboration, negotiation, specification, and validation.

7.1    The Bridge to Design and Construction

In this section, requirements engineering is described as a bridge between communication and analysis modeling and design and construction. It is important to point out to your students that even though the requirements engineering activities may be abbreviated, they cannot be eliminated.

Like all software engineering neophytes (and quite a few seasoned pros), your students will want to jump right in to the project by doing a bit of cursory design and then coding their hearts out. A bad mistake!

Spend some time discussing Brooks’ quote and why it’s true.

The “bridge” metaphor we use in this section implies connections. You should be certain to explain what those connections are. Where does the bridge originate and where does it go?

7.2    Requirements Engineering Tasks

This section introduces several requirements engineering tasks (inception, elicitation, elaboration, negotiation, specification, and requirements validation). A good way for you to introduce these tasks is to create a scenario in which your students must address what they’d do to accomplish each for a hypothetical project you pose. For example, assume you work for a music company and want to develop a system that will distribute .mp3 files for very low prices. What things will happen during inception, elicitation, elaboration, negotiation, specification, and validation?

Students need to experience the process of working with a customer to develop the requirements for a software product before they graduate. It is hard for students to do this in a one-semester software engineering course, but they should do this as part of a senior design project. Trying to understand customers' needs and negotiating changing requirements is part of every software development project. Students also need to experience the opportunity to judge the feasibility of solutions and steering the customer toward options that can be completed with the resources available.

Spend a few moments going over the requirement validation checklist presented in the sidebar.

7.3    Initiating the Requirements Engineering Process

The process of initiating engineering is the subject of this section. The point of view described is having all stakeholders (including customers and developers) involved in the creation of the system requirements documents.

The term “stakeholder” (Section 7.3.1) is used throughout SEPA. It’s very important that your students understand its meaning and just who is a stakeholder. Be sure you emphasize this.

Spend some time discussion how you reconcile multiple viewpoints (and conflicting requirements). Also discuss how collaboration is best achieved on a software project.

Two elicitation techniques are discussed (the use of context free questions in structured customer interviews and collaborative requirement gathering. Having students use these techniques to work with real customers or role-play working with simulated customers is a worthwhile task. If there is not enough time to do this in a one-semester course, if should be done in the senior projects course.

The series of context-free questions listed in section 7.3.4 should help the students gain a rudimentary understanding of the type of dialog needed between developers and customers when begin a software development project.

7.4    Eliciting Requirements

This section discusses two techniques for involving all stakeholders in gathering of system requirements. The first technique is called collaborative requirements gathering. In this approach the stakeholders collaborate under the supervision of a neutral facilitator to determine the problem scope and define an initial set of requirements. The second technique is called quality function deployment. In this technique the customer is asked to prioritize the requirements based on their relative value to the users of the proposed system. Use-cases are mentioned briefly in this section and discussed in greater detail in section 7.5.

Basic requirement elicitation is presented for SafeHome. It would be worthwhile to cover this in lecture.

7.5    Developing Use-Cases

Use-cases are a pivotal topic throughout SEPA. Be certain that you emphasize and re-emphasize their importance as a requirements gathering tool.

Go though each of the questions that use-cases ask and answer. Students often have difficulty understanding what an “actor” is. Be sure you explain the concept to them.

Note: If you’re a purist, then you’ll insist that students develop use-cases by following the template suggested in this section. However, you can be a bit more relaxed and have students develop a more narrative and informal “preliminary use-case.” The idea is to have them start thinking in scenarios—in my opinion, the form the scenario takes is secondary.

Spend a bit of time discussing the syntax and semantics of UML use-case diagrams.

Your students may need some help in thinking about people and devices as actors. Object-oriented analysis does not always come easily (even if your students are good object-oriented programmers). Functional decomposition may seem more natural to them in the beginning.

7.6    Building the Analysis Model

This section discusses analysis modeling. The elements of the analysis model (scenario-based, class-based, behavioral, and flow-oriented) are introduced. Several UML diagrams (use-case, activity, class, state) are described. It may be helpful to show your students additional examples of these diagrams. Dataflow diagrams are introduced briefly here and will be discussed in more detail in the next chapter.  The template for an analysis pattern is presented.

The analysis model is considered in detail in Chapter 8. At this point, you should focus on defining the four major elements of the model: scenario-based elements (use-cases), class-based elements, behavioral elements, and flow-oriented elements. A few simple examples can serve to foreshadow the content of Chapter 8, but there’s no need to go into detail at this point.

Analysis patterns are considered in Section 7.6.2.  If time permits, you might want to present one or two actual analysis patterns. As important, be certain to emphasize how these can help a software engineer as requirement management activities are conducted.

7.7    Negotiating Requirements

Most students have very little experience in the art of negotiation. The key point is to remind students to avoid an “us versus them” mentality when they become software developers. The negotiation guidelines included in this section should be helpful to your students in this regard. If time permits, discuss how the negotiation process works and point out tricks of the trade. You’ll provide students with information that will serve them well.

7.8    Validating Requirements

The purpose of requirements validation is to make sure that the customer and developer agree on details of the software requirements (or prototype) before beginning the major design work. This implies that both the customer and developer need to be present during the validation process.

The list of review questions should provide a good guidance for conducted reviews of analysis models. If time permits, your students may benefit from actually reviewing the analysis model for a software product by role-playing using these questions.