Hanging on to old requirements habits of specifying everything up-front and requiring sign-off of specifications before implementation, is not going to make us effective using these tools. Translating paper specifications to working software is difficult for developers, let alone for customers. As the sign-off this document becomes part of the contract, a customer will try to avoid any mistakes as he has to suffer from any rework later on. Special attention is given to getting “complete and correct” requirements … on paper...
What if we had a tool that enabled us to demonstrate to our customers what we have in mind directly. How different, if we could create models that are readable by customers and need no extra translation by developers. How great, if we (and our maintenance teams) would always have the corresponding version of the requirements available when looking at some implementation artifact? Sounds like a beautiful future...
I'll tell you, the future has arrived when using state-of-the-art BPM suites. I would like to give you an example on how you can exploit certain features of a BPM suite to obtain a lean requirements approach.
Requirements are implementation - Be Lean!
I would like to show you how to support business processes using IBM WebSphere Lombardi. Suppose we have the following business process to handle a Buyers Purchase Order:
figure: IBM WebSphere Lombardi Process Model
The question is: What requirements artifacts do we need to describe this process sufficiently for stakeholders to understand what’s going on and for the development team to understand what to build?
Let’s start at the process model: Some stakeholders like to get an overview of the process and get exited about process models like the one shown above. They can get an overview of who is doing what and when. They get an idea of decision moments in the flow and by analysing actual information gathered from ran processes they can optimize the flows if needed. However these models don’t appeal to everyone’s imagination... Isn’t it so that especially end-users are less interested in the overview but more in the details; that they can best contribute in the requirements process if they see the end-results of a run process, when they see forms with actual information to be entered in the right sequence.
Wouldn’t it be great if we could cater both types of stakeholders?
...the good thing is, we can...
The process model shown above is the actual executable process model in Lombardi. There is no need for us requirements people to describe it anywhere else or to clarify it anywhere else. The model neatly shows who does what, when, by showing swim lanes, process steps and process flow respectively. The model speaks for itself and since process steps are well named it is clear for almost anybody in the domain to get a good idea of what is going on...
To cater the other type of users who get excited if they see actual forms where to enter information, IBM Lombardi allows us to run the process in demonstration mode, showing mock-ups of the forms (to be described later) and to let end-users test the flow of the process by entering values and selecting scenarios showing the successive actions that take place.
Brings us to what we do have to describe apart from what IBM lombardi gives us by implementing the solution. Probably we want to give an overview of the objectives to achieve using this process model and the details of the process steps. On the details of the process steps, lets take the human step to Submit a Purchase Order, in normal requirements practices we are used to writing a something like a Use Case describing the interaction of the User with the System: we would describe the data entered and the forms used, we would describe validation rules and business rules and we would describe supplementary specifications.
Using Lombardi we can take a lean approach to providing this information and only describe those assets we can’t model in the tool directly. Let’s see what we can specify in the tool apart from the process model already described above: Domain objects, User Interfaces, Business and Validation rules, Coarse steps of the UseCase.
Domain objects
With Lombardi we describe the domain objects and data to be used in the system. Often the implementation glues together information available in various legacy systems and standard applications. Some of the processing probably takes place in the legacy systems and glues together the various systems. Often information crosses departments making it important to have a mutual understanding on the meaning of each domain element and attribute. Terms like Shipping date can easily be interpreted or defined differently over departments: one department may define the shipping date being the date where the order is picked and the box is sealed, another department may define the shipping date as the date where the order actually leaves the plant. Using the descriptions of these attributes and using business rules we can clearly define what is meant with a shipping date.
IBM WebSphere Lombardi DomainModel
User Interface
BPM suites allow us to create mock-up’s of the user interfaces or the actual user interfaces used in the system itself. The mock-up’s may not contain all details in the requirements phase, but because we can show this mock-up in it’s place in the process, we have a very effective way to communicate our ideas about the process and user interfaces. In the run down of the process the user can enter data and see if the flow of forms is correct.
IBM WebSphere Lombardi User Interface
Business Rules
Also the business rules we can describe directly in the BPM suite in a readable format. see for instance the decision table below. The headers above the table refer to classes and attributes in the domain model we have created or that we update on the fly. For us requirements people it is easy to create an executable model and have the user enter data in a form, for instance the values for updatedQuantityPercent and updateUnitPricePercent. The decision table can be used in various places: in the process flow to decide on the next step or it can be used to show or hide information in a form and so on...
IBM WebSphere Lombardi validation rule
Coarse Use Case steps
We sometimes only scratch the surface by providing and creating the models described above. Besides specifying the user's interaction with the system we often have to describe how to connect to legacy systems or how a certain task breaks down in lower level activities. We can break down the functionality in smaller steps to give more detail about the processing. Often these descriptions are sufficiently describing what is needed from a functional level. If more description is needed then describe each by specifying what the user wants to acheive with this step. Also by having these models in the tool we can easily demonstrate the working of the application to the user. Do we still need a detailed description of the workflow of the user interaction? Maybe yes...But probably no, since we can model further details in a service:
IBM WebSphere Lombardi service
Using good naming we can put extra detail to communicate with users and for the implementation team to implement these interactions in the right order.
http://www.ibm.com/developerworks/websphere/library/techarticles/1101_wang/1101_wang.html
One of the issues with this way of using the actual models as a description of the functionality is that we have to be cautious not to stick too much detail to the first level of these models. Take the service... When detailing this service developer likely add more steps if necessary. If there is too little focus on structure we may end-up with unreadable and unmaintainable models.. be aware...
By doing so our requirements process creates the actual models and gives us the power to demonstrate the implications of choices directly getting feedback from users on actual implementation rather than on paper representation of the implementation.
I would say, no time to sit back... no time to hang on to old habits...
There are now new ways to serve our customer with way more output! Take control... add new habits, start working in an agile fashion use a lean requirements approach!
Start empowering your end-users!
