How do you keep track of complex business rules outside of code?

Question

I'm interested in seeing how other people do this. Especially in situations where multiple different clients are using the same software base with slightly different business rules. What kind of practices do you use to document how everything is supposed to work or business rules.

Basically so when a new developer comes on the team is easy access to see how things are supposed to work because there's obviously a difference between making something bug free and making something work properly.

It would be really nice to have a go to resource rather than having to bring an architect or BSA into the conversation every time a question comes up on how something should be processed.

• yannis: What kind of practices do you use to document how everything is supposed to work or business rules. Trust me, you don't want to know... <sigh>
• Raku: Yo dawg, I herd you liek business rules, so I created rules for your rules, so you can describe rules while you describe rules. SCNR.

Answer 1

This is one of the use cases for BDD frameworks, like Cucumber, that allow you to capture the business requirements in code and test against those requirements frequently. Other approaches I've seen used include long and complicated specification documents, large sheets of paper tacked to the wall, slide decks, and Joe, the guy at the end of the table who knows everything.

• MetaGuru: now THIS looks slick, also found for C#: specflow.org

Answer 2

I would think, at the very least, these would be documented and maintained in the requirements document.

I realize that most places either don't have written requirements, or they're not maintained, but that's a different problem. :-)

Answer 3

We have used BPMN to document and model our business workflows if that's what you mean.

We've also tried to use a workflow engine in a project to let the users participate in modelling, but that hit quite some resistance because they were too afraid to break things, even if it the modeling was done together with a workflow specialist from our IT department.

• Michael K: Being afraid to break things seems pretty common - we have a good bit of user configurable material in our webapp, but we tend to make the changes when our users aren't familiar with the functionality they are trying to change.
• MetaGuru: omg.org/spec/BPMN "OMG", my thought exactly. I'm going to start looking into this though, thanks for a real answer.
• Raku: I think workflow engines and BPMN are an amazing idea in general, but their success depends largely on the tech-affinity of the later users. I hope the next generation of users will have no problem with them. </optimism>
• Raku: Yup, OMG is just the right description for that :-).