Business Analysis en 100 Small Business Pain Points <span class="field field--name-title field--type-string field--label-hidden">100 Small Business Pain Points</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/1" lang="" about="/user/1" typeof="schema:Person" property="schema:name" datatype="" class="username">admin</a></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 03/29/2023 - 17:51</span> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>Despite what you may have heard, owning a business is unusually painful.</p> <p>That’s good news for the companies who market products and services to small businesses. After all, pain is a motivator for action. Ask any salesperson how they get deals done and they’ll tell you that it’s all about understanding the prospect’s pain points and offering a way to ease the pain.</p> <p>In case you didn’t know it, figuring out how to reach small business owners is a niche area that Walker Sands is particularly strong in.</p> <p>Over the years, we’ve helped a number of companies, large and small, to figure out how to reach small and mid-sized businesses (SMB customers). As a result, we’re very familiar with small business pain points as a precursor to research, review and purchase. In fact, here’s a list of small business pain points that we’ve thrown together quickly for this blog post.</p> <p>There are 100 small business pain points in this list.<em> In a future article</em>, I’ll discuss how to make sure your marketing messages and your sales team are in front of a small business owner at exactly the right time, just as they are experiencing a world of pain from one of these small business pain points and are eager to pay you a little money to make the pain go away.</p> <p><strong>Small Business Pain Points</strong></p> <p>1. We don’t have enough money.</p> <p>2. We are not able to get new customers.</p> <p>3. We are not able to keep existing customers.</p> <p>4. Our revenues are too low.</p> <p>5. Revenues are OK, but profitability sucks.</p> <p>6. Our employee turnover is too high.</p> <p>7. I need to sell this business.</p> <p>8. My business partner is a jerk.</p> <p>9. We’re having quality issues with our products.</p> <p>10. Our website sucks.</p> <p>11. We’re constantly out of office supplies.</p> <p>12. We need to move to bigger space.</p> <p>13. I think one of my employees is a drug addict.</p> <p>14. We hired somebody and we didn’t realize they had a criminal record.</p> <p>15. Our prices are too low.</p> <p>16. Our products are growing obsolete.</p> <p>17. A virus infected every computer in our office.</p> <p>18. My business partner just passed away.</p> <p>19. I’m getting a divorce and my wife wants the business.</p> <p>20. We just lost our biggest client, accounting for 50% of our revenues.</p> <p>21. My employees are coasting on me. There’s no work ethic here.</p> <p>22. Our business culture sucks.</p> <p>23. I don’t have a good business lawyer.</p> <p>24. One of our customers is suing the business.</p> <p>25. My biggest competitor just raised $50 million in venture capital.</p> <p>26. Nobody knows who we are.</p> <p>27. I’m not getting any foot traffic into my store.</p> <p>28. All this government paperwork is killing me.</p> <p>29. I hate, hate, hate processing payroll.</p> <p>30. I don’t have enough money to pay my estimated income taxes for the quarter.</p> <p>31. We keep hiring idiots.</p> <p>32. My accountant is not returning my phone calls.</p> <p>33. We have a bunch of receivables, but the checks are not coming in for some reason.</p> <p>34. The competitors’ advertising is way better than ours.</p> <p>35. We don’t show up for anything relevant to our business when people search in Google, Bing or other search engines.</p> <p>36. I can’t find workers compensation insurance for my business.</p> <p>37. How am I supposed to get and be able to afford a good small business health insurance plan for my employees?</p> <p>38. I’m ready to shut this thing down. I’m at my wit’s end.</p> <p>39. Janet just told me that Steve is sexually harassing her at work, and she’s really pissed.</p> <p>40. I have no clue how much my business is worth?</p> <p>41. I think I’m paying too much for shipping.</p> <p>42. Our office equipment keeps breaking down.</p> <p>43. I would like to franchise this business but I have no clue how to get started.</p> <p>44. Our business credit rating is bad.</p> <p>45. I need a small business credit card, ideally without a personal guarantee.</p> <p>46. I never bothered to incorporate. I think I’m overdue to do it, because we’re struggling and I’m worried creditors are going to come after me personally.</p> <p>47. I’m dying and I have no viable successor for this business.</p> <p>48. None of my kids has any desire to work for my company.</p> <p>49. Our legal bills are out of control.</p> <p>50. Our finances are a mess.</p> <p>51. This is a commodity business. How can we differentiate ourselves on anything but price?</p> <p>52. My employees are complaining that we don’t offer any training.</p> <p>53. My best employee just got poached by another firm.</p> <p>54. The career path here is non-existent and employees are bitching about it.</p> <p>55. We are weak on employee diversity. This place looks like a Ku Klux Klan meeting.</p> <p>56. We just got broken into by burglars last night!</p> <p>57. Honestly, I think are company name is stupid and we’re losing business because of it.</p> <p>58. I have no clue why we just lost that big sale.</p> <p>59. There’s a lot of infighting within my management team.</p> <p>60. Cash flow is really tight. We may not make payroll later this month.</p> <p>61. One of my employees slipped on a puddle of water and broke their back.</p> <p>62. Our distribution partners don’t seem to be motivated to sell our stuff.</p> <p>63. Our office flooded last night. We are totally screwed.</p> <p>64. Customer complaints are up.</p> <p>65. I’m able to pay my employees but I’m not pulling enough money out of the business.</p> <p>66. Foreign competition is killing us.</p> <p>67. Sales are down 30% from last year.</p> <p>68. There’s some new competition in town, and they look like they really know what they are doing.</p> <p>69. We’ve been accused of patent infringement.</p> <p>70. I need to layoff 20% of my workforce.</p> <p>71. One employee is destroying everybody else’s morale. He’s a poison to the company!</p> <p>72. Inventory shrinkage is going through the roof lately. What’s up with that?</p> <p>73. I never thought it would play out this way, but I think bankruptcy is my only option.</p> <p>74. It’s time to move out of my house and get a real office.</p> <p>75. Why did I buy this stupid phone system? It’s horrible, and it’s ruining our reputation.</p> <p>76. My independent contract just said that he should be classified as an employee and that I have to pay him benefits.</p> <p>77. We’ve been trying to sell this business for five years now, and we haven’t received a single offer.</p> <p>78. I can’t see my colleague’s work schedules and it’s driving me crazy. I keep scheduling meetings when they already have meetings.</p> <p>79. I’ve got a stack of business cards that are good leads, but they’ve just been sitting in a box gathering dust.</p> <p>80. How can I get a list of good prospects for our business? We need to start talking to more people.</p> <p>81. This is possibly the worst CRM system known to man.</p> <p>82. Our money is sitting in our bank account and it’s earning zero interest. That’s crazy.</p> <p>83. I’m a business owner and I have no retirement plan, very little savings, and my kids are about to go to college.</p> <p>84. I have a troublesome, insubordinate employee on my hands.</p> <p>85. The competition is spreading false rumors about us.</p> <p>86. We are severely understaffed and I’m worried that people are getting burned out.</p> <p>87. Apparently, we’ve been paying less than the minimum wage. I think we may be in trouble.</p> <p>88. Employee morale is low. I have no clue why.</p> <p>89. The landlord just leased our space out from under us. We’ve got to find new space and move to it within 60 days.</p> <p>90. The Internet connection here is lame.</p> <p>91. We don’t have an employee manual, and it’s starting to become a problem.</p> <p>92. My sales guys don’t know how to sell big deals.</p> <p>93. I haven’t had a vacation in three years.</p> <p>94. This business is like a jail sentence.</p> <p>95. Everybody’s making money in this industry but us.</p> <p>96. Client projects are not getting done on time.</p> <p>97. I don’t know whether we are making money or losing money.</p> <p>98. We outsourced some things to another company and it’s not working out.</p> <p>99. Shoot. It looks like we have to do a product recall.</p> <p>100. The shrinkwrap machine is broken, which means we won’t be getting those orders out tonight. Customers are going to be pissed!</p> <p>That’s a quick list of pain points for business owners. Just sitting here typing, dozens more are coming to mind. Have any more small business pain points that you’d care to share with us? Have any advice to share on how to effectively market to small business owners? We welcome your comments, tips and questions!</p> <p aria-describedby="tooltip625998" data-original-title="" title="">Via <a href="" target="_blank">Walker Sands</a></p> </div> <div class="field field--name-field-blog-category field--type-entity-reference field--label-inline clearfix"> <div class="field__label">Category</div> <div class="field__item"><a href="/taxonomy/term/47" hreflang="en">IT Consulting</a></div> </div> <div class="field field--name-field-tags field--type-entity-reference field--label-inline clearfix"> <h3 class="field__label inline">Tags</h3> <ul class="links field__items"> <li><a href="/taxonomy/term/438" hreflang="en">Business Analysis</a></li> <li><a href="/taxonomy/term/296" hreflang="en">Business Intelligence</a></li> </ul> </div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> Wed, 29 Mar 2023 10:51:07 +0000 admin 1610 at What is a Software Post-Mortem? <span class="field field--name-title field--type-string field--label-hidden">What is a Software Post-Mortem?</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/1" lang="" about="/user/1" typeof="schema:Person" property="schema:name" datatype="" class="username">admin</a></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 09/21/2022 - 21:36</span> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>There are software bugs that can end up crippling companies if they aren't dealt with rapidly.</p> <p><a href="">The Knight Capitol Group</a> was an American financial services company. A technician forgot to copy some new code to a computer server, and this software release caused to them to lose $440 million. This happened because one of the computer servers started to rapidly purchase stock (it completed over 4 million purchases and sales) over a 45 minute period.</p> <p>Not every software bug is as dramatic. But there are moments as a software developer where you have to resolve bugs as fast as you can.</p> <p>I recently learned about companies releasing publicly accessible post-mortems on their emergency bugs, and dove head first into them.</p> <h1 id="what-is-a-post-mortem">What is a post-mortem?</h1> <p>A post-mortem is where a team reflects on what went wrong with something they did, and documents it and/or amends their process to stop it happening again.</p> <p>Did a software release go bad? Let's break down a timeline of where things started to go wrong, and let's reflect how we could have caught it earlier.</p> <p>Here is the most important point: Post-mortems <strong>ARE NOT</strong> to assign blame. If we look at The Knight Capitol Group example, there should have been <strong>no way</strong> for one person to forget something and cripple the company.</p> <p>Where was the quality assurance process where someone checked the technician's work? Did they test this before going to production? Were there no automatic tests that ran before the deploy to production succeeded?</p> <p>You should be finding <strong>process failures </strong>not<strong> personal failures</strong>.</p> <h1 id="why-should-we-do-a-post-mortem">Why should we do a post-mortem?</h1> <p>So we can stop making the same mistake over and over!</p> <p>We provide more robust, bug free, stable software by learning how we failed in the past.</p> <p>Most importantly, we can catch bugs we don't even know about. And if we fix the processes that were prone to cause issues early, then those mistakes won't even happen.</p> <p>We want to learn every single lesson we can from the outages and emergencies to ensure they never happen again. Nothing is more valuable than experience.</p> <p><img alt="Postmorterm Template" data-entity-type="file" data-entity-uuid="0eb45670-6c54-4eab-a5c6-2b143e73eed7" src="/sites/default/files/inline-images/og_template_post_mortem.png" /></p> <h1 id="let-s-look-at-some-post-mortems-together">Let's look at some post-mortems together</h1> <p>I wanted a little bit of variety of companies and languages, so let's review some from Google, Microsoft, and Flowdock.</p> <p>A <a href="">common post-mortem template </a>will contain some key details like:</p> <ul><li>when it happened</li> <li>who owns the post-mortem (and will do the analysis)</li> <li>some lessons learned</li> <li>a rough timeline of the emergency bug and some actions from the post-mortem</li> </ul><p>So let's dive in.</p> <p><img alt="Postmorterm Template" data-entity-type="file" data-entity-uuid="aeff93e9-fa25-4d8b-8bee-f2039648054c" src="/sites/default/files/inline-images/lightweight-post-mortem-template-1024x486.png" /></p> <h2 id="google">Google</h2> <p>If you did a Google search between 6:30 a.m. PST and 7:25 a.m. PST on January 31st, 2009, you would have seen the message "This site may harm your computer" accompanying every single result.</p> <h3 id="what-happened">What happened?</h3> <p>Google flags search results with this message if the site is known to install malicious software. This is a warning to protect Google users, and is collated with Google's automatic algorithms, manual data entry, and a non-profit called <a href=""></a>.</p> <p>One of the developers had updated the list and accidentally entered in a <code>/</code>, which resolved to every single site!</p> <p>We know this one was human error, and because of this, Google implemented some tests and checks whenever that file changes. (And I haven't seen it happen again since 2009!)</p> <p>The full post-mortem can be found <a href="">here</a>.</p> <h2 id="microsoft">Microsoft</h2> <p>Microsoft had a 12 hour outage on February 29th, 2012.</p> <h3 id="what-happened-1">What happened?</h3> <p>Microsoft have <strong>Fabric Controllers </strong>which are computers that control around 1,000 servers. It manages their life cycles, monitors their health, and restarts servers when they go down.</p> <p>Isolating all these servers into 1,000 server clusters helps them keep modularity and keeps failures localized to 1 <strong>Fabric Controller </strong>(rather than all of their servers going down).</p> <p>Each server in the cluster has something called a <strong>Host Agent</strong>, and this is used by the <strong>Fabric Controller </strong>to do the work it deems necessary. One of the things it handles is deploying SSL certificates to keep the servers using HTTPS, which is a way of encrypting data.</p> <p>To know when these SSL certificates need to be re-generated, they take the next day at midnight and add one year. So if the <strong>Fabric Controller </strong>is creating a new certificate for a server on March 19, 1990 it will expire March 20, 1991.</p> <p>Do you see where this is going? These servers attempted to generate a one year certificate for a server on a leap year. It was trying to set the certificates to expire on <strong>February 30th, 2020</strong>.</p> <p>When the certificates fail to generate for the server, it terminates. And if it terminates three times in a row, it's considered to be a hardware failure, and then tells the <strong>Fabric Controller </strong>it is faulty.</p> <p>The <strong>Fabric Controller</strong>,<strong> </strong>in an attempt to "heal" the failed server, will hand over the work to another server. One by one, all the servers will error out while trying to generate these certificates. And this eventually shuts down the <strong>Fabric Controller </strong>(with it's 1000 servers!).</p> <p>This disaster resulted from faulty code. There are better ways to handle date problems like leap years and time-zone differences.</p> <p>The full post-mortem can be found <a href="">here</a>.</p> <h2 id="google-take-two">Google, take two</h2> <p>From Thursday August 13, 2015 to Monday August 17, 2015, there were some errors on Google Cloud services, along with permanent data loss on 0.000001% of some hard drives.</p> <h3 id="what-happened-2">What happened?</h3> <p>There were four successive lightning strikes on the local electrical grid that sent power to Google's computers powering Google Cloud services.</p> <p>There were systems that began to immediately replace the power that was taken out by using a battery backup. Alongside manual intervention from Google employees, the service was restored with minimal permanent loss.</p> <p>Google has an ongoing program of upgrading their infrastructure so that they are less susceptible to issues like this. After this, they ran analysis covering electrical distribution, software controlling the Cloud services, and the Cloud hardware being used.</p> <p>The full post-mortem can be found <a href="">here</a>.</p> <h2 id="flowdock">Flowdock</h2> <p>Flowdock instant messaging became unavailable for roughly 32 hours between April 21st and 22nd 2020. Weird behavior was also spotted, like some users not being able to log in. Also, some people found users from another organization in their organization (like Amazon employees cross-contaminated Microsoft, for example).</p> <h3 id="what-happened-3">What happened?</h3> <p>Coronavirus caused a sudden spike of people working from home, which led to a higher than usual usage of Flowdock. This caused very high CPU usage and caused the database to hang whilst trying to deal with the load. There was also some permanent data loss.</p> <p>The full post-mortem can be found <a href="">here</a>.</p> <h1 id="things-to-keep-in-mind-when-doing-a-post-mortem">Things to keep in mind when doing a post-mortem</h1> <p>I read a fantastic article by Adrian Hornsby, a Principle Developer Advocate from Amazon. In it, <a href="">he discussed</a> some things to avoid, and things to emphasize in order to write the best post-mortem if you are ever the owner of one.</p> <p>Here are some things he suggested:</p> <ul><li>Don't do post-mortems to blame people, teams, or organisations. Instead, focus on the <strong>process(es) </strong>that<strong> </strong>failed to allow these mistakes to cause mischief. Never do a post-mortem to punish someone. There's no value in that, and you won't find improvements.</li> <li>Don't assume events that happened were more predictable than they were. Only because they've happened are they now obvious. (<strong><a href="">Hindsight <strong>bias</strong></a></strong>)</li> <li>Make sure you go deep enough. Don't just say we saw an error in the front end code. Really dig deep into the specific error and the conditions that led to it. How can the process catch this next time? A better QA process? More peer reviews? Better error logging?</li> <li>If your resolution steps to stop it from happening are really vague like "improve documentation" or "train better", you don't understand it clearly enough to be more specific. Make these resolution steps actionable and concrete.</li> <li>Try and keep your resolution steps to things that can be done in the <strong>short term</strong>.<strong> </strong>We are trying to stop these from happening again as soon as possible. Post-mortems can spawn longer term process changes, but that's not what you're focusing on at the moment. Don't try to re-architecture something fundamental or try to change the language some huge codebase is written in.</li> <li>Let your post-mortem challenge what your team currently believes to be true. Don't assume because everyone believes something to be true that it is (<a href=""><strong>Com</strong></a><strong><a href=""><strong>mon belief fallacy</strong></a>)</strong></li> </ul><h2 id="how-to-learn-more">How to learn more</h2> <p>If you enjoyed this, you can find more public post-mortems <a href="">here</a>. These include post-mortems from the companies we have already discussed along with examples from Amazon, GitHub, Linux, Heroku, Spotify, Valve, Cloudfare, Etsy, GoCardless, Travis CI and more.</p> <h2 id="conclusion">Conclusion</h2> <p>I hope this has explained what a post-mortem is in the software development lifecycle, how to effectively write one, and common mistakes that happen when you write your first few.</p> <section><em><a data-test-label="profile-link" href="">Kealan Parr</a><br /></em><br />  </section></div> <div class="field field--name-field-blog-category field--type-entity-reference field--label-inline clearfix"> <div class="field__label">Category</div> <div class="field__item"><a href="/taxonomy/term/47" hreflang="en">IT Consulting</a></div> </div> <div class="field field--name-field-tags field--type-entity-reference field--label-inline clearfix"> <h3 class="field__label inline">Tags</h3> <ul class="links field__items"> <li><a href="/taxonomy/term/105" hreflang="en">Testing</a></li> <li><a href="/taxonomy/term/106" hreflang="en">Quality Management</a></li> <li><a href="/taxonomy/term/438" hreflang="en">Business Analysis</a></li> </ul> </div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> Wed, 21 Sep 2022 14:36:31 +0000 admin 1434 at What is Requirements Elicitation? Why is it important for software project success? <span class="field field--name-title field--type-string field--label-hidden">What is Requirements Elicitation? Why is it important for software project success?</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/1" lang="" about="/user/1" typeof="schema:Person" property="schema:name" datatype="" class="username">admin</a></span> <span class="field field--name-created field--type-created field--label-hidden">Thu, 09/08/2022 - 14:25</span> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>Discussing requirements is one of the first and most important stages of software development. The scope, budget, and time estimation for a project fully depend on how complete, clear, and relevant the requirements are. <a href="" rel="noopener" target="_blank">Standish Group’s 2018 CHAOS Report</a> even lists incomplete requirements as one of the most common reasons for IT project failure.</p> <p>Making requirements clear and complete is a task for a business analyst (BA) — and something that our BAs do extremely well. By forming a shared vision of a project, a BA saves many hours during development. That’s why we insist on involving a business analyst in each project at the earliest stages.</p> <p>In this article, we discuss what requirements elicitation is, the benefits and challenges it brings, and the workflow and techniques we use to work with software requirements. This text will be useful for managers that want to figure out the role and value of a business analyst in software development.</p> <p><strong>Contents:</strong></p> <ul><li>What are project requirements?</li> <li>Why do requirements need to be elicited?</li> <li>Stages of requirements elicitation</li> <li>Elicitation techniques</li> <li>Challenges of requirements elicitation</li> <li>Conclusion</li> </ul><h2><a name="q1" id="q1"></a>What are project requirements?</h2> <p>In software development, requirements describe the solution to be developed, including its functions, interfaces, design, and user experience. They’re usually formulated by the client or <a href="" rel="noopener" target="_blank">stakeholders</a> — people who are involved in or affected by the project and therefore are interested in its success.</p> <p>There are <strong>four types of requirements</strong>:</p> <ul><li><strong>Business requirements</strong> describe why a project is needed and how the company will benefit from it.</li> <li><strong>Stakeholder requirements</strong> capture the needs and expectations of stakeholders.</li> <li><strong>Solution requirements </strong>contain technical demands. They can be functional (describing what the system should do) and non-functional (describing the qualities the system should have).</li> <li><strong>Transition requirements</strong> define actions to be taken to transfer an organization from its current state to the desired state.</li> </ul><p><img alt="four types of requirements:" data-entity-type="file" data-entity-uuid="c373824b-1e85-45c9-ac93-77bd9bee6c8e" src="/sites/default/files/inline-images/Requirement_Elicitation_Process-01.jpg" /></p> <p>Gathering accurate requirements is an important task carried out by a business analyst. A single missed or unclear requirement may lead to scope creep, budget overruns, the creation of irrelevant functionality, or an increase in the required development hours. To avoid this, a BA starts working on requirements at the very beginning of the project. Once all the requirements are gathered, the business analyst starts eliciting them. Let’s find out why this process is important and how it’s done.</p> <h2><a name="q2" id="q2"></a>Why do requirements need to be elicited?</h2> <p>What do you see when someone asks you to imagine a car? Which make, model, and color is the car you picture? </p> <p>If you want someone else to picture the exact same car you do, the only way you can achieve this is by describing your car in detail. Some details may seem irrelevant or too obvious to you until someone asks about them. That’s exactly how elicitation works in software development.</p> <p><a href="" rel="noopener" target="_blank">Requirements elicitation</a> is a complex process that consists of gathering, researching, defining, structuring, and clarifying a product’s requirements. As a result of elicitation, a BA creates a set of project objectives. These objectives have to be understandable for each team member and represent all of the client’s demands and needs. Requirements elicitation is an important step of the software development discovery phase.</p> <p>During the elicitation process, a business analyst works closely with the client and all stakeholders, studying and validating their needs and assumptions as well as project risks. The discussion ends when stakeholders can think of no new use cases or when the use cases they can think of have a low priority and can be implemented during future iterations.</p> <p>Requirements elicitation has several key benefits:</p> <ul><li><strong>Establishes the precise scope of work and the budget.</strong> Clear, prioritized, and approved requirements allow a development team to accurately plan and estimate a project. That means we can provide the client with a realistic budget and release dates.</li> <li><strong>Avoids confusion during development.</strong> A shared understanding of what should be done, when, and how to finish a project greatly speeds up and streamlines communication. Productive elicitation helps to avoid numerous meetings that should have been emails during development.</li> <li><strong>Adds business value.</strong> To develop a product that will facilitate a customer’s business activities, it’s important to discuss both <em>what </em>should be done by the development team and <em>why</em>. With that understanding, the team can create a solution that meets all the client’s needs.</li> <li><strong>Reveals hidden and assumed requirements.</strong> Stakeholders always know their market and business needs the best. That’s why stakeholders may find some requirements too obvious to discuss. But developers need to know each aspect of the solution, and a BA helps them figure out and specify such requirements.</li> <li><strong>Allows for developing only relevant functionality.</strong> When discussing requirements, business analysts use their knowledge of the development team to improve the initial requirements. They help clients cast off inefficient features and choose the best possible technologies.</li> </ul><p><img alt="5 reasons" data-entity-type="file" data-entity-uuid="1f7b0067-baf2-4eb9-b14c-4236d11c5cc6" src="/sites/default/files/inline-images/Requirement_Elicitation_Process-02.jpg" /></p> <p>There are lots of cases when a BA’s attention to detail has saved hours of development.</p> <p><em>For example, one BA was working on a reporting system for a logistics company. One of its key features was the ability to download multiple PDF files simultaneously. When our BA asked for more details on this feature, it turned out that the solution had to download more than 500 files at a time. Realizing that this would influence system performance, the business analyst specified a time limit for the downloading process. Such a detail may seem insignificant to the customer, but it’s extremely important for developers.</em></p> <p>Eliciting requirements usually happens in three stages. During these stages, a business analyst collects relevant information from the client, conducts elicitation sessions with stakeholders, and gets approval for the requirements before handing them over to developers. Let’s investigate this process in detail.</p> <h2>Stages of requirements elicitation</h2> <p>There are three common stages of the requirements elicitation process:</p> <p><img alt="Key stages" data-entity-type="file" data-entity-uuid="aa0de894-7694-4ae5-ba43-58d41615e3f2" src="/sites/default/files/inline-images/Requirement_Elicitation_Process-03.jpg" /></p> <h3>1. Preparing for elicitation</h3> <p>Preparation starts with business analysts <strong>collecting the documentation</strong> they need and analyzing the current system (if one exists). Documentation usually includes (but is not limited to):</p> <ul><li>a description of the organization: business rules, structure, legal and regulatory requirements</li> <li>details of the project: solution analysis results, reports, or requirements prepared by other business analysts, technical and end user documentation of the existing system, manuals, instructions, tutorials for users and employees</li> <li>marketing materials: market research, competitor analysis, materials used to promote the solution</li> </ul><p>This set of information helps a BA understand the client’s business and industry, the practices and solutions used, and the current and desired state of the organization. To speed up the study of complex documents, a BA usually asks the client to provide a <a href="" rel="noopener" target="_blank">subject-matter expert</a> (SME) — someone who knows the organization, project, and technology well.</p> <p>The next preparatory step is <strong>analyzing stakeholder roles</strong>. During this analysis, a BA defines all stakeholders affected by the project and decides which of them should be involved in elicitation. This stage is necessary to speed up the elicitation process, engage only relevant stakeholders in the discussion, and keep everyone affected by future changes informed.</p> <p>For effective communication, we usually apply the <a href="" rel="noopener" target="_blank">RACI</a> (Responsible, Accountable, Consult, Inform) matrix to identify the role of each stakeholder. We prepare a table that lists various project tasks and stakeholders. A business analyst then determines whether a particular stakeholder is responsible or accountable for an activity, can consult on it, or should be informed about changes.</p> <p><img alt="RACI Matrix" data-entity-type="file" data-entity-uuid="01cb6d4a-3ef8-42e2-bef9-18b7565b4bec" src="/sites/default/files/inline-images/Requirement_Elicitation_Process-04.jpg" /></p> <p><em>For one of our projects, we had to reduce the call handling time in a call center by introducing a new system for taking calls. This system impacted a lot of people: operators, supervisors, the operations department, etc. Our business analysts prepared a RACI matrix that allowed them to quickly assess the needs of stakeholders, determine their responsibilities, and figure out how to work with each of them without causing any issues.</em></p> <p>Once stakeholder analysis is completed, the business analyst <strong>prepares use case and process flow</strong> <strong>diagrams </strong>to discuss them with stakeholders. A use case diagram is a graphical representation of a relationship between an actor (a user, application, or system) and a solution. User flow diagrams help you visualize all possible interactions with a solution and choose the one that best suits the client’s needs.</p> <p><em>For example, in a use case diagram for a system designed to handle calls and schedule rides, an actor is a call center operator, and this operator’s relation to the system is actions they perform: viewing information about callers, verifying caller information, reviewing the history of calls and previous rides. By discussing use cases with stakeholders, we agreed on the swiftest and most comfortable interactions with the system.</em></p> <p>A process flow diagram is a chart that visualizes the processes happening inside a solution. It shows participants in the process, steps in the process, decision points, events, and their triggers.</p> <p>Use case and process flow diagrams allow for improving a stakeholder’s understanding of those scenarios and possible issues.</p> <p>Besides preparing themselves, business analysts <strong>prepare stakeholders for elicitation</strong>. At this stage, BAs make sure all participants understand the goal and process of elicitation. Preparation includes:</p> <ul><li>choosing the most appropriate means of communication with stakeholders (email, in-person meetings, etc.)</li> <li>scheduling periodic meetings if necessary</li> <li>defining which information is needed from stakeholders.</li> </ul><p>These activities form stakeholders’ expectations of elicitation and help to make discussions short and effective.</p> <p><img alt="4 steps" data-entity-type="file" data-entity-uuid="e4c78ac3-7f3e-4a22-8dbd-ebc6b2844a51" src="/sites/default/files/inline-images/Requirement_Elicitation_Process-05.jpg" /></p> <p>Only after a BA outlines the list of questions to discuss and the stakeholders to participate in discussions do they start eliciting requirements.</p> <h3>2. Eliciting software requirements</h3> <p>Elicitation happens during a series of meetings with various stakeholders. During these meetings, a business analyst has several tasks:</p> <ul><li><strong>Define requirements for the development team and stakeholders.</strong> Stakeholders of the same project may understand the requirements differently. It’s up to the BA to help stakeholders articulate their needs and make sure everyone agrees.</li> <li><strong>Manage the elicitation.</strong> Discussions of requirements may turn in unexpected directions, especially if they involve multiple stakeholders. Business analysts should control and guide these discussions so all questions are answered.</li> <li><strong>Document discussions.</strong> During elicitation, a BA takes notes of the progress stakeholders make to improve the initial requirements after the meeting.</li> <li><strong>Follow up with participants.</strong> Follow-ups help to structure the topics discussed and the outcome of each elicitation session.</li> </ul><h3>3. Finalizing the elicitation </h3> <p>Once elicitation is done, a business analyst goes through the requirements to make sure that each of these questions is answered for each requirement:</p> <ul><li><em>Why?</em> — Why should the requirement be implemented, what problem does it solve, and what benefits does it provide?</li> <li><em>What?</em> — What is the exact meaning of the requirement, what are the business rules, and what are the compliance or other requirements?</li> <li><em>How?</em> — What are the possible ways to implement the requirement and what are the possible obstacles (outdated or insecure technologies, network limitations, etc.)?</li> <li><em>When?</em> — How urgent is the requirement and how should it be prioritized?</li> </ul><p>Requirements are documented and maintained with a specifications template. Such a specification is important in software engineering and convenient both for developers and stakeholders. After that, stakeholders confirm that everything is documented correctly and the BA hands the requirements over to the development team.</p> <h2>Elicitation techniques</h2> <p>Business analysts choose a technique for requirements elicitation depending on the stakeholders and tasks at hand. The BABOK guide <a href="" rel="noopener" target="_blank">lists</a> the nine most popular requirements elicitation techniques:</p> <p><img alt="Most common techniques" data-entity-type="file" data-entity-uuid="6b6ed637-279d-442b-8233-9c049fd8e0f0" src="/sites/default/files/inline-images/Requirement_Elicitation_Process-06.jpg" /></p> <p>BA engineers usually conduct interviews and surveys, prepare questionnaires, and analyze software and user interfaces as these are the most comfortable and useful techniques for gathering information.</p> <p>An <strong>interview</strong> entails eliciting requirements from a group of stakeholders — or, in rare occasions, from one stakeholder — during a meeting. An interview can be conducted in person, during a video call, via email, or in a messenger.</p> <p><em>To conduct an effective interview, it’s important to remember a stakeholder’s cultural background. For example, emails to customers from South Korea or Japan should contain a lot of polite constructions because a simple list of questions might be considered impolite. Americans prefer short and accurate emails.</em></p> <p>Interviewing stakeholders has several benefits compared to other techniques:</p> <ul><li>It builds trust between the business analyst and stakeholders.</li> <li>It allows you to discuss ideas, risks, and the necessity of each requirement.</li> <li>It reveals hidden and dubious requirements.</li> </ul><p>A <strong>survey or questionnaire</strong> is a good option in case a BA needs to get information from a large audience all at once. When using this technique, a BA has to:</p> <ul><li>define the group of participants</li> <li>choose the type of questions and compose them</li> <li>distribute questions and collect and analyze answers.</li> </ul><p>While creating questions, the BA focuses on the target audience. </p> <p><em>We used a questionnaire when we worked on a parental control application. It was important to question parents of all ages and social statuses that could be interested in the app. There was a risk of missing the insights of younger and older parents and focusing on 30- to 40-year-olds. We created a balanced questionnaire that reflected the opinions of all parents.</em></p> <p><strong>Interface analysis</strong> refers to research into interfaces that help systems or components interact with each other. During interface analysis, a BA investigates who uses the interface, how it works, and what data it requires. Such analysis can also be performed for competitors’ systems. Interface analysis helps you to identify business rules, possible challenges, and lacking or excessive functionality that needs to be discussed with stakeholders.</p> <p><em>For example, one of our clients wanted to add functionality for archiving data to his data backup application because his competitor offered that functionality. After analyzing the competitor’s product and discussing the feature with the development team, however, the BA figured out that this requirement was absolutely redundant for the client’s application. The business analyst explained this to the client, who decided to substitute this feature with a more useful one.</em></p> <p><strong>User interface (UI) analysis</strong> is a requirements elicitation method applied by a BA to explore an existing UI and learn how users interact with it. UI analysis is useful for preparing use cases and understanding user needs. As a result of this technique, the business analyst can detect issues with the UI and figure out ways to resolve them.</p> <p><em>UI analysis allowed us to improve the functionality, design, and usability of the SaaS solution for access control and user activity monitoring. The product has a robust feature set and provides the user with lots of data on each screen. As a result, its pages and content tables were overloaded with information. We analyzed the existing solution and improved the interface by reworking the structure of pages, simplifying content tables, and adding alerts on suspicious events.</em></p> <p>Each of the techniques discussed above helps a BA elicit requirements and see eye to eye with the client. That results in efficient meetings, clear estimates, and fast solution development. To make the elicitation process smooth, we’ve tackled a lot of challenges — let’s take a look at them.</p> <h2>Challenges of requirements elicitation</h2> <p>Based on our projects, we can outline these common obstacles in the elicitation process:</p> <p><img alt="8 challenges" data-entity-type="file" data-entity-uuid="110c3aca-afab-48e5-a255-c37bfe664d5c" src="/sites/default/files/inline-images/Requirement_Elicitation_Process-07.jpg" /></p> <p><strong>New project domain.</strong> When working with a new industry or a new type of solution, a business analyst has to quickly become an expert in the field. To do so, they search for any source of information on the subject: colleagues, subject-matter experts on the client’s side, literature, and so on.</p> <p><strong>Unclear project vision.</strong> Usually, stakeholders have a basic set of requirements and a general image of the solution they want. If stakeholders don’t have a clear understanding of what functionality their software needs, BAs and developers create prototypes of product features to help them visualize possibilities and choose the best one.</p> <p><strong>Fixation on specific features.</strong> Stakeholders may insist on designing certain features because they believe they will benefit their business. There are many reasons for a fixation on features: competitors offer similar features, those features use cutting-edge technologies, etc. A BA conducts external research, analyzes the market and competitors, and discusses requirements with developers to verify the need for features. As a result, business analysts often propose simpler and more relevant features.</p> <p><strong>Contradictory requirements.</strong> When a project affects a lot of stakeholders, their requirements may contradict each other. One of our BAs worked on a project with 35 stakeholders. It was a challenging experience, but thanks to it, we now know how to deal with this issue:</p> <ol><li>Limit the number of people invited to elicitation sessions. </li> <li>Elicit requirements related to one topic with one relevant group of stakeholders that includes several subject-matter experts.</li> <li>Email all participants in an elicitation session after the meeting.</li> </ol><p><strong>Never-ending requirements.</strong> We faced this challenge when one of our clients kept emailing our business analyst with new requirements even after elicitation sessions. To resolve the issue, the BA carefully reviewed and prioritized all additional requirements. Such an approach helped us avoid misunderstanding the value of the requested changes and define the scope of the first phase of development.</p> <p><strong>Limited access to documentation.</strong> Some clients don’t provide all the necessary documentation to a BA because of concerns about disclosing sensitive information, lost or unstructured documents, the time required to prepare the requested information, etc. However, if BAs can’t access documentation, evaluating the current state of the project will take more time. That’s why, we always sign non-disclosure agreements with clients and provide a reason for each information request.</p> <p><strong>Focus on solutions instead of requirements.</strong> During elicitation sessions, stakeholders may start discussing the details of solutions (checkboxes, buttons, etc.) instead of requirements. To keep the focus on requirements, our business analysts often ask themselves during meetings, <strong><em>Are we talking about what to do or how to do it?</em> </strong>It’s important to remember that stakeholders should explain what they want to be done; it’s the developer’s job to figure out how to do it.</p> <h2>Conclusion</h2> <p>To be effective, software requirements elicitation requires close collaboration between the client, contractors, and a professional business analyst to manage the process. Requirements elicitation is a vital stage of software development. Unclear or incomplete requirements will inevitably lead to a lengthy development process, a need to rework parts of the solution, and budget overruns.</p> <p>To avoid these pitfalls, we has a team of experienced business analysts that enhance our managed development teams or work on projects independently. Their goal is to create a shared understanding of the specifics of a project among stakeholders and developers.</p> <p>If you’re planning a complex project and need an experienced business analyst to streamline communications and facilitate development, feel free to contact us!</p> <p><em>Julia Kondratenko (Business Analyst) - apriorit</em></p> <p> </p> </div> <div class="field field--name-field-blog-category field--type-entity-reference field--label-inline clearfix"> <div class="field__label">Category</div> <div class="field__item"><a href="/taxonomy/term/47" hreflang="en">IT Consulting</a></div> </div> <div class="field field--name-field-tags field--type-entity-reference field--label-inline clearfix"> <h3 class="field__label inline">Tags</h3> <ul class="links field__items"> <li><a href="/taxonomy/term/438" hreflang="en">Business Analysis</a></li> <li><a href="/taxonomy/term/51" hreflang="en">BA</a></li> <li><a href="/taxonomy/term/202" hreflang="en">Software Development Consulting</a></li> <li><a href="/taxonomy/term/43" hreflang="en">Outsourcing</a></li> </ul> </div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> Thu, 08 Sep 2022 07:25:05 +0000 admin 1367 at What is the difference between a use case alternative flow and an exception flow? <span class="field field--name-title field--type-string field--label-hidden">What is the difference between a use case alternative flow and an exception flow?</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/1" lang="" about="/user/1" typeof="schema:Person" property="schema:name" datatype="" class="username">admin</a></span> <span class="field field--name-created field--type-created field--label-hidden">Sat, 07/09/2022 - 00:07</span> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>A use case specification describes the functionality of a system in terms of a sequence of user-system interactions. The main flow of events describes a single path through the system. It represents the most common way that the use case plays out successfully and contains the most common sequence of user-system interactions. Other scenarios or paths through the system are described in alternative flows and exception flows.  So what is the difference between and alternative flow and an exception flow?</p> <p><img src="" /></p> <p>First, it’s worth saying that there’s a number of differing opinions in this area since the Unified Modeling Language has no standard for Use Case Specifications. Some authors mention only alternative flows and use them for both optional user paths and error paths. However, among authors who differentiate between alternative flows and exception flows, agreement has emerged.  </p> <p><img src="" /></p> <p>An alternate flow describes a scenario other than the basic flow that results in a user completing his or her goal. It is often considered to be an optional flow. It implies that the user has chosen to take an alternative path through the system. An exception flow is an unintended path through the system usually as a result of missing information or system availability issues. Exception flows represent an undesirable path to the user. However, even though the exception flow has occurred the system should still react in a way that recovers the flow and provides some useful information to the user.</p> <figure role="group" class="caption caption-img"><img alt="Alternative flow and exceptional flows" data-entity-type="file" data-entity-uuid="b0e64e74-b787-431f-9790-6b22852cfcb2" src="/sites/default/files/inline-images/Example_of_activity_diagram_with_basic_alternative_exceptional_flows.png" /><figcaption>Alternative flow and exceptional flows</figcaption></figure><p>The primary benefit of differentiating between alternative flows and exception flows is the focus that exception flows bring to error conditions. By capturing all of the ways that the system can fail or produce an error, the business analyst can be sure to create a design that mitigates the impact of the error.</p> <p><strong>Chris Adams</strong></p> </div> <div class="field field--name-field-blog-category field--type-entity-reference field--label-inline clearfix"> <div class="field__label">Category</div> <div class="field__item"><a href="/category/kinh-doanh-va-cong-nghe" hreflang="en">Business Technology</a></div> </div> <div class="field field--name-field-tags field--type-entity-reference field--label-inline clearfix"> <h3 class="field__label inline">Tags</h3> <ul class="links field__items"> <li><a href="/taxonomy/term/485" hreflang="en">Software Design</a></li> <li><a href="/taxonomy/term/438" hreflang="en">Business Analysis</a></li> </ul> </div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> Fri, 08 Jul 2022 17:07:04 +0000 admin 1244 at What is Non-functional Requirements (NFRs)? Examples? <span class="field field--name-title field--type-string field--label-hidden">What is Non-functional Requirements (NFRs)? Examples?</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/1" lang="" about="/user/1" typeof="schema:Person" property="schema:name" datatype="" class="username">admin</a></span> <span class="field field--name-created field--type-created field--label-hidden">Sat, 03/12/2022 - 22:59</span> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>Non-functional Requirements (NFRs) <b>define system attributes such as security, reliability, performance, maintainability, scalability, and usability</b>. They serve as constraints or restrictions on the design of the system across the different backlogs.</p> <p>Functional requirements define what a system is supposed to <i>do</i> and non-functional requirements define how a system is supposed to <i>be</i>. <strong>Functional requirements</strong> are usually in the form of "system shall do &lt;requirement&gt;. In contrast, <strong>non-functional requirements</strong> are in the form of "system shall be &lt;requirement&gt;", an overall property of the system as a whole or of a particular aspect and not a specific function. The system's overall properties commonly mark the difference between whether the development project has succeeded or failed.</p> <p><img src="" /></p> <p>Non-functional requirements are often mistakenly called the "<a href="" title="List of system quality attributes">quality attributes</a>" of a system, however there is a distinction between the two. Non-functional requirements are the criteria for evaluating how a software system should perform and a software system must have certain quality attributes in order to meet non-functional requirements. So when we say a system should be "secure", "highly-available", "portable", "scalable" and so on, we are talking about its quality attributes. Other terms for non-functional requirements are "qualities", "quality goals", "quality of service requirements", "constraints", "non-behavioral requirements", or "technical requirements".<span style="font-size: 16.6667px;"> </span></p> <p><img src="" /></p> <h2>Examples of Non-functional requirements</h2> <p>Here, are some examples of Non functional requirements:</p> <ol><li>Users must change the initially assigned login password immediately after the first successful login. Moreover, the initial should never be reused.</li> <li>Employees never allowed to update their salary information. Such attempt should be reported to the security administrator.</li> <li>Every unsuccessful attempt by a user to access an item of data shall be recorded on an audit trail.</li> <li>A website should be capable enough to handle 20 million users with affecting its performance</li> <li>The software should be portable. So moving from one OS to other OS does not create any problem.</li> <li>Privacy of information, the export of restricted technologies, intellectual property rights, etc. should be audited.</li> </ol><p><br /><strong>Technical Requirement</strong></p> <p>Most computer-based systems perform some automated procedures or processes, even the simplest website enables a visitor to navigate around the site to find information. More complex websites authenticate visitors and may automate transactions through e-commerce.</p> <p>Technical requirements for system procedures and processes identify the non-functional specifications of the proposed system itself. The non-functional requirements can include:</p> <ul><li>Performance or speed of the system</li> <li>Quality</li> <li>Environmental requirements or business rules</li> <li>Size</li> <li>Ease of use</li> <li>Reliability</li> <li>Robustness</li> <li>Portability</li> </ul><p>For Example:</p> <ul><li><strong>If the system is a sales system: </strong>technical requirements may address the number of transactions per minute.</li> <li><strong>If the system is a website:</strong> the technical requirements may address the page display speed, compatibility with browsers and hardware platforms.</li> <li><strong>If the system is a database-centred system:</strong> the technical requirements may address the constructs of the database, number of records or processing time.</li> <li><strong>If the system is an inventory control system:</strong> the technical requirements may address the ability to set the alarm levels for high and low stocks.</li> <li><strong>If the system is a network:</strong> the technical requirements may address download or response times, application access, redundancy procedures, disk access speeds, number of users etc.</li> </ul><p>In addition technical requirements for system procedures and processes may address the application architecture, development environment or network topology and protocols.</p> <p>Thank you for reading!</p> </div> <div class="field field--name-field-blog-category field--type-entity-reference field--label-inline clearfix"> <div class="field__label">Category</div> <div class="field__item"><a href="/category/kinh-doanh-va-cong-nghe" hreflang="en">Business Technology</a></div> </div> <div class="field field--name-field-tags field--type-entity-reference field--label-inline clearfix"> <h3 class="field__label inline">Tags</h3> <ul class="links field__items"> <li><a href="/taxonomy/term/104" hreflang="en">Requirement Engineering</a></li> <li><a href="/taxonomy/term/103" hreflang="en">Requirements Elicitation</a></li> <li><a href="/taxonomy/term/438" hreflang="en">Business Analysis</a></li> </ul> </div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> Sat, 12 Mar 2022 15:59:33 +0000 admin 1095 at