Modelling Business Logic with NON-Techies

Question

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 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.

Answer 1

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.

Answer 2

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.-

Answer 3

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.