Impact analysis is a key aspect of responsible requirements management. It provides an accurate understanding of the implications of a proposed change, which helps the teams make informed business decisions about which proposals to approve.
The analysis examines the proposed change to identify components that might have to be created, modified, or discarded and to estimate the effort associated with implementing the change.
Skipping impact analysis doesn’t change the size of the task. It just turns the size into a surprise. In product development surprises are rarely good news. Before a developer says, “Sure, no problem” in response to a change request, he or she should spend a little time on impact analysis.
Understand the possible implications of making the change. Change often produces a large ripple effect. Stuffing too much functionality into a product can reduce its performance to unacceptable levels.
Identify all the files, models, and documents that might have to be modified if the team incorporates the requested change.
Identify the tasks required to implement the change, and estimate the effort needed to complete those tasks.
Traceability data that links the affected requirement to other downstream deliverables helps greatly with impact analysis. On complex projects with thousands of artifacts, to manually determine what and who is affected by a change is time-consuming and error-prone. Alternatively, you could adopt a product development solution like Jama Connect, which includes built-in functionality for end-to-end traceability and impact analysis, and automatically highlights the items and people that are impacted when a change occurs.
Whichever route you take, understanding the impact enables teams to quickly and accurately respond to change requests. The team can be responsive while maintaining control over the scope and customer expectations.
Lastly, impact analysis is essential on projects where quality and safety are an issue such as in healthcare, automotive, and aerospace projects. In these situations, it’s critical to understand the specific set of requirements and features that need to be retested after a change is implemented.
Steps in a typical impact analysis process look like this:
Identify the sequence in which the tasks must be performed and how they can be interleaved with currently planned tasks.
Determine whether the change is on the project’s critical path. If a task on the critical path slips, the project’s completion date will slip. Every change consumes resources, but if you can plan a change to avoid affecting tasks that are currently on the critical path, the change won’t cause the entire project to slip.
Estimate the impact of the proposed change on the project’s schedule and cost.
Evaluate the change’s priority by estimating the relative benefit, penalty, cost, and technical risk compared to other discretionary requirements.
Report the impact analysis results to all stakeholders so that they can use the information to help them decide whether to approve or reject the change request.
In most cases, this procedure shouldn’t take more than a couple of hours to complete. This may seem like a lot of time to a busy developer, but it’s a small investment in making sure the project wisely invests its limited resources. If you can adequately assess the impact of a change without such a systematic evaluation, go right ahead; just make sure you aren’t stepping into quicksand.
What can happen if you don’t take the time to perform impact analysis before diving into implementing a significant change request?
Imagine two developers on your team estimate that it will take four weeks to add an enhancement to one of your product lines. The customer approves the estimate, and the developers set to work. After two months, the enhancement is only about half done and the customer loses patience: “If I’d known how long this was really going to take and how much it was going to cost, I wouldn’t have approved it. Let’s forget the whole thing.”
In the rush to gain approval and begin implementation, the developers didn’t do enough impact analysis to develop a reliable estimate that would let the customer make an appropriate business decision. Consequently, you waste several hundred hours of work that could have been avoided by spending a few hours on an up-front impact analysis.
https://www.jamasoftware.com/media/2017/03/2020-08_BestPracticesChangeImpactAnalysis_1024x512-copy.jpg5121024Karl Wiegers/media/jama-logo-primary.svgKarl Wiegers2022-09-12 13:00:132024-09-04 16:16:44Best Practices for Change Impact Analysis
Every product development team talks about project scope and team members often complain about unending scope creep. The vision and scope document (often including a use case diagram and a context diagram), otherwise known as the MRD (marketing requirements document) or business case, is a key deliverable in defending against scope creep. You don’t necessarily need a standalone vision and scope document for a small project. Any project of any size, though, will benefit from such strategic guidance, even if it’s just a paragraph or two at the beginning of the requirements specification.
Vision and Project Scope
Both the vision and the scope are components of the project’s business requirements. I think in terms of the product vision and the project scope. I define the product vision as: “A long-term strategic concept of the ultimate purpose and form of a new system.” The product vision could also describe the product’s positioning among its competition and in its market or operating environment.
A well-defined scope sets expectations among the project stakeholders. It identifies the external interfaces between the system and the rest of the world. The scope definition helps the project manager assess the resources needed to implement the project and make realistic commitments. The scope statement defines the boundary of the project manager’s responsibilities.
Your scope definition also should include a list of specific limitations or exclusions—what’s out. Obviously, you can’t list everything that’s out of scope because that would include every detail in the universe except for the tiny sliver that is in scope for your project. Instead, the limitations should identify capabilities that a reader might expect to be included in the project, but which are not included. I know of a project to build a Web site for a national sports team that included the following exclusions for the initial release:
There will be no virtual or fantasy games via the Web.
There will be no ticketing facilities on the site.
There will be no betting facilities available.
The demographic details for newsletters will not be collected.
Message boards are out of scope for phase 1.
Some stakeholders involved with this project might have expected these capabilities to be included. Itemizing them as exclusions makes it clear that they won’t be. This is a form of expectation management, an important contributor to project success.
The venerable context diagram dates from the structured analysis revolution of the 1970s. Despite its antiquity, the context diagram remains a useful way to depict the environment in which a software system exists. Figure 1 illustrates a partial context diagram for a hypothetical corporate cafeteria ordering system. The context diagram shows the name of the system or product of interest in a circle. The circumference of the circle represents the system boundary. Rectangles outside the circle represent external entities, also called terminators. External entities could be user classes, actors, organizations, other software systems to which this one connects, or hardware devices that interface to the system.
The interfaces between the system and these external entities are shown with labeled arrows, called flows. If the “system” is strictly an electronic system involving software and perhaps hardware components, flows will represent data or control signals. However, if the “system” includes both a software application and manual operations, flows could also represent the movement of physical objects. Two-headed flows indicate update operations involving the data object on the flow.
The context diagram depicts the project scope at a high level of abstraction. This diagram deliberately reveals nothing about the system internals: no information about functionality, architecture, or look-and-feel. Nor does it explicitly identify which features or functionality are in scope and which are not. The functional behavior of the system is merely implied by the labeled flows that connect the system to the external entities. Even the flows are labeled at a high level of abstraction, just to keep the diagram’s complexity manageable.
Despite the limited view that the high level of abstraction imposes, the context diagram is a helpful representation of scope. It serves as a tool to help the project stakeholders communicate about what lies outside the system boundary.
Use cases are a powerful technique for exploring user requirements. The Unified Modeling Language (UML) includes a use case diagram notation. Figure 2 shows a partial use case diagramfor our cafeteria ordering system. The rectangular box represents the system boundary, analogous to the circle in a context diagram. The stick figures outside the box representactors, entities that reside outside the system’s context but interact with the system in some way. The actors correspond approximately (exactly, in this example) to the external entities shown in rectangles on the context diagram.
Unlike the context diagram, the use case diagram does provide some visibility into the system. Each oval inside the system boundary box represents a use case. The use case diagram shows the interactions of the system with its users and some connections between internal system operations, albeit at a high level of abstraction.
The arrows on the use case diagram indicate which actors participate in each use case. In Figure 2, the arrow from the Patron to the oval labeled “Submit Feedback” means that the patron actor can initiate the Submit Feedback use case. The arrow from Submit Feedback to the Menu Manager actor indicates that the Menu Manager participates somehow in the execution of Submit Feedback. Arrows on the use case diagram do not indicate data flows as they do on the context diagram. In addition to showing these connections to external actors, a use case diagram could depict logical relationships and dependencies between use cases.
The use case diagram provides a richer scope representation than the context diagram because it provides a high-level look at the system’s capabilities, not just at its external interfaces. There is a practical limitation, though. Any sizable software system will have dozens of use cases, with many connections among them and between use cases and actors. Attempting to show all those objects inside a single system boundary box quickly becomes unwieldy. Therefore, the analyst needs to model groups of related use cases as packages or to create multiple use case diagrams.
Many analysts have found the context diagram and use case diagram to be helpful ways to represent and communicate a shared understanding of a project’s scope. In Part 2 of this series, I’ll describe two other techniques for defining scope, feature levels and system events.
https://www.jamasoftware.com/media/2017/03/Project_Scope_Blog_Post.png5121024Jama Software/media/jama-logo-primary.svgJama Software2019-09-24 12:00:092023-01-12 16:51:24Defining Project Scope: Context and Use Case Diagrams
Developers often want to freeze software requirements following some initial work and then proceed with development, unencumbered by those pesky changes. This is the classic waterfall paradigm. It doesn’t work well in most situations. It’s far more realistic to define a requirements baseline and then manage changes to that baseline.
What is a Requirements Baseline?
A requirements baseline is asnapshot in time that represents an agreed-upon, reviewed, and approved set of requirements that have been committed to a specific product release.
That “release” could be a complete delivered product or any interim development increment of the product. When stakeholders “sign off” on requirements, what they’re really doing is agreeing and committing to a specific requirements baseline (whether they think of it in those terms or not).
Once the project team establishes a requirements baseline, the team should follow a pragmatic change control process to make good business and technical decisions about adding newly-requested functionality and altering or deleting existing requirements.
A change control process is not about stifling change; it’s about providing decision-makers with the information that will let them make timely and appropriate decisions to modify the planned functionality. That planned functionality is the baseline.
Typically, a baseline is also given a unique name so that all the project participants can refer to it unambiguously. And good configuration management practices allow the team to reconstruct accurately any previous baseline and all its components.
Implementing a Requirements Baseline
Whereas the scope definition distinguishes what’s in from what’s out, the requirements baseline explicitly identifies only those requirement specifications that the project will implement. A baseline is not a tangible item but rather a defined list of items. One possible storage location is a software requirements specification (SRS) document.
If that SRS document contains only—and all—the requirements for a specific product release, the SRS constitutes the requirements baseline for the release. However, the SRS document might include additional, lower-priority requirements that are intended for a later release.
Conversely, a large project might need several software, hardware, and interface requirement specifications to fully define the baseline’s components. The goal is to provide the project stakeholders with a clear understanding of exactly what is intended to go into the upcoming release.
Perhaps you’re storing your requirements in a requirements management solution, rather than in documents. In that case, you can define a baseline as a specific subset of the requirements stored in the database that are planned for a given release.
Storing requirements in a solution allows you to maintain an aggregated set of both currently committed requirements and planned future requirements. Some commercial requirements management tools include a baselining function to distinguish those requirements (perhaps even down to the specific version of each requirement) that belong to a certain baseline.
Alternatively, you could define a requirement attribute in the solution to hold the release number or another baseline identifier. Moving a requirement from one baseline to another is then a simple matter of changing the value for that requirement attribute.
The attribute approach will work when each requirement belongs to only a single baseline. However, you might well allocate the same requirement (or different versions of the same requirement) to several baselines if you’re concurrently developing multiple versions of your product, such as home and professional versions. Tool support is essential for such complex baseline management.
When following an incremental or iterative development life cycle, the baseline for each iteration will represent just a fraction of the overall system’s functionality.
A small project my team once worked on took this approach. This project worked in three-week release cycles. For each cycle, the BA specified the software requirements that were to be designed, coded, integrated, and verified during the next three weeks. Each requirements baseline was therefore quite small. In a classic agile approach, the product grew incrementally toward full functionality as the developer periodically released useful versions to the users.
Business analysts sometimes struggle with exactly when to define a requirements baseline. It’s an important decision because establishing the baseline has the following implications:
Formal change control begins. Change requests are made against an established baseline. The baseline. therefore, provides the point of reference for each proposed change. Make sure your change control process and players are in place before you define any project baselines.
Project managers determine the staffing levels and budgets needed. There are five dimensions to a software project that must be managed: features, quality, schedule, staff, and budget. Once the features and quality goals are defined in the baseline, the project manager adjusts the other three dimensions to accomplish the project’s objectives. It can work the other way, too. If staff, budget, and/or schedule are pre-established by external forces, the baseline composition is necessarily constrained to fit inside the project box bounded by those limits.
Project managers make schedule commitments. Prior to baselining, requirements are still volatile and uncertain, so estimates are similarly volatile and uncertain. Once a baseline is established, the contents of the release should be sufficiently well understood so that managers can make realistically achievable commitments. The managers still need to anticipate requirements’ growth (per their requirements management plan) by including sensible contingency buffers in their committed schedules.
Baselining requirements too early can push your change process into overdrive. In fact, receiving a storm of change requests after defining a baseline could be a clue that your requirements elicitation activities were incomplete and perhaps ineffective. On the other hand, waiting too long to establish a baseline could be a sign of analysis paralysis: perhaps the BA is trying too hard to perfect the set of requirements before handing them to the development team.
Keep in mind that requirements elicitation attempts to define a set of requirements that is good enough to let the team proceed with construction at an acceptable level of risk. Use the checklist in Table 1 to judge when you’re ready to define a requirements baseline as a solid foundation for continuing the development effort.
Table 1. Factors to Consider Before Defining a Requirements Baseline
Business Rules
Determine whether you’ve identified the business rules that affect the system and whether you’ve specified functionality to enforce or comply with those rules.
Change Control
Make sure a practical change control process is in place for dealing with requirement changes and that the change control board is assembled and chartered. Ensure that the change control tool you plan to use is in place and configured and that the tool users have been trained.
Customer
Perspective
Check back with your key customer representatives to see whether their needs have changed since you last spoke. Have new business rules come into play? Have existing rules been modified? Have priorities changed? Have new customers with different needs been identified?
Interfaces
See if functionality has been defined to handle all identified external interfaces to users, other software systems, hardware components, and communications services.
Model Validation
Examine any analysis models with the user representatives, perhaps by walking through test cases, to see if a system based on those models would let the users perform their necessary activities.
Prototypes
If you created any prototypes, did appropriate customers evaluate them? Did the BA use the knowledge gained to revise the SRS?
Alignment
Check to see if the defined set of requirements would likely achieve the project’s business objectives. Look for alignment between the business requirements, user requirements, and functional requirements.
Reviews
Have several downstream consumers of the requirements review them. These consumers include designers, programmers, testers, documentation and help writers, human factors specialists, and anyone else who will base their own work on the requirements.
Scope
Confirm that all requirements being considered for the baseline are within the project scope as it is currently defined. The scope might have changed since it was originally defined early in the project.
TBDs
Scan the documents for TBDs (details yet to be determined). The TBDs represent requirements development work remaining to be done.
Templates
Make sure that each section of the SRS document template has been populated. Alternatively, look for an indication that certain sections do not apply to this project. Common oversights are quality requirements, constraints, and assumptions.
User Classes
See whether you’ve received input from appropriate representatives of all the user classes you’ve identified for the product.
Verifiability
Determine how you would judge whether each requirement was properly implemented. User acceptance criteria are helpful for this.
You’re never going to get perfect, complete requirements. The BA and project manager must judge whether the requirements are converging toward a product description that will satisfy some defined portion of customer needs and is achievable within the known project constraints.
Establishing a baseline at that point establishes a mutual agreement and expectation among the project stakeholders regarding the product they’re going to have when they’re done. Without such an agreed-upon baseline, there’s a good chance someone will be surprised by the outcome of the project.
And software surprises are rarely good news.
To learn more about how to write requirements in a way that all stakeholders have a clear understanding of development needs, download our eBook, Best Practices for Writing Requirements.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at ProcessImpact.com.
https://www.jamasoftware.com/media/2019/06/defining-and-implementing-requirements-baselines_1024x512-1.jpg5121024Karl Wiegers/media/jama-logo-primary.svgKarl Wiegers2019-06-18 04:00:522023-01-12 16:51:36Defining and Implementing Requirements Baselines
At a conference I attended recently, I listened to teamsdiscuss the challenges they faced in deploying software in their organizations. The consensus was thatthe software is easy; the people are hard.That is to say, getting up to speed with a newsoftware solution itself is relatively easy compared to getting people to change their behaviorand successfully adopt new software.
ROIRequires that TeamsActually Use the Solution
One of the speakers said something that really stuck with me. This personsaid, “There is no return on investment without adoption, and there is no adoption without user acceptance.” And while that may seem obvious, many times the end user of the software is forgotten. Other priorities — like budget, schedule, and various agendas —put a lot of pressure on the deployment plan. The human aspect, as important as it is, gets lost.
Gaining Acceptance Later in the Implementation Will Cost You
When implementing a new solution, it’s imperativethat you get your team on board from the get-go – and not just for the purpose of keeping them happy. Just as it’s more costly to identify inaccurate requirements late in the product delivery lifecycle, the same principle holds true for user acceptance. Resistance from users identified late is always going to be more costly than adoption issuesidentified and addressed early.
While implementing a new solution may be a top–down decision, it’s important to remember that the users are the ones who will need to adapt to the change. The primary impacted stakeholders (i.e. the end–users) will be more receptive to a major change if they are participating in the process, rather than being told that they must adopt a new tool.
Change is difficult, and without a full understanding of the benefits ofa new solution, teams may feel frustrated or resistant. One way to preemptively combat resistance is by identifying long- and short-term goals for each team member and encouraging users to be involved in the implementation process.
The Key to User Adoption is People
Having worked in professional services for over a decade, I have come to see just how valuable it is to understand the people side of deployments. In my years as a business analyst, I’ve seen from the inside just how difficult it can be to get people on board with new solutions, particularly those that also come with process changes, and how to make those changes stick.
My interest in this topic goes even deeper. A few years ago, I completed a master’s program in psychologywhere I studied human behavior and why people do or do not change. I’ve found that what I learned during my study of psychology has translated quite well to the consulting world.
In this post I won’t be able to outline the perfect adoption plan for your organization; this would be futile as no two companies have the same needs or challenges. But I will discuss the approach we recommend when planning for a solution rollout that maximizes adoption.
If You’re Taking a Trip, Bring the Whole Team Along
I’m going to start with an analogy:
Let’s say you’ve pretty much determined that everyone on your team could benefit from a vacation. You’ve even heard people say so. You’ve had some good conversations about what people want and need, and with that knowledge you pick out a destination that’s going to recharge everyone.
Next, you have to figure out what kind of transportation you’re going to use to get everyone to the identified location. You’ve gone online and talked to some others about what kind of vehicle works best for teams like yours.
So, with the information you have, you go ahead and buy the perfect car for this trip. It has all the things you need.
In case you haven’t figured out how the pieces of my analogy fit into the rollout of a new solution, here it is:
The people are those who would benefit from a new process and solution to meet their business objectives
The “destination” is that ultimate goal, where the benefits are realized
The “car” is the newsoftware solution that gets you to that ultimate goal
But here’s something you have to consider before you embark on this journey: You have to figure out where everyone lives, what kind of baggage they’re bringing with them, and how you’re going to organize picking them all up so you can all be in the car at the same time, happily enjoying the journey to your destination. More on that in a bit.
Key Factors in Planning a Successful Software Deployment
If you’ve ever actually planned an out-of-town experience with coworkers (or family, for that matter), you know it’s impossible to make everyone happy all the time. Introducinga new way of working to your teams can be even more difficult. Why?
Before I answer that, remember that these are the main things to keep top-of-mind when planning a successful deployment:
Bringing new teams into a new solution, with new processes, is not simply a functional or technical issue;it is a people-centric change.
Benefits that require that people adopt the solution inherently require that those people change behavior.
The longer adoption problems go unaddressed the more difficultand expensivethey are to address.
New data for 2019 revealsthe growing gap between product complexity and requirements management. Find out more by downloading our report.
Design Your Approach Based on the Specific Needs of Your Team
Change is hard – especially when people are involved. You can put up your pie chart or line graph with anticipated benefits and have everyone nodding their heads in agreement, and you can find the perfect “car” to get you there.But you cannot assume that pointing at that amazing vacation spot on a map or showing off your awesome new vehiclewill translate to motivation and acceptance for the people whomust be on board in the end.
Of course, some will be on board immediately, so make sure you identify those people and train them to evangelize for the effort. Theseadvocates are a great asset as you complete your rollout to the rest of the organization. Successful organizations often pair these early adopters with new users to help them get up to speed with the new process.
Others may need more attention, and youmust pay careful attention to their fears and objections and speak to them early and often.
Consider the Delta Between Where Your Team is Today and Where You Want to Be
You must considerthe maturity of your organization and teams. Of course, it doesn’t have anything to do with the emotional maturity of the individuals (though that could come into play), but the maturity of theirprocesses and toolset and how they’re accustomed to getting their work done today. In my experience as a consultant, I find that team maturity ranges widely, especially when it comes to requirements management processes and supportingtools.
Knowing where teamsare — or theirlevel of maturity — is important for a number of reasons, not least of which is anticipating resistance. Think about the person who is currently using a Word doc that they keep somewhere on their laptop to manage the requirements for a really complex product. This might be considered a pretty basic level of maturity.
Now, before bringing this person into a new solution, it is important to think about the degree of change being asked of this person. What does a single-source collaborative system feel like to a person coming from Word files on their computer? What resistance can you anticipate and what will be your approach? Again, communication early and often is going to be key to getting this person on board with a new solution.
When change is introduced, the initial reaction from most is to resist. This isn’t necessarily a bad thing, as not all change is good. But if you don’t address resistance, it can lead to rigidity, causing teams to dig their heels in and get stuck.
When you are bringing on a new team into your deployment effort, don’t just set up training on how to usethe tool. You’ll want to engage with your peopleat a personal level so you can uncovertheir anxieties and address them. You’ll need to anticipate their questions and welcome their concerns. When you know their concerns, you can address them; it’s the concerns you don’t know about that can manifest very late and cause problems for the whole deployment.
For example: Consider a person who has yet to log into the software even a month after deployment. What did we not know about this person that let them slip through the cracks? A quick way to find out is to simply ask them.
Remember that unanswered questions today turn into resistance tomorrow. Provide opportunities for people to voice their questions early so you can address them. Consider establishing clear channels for communication with users.
Adopt a Change Management Model to Give Your Project Structure
There are many change management models out there, and I recommend researching these until you find one that make sense for the size of your company, itsculture, and your strategic goals. I personally like the ADKAR model from Prosci.
The five parts of this specific change management model fit well with how we’ve been discussing bringing on teams to improve adoption:
Awareness of the need for change.
Desire to participate and support the change.
Knowledge on how to change.
Ability to implement required skills and behaviors.
Reinforcement to sustain the change.
We’ve also seen great success from teams who have read this book: “Change Management: The People Side of Change,” by Jeffrey M. Hiatt and Timothy J. Creasey.
A good change management model, like ADKAR, will help you consider the approach you want to take as you get started on your deployment plan. You’ll want to think about:
How you will build awareness, not just of new processes and solutions, but also why you’re taking on this initiative and what you hope it will do for your organization.
How you will communicate the benefits of using the solution, particularly the “what’s in it for me” for each individual or each team.
How you will build knowledge about how the solution works, relative to the current tool, and how to get the most of it.
How will you ensure people gain the ability to use the solution with the proper training for their position, in a style that will help them feel empowered and not burdened through the learning curve.
What kind of reinforcements you can use to ensure that the process change sticks and the initiative’s objectives are met.
These are just a few examples of how to use the ADKAR modelbut the key is to engage with this line of thinking early and be open to adjusting as you learn more.
https://www.jamasoftware.com/media/2015/10/Elucent.png5121024Zeb Geary/media/jama-logo-primary.svgZeb Geary2019-04-11 10:00:132024-09-26 13:10:06Why Your Rollout Strategy Must Put People First
As Karl Wiegers accurately states in his paper on writing better requirements, “quality is in the eye of the reader … No matter how fine the author thinks the requirements are, the ultimate arbiters are those who must base their own work on those requirements.”
Avoiding ambiguity when writing requirements is essential to building the product you want built. In our recent post, “Five Ways Ambiguous Language Will Ruin Your Requirements,” we shared examples of ambiguity in requirements writing and gave expert tips to help clarify.
Here are four more sources of ambiguity, plus additional best practices to save your requirements — and your product.
Negative Requirements
Negative or inverse requirements create a lot of unnecessary ambiguity. Positive requirements in active voice are much easier to understand. Here are some before and after examples of increased clarity when moving from negative to positive.
Abbreviations i.e. and e.g.
Some readers might misconstrue the use of i.e. and e.g. The abbreviation i.e. stands for the Latin phrase id est, which means “that is.” The abbreviation e.g. stands for the Latin phrase exempli gratia, which means “for example.”
These two abbreviations are so commonly confused — either on the part of the writer or the reader — that they are best avoided altogether in favor of explicitly saying what you mean.
A/B Construct
Some requirements writers use the A/B construct, as in, “data should be recorded in an audit/history table.” This construct is rarely used in formal writing because it is so vague it could be interpreted in a variety of ways. Some examples include:
A is the same as B. In this case, they are synonyms and you should stick to one term consistently.
Both A and B. In this case, use the explicit conjunction “and.”
A or B. In this case, use the explicit conjunction “or.”
Adverbs
Words that end in -ly often are ambiguous. They might describe some desirable property of the product, but exactly what is desired is left to each reader’s interpretation. Here are a few examples:
“Allows the user to edit his interests and possibly search results …” Should the user be able edit the search results or not?
“Optimize upload and download to perform quickly.” Is five seconds considered quick?
“Offer significantly better download times.” State exactly how much better or give a range for precisely what the download time should be.
“Subscribers who are changing content selection (effectively a subset of the currently subscribed subscribers) …” Are they a subset or not?
“Exposing information appropriately …” What’s considered appropriate?
Be specific when describing the intended product’s characteristics so all readers share a common vision of the desired result when they’re done.
https://www.jamasoftware.com/media/2018/03/Header-Image_-Blog-Post-38.png573856Jama Software/media/jama-logo-primary.svgJama Software2018-03-19 09:21:282023-01-12 16:53:13How to Avoid Ambiguity and Save Your Requirements
When a requirement can be interpreted in more than one way, problems ensue. In his paper, “Writing High-Quality Requirements,” expert Karl Wiegers gives examples of ambiguity issues in requirements and best practices to successfully clarify them. Here are five sources of ambiguity and tips to overcome.
Complex Logic
Boolean logic offers many opportunities for ambiguities and missing requirements. Try using a decision tree to reveal gaps and ensure clarity.
Omissions
When requirements lack important pieces of information, it’s unlikely that all readers will interpret them in the same way unless they make precisely the same assumptions. Be sure to include trigger causes that lead to the behavior and indicate what is required to happen because of or after the behavior. Further, specify the action as well as the reverse operation as part of the requirement. For example:
“The system shall display the user’s defined bookmarks in a collapsible hierarchical tree structure.”
Changes to:
“The system shall display the user’s defined bookmarks in a collapsible and expandable hierarchical tree structure.”
Boundaries
Boundary values in numerical ranges are common sources of ambiguity, and they are a good place to look for missing requirements. One easy way to resolve boundary confusion is to show the information in a table. If you see a number represented in two ranges, you know something needs fixing. Conversely, if there is no value in one of the table’s cells, you can quickly identify the missing requirement.
Synonyms
Using synonyms to describe the same thing across different requirements unnecessarily introduces ambiguity. Will the reader automatically know you mean the same thing or might they assume them to be different? If they are truly identical, use the same word consistently. If there are differences, even subtle ones, place such definitions in a shared glossary so team members understand the terms and use them consistently.
Pronouns
Pronouns can be a source of headaches in a requirements specification. Be certain that the antecedent is crystal clear whenever you employ a pronoun. If you use a word such as this or that, there should be no confusion in the reader’s mind about what you’re referring to.
Learn more requirements best practices from expert Karl Wiegers. In his paper, “Writing High-Quality Requirements,” he explains they begin with proper grammar, well-constructed sentences and a logical organization.
https://www.jamasoftware.com/media/2018/03/Header-Image_-Blog-Post-37.png573856Jama Software/media/jama-logo-primary.svgJama Software2018-03-07 09:14:162023-01-12 16:53:14Five Ways Ambiguous Language Will Ruin Your Requirements
In today’s hyper-competitive marketplace, companies are releasing products faster than ever before. However, that increased emphasis on time to market doesn’t change the expectations: producing quality products while, when necessary, conforming to all relevant safety and quality standards.
Finding that critical balance between speed and quality is essential for product teams, which is where requirements management comes into play. Unfortunately, a lot of teams don’t take the time to flesh out requirement details – or they have the opposite problem and provide too many details, and confuse requirements with design specifications. Here are some examples and recommendations to make sure you’re getting the most value from your requirements.
Scenario 1: I need more details!
In this situation, teams fall into a trap of not taking the time to define requirements. For example, a marketing team — which tend to think more strategically — will often give high-level problem statements directly to an engineering team, which typically thrive on details.
What happens next is either:
Engineering team builds a product that doesn’t solve the high-level problem
or
Engineering team will bombard the marketing team with requests for additional information until both sides are frustrated and late on delivery
Neither scenario results in a smooth development process, and both can breed mistrust between teams whose ultimate goal is the same, in spite of their differing roles.
Well-formed and reviewed requirements clear the path for a quality product that meets market needs and expectations.
They ensure each team member is on the same page, and that everyone involved knows exactly what they’re building and why.
Scenario 2: Too many details – I can’t innovate!
In this case, the team members responsible for authoring requirements can sometimes cram too many design details into the requirements themselves. For example, I once saw a requirement that read: “the button shall be red and shall be located in the top-right corner of the console.”
First off, that’s actually two requirement statements – but either way – it’s describing implementation detail and, taken on it’s own, I have no idea of “what” the button should do or “why.” Is this supposed to dispense a soda from a vending machine or fire a missile from a battleship?!?
Requirements like these create friction within engineering teams, limiting their ability to innovate while getting bogged down with overly specific instructions.
Engineering teams should ideally be free to iterate and innovate the design rather than simply doing what they’re told. The requirements should focus on the need and keep teams aligned on “what” is needed and “why” while engineering experts figure out “how” to implement.
Recommendation: Establish a Common Taxonomy and Trace Model
An important step in striking the right level of detail in your requirements is establishing common terms in your product development process.
Many teams use different terms to refer to the same thing (e.g. “specification” – this term means so many different things across different teams).
Having a glossary or standard that clearly delineates important terms and deliverables facilitates clarity throughout the development process and reduces the confusion referenced above.
Using a traceability model establishes appropriate hierarchy and helps break down high-level problems to detailed requirement needs. It also can facilitate test coverage of requirements. This clarity is especially important when dealing with life-critical systems, such as medical devices or autonomous vehicle systems. In these cases, missing requirements or inadequate design and testing can quite literally cost lives.
Finally, teams should be able to differentiate Requirements from Design. In other words, the “Need” vs the “How.” Bundling both together inside requirements can lead to added complexity, unnecessarily constrained design, and friction between teams.
Quickly bringing a quality, safe product to market is a challenge. Requirements and design are both key elements to doing so. Making sure teams strike the right level of detail in the requirements is critical in avoiding confusion and reducing friction in the process.
For a deeper dive on separating requirements and design specifications, check our this webinar, “Best Practices for Writing Requirements.” Jama also offers Requirements 101 workshops – please inquire if you’re interested in improving the requirements process in your organization!
https://www.jamasoftware.com/media/2018/02/Header-Image_-Blog-Post-25.png573856Preston Mitchell/media/jama-logo-primary.svgPreston Mitchell2018-02-06 08:36:412023-01-12 16:53:18Striking the Right Level of Detail in Requirements
The next time you feel like your professional life has gotten too complicated, get some face time with a seasoned Quality Assurance pro. The job? Easy stuff such as exposing the production flaws in embedded systems, integrated systems and connected devices.
What seems like a negative focus requires positive determination to straddle the line between the ideal and the real. Terminology that would terrify mere mortals such as “safety-critical,” “guaranteed compliance” and “life-and-economy critical” govern every QA action. Once the benchmark is set, QA is the muscle and willpower that keeps it in place.
And when your job is ensuring that only high-quality products make it to market, unwavering commitment to QA principles is required because your work is so demanding:
Tall tasks:
Trying to guarantee consistent product quality by developing, validating and enforcing reliable automated testing practices.
Pressure points:
Lacking visibility into changing requirements.
Lacking appropriate, comprehensive test coverage.
Struggling to capture and track all related defects.
Being the last to know when obstacles arise.
Burning desires:
To establish a clear workflow of requirements, be able to understand impacts when requirements change, and to ultimately ensure proper and meaningful test coverage.
With Jama, Quality Assurance Leads can turn wayward “Lost in Space” episodes into navigable “Star Trek” epics.
How so? You’re able to…
Speed up the test planning process.
Enable and ensure dependable test coverage for all requirements and defects.
Create and execute test cases using one platform.
Capture and track all related defects using one platform.
Easily integrate Jama with defect tracking and test automation tools you’re already using.
Communicate easily with the entire project team to get clarification on questions asked and decisions made, regardless of location.
/media/jama-logo-primary.svg00Marc Oppy/media/jama-logo-primary.svgMarc Oppy2015-07-02 11:51:082023-01-12 16:55:51It’s a Tough Job but Someone’s Gotta Do It, Pt. IV. How Jama Helps QA Leads
In the first part of this two-part series I described the value of managing risks formally on a software project and listed numerous common risks in various categories. This article describes the various activities associated with the practice of risk management and recommends specific information you should record about each risk you identify.
Risk Management Components
As with other project activities, begin risk management by developing a plan, perhaps using the risk management plan template available at www.ProjectInitiation.com. Small projects can include a concise risk management plan as a section within the overall project plan. Risk management consists of the activities illustrated in Figure 1 and described below.
Risk Assessment
Risk assessment is the process of examining a project to identify areas of potential risk. Risk identification can be facilitated with the help of a checklist of common risk areas for software projects, as I described in the first article in this series. Risk analysis examines how project outcomes might change with modification of risk input variables. In other words, just how could the risk harm your project.
Figure 2: Risk exposure is a function of probability and potential loss.
Risk prioritization helps the project focus on its most severe risks by assessing the risk exposure. Exposure is the product of the probability of incurring a loss due to the risk and the potential magnitude of that loss. I usually estimate the probability from 0.1 (highly unlikely) to 1.0 (certain to happen), and the loss (also called impact) on a relative scale of 1 (no problem) to 10 (deep tapioca). Multiplying these factors together provides an estimate of the risk exposure due to each item, which can run from 0.1 (don’t give it another thought) through 10 (stand back, here it comes!). It’s simpler to estimate both probability and loss as High, Medium, or Low. Figure 2 shows how you can estimate the risk exposure level as High, Medium, or Low by combining the probability and loss estimates.
Risk Avoidance
Risk avoidance is one way to deal with a risk: don’t do the risky thing! You might avoid risks by not undertaking certain projects, or by relying on proven rather than cutting-edge technologies when possible. You might be able to transfer a risk to some other party, such as a subcontractor.
Risk Control
Risk control is the process of managing risks to achieve the desired outcomes. Risk management planning produces a plan for dealing with each significant risk, including mitigation approaches, owners, and timelines. Risk resolution entailsexecuting the plans for dealing with each risk. That’s when you actually control the risk. Finally, risk monitoring involves tracking your progress toward resolving each risk item.
Let’s look at an example of risk management planning. Suppose the “project” is to take a hike through a swamp in a nature preserve. You’ve heard the swamp might contain quicksand, so the risk is that we might step in quicksand and be injured or even die. One strategy to mitigate this risk is to reduce the probability of the risk actually becoming a problem. A second option is to consider actions that could reduce the impact of the risk if it does in fact become a problem. So, to reduce the probability of stepping in the quicksand, we might look for signs of quicksand as we walk and draw a map so we can avoid these areas on future walks. To reduce the impact if someone does step in quicksand, the members of the tour group could rope themselves together. That way if someone does encounter some quicksand the others could quickly pull him to safety.
Even better, is there some way to prevent the risk from becoming a problem under any circumstances? Maybe we build a boardwalk as we go so we avoid the quicksand. That will slow us down and cost some money. But, we don’t have to worry about quicksand any more. The very best strategy is to eliminate the root cause of the risk entirely. Perhaps we should drain the swamp, but then it wouldn’t be a very interesting nature walk. By taking too aggressive a risk approach, you can eliminate the factors that make a project attractive in the first place.
Documenting Risks
Simply identifying the risks facing a project is not enough. We need to write them down in a way that lets us communicate the nature and status of risks throughout the affected stakeholder community over the duration of the project. Figure 3 shows a form I’ve found to be convenient for documenting risks. It’s a good idea to keep the risk list itself separate from the risk management plan, as you’ll be updating the risk list frequently throughout the project. You can download an alternative template for your risk list from www.ProjectInitiation.com. This format includes essentially the same information that’s in Figure 3, but it’s laid out in a way that’s amenable to storing in a spreadsheet or as a table in a word-processing document.
ID:<sequence number or a more meaningful label>
Description: <List each major risk facing the project. Describe each risk in the form “condition – consequence.”>
Probability: <What’s the likelihood of this risk becoming a problem?>
Loss: <What’s the damage if the risk does become a problem?>
Exposure: <Multiply Probability times Loss.>
First Indicator:<Describe the earliest indicator or trigger condition that might indicate that the risk is turning into a problem.>
Mitigation Approaches:<State one or more approaches to control, avoid, minimize, or otherwise mitigate the risk.>
Owner:<Assign each risk mitigation action to an individual for resolution.>
Date Due: <State a date by which the mitigation approach is to be implemented.>
Figure 3: A risk documentation form.
Use a condition–consequence format when documenting risk statements. That is, state the risk situation (the condition) that you are concerned about, followed by at least one potential adverse outcome (the consequence) if that risk should turn into a problem. Often, people suggesting risks state only the condition—“The customers don’t agree on the product requirements”—or the consequence—“We can only satisfy one of our major customers.” Pull those together into the condition-consequence structure: “The customers don’t agree on the product requirements, so we’ll only be able to satisfy one of our major customers.” This statement doesn’t describe a certain future, just a possible outcome that could harm the project if the condition isn’t addressed.
Keep the items with high risk exposures at the top of your priority list to focus your risk-control energy. Set goals for determining when each risk item has been satisfactorily controlled. Your mitigation approaches for some items may focus on reducing the probability, whereas the approach for other risks could emphasize reducing the potential loss or impact. With any luck, some of your mitigation strategies will help you control multiple risk factors.
Risk Tracking
As with other project management activities, you need to get into a rhythm of periodic monitoring. You may wish to appoint a risk manager for the project. The risk manager is responsible for staying on top of the things that could go wrong, just as the project manager stays on top of the activities leading to project completion. It’s a good idea to have someone other than the project manager serve as the risk manager. The project manager is focused on what he has to do to make a project succeed. The risk manager, in contrast, is identifying factors that might prevent the project from succeeding. In other words, the risk manager is looking for the black cloud around the silver lining that the project manager sees. Asking the same person to take these two opposing views of the project can lead to cognitive dissonance; in an extreme case, his brain can explode.
Keep the top ten risks highly visible and track the effectiveness of your mitigation approaches regularly. New risks might float up into the top ten as you gradually beat the initial list of top priority items into submission. You can drop a risk off your radar when your mitigation approaches have reduced the risk exposure from that item to an acceptable level. Don’t conclude that a risk is controlled simply because the selected mitigation action has been completed. Controlling a risk might require you to change the risk control strategy if you conclude it isn’t working.
A student in a seminar once asked, “What should you do if you have the same top five risks week after week?” A static risk list suggests that your risk mitigation actions aren’t working. Effective mitigation actions should lower the risk exposure as the probability, the loss, or both decrease over time. If your risk list isn’t changing, check to see whether the planned mitigation actions have been carried out and whether they had the desired effect.
Also, look for new risks that might arise during the course of the project. Conditions can change, assumptions can prove to be wrong, and other factors might lead to risks that weren’t apparent or perhaps did not even exist at the beginning of the project. Escalate risks that aren’t being controlled to the attention of senior managers or other stakeholders. They can then either stimulate corrective actions or else make a conscious business decision to proceed in spite of the risks.
Learning from the Past
We can’t predict exactly which of the many threats to our projects might come to pass. However, most of us can do a better job of learning from previous experiences to avoid the same pain and suffering on future projects. As you begin to implement risk management approaches, record your actions and results for future reference. The risks are out there. Find them before they find you.
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 Wiegers2014-04-02 17:36:572023-01-12 16:56:06Knowing Your Enemy: Risk Management Part 2
In part one and part two of this series, adapted from my book Practical Project Initiation, I’ve described fifteen practices the project manager can apply to lay the foundation for a successful project, plan the project, and estimate the work to be done. In this final article I share two additional estimation practices, three good practices for tracking your progress throughout the project, and one practice for learning how to execute your future projects more successfully.
Estimating the Work (continued)
Practice #16: Use estimation tools. Many commercial tools are available to help project managers estimate entire projects. Based on equations derived from large databases of actual project experience, these tools can give you a spectrum of possible schedule and staff allocation options. They’ll also help you avoid the “impossible region,” combinations of product size, effort, and schedule where no known project has been successful. The tools incorporate a number of “cost drivers” you can adjust to make the tool more accurately model your project, based on the technologies used, the team’s experience, and other factors. You can compare the estimates from the tools with the bottom-up estimates generated from a work breakdown structure. Reconcile any major disconnects so you can generate the most realistic overall estimate.
Practice #17: Plan contingency buffers. Projects never go precisely as planned. The prudent project manager incorporates budget and schedule contingency buffers at the end of phases, dependent task sequences, or iterations to accommodate the unforeseen. Use your project risk analysis to estimate the possible schedule impact if several of the risks materialize, then build that projected risk exposure into your schedule as a contingency buffer. An even more sophisticated approach is critical chain analysis, a technique that pools the uncertainties in estimates and risks into a rational overall contingency buffer. Chapter 10 of Practical Project Initiation is all about contingency buffers.
Your manager or customer might view these contingency buffers as padding, rather than as the sensible acknowledgment of reality that they are. To help persuade skeptics, point to unpleasant surprises on previous projects as a rationale for your foresight. If a manager elects to discard contingency buffers, he has tacitly absorbed all the risks that fed into the buffer and assumed that all estimates are perfect, no scope growth will occur, and no unexpected events will take place. Sound realistic to you? Of course not. I’d rather see us deal with reality—however unattractive—than to live in Fantasyland.
Tracking Your Progress
Practice #18: Record actuals and estimates. Unless you record the actual effort or time spent on each project task and compare them to the estimates, your estimates will forever remain guesses. Someone once asked me where to get historical data to improve her ability to estimate future work. My answer was, “If you write down what actually happened today, that becomes historical data tomorrow.” It’s really not more complicated than that. Each individual can begin recording estimates and actuals, and the project manager should track these important data items on a project task or milestone basis. In addition to effort and schedule, you could estimate and track the size of the product, in terms of requirements, user stories, lines of code, function points, GUI screens, or other units that make sense for your project.
Practice #19: Count tasks as complete only when they’re one hundred percent complete. We give ourselves a lot of partial credit for tasks we’ve begun but not yet fully completed: “I thought about the algorithm for that module in the shower this morning, and the algorithm is the hard part, so I’m probably about sixty percent done.” It’s difficult to accurately assess what fraction of a sizable task has actually been finished at a given moment.
One benefit of using inch-pebbles (see Practice #6 in Part 2 of this series) for task planning is that you can break a large activity into a number of small tasks (inch-pebbles) and classify each small task as either done or not done—nothing in between. Project status tracking is then based on the fraction of the tasks that are completed and their size, not the percentage completion of each task. If someone asks you whether a specific task is complete and your reply is, “It’s all done except…,” then it’s not done! Don’t let people “round up” their task completion status. Instead, use explicit criteria to determine whether an activity truly is completed.
Practice #20: Track project status openly and honestly. An old riddle asks, “How does a software project become six months late?” The rueful answer is, “One day at a time.” The painful problems arise when the project manager doesn’t know just how far behind (or, occasionally, ahead) of plan the project really is. Surprise, surprise, surprise.
If you’re the PM, create a climate in which team members feel it is safe for them to report project status accurately. Run the project from a foundation of accurate, data-based facts, rather than from the misleading optimism that can arise from the fear of reporting bad news. Use project status information and metrics data to take corrective actions when necessary and to celebrate when you can. You can only manage a project effectively when you really know what’s done and what isn’t, what tasks are falling behind their estimates and why, and what problems, issues, and risks remain to be tackled.
The five major areas of software measurement are size, effort, time, quality, and status. It’s a good idea to define a few metrics in each of these categories. Instilling a measurement culture into an organization is not trivial. Some people resent having to collect data about the work they do, often because they’re afraid of how managers might use the measurements. The cardinal rule of software metrics is that management must never use the data collected to either reward or punish the individuals who did the work. The first time you do this will be the last time you can count on getting accurate data from the team members.
Learning for the Future
Practice #21: Conduct project retrospectives. Retrospectives (also called postmortems and post-project reviews) provide an opportunity for the team to reflect on how the last project, phase, or iteration went and to capture lessons learned that will help enhance your future performance. During such a review, identify the things that went well, so you can create an environment that enables you to repeat those success contributors. Also look for things that didn’t go so well, so you can change your approaches and prevent those problems in the future. In addition, think of events that surprised you. These might be risk factors to look for on the next project. Finally, ask yourself what you still don’t understand about the project, so you can try to learn how to execute future work better.
It’s important to conduct retrospectives in a constructive and honest atmosphere. Don’t make them an opportunity to assign blame for previous problems. Chapter 15 of Practical Project Initiation describes the project retrospective process and provides a worksheet to help you plan your next retrospective. It’s a good idea to capture the lessons learned from each retrospective exploration and share them with the entire team and organization. This is a way to help all team members, present and future, benefit from your experience.
The twenty-one project management best practices I’ve described in this series of articles won’t guarantee your project a great outcome. They will, however, help you get a solid handle on your project and ensure that you’re doing all you can to make it succeed in an unpredictable world.
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 Wiegers2014-03-20 20:20:372023-01-12 16:56:08Project Management Best Practices: Estimating Work and Tracking Progress
