9

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.

Improve this question
2
  • 6
    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> Commented May 22, 2012 at 13:05
  • 3
    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. Commented May 22, 2012 at 13:50

3 Answers 3

Reset to default
10

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.

Improve this answer
1
  • now THIS looks slick, also found for C#: specflow.org Commented May 22, 2012 at 14:37
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. :-)

Improve this answer
1

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.

Improve this answer
4
  • 2
    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. Commented May 22, 2012 at 13:27
  • 1
    omg.org/spec/BPMN "OMG", my thought exactly. I'm going to start looking into this though, thanks for a real answer. Commented May 22, 2012 at 13:28
  • 1
    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> Commented May 22, 2012 at 13:29
  • 1
    Yup, OMG is just the right description for that :-). Commented May 22, 2012 at 13:36

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.