Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
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> –  Yannis Rizos May 22 '12 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. –  Raku May 22 '12 at 13:50

3 Answers 3

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.

share|improve this answer
    
now THIS looks slick, also found for C#: specflow.org –  ioSamurai May 22 '12 at 14:37
1  
+1 for Joe, so typical –  Chris Wagner May 23 '12 at 6:49

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

share|improve this answer

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.

share|improve this answer
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. –  Michael K May 22 '12 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. –  ioSamurai May 22 '12 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> –  Raku May 22 '12 at 13:29
1  
Yup, OMG is just the right description for that :-). –  Raku May 22 '12 at 13:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.