7

I have a domain expert to work with, but he would throws a lot of details to me verbally. The business logics are complex, business rules change often, the business process is long and multi-ending / intermediate wait-state. There are a lot of cases to deal with (because there are many states for the account, product and subscription).

What's the best way to deal with it? BPMN diagram isn't even low level enough to explain. Written documentations are time consuming to write and read. UML state diagram can become crazily complex very soon.

Any advice would be appreciated.

Henry
  • 289

5 Answers5

6

I would focus on use-cases and user-stories. I could document them, perhaps in a wiki, and give each one an ID (like UC00001). Then when I wrote unit tests and/or integration tests, I'd label them with the use case they inform.

Then when I get to two unit tests that can't both pass because they're mutually exclusive, I'd throw those two use cases back at the domain expert and have him/her reconcile them. That's the only way I can think of to keep it all straight.

Scott Whitlock
  • 21,979
5

My experience working with extremely complex business logic and a domain expert is that the time of the domain expert tends to be extremely valuable, even more so in a small sized company.

He is of course rattling off endless details and nuances to you because it comes naturally to him for one, and secondly because he is likely an extremely busy person. These types of people don't like to have to repeat themselves.

I know this sounds strange but get a decent digital voice recorder like the kind a journalist might carry around with them. Have a sit down and just let him brain dump. While he is talking take notes but only write down the Main Points.

When you are done, tackle a single point at a time and replay the audio sections to recap all of the details that you missed. If you are not an aural person you can dictate the conversation into text or if your office has a secretary or administrative assistant that you are allowed to utilize then ask her to copy the conversation into a textual document for you.

This is the best way in my opinion and you will find that the domain expert will be much more clear and descriptive knowing he/she is being recorded, just make sure he/she is comfortable with this before you do. Further the weekends play havoc on your short term memory, you will come in on Monday and forget critical pieces of information forcing you to bug the domain expert with nagging questions that he has already been over.

Only then when you have the raw information can you formulate use cases and user stories.

maple_shaft
  • 26,570
3

break it down:

  1. get general outline first and create a prelim design of the simple version

  2. then start adding complexities in line with business logic but keep the changes small and compatible with expected updates (but keep consistency always)

(this is a top-down approach)

shut the domain expert up and/or interrupt him regularly with questions/remarks if you need to. you can't help if you don't know what should be done

and business rules shouldn't be changing often, there is likely a scope problem if they do. see if that can be fixed

ratchet freak
  • 25,986
1

You appear to have a very complex task at hand, and need to treat it with the respect it deserves. Are you sure you don't have a tiger by the tail thinking of it as a domestic cat. The outcome of such a mistake is fairly predictable.

The documentation will take a while because its a big complex job requiring complex documents. The UML gets complex and hard to understand because the job is complex and hard to understand. The job needs to be treated as a big complex job, until proven otherwise.

Therefore my advice is start by 'employing' a Project Manager and a Business Analyst. If you are 'it', put away you compiler and read a book on the above two jobs and perform those roles, before being a software developer.

mattnz
  • 21,490
1

I think that this is not unusual. All the litrature in requirements gathering can qualify for an answer here but you can see this elsewhere of course.

On a high level, I would approach the problem this way:

  1. Clearly identify the problem at hand.

  2. Define objective of the system.

  3. Now you have a scope to work with. Identify the main business processes.

  4. For each business process in scope, define: inputs, outputs, actors and business rules (pre conditions, post conditions, rules, exceptions)

  5. Use BPMN to document essential business flow from a business perspective to show how processes relate

At this point, you have documented your understanding of the business. Confirm it and Proceed from this point with your software design to solve the problem.

Time spent on analysis is well worth it.

NoChance
  • 12,532