2.13. Modeling New Requirements

Let’s look at some typical new requirements:

1. New essential requirements that are not part of the current system: Management sees a new business opportunity, and the current system cannot support it, nor can the system be modified to incorporate the new business requirement. Often this kind of need prompts the whole systems redevelopment effort and results in one or more new event-responses.

Similarly, new requirements “grow” during the analysis. Thanks to your analysis modeling efforts, users can see a better picture of their business. Now that they can communicate successfully with technical people, they will suggest all sorts of requirements for things they’d like to do, if only they had a system for doing it.

2. New requirements that are outside the current context of study: Again, your analysis gets the users thinking, and they discover useful functionality in adjacent systems. By extending your context to include functions from other parts of the business, the final system will be far more useful to the business as a whole. These new requirements usually add several new event-responses to your system.

3. New requirements that are actually modifications to the way the current system responds to an event: These often appear to be completely new requirements, but your analysis reveals them for what they are. This type of new requirement is usually an addition or a change to an event-response that is already within your context of study.

Figure 2.13.1: New requirements appear in a number of guises. Some are additions or modifications to the system you are studying, and some are (for the moment) outside your context of study.

We’ve noticed over the years the tendency of some project members to discourage their users from bringing up new requirements. The analysts feel that new requirements are an inconvenient interruption to the analysis. This attitude defeats the whole purpose of analysis: to discover all the requirements for a new system. New requirements are just as valid as any other, no matter how inconvenient. Eventually, you will have to incorporate new requirements into the system. To leave them until after implementation makes the project far more expensive than is necessary.

However, any requirement that alters the context of the study also alters the amount of time needed to complete the project. To ensure that you reflect the impact of all new requirements, you must change the schedule.

The best way to deal with a new requirement is to model it in the same way you model all the existing requirements. That is, build event-response process and data models for each new requirement.

Figure 2.13.2: The event-response model for the new requirement is just like any other. There is no reason to model new policy differently from any other policy.

When you model a new requirement using event-response process and data models, some of the entities, attributes, and relationships may already exist in the system data model, just as some of the processes may be part of your current process models. Do not let this influence your approach. Treat each new requirement as a stand-alone mini system. This strategy helps you to focus on the details of the policy. Later on, you can worry about how and whether to integrate the new requirement with the existing context of study.

As an example of a new requirement, let’s reconsider the user’s statement: “When we have the new system, we can issue credit cards printed with a photograph of the new offices, and we can offer itemized billing of the services, just like Compétiteur, Inc. Or maybe we should have a picture of the chairman’s new car on the card ... or maybe his dog.” If you ignore the obviously silly implementation ideas, there are several events that you need to model:

• Customer applies for card

• Customer makes a purchase

• Time to bill the customer

The essential event-response models look like those in Figures 2.13.3, 2.13.4, and 2.13.5.

Figure 2.13.3: Essential event-response models for Customer applies for card.

Figure 2.13.4: Essential event-response models for Customer makes a purchase.

Figure 2.13.5: Essential event-response model for Time to bill the customer.

1. Do I need to change the context of the system because of a completely new boundary data flow? Sometimes, the flow is not really new, but is an existing flow disguised as a new one.

2. Do I need to store new data? Do the attributes exist in my current data model to support the new requirement, or must I create completely new ones?

3. Do I need to define any new relationships? Does the new requirement create or use relationships between new or existing data objects?

4. Do I need to define any new business rules or change any existing business rules? Sometimes, of course, the new requirement is really a modification of an existing piece of policy.

If the answer to any of these questions is yes, then the new requirement is a genuinely new piece of essential policy and you must incorporate it into the specification. If the answer is no, then you either have a duplication of something the system is already doing, or the user has been feeding you implementation constraints. Even though these constraints are not part of the essential requirements, you will want to make sure that you do not forget them. Trap them when they arise by adding them to the appropriate view of the system: the new physical model.

Let’s look at the three example event-responses modeled in Figures 2.13.3 through 2.13.5. Suppose there is no data flow anything like CREDIT CARD in the current context diagram. Nor are the attributes CARD NUMBER, EXPIRATION DATE, or CREDIT LIMIT stored by the current system. If this is the case, you can be sure that the first event-response and the entity CARD are completely new.

In the case of the second event-response, we discover that our context already covers the response to Customer makes a purchase. So the second event-response is a modification of an existing event-response for which you have already built a model. The credit cards are new, so anything to do with relating PURCHASE to CARD will modify an existing mini specification.

The third event-response, Time to bill the customer, is new. The bill assembles the purchases by card, so consider this to be a new event.

Some of the stored data already exist in the system. For example, CUSTOMER must be part of any current system, as must PURCHASE and SERVICE. The new addition to the data model is CARD. So you must update your existing data model and data dictionary to show the entity CARD and the new relationships with the existing entities.

The part of the user’s statement concerning the decoration of the charge card is an implementation detail and can be safely diverted to the new physical model.

Careful monitoring of new requirements helps to keep your project under control. Whenever there is a change to the context of the system, there must be a corresponding change to the amount of analysis effort. This means the project plan must be altered to reflect that the project is delivering more or less functionality than was thought when the delivery date was decided. The context of the system establishes the analysis effort. If the context changes, so does the effort.

Similarly, just as you separated the essence from the implementation to build your essential event-response models, you also filter out any proposed implementation for the new requirements. While the implementation is not allowed to influence the essential policy of existing requirements, neither is it allowed to obscure the future ones.