BA Toolkit: Top Models for Complete Requirements Analysis Webinar Q&A – Part 1

Thank you to everyone who attended the “BA Toolkit: Top Models for Complete Requirements” webinar, hosted by Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA. If you missed it or would like to review, check out the recording.

In the webinar, our expert host covered the top models business analysis practitioners can use in their “toolkit” for complete requirements analysis. Each of the models was reviewed by category and typical analysis patterns were discussed. The webinar is meant to help explain how to leverage models using concurrent requirements modeling, speeding up analysis by exploiting the complementary ways that the key models interact with each other.

See below for some of the answers to questions that came up during and after the webinar that we did not have time to cover. (Part 2 will cover the remaining unanswered questions.)

Q. You’ve used use cases and agile…are you considering Use Cases and User Stories one in the same?

A. The quick answer is that use cases and user stories are different. User stories are high-level requirements that become part of a product backlog and prioritized. At some point, these user stories need to be fleshed out with the detail needed to estimate and build them. Use case models contain the use case diagram, which shows functionality that will be included in the solution, and the use case narratives, which detail the use cases. I could make the case that the high-level use cases are not that dissimilar to user stories, since they both show desired features to be included in the solution. Certainly the format for each is different. Importantly, the use cases as shown on a use case diagram and the user stories are very high-level and need to be fleshed out.

Q. Is it acceptable to have an Actor in a use case be a system?

A. I’m not quite sure what this question is asking. Let me make an assumption and interpret this question as, “Can an actor in one use case be a system in another?” If I’m understanding the question, the answer is yes. For example, let’s say that I am working on a brand new system. I have my actors and use cases. Let’s say that system gets implemented and now I have to modify it. My “system” will be the modifications, and the use cases will be the functionality needed for the modifications. It is very possible that the whole system will be an Actor that needs to talk to the modification piece.

Q. Can you use these models if the solution has nothing to do with a system solution?  For example, what if the solution is a policy development framework?

A.  Yes. Your “system” (you can call it a solution—something that solves the business need for having this framework) is the policy development framework. Your actors are the people who have to create the framework, as well as those who will be using it. The use cases are the ways the actors will use it. For example, perhaps someone has to develop it, which would be a use case (create policy development framework). Perhaps you will purchase it from an outside vendor. There would probably be several use cases relating to this purchase.

Q. What do you mean exactly by synthesize?

A. Part of elicitation (and I’d call it perhaps the hardest part) is to gather all the different information we’ve gotten from a wide and diverse set of stakeholders, documentation, current software and processes, etc. and make sense of it all. Put it all together in a clear, concise way that’s easy to read and easy to understand, so that it can easily be confirmed.

Q. Sounds like there is a high rate of attendance for Business BAs vs. IT BAs. Just wondering what type of BAs are in our audience today?

A: This should probably be a whole separate blog, so I’ll try to make it short. I would not come to the same conclusion. Although many people do, I do not find it helpful to distinguish between business and IT BAs. Business analysis work encompasses a whole range of activities from multiple perspectives, and it is done by a wide variety of roles and titles. I really like both IIBA’s BABOK® Guide and PMI’s Business Analysis Practice Guide. They both make it pretty clear that business analysis starts prior to the beginning of any project (initiative) and continues post-implementation. Not everyone will do all the tasks involved in business analysis, but it’s all business analysis work.

Q. How much detail should a process model include? % of exceptions?

A. I hate to say it depends, but it really does. If you are developing software, you will ultimately need most or all of the exceptions. For process improvement, not so much, and in this case, your stakeholders will be able to tell you whether or not exceptions are worth covering.

Q. Is it valuable to provide the business with a supporting details document with the process model? Specifically, if the process model is going to be utilized for Gap Analysis?

A. Yes, and there are a wide variety of supporting details that can be helpful. I can provide a better answer if I know what type of detail you’re talking about.

Q. What is the best way to estimate the amount of time to allow for modeling?

A. I have estimated modeling using a few different techniques. Let me preface this by saying that I have always had the team track their hours, so I have been successful using history in combination with the estimating techniques. Also, just because it has worked for me doesn’t mean it will work for everyone.

• I have used history for a Rough Order of Magnitude (ROM). For example, on this type of past projects modeling, I took x% of our total time. Given the total ROM estimate for the current project, the modeling piece is this many hours, based on a percentage of the total.
• I have used analogous estimating using history of a similar project to provide a budgetary estimate.
• I have used a parametric estimate successfully, as well. For example, I generally know how long a complex use case model takes (diagram and/or narratives) based on history. I estimate how many there will be and multiply the number of hours for each one by the total number for the project. Same for process models.
• In general, I have not been successful in using bottom-up estimating for modeling. I use it successfully for all other aspects of the project, but for some reason it doesn’t work for me on the modeling piece.
• I have also used rolling wave, and, to some extent, this worked the best. Modeling estimates are part of the “horizon” as long as this horizon is short.
• In general, I think Agile does the estimating piece very well—high-level (such as T-shirt sizing) and then looking at what needs to be done to complete each user story.

Q. If you are compiling written requirements, how far down the modeling path do you go before writing requirements?

A. If I had to compile textual requirements, I would do it in chunks. A bit of modeling, a bit of text, and so on.

There are still several questions that I have not answered, so look for Part 2 of the BA Toolkit Webinar Q&A in the near future.