Revisiting Requirements

In revisiting the SRS case study problem statement, we find that we've indeed missed one requirement, namely

Note?/td>

"The SRS will verify whether or not the proposed plan of study satisfies the requirements of the degree that the student is seeking."

We didn't model Degree as a class—recall that we debated whether or not to do so back in Chapter 10, and ultimately decided against it. Nor, for that matter, do we reflect the requirements of a particular degree program in our model. Let's look at what it would take to do so properly at this time.

Researching the way in which our university specifies degree program requirements, we learn the following:

• Every degree program specifies five "core" courses—that is, courses that a student must take. For example, for the degree of Master of Science in Information Technology (MSIT), students are required to complete the following five core courses:

  • Analysis of Algorithms

  • Application Programming Design

  • Computer Systems Architecture

  • Data Structures

  • Information Systems Project Management

• Secondly, students are expected to select an area of specialization within their degree program known as a concentration. For the MSIT degree, our university offers three different concentrations:

  • Object Technology

  • Database Management Systems

  • Networking and Communications

• Each concentration in turn specifies three mandatory, concentration-specific courses; for the MSIT degree with a concentration in Object Technology, the required concentration-specific courses are

  • Object Methods for Software Development

  • Advanced C# Programming

  • Object Database Management Systems

• Finally, the student must take two additional electives to bring his or her course total to 10.

Phew! To model all of these interdependencies would require a fairly complex class diagram structure, as shown in Figure 12-1.

We go back to our project sponsors—the future users of the SRS—and break the news to them that we've just uncovered a previously missed requirement that is going to significantly increase the complexity and cost of our automation effort. The sponsors decide that having the SRS verify the correctness of a student's plan of study is too ambitious a goal; they instead decide that a student will use the SRS to submit a proposed plan of study, but that his or her advisor will then be responsible for manually verifying and approving it. So, all we wind up having to do to correct our SRS class diagram as last presented is to add one attribute to the PlanOfStudy class, reflecting the date on which it was approved, and a new approves association connecting the Professor class to the PlanOfStudy class, and we're good to go!

Note that we don't need to add an ApprovePlan method to the PlanOfStudy class, because as discussed in Chapter 10 we may assume the presence of "set" methods for all attributes; the SetDateApproved method would suffice for marking a plan as approved. And, the approves association between the PlanOfStudy and Professor classes (see the diagram excerpt in Figure 12-2) ensures us that each PlanOfStudy object will maintain a handle on the Professor object who actually approved the plan on the date indicated.