Change your requirements habits: get Lean using your BPMS

Many BPM suite implementation projects still use a traditional requirements approach, either based on functional designs or on Use Cases. I’ve found that although these approaches lead to results, they don’t benefit the full potential of current BPM suites making design, development and maintenance harder than necessary -  ultimately not fulfilling the promise of obtaining agility in business’ process management...

Traditionally trained requirements personnel are likely to put much effort in creating a paper based specification of the software. This specification comprise documents describing use cases, process models, non-functional specifications and so on. Input documentation like stakeholder requirements, descriptions of business rules and regulations are referred to using text based links. Specifications are often verified and signed off by business personnel to become “the truth” for all  developers, testers and the implementation team. The value of these specifications is likely to deteriorate over the course of the project. Reason for this is that maintaining the elaborate set of documentation takes a big effort and adds only little value since team members get more and more knowledge about the domain themselves. Bug fixes and change requests augment the documentation set and more information is described in more places. Over the course of a project, the actual database model, the application flow, end-user documentation, web-forms, generated reports and source code become the truth, that is what everyone can depend on to be the actual status. The paper documentation, although often containing information not present elsewhere deteriorates.

Modern BPM suites offer very interesting options to make the requirements process more effective and make it lead to more durable results, taking away some of the problems described above. This is based upon the fact that the suites allow business people and IT personnel to share their work spaces and work together on developing software from their own perspectives. The actual software is generated from the models rather than that it is coded by IT personnel. Documentation is generated from the suite and will always give the up-to-date view of the software.  

Decision table modeled in the suite.

Let me give some examples as to how the requirements process can be improved using some great options of modern BPM suites:

• Store Business requirements and regulation documents in the suite. Create links from the relevant text fragments to the artifacts where they are implemented. Having traceability from the actual documents used by the business will give good support for impact analysis and help to audit compliance.
• Maintain specifications like use cases in the suite as close to the implementation as possible. Don’t create specifications if you can create a self explaining implementation artifact directly: rather than specifying a decision table in a paper document, create the table in the suite directly. The specification when linked to implementation artifacts, glues together functionality and forms a means for controlling the project.
• Create mock-ups of forms using the functionality of the suite to form a great means for requirement elicitation. Especially end-users can contribute effectively when they see what they are actually going to get. For developers these mock-ups form a good starting point as they are already in the right place and don’t have to be translated from a paper representation. In many cases the forms are linked to a Use Case, to the process flow and refer to the domain classes.
• Develop the process models and task flows directly in the suite to be able to walk through the created process, debugging and demonstrating the process flow to end users. This can be done by manually deciding where the flow is continuing and by responding to mock-up forms as created and attached to the right steps in the process.
• Maintain Business rules directly in the system using decision tables, decision trees and expressions and allow business analysts to change these rules themselves and give them opportunities to take IT support matters in own hands as much as possible.
• Maintain domain entities in the suite itself. Define and maintain relationships between the domain entities, define attributes and specify default value or value lists and let the generators take care of database specific implementations.

These are some ideas as to how you can model in a BPM suite directly and prevent double documentation. As I said in the beginning of this item and I hope you come to appreciate a bit, is that a traditional approach will work, but using the possibilities of the BPM suite will make your work more fun, will produce better results in shorter time and will ultimately lead to a better adaptable solution, happier customers and happier end-users:-)