Manage Learn to apply best practices and optimize your operations.

Requirements rethinking tutorial: Improving pre-development software analysis - Part 2

An expert shows how reimagining the software requirements elicitation process can lead to improving business requirements and add value to applications. In this tip, learn how to better evaluate your requirements upfront and throughout the SDLC.

Robin F. Goldsmith, JD
Robin F. Goldsmith, JD
Radical rethinking can reveal high-reward revolutionary software requirements, rather than the often lower-value evolutionary requirements that so much analysis routinely defines.

Table of contents
Problem Pyramid discovering REAL software requirements
Requirements rethinking tutorial: Improving pre-development software analysis - Part 2

"Rethinking" is the term I coined for the apparently additional analysis I used to discover requirements that were so dramatically different from the business requirements the client's capable analysts identified. Based on the same data, rethinking provided much higher breakthrough benefits.

While business analysis too commonly shortchanges analysis in general, rethinking is essentially an unrecognized special form of analysis that even someone who actually does it, such as I, hadn't been especially conscious of.

The existence and power of rethinking became strikingly evident in a recent pair of separate consulting projects for a client. While actively performing discovery of both projects' REAL business requirements, simultaneously I also was helping an internal champion lead the organization to change its project processes to include the approach and methods we were demonstrating work effectively in their real environment.

In order to clearly understand rethinking and what makes it so powerfully different, it's valuable first to describe the types of analysis ordinarily performed in traditional business analysis and when discovering REAL business requirements.

Analysis in traditional business analysis

Regardless of approach, requirements definition usually starts with some sort of elicitation. In an article titled Should BABOK Include Shorthand?, I pointed out that a great deal of traditional business analysis writing, teaching and practice makes many requirements elicitations processes fairly passive … in a manner that I liken to taking dictation.

As conventionally characterized, requirements elicitation mainly mechanically captures responses to questions like, "What do you want?" Such questions ordinarily invite describing a product, system or software solution that the stakeholder thinks will meet the objectives giving rise to the project.

Then, traditional business analysts subsequently perform "requirements analysis" on the elicited requirements. This requirements analysis focuses on using various modeling and analysis techniques to describe and possibly elaborate the requirements of the product, system, or software expected to be created.

For example, the International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge (BABOK®) Guide, version 2.0, says the Requirements Analysis Knowledge Area's purpose is "to define the required capabilities of a potential solution that will fulfill stakeholder needs."

In the BABOK, analysis includes prioritization of requirements based on business value, business or technical risk, implementation difficulty, likelihood of success, regulatory or policy compliance, relationship to other requirements, stakeholder agreement, and urgency. Techniques include decision analysis, risk analysis, MoSCoW (must, should, could, won't) analysis, timeboxing/budgeting, and voting.

IIBA's BABOK analysis process

BABOK analysis also includes organizing "to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives," according IIBA's guide. Various models articulating varying levels of abstraction are enlisted. User classes, profiles, and roles generally define the sources of requirements. Events, process models, and rules define when and how the requirements take place. Techniques include business rules analysis, data flow diagrams, data modeling, functional decomposition, organization modeling, process modeling, scenarios and use cases, scope modeling, and user stories.

BABOK analysis then specifies and models requirements "using a combination of textual statements, matrices, diagrams, and formal methods," according to the guide. Objectives are to "automate or simplify the work people perform … improve access to information … reduce complexity of interfaces … increase consistency of behavior [and] … eliminate redundancy." In addition to the above techniques, the guide says that one also can use acceptance and evaluation criteria, data dictionary and glossary, interface analysis, metrics and key performance indicators, non-functional requirements analysis, prototyping, sequence diagrams, and user stories.

BABOK analysis further includes verifying "that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work" (p.114). Such verification is achieved by checking that the requirements formats are cohesive, complete, consistent, correct, feasible, modifiable, unambiguous, and testable (pp. 115-116).

BABOK analysis also uses acceptance and evaluation criteria, metrics and key performance indicators, prototyping, risk analysis, and structured walkthrough, according to the IIBA guide to validate "that all requirements support the delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder need."

Analysis when discovering REAL business requirements

When applying my methodology for discovering REAL business requirements, the analyst first and foremost actively integrates analysis with elicitation. Throughout elicitation, the analyst is constantly thinking critically about and analyzing what s/he is hearing, reading, observing, and experiencing. In turn, the active analysis suggests ways to adjust the elicitation as it's occurring, which invariably reveals all manner of information traditional passive elicitation is likely to miss or misunderstand.

Moreover, this elicitation is not requirements elicitation; rather the analyst is eliciting data that are helpful for discovering the REAL, business requirements.

I use the powerful Problem Pyramid to guide disciplined discovery by systematically identifying data about the REAL problem, opportunity or challenge. Such data includes the measures quantifying the value of appropriately addressing the problem and the causes of the problem, which must be reduced or eliminated.

Then I use the conventional business analysis post-elicitation analysis techniques described above, but in a different way. Instead of analyzing the presumed product solution, I analyze the elicited data to help understand the problem, value measures, and causes in order to discover the REAL business requirements deliverable whats that when satisfied will address the problem and thereby achieve the value.

Only after getting the REAL business requirements what's right is it worthwhile to design a product solution how for satisfying the whats. Without getting bogged down in often-illusory verification and validation distinctions, and without calling it analysis, I apply more than 21 proactive testing techniques for making the REAL business requirements clearer, correct and complete. These methods are much more powerful and catch many more issues than the one or two techniques conventional reviews use.

Then I apply those 21 ways plus a few additional techniques to catch and prevent issues with the product/system/software requirements. These methods too find many more of the fewer remaining errors than traditional reviews ordinarily detect.

Rethinking software requirements

One of the client projects involved about 10 individuals who each use some data originating with one or more of the other individuals. Each user keeps the data in their own spreadsheets along with other related data needed for their particular purposes. The relevant source data values are added and changed on an ongoing basis but are reported back and forth among the users only periodically. Consequently, each of the users is working with combinations of data elements that don't fit together accurately.

The project was initiated to reduce the added effort each user regularly expended dealing with the erroneous data. Our active analysis and focus on REAL business requirements revealed additional unrecognized users and, most importantly, that one seemingly tangential user's wrong data already had lost the company significant revenue.

As part of our analysis, the client's experienced business analyst drew a diagram detailing the complex flows of data elements from their sources to the respective individual users. Such a diagram is a sound analysis technique and might well also have been drawn if we were using traditional business analysis; although there's a good chance it would have been missing some users and their data elements.

The client's business analyst used the diagram the way I think most analysts would; including me, sometimes. He revised the diagram of the current as-is process into a "should-be" process diagram for better getting users their needed data elements.

The should-be diagram indeed described a business process which would be the basis for REAL business requirements. However, the should-be process still was very complex. Its central logical database included and had to maintain all the data elements for all the users, which created additional data integrity timing and coordination issues that in turn would need to be addressed by numerous complicated additional REAL business requirements. In hindsight, I realized the analyst was using an evolutionary approach that channeled and limited his thinking.

In contrast, I did some rethinking; "out of box," if you will. Instead of being driven by how things were done currently, I stepped back mentally and concentrated on what was needed to provide value.

Rethinking from this perspective made it apparent that only a small set of core data elements actually was critical and needed to be captured at the time they were added or changed. Most of the core data elements originated with one of the users, with the remaining few from one other user. All users could access the core data elements to bring their own spreadsheets up-to-date; and all other necessary data sharing could be accomplished through simple one-to-one communications. We then checked the rethinking's REAL business requirements against the original flow diagram to assure all users' data needs were addressed.

Lest this rethinking effect seem specific to just this project, I can tell you the other project also had similar large REAL business requirements benefits from rethinking. Space and confidentiality limitations prevent me from sharing the details.

Obviously, skilled analysts could easily apply this sort of rethinking. They just don't seem to do it very often, largely because their analysis often is constricted by the ways things currently are done. The emphasis on value provided by the Problem Pyramid can help produce the perspective needed for rethinking.

About the author: Robin F. Goldsmith, JD, is President of Needham, Mass., consultancy Go Pro Management, Inc. He works directly with and trains business and systems professionals in requirements, quality and testing, metrics, ROI and project and process management. A subject expert and reviewer for IIBA's BABOK, he is the author of the Proactive Testing and REAL ROI methodologies and Discovering REAL Business Requirements for Software Project Success.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.