Modeling Business Logic Using NON-Techies

Question

Customization: Winform / ASP.NET MVC Projects. Exploring NHibernate SQL Server Applications

I work with clients who have no idea how to model the application. This is what I am for. However, we have many conflicts with verification, misunderstanding, etc.

For example, a customer will request an order entry screen. There should be a “product” on the screen. It is beautiful and dandy. However, the client did not know to inform me that the user cannot order a class “A” product if it is not on Tuesday.

Or they need a time entry screen. 2 days before he went into production, they accidentally forgot to mention that certain actions are valid only for certain situations. These situations are weeks of coding.

These, of course, are some crude examples (not many!). But the problem is that these non-technical customers are planning their business logic. For some reason they did not understand that the problem of “class A” would arise in two weeks, etc.

I am all for flexible programming, but is there any easy way to somehow make business logic so extremely easy to use and change on an almost daily basis?

Of course, I share the project into hopeful clever things using NHibernate, etc. But to make this BI logic so dynamic that it really complicates the time frame of the project, etc.

Any suggestions? I know that there will never be an ideal client (or an ideal provider), but how do you guys deal with constant misunderstandings?

Thanks.

Answer 1

The problem is that the client can always come up with some ideas with the left margin. "Oh, if a customer orders a Class A product on Tuesday, and it happens to be their birthday, give them a 50% discount and a free Class B product. And notify the Chairman to give them a phone call."

You CANNOT program for all cases. If you plan to create a mechanism for super-duper rules for business logic, this should be because your system will be widely deployed and must be configured by clients. Not because your customers don’t know what they want - in this case you are building a system to anticipate customer requirements, not a system for ordering products (or whatever that means to it).

Maybe I'm old-fashioned, or maybe because I had too many bad experiences, but I'm not at all interested in rapid development. How do you know which direction to travel if you don’t know where you want to go? For something more than a small, one-function trivial application, I (roughly) follow the Waterfall iterative method, keeping the cycles small. Make sure you have a complete document on what the system will do. After the customer has signed it, this is what they get. If they have any changes, they all come in "Version 2", which will be launched after the deployment of Version 1 into production. A little annoying them, but in the end, everything is much happier.

Yes, there are always exceptions, for example, when management needs a data entry system in 2 days. But then make it clear that if they add any requirements as you go, theyre automatically giving you as much extra time as you need to implement them.

Answer 2

I highly recommend the book “Domain-Driven Development: Fighting Complexity at the Heart of Software,” by Eric Evans. This is a great book that talks about how to communicate with your customers so that you are better able to model your needs.

The book is based on the concept of Ubiquitous Language ... a language that you, as a software architect, create in conversations with your customers using a tool called modeling.

As an architect, there is a fundamental rule that you must accept, as it will greatly help you to convey business value to your customers for your purposes: the client’s task is not quite that, and it’s neatly packed in a beautiful box that you can simply unfold and to build. As an average person between the client and the developer, it is important for you to understand that your job is to extract requirements from your customers.

Why am I saying this? The role of your customers is business, not software development. They are worried about making money so that they can pay their employees, their advertisers, their other bills ... and maybe make some profit in the process. They don't care about the details of how the software ... the tools they use to do the job ... work. They just make sure that the tool does what they need.

If you learn that as an architect, one of your roles is the requirements extractor, you will become more successful. With such success, your customers should be happier, which should lead to the fact that you will be happier and more satisfied with your work and the software that you and your developers create. His difficult task is a completely different approach. It requires a greater presence of mind and foresight, which gives you an idea of ​​the needs of your customers ... letting you know what they need before they do it. If you develop and use the ubiquitous language as your project continues, each meeting with your customers will improve as you both learn how to communicate in common terms that have clearly defined meanings.

Given all this, here are a few examples that could help you improve your requirements earlier:

---

Cust: So we need an input screen into which we can enter product orders.
Arch: Well, that’s doable. Can you give me more details about this order entry screen ?
Cust: Hm, ok ... I'm not sure ...

Arch: If possible, here are some thoughts I have about business rules:
Arch: Are there any restrictions on what can be ordered?
Cust: Oh! Yes, we do not want our customers to order any Class A products , unless its Tuesday.

Arch: Great, this is helpful. Do you offer any combination of deals, so if a customer orders product X, can they get product Y at a discount?
Cust: Hmm, not really. We have promotions , if a client is included in a specific advertising code , they can conclude a deal with one or more products.
Arch: Okay, so there are class restrictions and promotions . Anything else that might affect the behavior of the order screen?

Cust: Hm, now that you mention it ...

---

This is a common scenario when doing DDD. (Note that this is also very flexible because DDD and Agile work hand in hand.) In the dialog above, I highlighted in bold and italicized terms that should be part of you and your Ubiquitous Language client. The items in bold are the conditions that your client uses to describe some things about their business. These terms become part of your "software domain", which is the programming model of your customer business (at least the parts that you write software to). I use italics in terms that architects and developers use, such as business rules. If you read Evan's book, he explains in more detail how to develop the ubiquitous language and how to use special visual modeling to develop his software using terms from this ubiquitous language.

Hope this helps. And hopefully, DDD: Complexity at the Heart of Software will help even more. The ultimate goal, once you have the proper connection with your client, there will be (or very few) misunderstandings.

Answer 3

Get THEM to write it!

AFAIK, cucumber can be used with .NET

Cucumber allows the client (with minimal training) to write as they would like the application to behave. I did an informational interview with a store where customers wrote all the BLs in the cucumber, so there were few misunderstandings, and as a bonus, he encourages technicians who begin to understand how we need to think about problems.

Answer 4

Being able to meet requirements is difficult in any industry, not just IT, although it is probably a little complicated by the “mystery” associated with how this happens and people's assumptions about it.

Open communication, frequent and regular (I can’t emphasize regularity and frequency) customer feedback, realistic expectations and some conversations about how the systems are built and how the changes can work the rails have led most people to understand that that they need to invest considerable time and effort with me to communicate with their heads up to 80% of what needs to be done.

The remaining 20% ​​is a guessing job and will either happen by osmosis, or will not happen, or will happen after a delay before the original deadline.

But since they know this in advance, they are not surprised, and all this works great in the end.

Another important implementation of IMO is that the client always understands that he wants something else. This is normal and not limited to IT. As their vision comes to life, and they begin to use it, they realize that in some respects they were simply mistaken. Thanks to open communication, frequent and regular feedbacks, you can easily and quickly adapt to this wrong course so as not to cause too much damage.

Since they pay me and their system, they can request any changes that they want, as long as they also understand that they will have variations, almost always in cost and often in time.