tag:blogger.com,1999:blog-6666038.post-87733892129178300972007-12-20T16:43:00.001-05:002007-12-20T16:43:32.473-05:00<p></p> <p>This is a continuation of my <a href="http://www.trajano.net/2007/12/agile-curam-development-requirements_19.html">previous post</a> in which I specified how I would break up the business analysts with the customer.&nbsp; The approach on getting the requirements out uses the same process as User Stories in Extreme Programming.&nbsp; The following is a recap of the user story groups that would be done in Curam:</p> <ul> <li>End to end scenarios <li>Activity scenarios <li>Product/Rules/Evidence (for non-Curam projects this may not be necessary, but other projects may need to define the data and the rules behind the data from a domain expert). <li>Usage scenarios</li></ul> <p>In this post, I would be talking about the first group which is the end to end scenarios.</p> <p>An <em>end to end scenario </em>is representative of a full workflow as told by the customer.&nbsp; It is best to get an idea what the end to end scenarios are first, without it there isn't going to be a good understanding of how things would flow through the application.&nbsp; Without that, you'd just end up with chaos in development.</p> <p>Having end to end scenarios defined makes things a lot easier to develop and test.</p> <h2>Input sources for end to end scenarios</h2> <p>There are three possible sources for end to end scenarios:</p> <ul> <li>RFP from the customer</li> <li>User Stories written by the customer</li> <li>Previous output products if any.</li></ul> <h2>Output work products for end to end scenarios</h2> <p>There are two possible work products from the end to end scenarios:</p> <ul> <li>High-level workflow.</li> <li>Sub-workflow requirements.</li></ul> <p>This gathering information for the end to end scenarios is an iterative process, the output work products feed back into the process as new input.</p> <h2>High-Level workflow</h2> <p>A high-level workflow would at minimum capture the following:</p> <ul> <li>How does it get started?</li> <li>What information do we have when we enact the workflow?</li> <li>What are the activities?</li> <li>Who are assigned to each activity?</li> <li>Are there any activities that can be split into a sub workflow either because it is vague or to complex?</li></ul> <p>The workflow is then created and visualized using the Curam workflow activities.&nbsp; The workflow can then be shown to the client to confirm the understanding of the scenario.&nbsp; This task needs the BA to be cognisant of what the Curam workflow can provide.&nbsp; The workflow would also determine who are involved.</p> <p>Although it would be nice, there are some information are not <em>immediately</em> required to complete a high-level workflow.&nbsp; It is best that the these extra information would be detailed by a different group of BAs.&nbsp; Otherwise you'd get into analysis paralysis of the end to end workflow and won't get anything done.&nbsp; They are:</p> <ul> <li>What kind of information would we need per activity?</li> <li>Notification requirements.</li> <li>Distinct names for each element of the workflow.</li></ul> <p>In the en, the work product would be a document that would have the following sections:</p> <ul> <li>Workflow diagram</li> <li>A section for each activity</li> <li>Enactment information</li></ul> <p>Once the document has been signed off, it is sent down the pipe to the activity bucket.&nbsp; Which will detail off each activity on hopefully a <strong>different </strong>document, but tied to the original work product.&nbsp; The reason why you'd want it as a different document is to ensure tracibility.&nbsp; That is:</p> <ul> <li>If the customer decides to change the original work product, we know that the activity document would need to be revisited.</li> <li>Accountability, we want to ensure that the detailed version keeps the original information intact.</li></ul> <p>The activity document should have the same content as the original one though, it would just have new detailed information added underneath it.</p> <h2>Sub-workflow requirements</h2> <p>Determine sub-workflow requirements should not be too difficult.&nbsp; One of best ways of doing this is to define a metric.&nbsp; A good metric would be that the workflow diagram must fit within one legal sized paper in landscape orientation.&nbsp; By limiting the size of the workflow, you'd be forced to write sub-flows in order to handle complexities.&nbsp; The advantage of this would be better focus for the customer and the BAs as they won't get too bogged down in the details.</p> <p>Imagine having workflow diagrams the size of the Curam reference model poster, you'd probably have difficulty following it.&nbsp; Even worse if you are a new person to the project.</p> <h2>Working with the customer</h2> <p>Many of these scenarios be done at the same time, but the customer needs to prioritize them.&nbsp; It takes probably a couple of days to draw a 50 activity workflow by someone that has done it once before.</p> <p>The cheapest ways of building the workflow are to do it on a shared piece of paper or transparency sheet for larger audiences.&nbsp; Then have someone draw it more professionally afterwards using Curam.</p> <p>When capturing the detail for an end to end scenario, make sure the customer's focus is going from end to end, rather than expanding every single detail which may take a longer time.&nbsp; Explain to them that the parts they are not 100% sure of or would require a lot of steps can be broken into a sub-scenario (which would be coded as a sub-workflow eventually).&nbsp; Doing this would avoid analysis paralysis.</p> <h2>Non-Curam projects</h2> <p>For non-Curam projects, try and convince your customer and architect to invest time and effort on implementing a workflow solution.&nbsp; There are several out there, some of them free.&nbsp; Others like WebSphere Business Integration/Modeller provide a lot of <strong>overkill</strong>, but it is <strong>good overkill</strong>.&nbsp; Just like DB2, it has an overkill of features, but that is what makes it strong and able to deal with many of the things you throw at it.</p> <p>However, even if you do not have a workflow system, having end to end scenarios defined makes things a lot easier to develop and test.</p> <h2>Conclusion</h2> <p>The output work products for the end to end scenarios will provide a framework for you test team to follow when they are actually testing the application.</p> <p>These scenarios will help foster and reinforce understanding of the customer's business both to the BA <strong>and </strong>the customer.&nbsp; Visualization is a very powerful learning tool.</p> <p>By breaking things into activities, the other BAs can be more narrowly focused, which means that the development team would also be narrowly focused because the flow would be handled by the workflow engine.&nbsp; Also since each activity is more well defined, it is easier for the PM to plan and set dependencies between each activity.</p> <p>So as you can see having end to end scenarios defined makes things a lot easier.&nbsp; However, not just to develop and test, but planning <strong>and</strong> fostering customer understanding as well.</p> Archimedes Trajanohttp://www.blogger.com/profile/15993184075121538415noreply@blogger.com