What You ve Learned So Far | Managing Software Requirements[c] A Use Case Approach

What You've Learned So Far

Before we can kick-start your project requirements process, however, let's summarize what you've learned in the book so far.

Introduction

In the introductory chapters, we looked at why our industry often does a poor job of delivering quality applications on time and on budget. Some of the root causes of this problem are clear. Lack of user input, incomplete requirements and specifications, and changing requirements and specifications are commonly cited problems in projects that failed to meet their objectives.

Perhaps developers and customers alike have a common attitude that "since we can't determine everything we want in advance, it's better to get started with implementation now because we're behind schedule and in a hurry. We can pin down the requirements later." Since, even in this requirements text, we've agreed that it isn't possible to know everything in advance, that doesn't seem so inappropriate. But all too often, this well-intentioned approach degenerates into a chaotic , out-of-control development effort, with no one on the team quite sure what the user really wants or what the current system really does.

To address these issues, we've recommended an encompassing philosophy of requirements management, which we defined as

a systematic approach to eliciting , organizing, and documenting the requirements of the system, as well as a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system.

Since the history of software developmentand the future for at least as far as we can envision itis one of ever-increasing complexity, we also understand that well-structured and well-trained software teams must address the software development problem. Every team member will eventually be involved in helping manage the requirements for the project. These teams must develop the requisite skills to understand the user needs, to manage the scope of the application, and to build systems that meet these user needs. The team must work as a team to address the requirements management challenge.

In addition, we discussed that we must take an "iterative and incremental" approach to the problem, an approach that recognizes that not all requirements can be determined in advance. By delivering increments to the users, we can further refine our understanding of their needs and better evolve the system to meet their real needs.

Team Skill 1: Analyzing the Problem

In Team Skill 1, we introduced a set of skills your team can apply to understand the problem to be solved before too much is invested in the application . We introduced a simple, five-step problem analysis technique that can help your team gain a better understanding of the problem to be solved.

Gain agreement on the problem definition.
Understand the root causes of the problem.
Identify the stakeholders and the users whose collective judgment will ultimately determine the success or failure of your system.
Determine where the boundaries of the solution are likely to be found.
Identify and understand the constraints that will be imposed on the team and on the solution.

All in all, following this process will improve your team's ability to address the challenge ahead, providing a solution to the problem to be solved .

We also noted that a variety of techniques could be used in problem analysis. Specifically, we looked at business modeling, a problem analysis technique that works quite well in complex information systems that support key business processes. The team members can use business modeling to both understand the way in which the business evolves and to define where within the system they can deploy applications most productively. We also recognized that the business model we defined will have parallels in the software application, and we use this commonality to seed the software design phases.

For embedded-system software applications, we applied systems engineering as a problem analysis technique to help decompose a complex system into more manageable subsystems. This process helps us understand where new software applications should come to exist and what purpose they serve. However, we complicate the requirements challenge somewhat by defining these new subsystems, for then we must determine the requirements to be imposed on them.

Team Skill 2: Understanding User and Stakeholder Needs

We started Team Skill 2 by introducing three "syndromes" that increase the challenge of understanding the real needs of users and other stakeholders. The "Yes, But," the "Undiscovered Ruins," and the "User and the Developer" syndromes are metaphors that helped us better understand the challenge ahead and provided a context for the elicitation techniques we developed in this team skill.

We also recognized that since we rarely have been given effective requirements specifications for the systems we are going to build, in order to do a better job of building these systems, we have to go out and get the information we need to be successful. Requirements elicitation is the term we used to describe this process, and we concluded that the team must play a more active role.

To help the team address these problems and better understand the real needs of users and other stakeholders, we then presented a variety of techniques:

Interviewing
Requirements workshops
Brainstorming and idea reduction
Storyboarding

Although no one technique is perfect in every circumstance, each represents a proactive way to push your knowledge of user needs forward and thereby convert "fuzzy" requirements into requirements that are "better known."

Team Skill 3: Defining the System

In Team Skill 3, we moved from understanding the needs of the user to defining the solution. In so doing, we took our first steps out of the problem domain, the land of the user, and into the solution domain, wherein our job is to define a system to solve the problem at hand.

We invested most of our time in developing the use-case technique since it can do most of the "heavy lifting ." Use cases have a number of advantages over other techniques, including the way the use cases persist in the project to drive testing strategy and the development of the test cases themselves . We also discussed that complex systems require comprehensive strategies for managing requirements information, and we looked at a number of ways to organize requirements information. We recognized that we really have a hierarchy of information, starting with user needs, transitioning through features, then into the more detailed software requirements as expressed in use cases and supplementary specifications. Also, we noted that the hierarchy reflects the level of abstraction with which we view the problem space and the solution space.

We then "zoomed in" to look at the application definition process for a stand-alone software application and invested some time in defining a Vision document for such an application. We maintain that the Vision document, with modifications to the particular context of a company's software applications, is a crucial document and that every project should have one.

We also recognized that without someone to champion the requirements for our application and to support the needs of the customer and the development team, we would have no way to be certain that the hard decisions are made. Requirements drift , delays, and suboptimum decisions forced by project deadlines are likely to result. Therefore, we decided to appoint someone or to anoint someone to serve as product manager , someone to own the Vision document and the features it contains as well as to drive agreement on some of the commercial factors that convert an application into a whole product solution . In turn , the champion and the team empower a change control board to help with the really tough decisions and to ensure that requirements changes are reasoned about before being accepted.

Team Skill 4: Managing Scope

In Team Skill 4, we examined the endemic problem of project scope. It is not unusual to see projects initiated with two to four times the amount of functionality the team can reasonably implement in a quality manner. We shouldn't be surprised by this; it is the nature of the beast . Customers want more, marketing wants more, and the team wants more, too. Nevertheless, we have to manage this psychology aggressively if we intend to deliver something on time.

In order to manage scope, we looked at various techniques for setting priorities, and we defined the notion of the baseline, an agreed-to understanding of what the system will do, as a key project work product. We learned that if scope and the concomitant expectations exceed reality, in all probability, some bad news is about to be delivered. We decided on a philosophy of approach that engages our customer in the hard decisions. After all, we are just the implementers, not the decision makers ; it's our customer's project. So, the question is, "What, exactly, must be accomplished in the next release, given the resources that are available to the project?"

Even then, we expect to do some negotiating. We briefly mentioned a few negotiation skills and hinted that the team may need to use them on occasion.

We cannot expect that the process described so far will make the scope challenge go away, any more than any other single process will solve the problems of the application development world. However, the steps outlined can be expected to have a material effect on the scope of the problem, allowing application developers to focus on critical subsets and to deliver high-quality systems incrementally that meet or exceed the expectations of the user. Further, engaging the customer in helping solve the scope management problem increases commitment on the part of both parties and fosters improved communication and trust between the customer and the application development team.

With a comprehensive project definition, or Vision document, in hand and scope managed to a reasonable level, we at least have the opportunity to succeed in the next phases of the project.

Team Skill 5: Refining the System Definition

In Team Skill 5, we first took a more rigorous look at requirements and commented on some of the issues that arise in transitioning from requirements to design. In addition, we refined the use cases to sufficient specificity so that we can both implement them and use them later to develop the test cases that will determine when the requirements have been met. We also discussed the importance of nonfunctional requirements, including the system's usability, reliability, performance, and supportability, as well as the design constraints that may be imposed on our process. We described how to organize them in a supplementary specification that, along with the use-case model, completes our information model of the system we are building.

Team Skill 6: Building the Right System

Designing and implementing the correct system is the biggest job of all. In Team Skill 6, we described how to use the developed use cases to drive implementation via the design construct of the use-case realization . We also described how to use the use cases to develop a comprehensive testing strategy by deriving the test cases directly from them.

We also developed the concepts and described the challenges associated with requirements traceability and demonstrated how that technique can improve the quality and reliability outcomes of a development effort.

In addition, building the right system right also depends on the team's ability to manage change effectively . Since change is just part of life we must plan for change and develop a process whereby we can manage it. Managing change helps us make sure that the system we built is the right system and, moreover, that it continues to be the right system over time.

Lastly, we looked at a framework for assessing requirements quality, as well as overall project quality, within an iterative development process, and we used this to create guidelines your team can use to help assure you will deliver a quality result.

With all that behind us, we're almost ready to look at that requirements prescription our students have been clamoring for. Before we do, however, we have one last meaty topic to cover: the topic of picking an overall requirements method you can apply in your specific project context.