Modelling Business Logic with NON-Techies

The setup: Winform/ASP.NET MVC projects. Learning NHibernate SQL-Server driven apps

I work with clients that have no idea how to model an application. That's what I'm for. However, we have lots of conflicts with validation, mis-understandings, etc.

For example, the client will ask for an order entry screen. The screen should require a "product". That's fine and dandy. However, the client didn't know to tell me that the user can't order a product of "Class A" unless it's Tuesday.

Or, they need a time entry screen. 2 days before it's rolled into production, they casually forgot to mention that certain activities are only valid for certain situations. These situations being a week of coding.

That's of course, some crude examples (not by much!). But the problem is getting these non-technical clients to layout their business logic. They somehow didn't realize that the "Class A" problem 开发者_JS百科would come up two weeks later, etc.

I'm all for agile programming but is there an easy way to somehow make business logic like this extremely easy to implement and change on almost a daily basis?

I of course am splitting the project into hopefully intelligent pieces, using NHibernate, etc. But making this BI logic so dynamic is really making it hard to project timelines, etc.

Any suggestions? I know there will never be a perfect client (or a perfect provider) but how do you guys deal with the constant mis-understandings?

Thanks.

---

The problem is that the customer can always come up with some completely left-field ideas. "Oh, If the 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 CAN'T program for all eventualities. If you do plan to build a super-duper rules engine for business logic, it should be because your system is going to be widely deployed and needs to be customized by the customers. Not because your customers don't know what they want - in that case you'd be building a system to anticipate customer requirements, not a system to order products (or whatever it's main purpose is).

Maybe I’m old-fashioned, or maybe it because I’ve had just too many bad experiences, but I’m not at all interested in agile development. How do you know what direction to travel unless you know where you want to go? For anything more than a small, single function trivial application, I (roughly) follow an iterative Waterfall method, keeping the cycles small. Make sure that you have a complete document of everything that the system will do. Once the client has signed-off on it, that’s what they’re getting. If they have any changes, they all go into “Version 2” which will be started after Version 1 is deployed into production. A little irritating for them, but in the end everyone is a lot happier.

Yes, there are always exceptions, like when the management need a data-entry system in 2 days. But then make it clear that if they add any requirements as you go, they’re automatically granting you as much extra time as you need to implement them.

---

I highly recommend the book "Domain-Driven Design: Tackling Complexity in the Heart of Software", by Eric Evans. This is an EXCELLENT book that teaches how to communicate with your customers so that you are better equipped to model their needs.

Central to the book is the concept of Ubiquitous Language...a language that you, as a software architect, create during conversations with your customers, via the tool called modeling.

As an architect, there is a fundamental rule that you should come to embrace, as it will greatly help you in your endeavors to deliver business value to your customers: It is not the job of the customer to give you requirements all nicely and neatly packaged in a pretty box that you can just unwrap and build. As the middle man between the customer and the developer, it is critical for you to understand that it is YOUR job to extract requirements from your customers.

Why do I say this? Your customers role is business, not software development. They are concerned about making money so they can pay their employees, their advertisers, their other bills...and maybe make some profit in the process. They are not concerned about the details of how software...the tools they use to get the job done...work. They simply care that the tool does what they need it to.

If you can learn that as an architect, one of your roles is that of "requirement extractor", you'll become more successful. With that success, your customers should be happier, which should result in you being happier and more satisfied with your job and the software you and your developers create. Its not an easy thing to do...it takes a whole different approach. It requires a greater presence of mind and forsight that gives you insight into your customers needs...letting you know what they need before they do. If you develop and use an ubiquitous language, as your project continues, each meeting with your customers will improve as the two of you learn how to communicate in common terms that have well-defined meanings.

Given all that, here are some examples that might have helped you get better requirements earlier on:

---

Cust: So, we need an order entry screen that we can enter product orders on.
Arch: Ok, thats doable. Can you give me more specifics about this order entry screen?
Cust: Hmm, well....I'm not sure...

Arch: If I may, here are some thoughts I have about business rules:
Arch: Are there any restrictions about what may be ordered?
Cust: Oh! Yeah, we don't want our customers ordering any products of Class A unless its Tuesday.

Arch: Great, thats helpful. Do you offer any combination deals, so that if a customer orders Product X, they can get Product Y at a discount?
Cust: Hmm, not exactly. We do have promotional deals, were if a customer enters a certain promotion code, they can get a deal on one or more products.
Arch: Ok, so there are class restrictions and promotional deals. Anything else that might affect the behavior of the order screen?

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

---

This is a common scenario when doing DDD. (Note, this is also very Agile, as DDD and Agile work hand in hand.) In the dialog above, I have bolded and italicized terms that should become part of you and your customer's Ubiquitous Language. Things in bold are terms your customer uses to describe certain things about their business. These terms become part of your "software domain", which is the software model of your customers business (at least the parts you are writing software for.) I have italicized terms that architects and developers use, such as business rules. If you read Evan's book, he explains in much greater detail how to develop an ubiquitous language, and how to use ad-hoc visual modeling to design your software using the terms from that ubiquitous language.

Hopefully this helps. And hopefully, the book "DDD: Tackling Complexity in the Heart of Software" will help even more. The ultimate goal, once you have a proper rapport with your customer, there won't be any (or very few) misunderstandings.

---

Get THEM to write it!

AFAIK, cucumber can be used with .NET

Cucumber lets the client (with minimal training) write just how they'd like the app to behave. I did an informational interview with a shop that got the clients to write all of the BL in cucumber so there was little misunderstanding, and as a bonus, it encourages non techs to start to understand how we need to think about problems.-

---

Being able to elicit requirements is difficult in any industry, not just in IT, although it is probably complicated a bit by the 'mystery' surrounding how IT happens, and the assumptions people make because of it.

Open communication, frequent and regular (I can't stress regular and frequent enough) feedback from the client, realistic expectations and some 'cut-the-crap' talk about how systems are built, and how changes can run things off the rails have resulted in most people I deal with understanding they need to invest significant time and effort with me upfront to communicate from their heads to mine 80% of what needs to be done.

The remaining 20% is guess work, and will either happen by osmosis, won't happen, or will happen after a delay to the initial deadline.

But because they know this upfront they aren't surprised and it all works out fine in the end.

The other important realization to make IMO is that the client will always realize they want something different. Its normal, and not limited to IT. As their vision comes to life and they start using it, the realize they just got their idea plain wrong in some regards. With open communication, frequent and regular feedback you can adjust from this wrong course easily and early enough that it shouldn't have caused too much damage.

Since they're paying me and its their system, they can request any change they want, as long as they also realize it will come with a variation, almost always to cost and often to time.