Jama Software® Enables Measurable Performance Improvement with Client-Specific Success Paths
We’re excited to announce our further advancement to our market-leading customer success program that has led to high levels of customer retention and award-winning customer satisfaction. Our customers are now able to define measurable success paths from a catalog of consulting offerings to derive optimum and continuous value from Jama Connect®. The new Jama Software Success Program helps customers accelerate the best possible business outcomes and realize long-term success.
With the Jama Software Success Program, customers can now select the success path that best maps to the level of collaboration required to meet their unique needs and desired business outcomes. These customizable success paths deliver the industry-specific expertise, guidance, and resources clients need to see a quick return on investment and achieve their goals.
The Jama Software Success Program has three primary offerings:
Essentials Success – A foundational self-guided success path with access to key resources, tutorials, and training to set customers on the road to success.
Guided Success – A guided success path with enhanced resource offerings including benchmark assessments, personalized training offerings, and technical services to help evaluate compliance and improve process and quality.
Strategic Success – A strategic success path which provides even more advanced offerings, premium-level support, and a close partnership in complex and ongoing enterprise deployments to drive continuous process improvement across multiple projects.
To learn how Jama Software enables your company to succeed in a competitive market, CLICK HERE
With in-house industry experts, extensive consulting, training, and data-driven insights to measure and improve outcomes, the Jama Software Success Program enables customers to accelerate development, improve product quality, reduce risk, and manage innovation in systems engineering.
“With this program update, Jama Software now provides best practice engineering process improvement,” stated Tom Tseki, Chief Revenue Officer. “While other software companies are focused on just implementing their solutions, Jama Software is focused on providing measured process improvement for our customers that goes way beyond just the implementation of software.”
In the first part of this two-part series I described some cues that help the business analyst detect when a customer has presented some input that could be classified as a business requirement, use case, business rule, or functional requirement. This article continues the discussion to help you classify customer input into several other categories of requirements knowledge.
Quality Attributes. Statements that indicate how well the system performs some behavior or lets the user take some action are quality attributes, also called quality factors, quality of service requirements, and sometimes simply nonfunctional requirements. Listen for words that describe desirable system characteristics: fast, easy, intuitive, user-friendly, robust, reliable, secure, and efficient. Chapter 12 of my book Software Requirements, 2nd Edition provides guidance on writing quality attributes.
You’ve probably been asked to build user-friendly software, but I’ll bet you’ve never been asked to build user-hostile or user-surly software. Everybody wants user-friendly software. However, it does you no good to write down a requirement that simply states, “The system shall be user-friendly” or robust, or intuitive, or any of these other good things. Those are not useful requirements because we don’t know just what they mean yet. But the customer has an important and legitimate idea behind each requirement, which you’ll need to flesh out.
If you hear this sort of vague and fuzzy input, rather than just dismissing it as not useful, regard it as a clue to have a conversation about the statement. Ask the person who provided that input questions such as: “What does user-friendly mean to you? How would we know if this was user-friendly enough? Can you give me some examples of things that you consider as being user-friendly or not user-friendly?” As a BA, you’ll have to work with the users to understand precisely what they mean by these ambiguous and subjective terms so you can write clear, verifiable, and achievable quality goals.
External Interface Requirements. Requirements in this category describe the connections between your system and the rest of the universe. The SRS should include sections for interfaces to users, to hardware devices, and to other software systems, as necessary. Phrases that indicate that the customer is describing an external interface requirement might sound like the following:
• “Must read signals from (some device).”
• “Must send messages to (some other system).”
• “Must be able to read (or write) files in (some format).”
• “Must control (some piece of hardware).”
• “User interface elements must conform to (some UI style standard).”
Constraints. Design and implementation constraints legitimately restrict the options available to the developer. Hardware devices having embedded software often must respect physical constraints such as size, weight, and interface connections. It’s a good idea to record the rationale behind each constraint so that all project participants know where it came from and respect its validity. Is it truly a restrictive limitation, as when a device must fit into an existing physical space? Or is it a desirable goal, such as a tablet computer that weighs as little as possible?
Unnecessary constraints inhibit creating the best solution. Excessive constraints also reduce your ability to use commercially available components as part of the solution. A constraint that specifies that a particular technology be used poses the risk of making a requirement obsolete or unattainable because of changes in the available technologies. Certain constraints can help achieve quality attribute goals. An example is to improve portability by using only the standard commands of a programming language, not permitting vendor-specific extensions.
The following are examples of constraints that you might hear from a customer:
“Files submitted electronically may not exceed 10 MB in size.”
“The browser must use 128-bit encryption for all secure transactions.”
“The database must use the Framalam 10.2 run-time engine.”
Other phrases that suggest the speaker is describing a design or implementation constraint include these:
“Must be written in (a specific programming language).”
“Can’t require more than (some amount of memory).”
“Must operate identically to (or be consistent with) (some other system).”
“Must use (a specific user interface control).”
As with functional requirements, the analyst shouldn’t simply transcribe the user’s statement of a constraint into the SRS. Weak words such as identically and consistent need to be clarified and the real constraint stated precisely enough for developers to act on the information. Ask why the constraint exists, verify its validity (the constraint might be obsolete or based on an incorrect assumption), and document its rationale.
Data Definitions. Whenever customers describe the format, data type, allowed values, or default value for a data item or the composition of a complex business data structure, they’re presenting a data definition. “The ZIP code consists of five digits, followed by an optional hyphen and an optional four digits that default to 0000” is a data definition. Collect these in a data dictionary, a master reference that the team can use throughout the product’s development and maintenance. See Chapter 10 of Software Requirements, 2nd Edition for more about data dictionaries.
Data definitions sometimes lead to functional requirements that the user community did not request directly. What happens when a six-digit order number rolls over from 999999? Developers need to know how the system will handle such data issues. Deferring data-related problems just makes them harder to solve in the future; remember Y2K?.
Solution Ideas. Much of what users present as requirements fits in the category of solution ideas. Someone who describes a specific way to interact with the system to perform some action is presenting a suggested solution. The BA needs to probe below the surface of a solution idea to get to the real requirement. For instance, functional requirements that deal with passwords are just one of several possible solutions for an access control requirement.
Suppose you’re working on the requirements for a new point-of-sale system for a chain of stores that ship packages around the universe. Perhaps a user representative tells you, “Then I select the state where I want to send the package from a drop-down list.” The phrase from a drop-down list indicates that this is a solution idea. The user is envisioning a specific type of user interface control. The prudent BA will ask, “Why from a drop-down list?” If the user replies, “That just seemed like a good way to do it,” then the real functional requirement is something like, “The system shall permit the user to specify the state where he wants to send the package.” This statement gives the developer a lot of flexibility in choosing the most appropriate interaction mechanism.
However, maybe the user says, “I suggested a drop-down list because we do the same thing in several other places and I want it to be consistent. Also, it prevents the user from entering invalid data, and I thought we might be able to reuse some code.” These are fine reasons to specify a specific solution. Recognize, though, that embedding a solution idea in a requirement imposes a design constraint on that requirement. It limits the requirement to being implemented in only one way. This isn’t necessarily wrong or bad; just make sure the constraint is there for a good reason.
The thrust of these two articles is that you can’t expect your customers to present a succinct, complete, and well-organized list of their needs. Instead, they will present you with a wide variety of inputs, all of which seem important to them, and it’s up to you—the BA—to sort through what you hear to phrase it in a useful way and park it in a sensible location. That’s a big part of what requirements analysis is all about.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
As you acquire requirements input from various sources, it comes in all stirred together. People don’t just tidily tell you, “Here are all my business rules, here are all my use cases” and so forth. Instead, the business analyst is bombarded with a more or less random array of information. Therefore, an important part of requirements elicitation and analysis is to capture that array of input, understand it, and begin classifying it into different categories so you can store the information in the most appropriate locations and use it effectively on the project.
Figure 1 illustrates nine common requirement categories you’re likely to encounter. You’ll hear other kinds of information too, of course, including a large amount of extraneous or explanatory information. Information that doesn’t fit into one of these nine buckets might be one of the following:
• A requirement not related to the software development, such as the need to train users on the new system. • A project constraint, such as a cost or schedule restriction (as opposed to the design or implementation constraints described in the second article in this series). • An assumption, which is a statement about the project we regard as being true in the absence of definitive knowledge that it is true. • A data requirement, which can often be associated with some system functionality (you store data in a computer only so that you can get it out again later). • Additional information of a historical, context-setting, or descriptive nature.
Figure 1. Classifying the voice of the customer.
The rest of this two-part series suggests some phrases to listen for that will help the BA struggle to make sense of the customer input and to classify it all accordingly.
Business Requirements. Anything that describes the financial, market, or other business benefit that either customers or the developing organization wish to gain from the product is a business requirement. Business requirements answer the question “Why are we working on this project?” I like to document business requirements in a vision and scope document or a project charter.
It’s best if you can quantify these business objectives. Instead of just saying “increase market share,” try to set specific targets so you can track towards those goals and take actions that you think will help achieve them. Because the people who provide the input perhaps aren’t accustomed to stating their business requirements so precisely, the BA will have to help them structure the initial input into high-quality requirements. Listen for statements about the value that buyers or users of the software will receive, such as these:
• “Increase market share by X%.” • “Save $Y per year on electricity now wasted by inefficient units.” • “Save $Z per year in maintenance costs that are consumed by legacy system W.”
Use Cases or Scenarios. General statements of user goals or business tasks that users need to perform are use cases; a single specific path through a use case is a usage scenario. Work with the customers to generalize specific scenarios into more abstract use cases. You can often glean use cases by asking users to describe their business workflow. Another way to discover use cases is to ask users to state the goals they have in mind when they sit down to work with the system. A user who says, “I need to“ is probably describing a use case, as in the following examples:
• “I need to print a mailing label for a package.” • “I need to manage a queue of chemical samples waiting to be analyzed.” • “I need to calibrate the pump controller.”
User stories, as used in the agile development world, sound a lot like use case goals. User stories often are phrased in the form: “As a, I want [to achieve some goal] so that [I can reap some benefit].” It’s the same idea as a use case, although you might opt to document the two in different levels of detail when you reach that point in the project.
Business Rules. When a customer says that only certain user classes can perform an activity under specific conditions, he might be describing a business rule. A sample business rule for a chemical tracking system might be, “A chemist may order a chemical on the Level 1 hazard list only if his hazardous-chemical training is current.” You might derive some software functional requirements to enforce the rules, such as making the training record database accessible to the chemical tracking system. As stated, though, business rules are not functional requirements. Following are some other phrases that suggest the user is describing a business rule:
• “Must comply with (some law or corporate policy).” • “Must conform to (some standard).” • “If (some condition is true), then (something happens).” • “Must be calculated according to (some formula).”
As you can see from the final example above, even though they’re called business rules, these might also encompass information that you would think of as being more technical, such as formulas for performing certain calculations.
Functional Requirements. Functional requirements describe the observable behaviors the system will exhibit under certain conditions and the actions the system will let users take. Functional requirements derived from system requirements, user requirements, business rules, and other sources make up the bulk of the typical software requirements specification. Here are some examples of functional requirements as you might hear them from users:
• “If the pressure in the tank exceeds 40 psi, the high-pressure warning light should come on.” • “The user must be able to sort the project list in forward and reverse alphabetical order.” • “The system sends an e-mail to the Idea Coordinator whenever someone submits a new idea.”
These statements illustrate how users typically present functional requirements, but they don’t necessarily represent good ways to write functional requirements. For instance, in the first case, we would replace should with shall to make it clear that illuminating the warning light is essential. We would also want to make sure that there isn’t some other way to indicate a high-pressure condition besides illuminating a warning light. The warning light might just be an idea or assumption on the part of the speaker, or it could represent a legitimate physical constraint. The second example is a requirement of the user, not of the system. The requirement of the system is to permit the user to do the sorting. You can’t expect your users to provide you with well-crafted functional requirements from the get-go. You’ll have to pick up on the idea they’re trying to communicate and, through dialogue, shape that into a focused and unambiguous requirement statement.
In the final part of this series I’ll describe some cues you can use to detect when you’re hearing information from a customer that could be classified as a quality attribute, external interface requirement, constraint, data definition, or solution idea.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
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 information systems or hardware components that derive services from the software you’re writing. Those types of user classes also need a voice to speak for their needs. It’s unlikely that any one individual will be able to represent the needs of all the diverse user classes adequately and to balance their interests appropriately when making decisions and reconciling conflicts.
A more realistic approach is to enlist a small number of product champions to serve as key user representatives. More than twenty-five years ago, my small software group at Kodak adopted the product champion approach with great success. In this model, the primary communications bridge across which user requirements flow involves one or more BAs working with one or more product champions, as Figure 1 illustrates.
Figure 1. The requirements communication pipeline connects product champions and business analysts.
As a first approximation, look for one product champion per major user class. Some individuals might be members of multiple user classes and could present the needs of all those groups. In other situations, a large user class might be divided logically into sub-user classes. I encountered this situation on a project building an information system to track chemical usage. Our largest user class consisted of several hundred chemists. We found an experienced chemist, Don, who could supply most of the requirements for the common needs of these users. Don served as the product champion, the primary interface between the chemists and the BA (me, a former organic chemist myself). Don communicated with his colleagues to identify requirements, propose suggestions, and resolve conflicting inputs.
During this project, though, we learned that certain small groups of chemists throughout the company had some specialized needs. Therefore, we lined up several other chemists to work with Don to ensure thorough coverage of the community’s requirements. If this group of representative chemists couldn’t all agree on some issue, Don made the call. Someone has to make these kinds of decisions, and it works best when the decision-maker is a knowledgeable and respected user representative.
On this same project, we had three other important but much smaller user classes. We found a product champion to represent each of these other groups. The four product champions together served as our “voice of the customer.” Ideally, your champions will be co-located with the analysts and developers for the duration of the project so they can quickly answer questions and supply the myriad details that written requirements specifications lack (or get wrong). This is the intent of the on-site customer principle. In practice, none of our product champions ever spent more than about one-quarter of their time working on our projects. Nor were they co-located with the analysts and developers, although they were accessible enough to provide quick feedback when necessary.
I’ve spoken to many BAs, developers, and users who have tried the product champion model. They invariably report that the approach was highly successful, provided four conditions are met:
The right individuals assume the product champion role.
Each champion understands and signs up for his responsibilities. See Chapter 6 of my book Software Requirements, 2nd Edition for some typical product champion activities.
Each champion has the time available to do the job.
Each champion has the authority to make binding decisions at the user requirements level.
Simply having an on-site customer doesn’t guarantee that he’ll provide the expected contribution. My colleague Julia learned this the hard way. Julia’s original product champion was co-located with the developers, yet failed to interact with them in the expected way. As Julia put it, “He sat in our midst and still managed to avoid us all.” This negated the value of having a customer on site. Julia acquired a new champion who interacted much more effectively with the developers and strongly influenced the project’s direction. The moral of the story is that it’s essential for your customer representatives to commit to making the project contributions you need from them.
Surrogate Users The ideal product champion is an actual member of the user class he represents. This isn’t always possible, particularly when building commercial products for a faceless market. You might need to use surrogates in place of real user representatives. Perhaps a product manager can fill this role or a local subject matter expert can speak for the users, thereby acting as the product champion. Try to avoid the following user surrogates, though:
Former members of the user class. When your product champions are former—not current—users, you have to consider whether a significant disconnect has grown over time between their perceptions and the actual user needs. Their understanding of user needs and how current users would employ the system could be obsolete. However, they might be able to do a good job if they’re still in touch with current users or if the application domain changes slowly.
Managers of the real users. Managers sometimes are leery about delegating decision-making authority to ordinary users. Often, they’re also reluctant to have valuable employees spend a lot of time working with the software team. I’ve heard managers say, “I did that job myself for ten years. I can tell you everything you need to know. You don’t need to talk to any users.” There are two problems with this rationale. First, those managers probably aren’t current members of the user class. Second, busy managers rarely have the time to devote to a serious requirements development effort. It’s better to have managers provide input to the business requirements (why we are undertaking the project, business objectives) and ask them to identify some current members of the user class to contribute to the user requirements (use cases, tasks to accomplish).
Software developers who think they can speak for the users. Rarely, this situation will work. More commonly, even developers with considerable domain experience will find that actual users of the new product will bring a different, and more reliable, perspective. Of course, if the product is intended for use by software developers, your own developers might be perfectly reasonable user representatives.
Now Hear This Your stakeholders might hesitate to invest the considerable time it takes to have knowledgeable users work with BAs. Here’s how I see it. You’re going to get the customer input eventually. It’s a lot less painful to get it early on, as well as on an ongoing basis during development. The alternative is to wait until you deliver the system, hear complaints about all the things the BA and developers did wrong, and then spend a lot of time, money, and goodwill fixing those problems.
I encounter many teams that would love to have more customer involvement but which are deliberately blocked from talking to actual users. This is a special concern when the customer is not himself an end user, yet prevents the developers from interacting directly with users. In other cases, no one is willing to spend the time to work with the development team on requirements, prototype evaluations, or other opportunities for engagement. If you can’t get your customers or suitable surrogates to invest time in making sure the product meets their needs, I seriously question their commitment to project success.
In an ideal world, a single, full-time, expert user would indeed be sitting within view—”on sight”—of developers, ready at a moment’s notice to speak definitively for the entire user community. In reality, this is unlikely in most situations. More realistically, the project manager and business analyst should assemble a small group of product champions who can properly interpret and balance the needs of the user classes they represent. Then build a close, collaborative relationship with those product champions so that you can get the VOC—the voice of the customer—as close as possible to the EOD—the ear of the developer.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
/media/jama-logo-primary.svg00Karl Wiegers/media/jama-logo-primary.svgKarl Wiegers2012-10-26 09:41:302023-01-12 16:57:05Software Requirements: Hearing the Voice of the Customer
