Agile Curam Development Requirements Gathering

tag:blogger.com,1999:blog-6666038.post-44403921498733655952007-12-13T05:00:00.001-05:002007-12-19T11:00:19.378-05:00Agile Curam Development Requirements GatheringGathering requirements in Curam does not appear to be an easy thing to do.  One can go with a <a href="http://en.wikipedia.org/wiki/Big_Design_Up_Front">BDUF (big design up front)</a> approach or an iterative development approach.  With a COTS package like Curam a combination of the two approaches would be more beneficial. I've seen a lot of <a href="http://en.wikipedia.org/wiki/Big_Design_Up_Front">BDUF (big design up front)</a> type documentation in a lot of my projects.  Unless you are extremely good at estimating and your customers are very accomodating, these documents tend to take too long to create and is not 80% perfect when they reach their original deadlines. Iterative development such as RUP/XP try to remedy that.  However, unless your sales team is good enough to sell a time and materials contract, then an iterative development approach from requirements gathering to actual development would be a hard sell as well. Unlike the traditional development approach where you would almost start with scratch, a COTS solution offers a lot of things for you out of the box.  However, you would need someone who knows what you can get with minimal changes out of the box.  In such cases, you would need more people doing business analysis rather than actual developers.  The BA vs Dev mix should be roughly equal, with some of the BAs transitioning to a test team or Curam administrative roles as time progresses. <blockquote> I am writing this, in case I do switch to a BA lead role with focus on requirements gathering and analysis in a Curam project that may be fixed price. I say lead, because Curam requirements gathering for any reasonable sized application is not a single or two or three BA job, doing so is asking for a lot of trouble.  Conversely, it is not a single or two or three customer representative job, doing so is asking for a lot of trouble as well.  It should also be one BA to one customer business rep.</blockquote> Although my experience in COTS is primarily Curam, I think the concept would apply to most other COTS. This is the first in a series of blogs regarding requirements gathering.  I thought it best to start at the point before you even start working... <h2>Proposal and estimating</h2> Estimating the requirements gathering from an RFP depends highly on the quality of the RFP itself.  The following list shows a grid of how I would capture things.  The numbers represent some factors I would use in terms of days when calculating things. <table border="1"> <tbody> <tr> <th> </th> <th>High Complexity</th> <th>Medium Complexity</th> <th>Low Complexity</th></tr> <tr> <th>End to end scenarios</th> <td>30</td> <td>20</td> <td>10</td></tr> <tr> <th>Activity scenarios</th> <td>15</td> <td>10</td> <td>5</td></tr> <tr> <th>Delivery definitions</th> <td>10</td> <td>5</td> <td>3</td></tr> <tr> <th>Rules/Evidence</th> <td>30</td> <td>20</td> <td>10</td></tr> <tr> <th>Usage scenarios</th> <td>15</td> <td>10</td> <td>5</td></tr></tbody></table> Based on the data, I apply the factors to the counts I would gather from the RFP and just sum things up + add whatever buffer factor I would need. Complexity is determined by how complete the RFP is in the first place.  If there is sufficient detail to generate work products for each component, then I would mark them as low complexity, unless it is really complicated.  Remember, I am not building the final application, but rather gathering enough information so the development teams can do their work. Please note that what I have written above talks about effort.  It does not talk about dependencies so things may shift further in duration because of such dependencies.Archimedes Trajanohttp://www.blogger.com/profile/15993184075121538415noreply@blogger.com