{"id":7725,"date":"2016-02-23T12:00:00","date_gmt":"2016-02-23T18:00:00","guid":{"rendered":"http:\/\/www.watermarklearning.com\/blog\/?p=7725"},"modified":"2024-09-05T16:38:41","modified_gmt":"2024-09-05T21:38:41","slug":"ba-toolkit-qa-part-1","status":"publish","type":"post","link":"https:\/\/www.watermarklearning.com\/blog\/ba-toolkit-qa-part-1\/","title":{"rendered":"BA Toolkit: Top Models for Complete Requirements Analysis Webinar Q&A – Part 1"},"content":{"rendered":"

\"ElizabethThank you to everyone who\u00a0attended the\u00a0“BA Toolkit: Top Models for Complete Requirements” webinar, hosted by Elizabeth\u00a0Larson, PMP, CBAP, CSM, PMI-PBA.\u00a0If you missed it or would like to review,<\/strong> check out the recording<\/a>.<\/strong><\/p>\n

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.<\/p>\n

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.)<\/p>\n

Q.\u00a0You’ve used use cases and agile…are you considering Use Cases and User Stories one in the same?<\/strong><\/span><\/h4>\n

A.\u00a0The 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.<\/p>\n

Q. Is it acceptable to have an Actor in a use case be a system?<\/strong><\/span><\/h4>\n

A.\u00a0I\u2019m not quite sure what this question is asking. Let me make an assumption and interpret this question as, \u201cCan an actor in one use case be a system in another?\u201d If I\u2019m understanding the question, the answer is yes. For example, let\u2019s say that I am working on a brand new system. I have my actors and use cases. Let\u2019s say that system gets implemented and now I have to modify it. My \u201csystem\u201d 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.<\/p>\n

Q.\u00a0Can you use these models if the solution has nothing to do with a system solution?\u00a0 For example, what if the solution is a policy development framework? <\/strong><\/span><\/h4>\n

A. \u00a0Yes. Your \u201csystem\u201d (you can call it a solution\u2014something 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.<\/p>\n

Q.\u00a0What do you mean exactly by synthesize?<\/strong><\/span><\/h4>\n

A.\u00a0Part of elicitation (and I\u2019d call it perhaps the hardest part) is to gather all the different information we\u2019ve 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\u2019s easy to read and easy to understand, so that it can easily be confirmed.<\/p>\n

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?<\/strong><\/span><\/h4>\n

A: This should probably be a whole separate blog, so I\u2019ll 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\u2019s BABOK\u00ae Guide<\/em> and PMI\u2019s Business Analysis Practice Guide<\/em>. 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\u2019s all business analysis work.<\/p>\n

\"Learn<\/a><\/p>\n

Q. How much detail should a process model include? % of exceptions?<\/strong><\/span><\/h4>\n

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.<\/p>\n

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?<\/strong><\/span><\/h4>\n

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\u2019re talking about.<\/p>\n

Q. What is the best way to estimate the amount of time to allow for modeling?<\/strong><\/span><\/h4>\n

A.\u00a0I have estimated modeling using a few different techniques. Let me preface this by saying that I have always had the team track their hours,<\/em><\/strong> so I have been successful using history in combination with the estimating techniques. Also, just because it has worked for me doesn\u2019t mean it will work for everyone.<\/p>\n

    \n
  • 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.<\/li>\n
  • I have used analogous estimating using history of a similar project to provide a budgetary estimate.<\/li>\n
  • 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.<\/li>\n
  • 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\u2019t work for me on the modeling piece.<\/li>\n
  • I have also used rolling wave, and, to some extent, this worked the best. Modeling estimates are part of the \u201chorizon\u201d as long as this horizon is short.<\/li>\n
  • In general, I think Agile does the estimating piece very well\u2014high-level (such as T-shirt sizing) and then looking at what needs to be done to complete each user story.<\/li>\n<\/ul>\n

    Q. If you are compiling written requirements, how far down the modeling path do you go before writing requirements?<\/strong><\/span><\/h4>\n

    A.\u00a0If I had to compile textual requirements, I would do it in chunks. A bit of modeling, a bit of text, and so on.<\/p>\n

    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.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Thank you to everyone who\u00a0attended the\u00a0“BA Toolkit: Top Models for Complete Requirements” webinar, hosted by Elizabeth\u00a0Larson, PMP, CBAP, CSM, PMI-PBA.\u00a0If 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 […]<\/p>\n","protected":false},"author":4,"featured_media":10554,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"content-type":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[26,13,1],"tags":[],"coauthors":[141],"class_list":["post-7725","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-business-analysis","category-requirements-analysis","category-watermark-learning"],"_links":{"self":[{"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/posts\/7725","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/comments?post=7725"}],"version-history":[{"count":9,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/posts\/7725\/revisions"}],"predecessor-version":[{"id":11376,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/posts\/7725\/revisions\/11376"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/media\/10554"}],"wp:attachment":[{"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/media?parent=7725"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/categories?post=7725"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/tags?post=7725"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/coauthors?post=7725"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}