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 Karl Wiegers | Aug 6, 2013 | Business Analysis, Uncategorized |
Written by Karl Wiegers and Joy Beatty Some organizations acquire and adapt purchased packaged solutions (also called commercial off-the-shelf, or COTS, products) to meet their software needs, instead of building new systems from scratch. Software as a service (SaaS), or cloud, solutions are becoming increasingly available to meet software needs as well. Whether you’re purchasing a package as part or all of the solution for a new project or implementing a solution in the cloud, you still need requirements. Requirements let you evaluate solution candidates so that you can select the most appropriate package, and then they let you adapt the package to meet your needs. Some COTS products can be deployed out of the box with no additional work needed to make them usable. Most, though, require some customization. This could take the form of configuring the default product, creating integrations to other systems, or developing extensions to provide additional functionality that is not included in the COTS package. These activities all demand requirements. If you are seeking a commercial package to provide a canned solution for some portion of your enterprise information-processing needs, first document your requirements. You don’t need to specify all of the nitty-gritty functionality details, but consider the domains of use cases or user stories, business rules, data needs, and quality attribute requirements. Next, do some initial market research to determine which packages are viable candidates deserving further consideration. Then you can use the requirements you identified as evaluation criteria in an informed COTS software selection process. One evaluation approach includes the following sequence of activities: Weight your requirements on a scale of 1...
by Karl Wiegers | Jul 2, 2013 | Business Analysis, Uncategorized |
Written by Karl Wiegers and Joy Beatty Reuse is an eternal grail for those seeking increased software productivity. People think most often in terms of code reuse, but many other software project components also have reuse potential. Reusing requirements can increase productivity, improve quality, and lead to greater consistency between related systems. Reuse is not free, though. It presents its own risks, both with respect to reusing existing items and to creating items with good reuse potential. It will likely take more time and effort to create high-quality reusable requirements than to write requirements you intend to use only on the current project. In this article, adapted from our new book Software Requirements, 3rd Edition (Microsoft Press, 2013), we describe some of the approaches an organization should consider taking to maximize the reuse potential of its requirements. Just because a requirement exists doesn’t mean it’s reusable in its present form. It could be specific to a particular project. It might be written at too high a level because the BA could safely assume certain knowledge on the part of the development team or because some details were communicated only verbally. A requirement could be lacking information about how possible exceptions should be handled. You might have to tune up the original requirements to increase their value to future BAs. Well-written requirements lend themselves to reuse. The steps you take to make requirements more reusable also increases their value to the project for which you originally write them; it simply makes them better requirements. Reusers need to know about dependencies the requirement has on others, as well as other requirements...
by Karl Wiegers | Oct 19, 2012 | Business Analysis, Uncategorized |
Experienced project managers and developers understand the value of translating software requirements into robust designs and rational project plans. These steps are necessary whether the next release represents one percent or one hundred percent of the final product. This article explores some approaches for bridging the gap between requirements development and a successful product release. In particular, we will look at several ways in which requirements influence designs and code (Figure 1). Figure 1. Requirements drive project planning, design, coding, and testing activities. From Requirements to Designs and Code The boundary between requirements and design is not a sharp line, but keep your specifications free from implementation bias except when you have a compelling reason to intentionally constrain the design. Requirements specification should concentrate on describing the intended external system behaviors. Ideally, the descriptions of what the system is intended to do should not be slanted by design considerations. Practically speaking, many projects contain design constraints from prior products, and backwards compatibility is a frequent requirement. Because of this, a requirements specification almost always contains some design information. However, the specification should not contain inadvertent design. Include designers or developers in requirements reviews to make sure the requirements can serve as a solid foundation for design. A product’s requirements, quality attributes, and user characteristics drive its architecture. Studying a proposed architecture provides a different perspective that helps to verify the requirements and tune their precision, as does prototyping. Both methods use the following thought process: “If I understand the requirements correctly, then this approach is a good way to satisfy them. Now that I have a preliminary architecture (or...
by Karl Wiegers | Sep 19, 2012 | Business Analysis, Uncategorized |
Some agile software development approaches have as a central tenet the premise that every project needs a full-time, on-site customer who sits with the developers. The rationale is sound. Only knowledgeable and empowered customer representatives can answer questions and flesh out high-level requirements in appropriate detail. Failing to get timely answers or clarification holds up development and forces the developers to make their best guess. The right customers also can provide quick feedback on proposed user interface displays, clarify points of confusion, and resolve conflicting requirements and priorities. I fully endorse the premise of intimate, ongoing engagement of appropriate customer representatives on software projects, as well as the need to get input from a wide variety of other stakeholders. My concern about the phrase on-site customer is simply that it is singular. It suggests that a single individual is available who has sufficient knowledge, expertise, and authority to make requirements decisions on behalf of the entire user community. Even if you could find one such highly qualified representative, other demands likely will compete for his time unless he and his management make participating in the project a priority. In this article, adapted from my book More about Software Requirements (Microsoft Press, 2006) I describe a more effective approach to finding the literal voice of the customer and engaging customers on a project. User Classes and Product Champions In reality, most products have multiple—often many—distinct user classes, groups of users who have largely different needs. Certain groups—the favored user classes—will be more important than others to the business success of the project. Sometimes user classes aren’t even people: they’re other...
