The Six Blind Men and the Requirements: Part Two — Why Create Multiple Requirements Views?

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...

The Six Blind Men and the Requirements: Part One

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...

PMI-PBA vs. IIBA’s CBAP

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...

Early Validation in Agile Projects is Cost-Effective

When it comes to software development projects, agility should be focused on delivering business value in increments, and not developing software in cycles. While software development is a major aspect, it’s not the end goal of our projects. Too often when following agile development, the team is  uncertain or unclear of what to build that will actually deliver the value set out for at project inception. Then, what happens is the team starts coding before understanding what really needs to be built, which is a very expensive way to validate that the solution meets customer and business needs. If there is no feedback until the end of a big project, it might be too late or costly to adjust. Instead, it is prudent to get as much feedback as possible, as early in the project as possible. As Eric Ries, author of Lean Startup, puts it, don’t we all want to “avoid building products that nobody wants?” Recent Standish Group research shows that 20% of Features are used regularly and 50% of Features are hardly ever or never used. According to the study, the gray area is the 30% of Features and functions that get used sometimes or infrequently. All of these Features and functions that are never or barely used are causing higher costs, lower value, and longer cycle times, resulting in lower customer satisfaction. Focusing on the 20% of the Features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. To focus on the 20% of Features that give the most value, you need to validate early....

Agile Business Transformation Q&A

There were a few great questions asked at the end of our webinar yesterday, Agile Business Transformation. While I didn’t have time to answer them in the information-packed webinar, here are your answers. Q: Does Enfocus know of publications on Agile transformations for business with products with HW as well as SW products? A: –Agile Development has been used for both the development of hardware and software products.  One of the best-known examples is the development of Nokia phones.  In Enterprises, many infrastructure groups are also starting to use agile.   Many organizations are starting to adopt DevOps which is an umbrella concept that refers to anything that facilitates a smoother interaction between development and operations.  The best information for large agile transformations is at www.scaledagileframework.com.  There is also a major movement toward integrating Lean with agile and there are several good books on this subject. A very good book on this subject is Implementing Lean Software Development: From Concept to Cash by Tom and Mary Poppendieck. Q: I find it challenging to differentiate a Feature from An Epic! For example, how would you determine if a BR is a feature or an Epic? A: — Great Question.  A feature has to be small enough to fit into a Release. An epic spans multiple releases.  Epics are approved by Portfolio management, whereas Features are defined by program management and are used to decompose an Epic into manageable components.  View an epic as a project and a feature as a component of a project. Q: Most of the time, we find the stories changing to be a Feature or Epic! A:...

Traditional PMOs vs. Enterprise PMOs that Deliver Value to the Business

The common Program Management Office (PMO) is constantly challenged and called into question by senior management and the C-level. Without executive support, the PMO struggles to be successful in delivering program and project outcomes that effectively provide business value. Traditional PMOs have a tendency of becoming too bureaucratic and too focused on managing tasks instead of value, increasing project complexity and causing headaches across the enterprise. But recent research proves PMOs can still be effective at delivering business value if managed the right way—at the enterprise level. To deliver value with initiatives and reduce project complexity, the organization requires centralized coordination of processes and practices. In a traditional, departmentally-based PMO, it is very difficult to align projects with the strategic priorities of the organization. These types of PMOs may be successful on a departmental level but are often not taken seriously by the rest of the organization. When PMOs are departmentally-based, they tend to define value in different ways, skewing project results. Instead, the organization needs a PMO that provides a consistent mechanism to standardize practices and evaluate progress of initiatives across the organization, without creating unnecessary complexity. When the PMO is operating at an executive level, there is an increased likelihood that project outcomes align with organizational strategy because the PMO has the ability to affect the entire organization. According to a recent study, strategic PMOs that implemented an enterprise-wide approach in 2013 tended to have the most mature processes and practices, and were the most likely to achieve consistently successful project outcomes. The findings indicate that the traditional approach to Program Management Offices is transforming to an...