by Karl Wiegers | Aug 27, 2012 | Business Analysis, Uncategorized |
Software products are created for users, be they human beings, hardware devices, or other software systems. A user is a stakeholder who will interact with a completed system either directly (that is, hands on) or indirectly (for example, using reports from the system but not generating those reports personally). Users can be grouped into user classes, communities of users who have similar characteristics and similar requirements for a system. Discussions of use cases always involve the concept of actors. An actor is an entity outside the system boundary that interacts with the system for the purpose of completing an event, such as execution of a use case. Actors are related to—but are not precisely the same as—user classes. This distinction between user classes and actors is subtle. It doesn’t help that the books on use cases employ somewhat different terminology. Here are the key points: User classes represent groups of actual people or non-human users. A human user is a member of one or more user classes. You need to identify your product’s user classes so you know which people to talk with about requirements. You also need to understand which user classes are “favored” over others. Satisfying the needs of a favored user class is more important from a business perspective than meeting the needs of other groups of users. This distinction helps when making priority decisions and resolving requirement conflicts. An actor is an abstraction, a role performed by a member of a specific user class when he interacts with a product at a specific time. When you are talking with user class representatives, have them identify...
by Karl Wiegers | Aug 10, 2012 | Business Analysis, Uncategorized |
I don’t know of any way to be absolutely certain that you have not missed any requirements during elicitation. This makes it hard to know just when you can declare your set of requirements—whether for the full product or just the next iteration—complete. Even though you can’t know for sure if you’re done, at some point you need to define a requirements baseline and move ahead with the project work. In this article, adapted from my book Software Requirements, 2nd Edition, I propose several techniques for helping you find requirements you might have overlooked, as well as some ways to judge whether your elicitation process is sufficiently complete. Finding Missing Requirements Missing requirements are among the most common requirement defects. They’re hard to spot during reviews because they’re invisible! The following techniques will help you detect previously undiscovered requirements. Decompose high-level requirements into enough detail to reveal exactly what is being requested. A vague, high-level requirement that leaves much to the reader’s interpretation will lead to a gap between what the requester has in mind and what the developer builds. Imprecise, fuzzy terms to avoid include support, enable, permit, process, and manage. Make sure that all user classes have provided input. Make sure that each use case has at least one identified actor. Trace system requirements, use cases, event-response lists, and business rules into their detailed functional requirements to make sure that the BA derived all the necessary functionality. Check boundary values for missing requirements. Suppose one requirement states, “If the price of the order is less than $100, the shipping charge is $5.95” and another says, “If the...
by Karl Wiegers | Aug 6, 2012 | Business Analysis, Testing, Uncategorized |
Someone once asked me when you can begin testing your software. “As soon as you’ve written your first requirement, you can begin testing,” I replied. It’s hard to visualize how a system will function just by reading the requirements specification. Tests that are based on requirements help make the expected system behaviors more tangible to the project participants. And the simple act of designing tests will reveal many problems with the requirements long before you don’t execute the tests on an operational system. If you begin to develop tests as soon as portions of the requirements stabilize, you can find problems while it’s still possible to correct them inexpensively. Requirements and Tests Tests and requirements have a synergistic relationship. They represent complementary views of the system. Creating multiple views of a system—written requirements, diagrams, tests, prototypes, and so forth—gives you a much richer understanding of the system than can any single representation. Agile software development methodologies often emphasize writing user acceptance tests in lieu of detailed functional requirements. Thinking about the system from a testing perspective is very valuable, but that approach still leaves you with just a single representation of requirements knowledge. Writing black-box (functional) tests crystallizes your vision of how the system should behave under certain conditions. Vague and ambiguous requirements will jump out at you because you won’t be able to describe the expected system response. When BAs, developers, and customers walk through the tests together, they’ll achieve a shared vision of how the product will work. A personal experience really brought home to me the importance of combining test thinking with requirements specification. I once...
by Karl Wiegers | Jul 11, 2012 | Business Analysis, Uncategorized |
If you’re going to go to all the trouble to build software system, you’d like to be confident that you’re working from the right requirements. You’d like to know that the product you build has a high chance of satisfying customer needs and will let them get their jobs done in a way they find acceptable and maybe even enjoyable. But without taking the time to validate the requirements, the risk of missing the mark goes up. Most software developers have experienced the frustration of being asked to implement requirements that were ambiguous or incomplete. If they can’t get the information they need, the developers have to make their own interpretations, which aren’t always correct. Substantial effort is needed to fix requirement errors discovered after those requirements have already been implemented. Any measures you can take to detect errors in the requirements specifications will save you considerable time and money. This article, adapted from my book Software Requirements, 2nd Edition (Microsoft Press, 2003), describes the importance of requirements validation and some valuable techniques to try. Validation Defined Requirements validation is the fourth component—with elicitation, analysis, and specification—of requirements development. Validation assesses whether a product actually satisfies the customer needs (doing the right thing). In contrast, verification determines whether the product of a development activity meets the requirements established for it (doing the thing right). Both activities are vital to successful product development, but we will focus on validation here. Requirements validation attempt to ensure that: The SRS correctly describes the intended system capabilities and characteristics that will satisfy the various stakeholders’ needs. The software requirements were correctly derived from...
by Karl Wiegers | Jul 5, 2012 | Business Analysis, Uncategorized |
Rather than expecting use cases to contain one hundred percent of the system’s functionality, I prefer to employ use cases to help the business analyst discover the functional requirements. That is, the use cases become a tool to reveal functionality rather than being an end requirements deliverable themselves. Users can review the use cases to validate whether a system that implemented the use cases would meet their needs. The BA can study each use case and derive the functional requirements the developer must implement to realize the use case in software. I like to store those functional requirements in a traditional SRS, although you could add them to the use case description if you prefer. I’m often asked, “Which comes first: use cases or functional requirements?” The answer is use cases. Use cases represent requirements at a higher level of abstraction than do the detailed functional requirements. I like to focus initially on understanding the user’s goals so that we can see how they might use the product to achieve those goals. From that information, the BA can derive the necessary functionality that must be implemented so that the users can perform those use cases and achieve their goals. Conversely, if users present fragments of functionality during a requirements elicitation discussion, the BA should try to figure out which use case that functionality might with, if any. Functional requirements—or hints about them—lurk in various parts of the use case. The remainder of this article describes a thought process a BA can go through to identify the less obvious functional requirements from the elements of a use case description. Preconditions...
