by Karl Wiegers | Jul 15, 2014 | Business Analysis, Uncategorized |
If you create only one view of the requirements, you must believe it. You have no other choice. If you develop multiple views, though, you can compare them to look for disconnects that reveal errors and different interpretations. There’s an old saying, variously attributed to the Swedish Army, the Swiss Army, the Norwegian Boy Scouts, a Scottish prayer, and a Scandinavian proverb: “When the map and the terrain disagree, believe the terrain.” Unfortunately, we have no absolute “terrain” for requirements: every representation is a map! Even though you can’t tell which representation is correct, differences between them indicate problems. In this article, adapted from my book, More About Software Requirements (Microsoft Press, 2006), I’ll explain the value of creating more than one view of your requirements. Consider the figure below. A use case presents a high-level view of requirements from the user’s perspective. It describes some goal the user needs to accomplish with the help of the system, expressed as a sequence of interactions between a user and the system that leads to an outcome of value. A primary purpose of the use case technique is to help the BA derive the functional requirements that developers must implement to let users perform a use case. These functional requirements represent a second, more detailed view. The BA might also draw graphical analysis models, diagrams that represent additional views of the requirements. The BA should be able to relate the functional requirements to elements shown in the models to make sure that these complementary views agree. Suppose a tester were to write some test cases—thereby creating yet another view of the...
by Karl Wiegers | Jul 11, 2014 | Business Analysis, Uncategorized |
There’s an old fable about six blind men who encountered an elephant for the first time. Although they couldn’t see it, they wanted to learn what an elephant was like. Each of them touched a different part of the elephant. The first man wrapped his arms around the elephant’s leg and said, “Why, an elephant is just like a big tree.” “No,” said the man who held the elephant’s tail, “an elephant is like a rope.” The third man felt the side of the elephant and reported, “This elephant is like a big wall.” The fourth man gripped the elephant’s trunk and declared, “You’re all wrong. The elephant is like a giant snake.” The fifth man rubbed the elephant’s tusk and said, “I think an elephant resembles a spear.” “No, no, no!” said the final man, who touched the elephant’s ear. “An elephant is like a big fan.” The blind men were all correct. The elephant has all the characteristics they described, but no single feature of the elephant provides a complete description of what an elephant is all about. Each man had but a limited view of the elephant and could draw conclusions only from that view. There’s an analogy with software requirements. I learned long ago that no single view of the requirements tells us everything we need to know about them. Often it’s desirable to represent requirements in multiple ways, thereby giving the readers a richer, more holistic understanding of the requirements elephant. Unfortunately, nearly every requirements specification I have read contains just a single view: natural language text. The clever business analyst can do better...
by Jenny Boronyak | Jun 9, 2014 | Business Analysis, Project Management, Uncategorized |
With the PMI’s recent release of the new Professional in Business Analysis (PBA) certification, business analysts (BAs) in the community are asking what is the difference between this new PMI-PBA and the IIBA’s existing Certified Business Analysis Professional (CBAP)? Also, if we’re looking into getting certified, which one should we go after? In their announcement to offer the new certification, the PMI quoted a statistic by the US Bureau of Labor Statistics that “business analysis jobs are predicted to increase 19 percent by 2022.” We agree that this is a good reason for more people to get certified in the field of business analysis. We’re looking at this new certification from the PMI as great news; business analysis as a profession needs to break through the lack of recognition and demand more respect from the global community so that we can all be more successful in our jobs. This certification is definitely a step in that direction. But before you go and sign up for the PMI-PBA pilot program, we recommend making sure it’s the right certification for you. After looking at the available literature, including the PMI-PBA Examination Content Outline (ECO), it is apparent that this particular certification is focused on a very specific area of business analysis, and is developed for a very specific subset of business analysts. According to the PMI’s literature on the new certification, “business analysis is a critical function that helps define business requirements in order to shape the output of projects and drive successful business outcomes. In order to ensure the quality of requirements and projects, it is crucial that individuals be...
by John Parker | Mar 24, 2014 | Business Analysis, Uncategorized |
In the most recent VersionOne State of Agile Survey released in 2014, Business Analysts are considered the least knowledgeable about Agile. Please see the diagram below. Working with many Business Analysts, I am not surprised by this statistic, but it does concern me. In the Scrum world, there is no official role for a Business Analyst. We don’t write the functional requirements the way we did in the past and a Business Analyst is not required or needed to write or draft user stories. Business Analysis skills are very much needed, however the traditional BAs that simply write functional requirements will either need to re-skill or retire. Recently Forrester research shows that more than 90% of organizations are actively pursuing Agile. If Business Analysts do not learn and embrace Agile now, and they plan on continuing writing functional requirements in the ways they have in the past, then they should start planning a new career as their positions will soon be eliminated in a future downsizing effort. If the BAs in your organization have not made the transformation to Agile, please call us at Enfocus Solutions; we can help. We can provide you with the education, knowledge, and tools to transform you business analysis function to the Agile world. Please attend the Webinar tomorrow to find out more. [cta...
by John Parker | Mar 7, 2014 | Business Analysis, Collaboration, Uncategorized |
In one of my recent blog articles, Risk Management: Business Analysis is a Huge Risk for Most Organizations, I stated that business analysis is at a dangerously low level of maturity for most organizations as evidenced by Standish Group Research, which analyzes project performance. Standish Group Research shows that the top five reasons for failed or challenged projects are: Lack of user involvement Lack of transparency Poor or incomplete requirements Changing requirements Lack of business alignment Now, examine these problems carefully; all of them are related to poor business analysis. Looking at this and other research, I firmly believe that poor business analysis is the number one cause of failed and challenged projects. According to the Business Analysis Body of Knowledge (BABOK), business analysis involves much more than just writing solution requirements. However, in many organizations, BAs only write solution requirements and do not perform other key activities specified in BABOK. For example, few business analysts are actually involved in Enterprise Analysis and Solution Assessment and Validation which are two key knowledge areas specified in the BABOK. Many people think that Requirements Analysis and business analysis are one in the same. Requirements Analysis is only one of the six knowledge areas in BABOK. It’s important to stress that there is much more to business analysis than just writing solution requirements. Many confuse requirements engineering and business analysis, thinking they are one in the same; however, they are not. Understanding the differences is key for successful IT projects. Requirements engineering, although helpful, is certainly not the key for success on business IT projects. Requirements engineering might address problems 3 and...
