How to reconcile these two requirements?

Question

I'm developing a system on which there are two requirements that seems to be in conflict. Since this seems to be a situation that can be more general, I thought it to be valid to ask here.

The system in question is for management of the finances of a company.

In the system the customers are registered and in the customer data it is possible to specify the services the company is providing for them.

The system also has a billing module, where the company registers its services, and issues bills to the customers by selecting the service they registered.

The two requirements in conflict are:

1. In the customer registration module, the services are predefined. One picks what services are provided for each customer and the properties of the corresponding service, which tune how the service is provided. The point is that each service has some defining properties. Furthermore, on other areas of the system, there is business logic that needs to know about those services and properties. This makes the services end up hardcoded.

2. In the billing module, the end user wants to register the services by their own. They want to be able to register the services and categorize the services they are billing in their own way.

Now, these two are in conflict because integration is required. In the sense that when a service is provided to a customer, the end user wants the bill to be issued automatically.

One example: if there is one Support service, on the customer registration there could be a class representing the service or a property of the Customer, indicating whether the service is provided or not. This will allow the system to make decisions and perform business logic related to the Support provided to this Customer.

On the other hand, on the billing part of the system, the end user added manually a register "Support". Now, if we need to automate, there is no way the system can automatically know that the "Support" that is hardcoded there, in a class or in a property, corresponds to the "Support" entry on the database.

In my opinion the correctly way to solve this issue is to remove the possibility of the end user registering the services themselves. But then there's the problem: what if the end user doens't want to hear and wants it that way no matter what?

How can I reconcile these two requirements? How can I deal with the situation where in two parts of the system the same concept appears, in one it needs to actually be coded and in the other the user wants to have freedom to register it by itself? I believe DDD bounded contexts can help here, but I don't know how yet.

Answer 1

It appears that you don't have two conflicting requirements; you have one customer requirement that conflicts with an existing implementation.

Only requirement 2 appears to describe something the customer actually wants. Requirement 1 describes how something was already implemented and justifies it because different parts of the system "need" something.

This looks like a case of a very common problem: technical decisions are inappropriately driving design choices and limiting what is considered possible.

The implementation decisions that led to this point need to be revisited.

• Probably the implementation that led to the situation in #1 needs to be changed so that the customer's requirement can be met.
• In some cases, a customer requirement may be infeasible for business reasons. For example, the functionality they want is not in the contract, or their budget or schedule would not allow it. If so, this discussion needs to be reframed in the context of what is possible from a business perpsective.
• Occasionally, a customer requirement might actually be impossible, due to some inherent technology limitation. But this is pretty rare, and your case doesn't strike me as such.

Answer 2

From your comment:

Who decides what services must be provided in the system is the end user. The point is that by the way the end user told the requirements, it seems they want a predefined set of services on the customer registration, while they want to actually be free to type in the services at the billing part. The question is how do I deal with the fact that the service they typed in is the same as the predefined one. Actually I don't know why they want to type in any services. I edited the question trying to focus more on the requirement itself.

You appear to be conflating a user requirement and a system requirement that exists simply because of implementation choices. The system is not in charge. It doesn't get a vote.

You've brought up an input issue. It's a classic one: menu vs free form field. Menus ensure choices are valid but quickly becomes painful as the number of choices grows.

Free form fields handle a large number of choices well, look at google. But free form relies on the user knowing the name of the thing they want and being able to spell it, which is why google invested so much in spell checking.

There are two ways to bridge this gap. A menu that lets you type makes a large number of options more tolerable. And a free form field that watches you type and makes suggestions can keep you from entering nonsense.

It's the same user interface problem regardless of whether it's for billing or configuration. So the fact that your system does it differently in different places isn't important.

Where this gets interesting (the ancient Chinese curse kind of interesting) is if you need to add a new service. Are you going to let the user do that? Do you want them doing this without knowing this is a new service? How do let them know it's new? How do you keep them from creating a new way to spell an old service?

There are tricks to deal with all that. And if that's really what you're asking about ux.stackexchange.com is likely where you want to be.