Pattern-Oriented Software Architecture For Dummies

Identifying the Requirements

When you thoroughly understand the problem to be solved, as discussed in the preceding section, you need to translate it into detailed requirements (the list of things that you need to include in the solution). Sometimes, you need to be formal and write down the requirements, even numbering them and tracking them through to the code. At other times, you don't need to be so formal, but you should still document the requirements. The level of detail needed in the requirements is related to the complexity of the problem and the solution; complex problems and solutions call for detailed requirements.

Architectures are created to implement and meet requirements.

You identify requirements in much the same way that you define the problem statement (refer to “Developing a problem statement,” earlier in this chapter). You need to talk to the customer or client and find out what he really wants you to design and build.

Defining functional requirements

Some requirements are obvious from the customer's needs. Perhaps the customer wants the main user interface to be through a web browser, for example. Or perhaps the system needs to compute a table of values following the customer's formula, such as “compute the amount to be paid to an employee using hours worked and per-employee deductions as inputs.”

Requirements like these, which define something that the system ...