Modelling highly specific business requirements

Question

How can one go about modelling highly specific business requirements, which have no precedent in the system? Take for example the following requirement: When a purchase order contains N lines, is over X value in total and is being recorded against project Y, an email needs to be sent to persons A and B with the details

This requirement supplements other requirements surrounding purchase orders, but comes in at a much later date in response to some ongoing problem elsewhere in the business.

Persons A and B are not part of any role or group in the system, and don't hold any specific responsibility; they are simply the two people the business has appointed to receive these emails in this very specific case. Projects are also data driven, so project Y has no special properties to distinguish it from any other project. The only way to identify it is to compare its identifier to a magic number.

How can one go about modelling this kind of case without introducing too much additional complexity? That I can think of right now, there are a couple of options.

1. Perform the checks and actions inline with the existing code. Here we find the correct spot in the code, check the conditions in the requirement and send the emails to hardcoded addresses. Of course this is fraught with issues. At the very least it stops working if one of these people leaves or changes their email address. At worst you have to ensure that any tests and test data are aware that additional actions are taken for a specific set of criteria.

2. Introduce some form of events system. Here we introduce an eventing system, so that we might react to some event, and fulfil the requirement outside of the usual path of execution. This sounds like a cleaner solution than option 1, but the work involved is ultimately probably slightly overkill for this one small requirement. That said, having it in place does allow the system to handle these kinds of specific requirements consistently and easily in the future.

Are there any other (good/better) ways of handling highly specific requirements? I mean other than telling the other parts of the business no!

Answer 1

Option one seems fine if you provide some sort of configuration setting somewhere in the system so that you can change the Email addresses.

Option two seems like overkill for what appears to be a relatively straightforward business requirement. Only implement it if it appears that it will solve more problems than just this specific requirement.

Answer 2

I suggest that you take both options.

Step 1: Introduce the concept of an Alertable category that can be applied to projects. For each instance of Alertable, allow the attachment of one or more users (who have email addresses). Introduce the concept of a Condition which can be attached to each Alertable which holds a generalizable predicate. So you model those concepts on your whiteboard to the point where you can clearly see most of the code.

Step 2: Now, take your existing code and use the terminology of the concepts you built in the previous paragraph, implement the capability. You will hard wire Project Y to pretend that it has an Alertable instance, hard wire the Condition detection, and then hard wire the alerting process.

Your code might look like this:

In Project object:

Boolean isAlertable() {
   return projectNumber == MAGICNUMBER;
}

In the PurchaseOrder object, check the project for isAlertable(). Hard wire the condition check at this time, because implementing a generalized predicate is premature. Then, ask the Project to send the alert emails.

The point of the first step is to see if you really understand the concept. It also lays the groundwork for future development. The point of the second step is to get the job done. There is a good possibility that, in future, you will receive similar kinds of requests for "odd" alerting requirements. In that case, you can be ready with a design that you can apply.

Answer 3

This requirement supplements other requirements surrounding purchase orders, but comes in at a much later date in response to some ongoing problem elsewhere in the business.

You seem to think that, once this issue is solved, your customer will have no more ongoing problem elsewhere in the bussiness. Experience shows that they will have.

And you should plan accordingly some system that is extensible. In fact, IM(ns)HO it should have been done from the beginning; thinking that the rules of validation of a Purchase may change over time is not something, and would have helped in implementing the rules that you knew beforehand (by making them more modular).

Anyway for me it is not a programming question but a project management question. Since it was not contemplated in the initial project because nobody asked about that possibility, it mingt be the moment to call the stakeholders and let them decide: a fast, dirty fix that will require modifications to the code for every change, or a more flexible solution that will be delivered later (and probably with some additional costs).

It is the stakeholders who really know what is in the balance (how many of these changes are likely to happen, which are the costs of deploying late the project, even if that check is really so important that it cannot be done by having someone review the data in a report).

You can make an educated guess of the importance of such changes, but really cannot be sure. Also, by involving stakeholders and make them decide, you can hope to educate them into realizing the costs of incomplete/late specifications so that in the next project they do a better job at it.