Categories
Design Requirements Testing Workflow

The Good, the Bad, and the Ugly in software and system testing

This article was written by Bartosz (Bart) Chrabski of SmarterProcess – with some minor contributions from yours truly.

You may remember an old western movie titled The Good, the Bad and the Ugly starring Clint Eastwood. Testing can sometimes feel the same way.

Imran Hashmi Canadian Hub for Requirements Management

In today’s dynamic product development arena requirements keep changing and evolving. There is a relationship between three dimensions – namely cost, quality and time.

Ideally, we would have sufficient budget, time, and – product teams would be able to implement a high-quality product. In practice, it’s rarely the case that projects have enough budget and time. Often projects run over budget and experience time constraints. As a result, testing efforts are rushed and the quality of the product suffers.

Verification and validation of products – software and hardware – are some of the most critical steps in the development process and typically consume 30% to 35% or more of the total cost and effort in most projects.

Testing is often the least planned part of the development lifecycle. This lack of rigor can lead to the delivery of lower quality products and applications, which have a negative impact on customer satisfaction.

This article outlines some of the most common challenges encountered in testing efforts and presents several recommended practices. These practices will improve the efficiency and accuracy of your testing processes.

Problems resulting from poor testing processes have many different sources, often from poor planning or execution of testing tasks.

Below are some of the causes we have observed in real world projects.

• Lack of an independent test team
Most small project teams do not have an independent test team. The people who act as testers are at the same time developers, engineers, or analysts – often focused on other responsibilities, which may lead to incomplete or ineffective testing. Depending upon your industry, regulations may require a separate dedicated testing team.

• Limited understanding of the testing process
In small projects, often a project manager also acts as a test manager and may lack of appropriate knowledge and skill to plan and execute test activities – and their responsibilities of the two roles may conflict.

• Poor test planning
Planning the testing process is rarely perfect – testing is often only done to the extent that time is available. Sometimes testing is like an exorcism designed to get rid of evil spirits in a project. Often the person responsible for planning the testing may not be familiar with the testing process and may miss important steps.

• Lack of qualified resources
It can be difficult to find staff with the motivation and skills to do the testing. Since locating the appropriate skills can be challenging, positions are often filled with inexperienced testers, which may lead to incomplete or ineffective testing.

• No test data (no data-driven testing)
In our experience clients often underestimate the importance of good test data. Frequently, test data does not cover all possible conditions occurring in the application. In some cases, no test data is delivered at all. The result is that not all scenarios will be tested, which leads to quality issues.

• Lackluster test environment or product configuration
Some practitioners involved in testing underestimate the importance of getting the test environment and its configuration set up correctly. It’s standard practice to treat development, test, and production systems differently – mostly because they have differing security, data, and privacy controls. Testing in production can lead to corrupted or invalid production data, leaked protected data, overloaded systems and more.

If there is a separate dedicated test environment it may not match the proposed production environment. The wider the gap between test and production, the greater the probability that the delivered product will have more defects. It is common for test teams to clone the production data and use it for testing purposes. This approach can be time-consuming, error-prone and may not meet the data protection policies.

• Poor release management
Many projects do not have a well-documented release management process for testing purposes. This lack of rigor may lead to inconsistencies. Often, we have seen situations where a patch designed to correct a problem injects new ones, which may lead the system to fail.

• Inadequate defect management
In small organizations defects are sometimes not tracked centrally or are manually tracked using spreadsheets or email. This approach leads to inaccuracies or failures to correct defects. Manual operations are also burdened with a considerable amount of work to maintain the process.

• No central repository of test cases
Many legacy products/systems may have been used for years and often a test case repository is not available or maintained. If they are maintained, they usually contain just the latest requested changes and not the complete functionality of the product/system. New team members will struggle to learn the full functionality and to perform tests without reference to past test cases. This can lead to incomplete and error prone testing.

• Incomplete regression tests
When test case repositories do exist they are often outdated or incomplete. As functionality changes test cases should also be maintained and updated to match those changes. Regression tests that are limited to new capability results in poor test coverage and subsequently leads to new defects being injected to a partially tested product.

• Limited testing automation
Often, repetitive testing is performed manually. Automation can aid in creating the test environment building as well as functional regression testing, load testing, coverage testing and release management.
We suggest you evaluate the automation you have available inhouse and from 3rd parties. Assess the value of using automation versus the cost and effort. Is this a product/system that will be around for a long time and the effort of automation will continue to be used? Or is this a short-term fix with a limited life?

• Lack of training
Members of the project teams may not be familiar with the tools that are available to them or may not be trained on how to use them. Consequently, although the organization has tools they are not used. Lack of tool usage/knowledge can result in the limited ability to effectively track errors, supervise the entire process, or define measures and metrics to manage system development effectively.

• Lack of knowledge of available methodologies
Many project teams lack documented and understood testing methodologies and processes. Lack of following existing methodologies/processes or the absence of a documented approach leads to an inefficient testing process. The adopted methodologies and methods do not always have to be written down in the form of official documents, but they must be understood and applied in practice.

• Measures and metrics
Often, organizations collect data on ongoing projects but sometimes do not analyze the testing processes to seek improvements. For example, if it is uncovered that poorly documented or understood requirements are creating testing errors, the need arises to improve requirements elicitation and documentation process. This postmortem analysis provides an opportunity for iterative improvement of the testing phase.
We recommend testing retrospectives to see what the team has learned and what can be done to improve the overall development process.

Best Practices

The following are the best market practices. These practices are recommendations that are not applicable in every test team and not in every organization. Based on our practical experience we suggest:

  • Have an independent test team, whenever possible.
  • Plan the participation of the test team at an early stage of product development. It’s important to have the test team participate in the analysis stage and aid in assessing the functional and non-functional requirements in terms of their validation capabilities and the associated testing workload.
  • Define a strategy for testing the software with the customer.
  • Provide for collaboration among engineers, architects, designers, project managers, developers and testers in planning activities related to the testing process.
  • The preparation of test data should take place together with the construction of test cases. The data created should be subject to versioning and creating base lines.
  • When test environments use production test data, special attention should be paid to disguising or modifying the test data in order to ensure compliance with data protection legislation.
  • Create separate environments for testing and development. The test team should keep the test environment as compatible as possible with production.
  • Focus on the preparation and verification of the test environment before the start of each test phase.
  • Use tools to support configuration management, error tracking and requirements management to facilitate the work and increase its efficiency.
  • Build and maintain a test case repository that can be accessed by the project team.
  • Maintain traceability between tested functionality (requirements) and test cases in a matrix or other method. This provides information on the functionality being retested, limiting the time and scope of testing. Traceability relationships will reduce the number of regression tests by using the ability to track the relationship between requirements and test cases.
  • Maintain a repository for unit tests; use component simulation tools to support team sharing.
  • Use measures and metrics in the project to analyze the results. The data collected should help to improve the software development process and the efficiency of the team.
  • In our experience, a good testing process is one of the most important activities to ensure the delivery of value to both the development team and client.

Regardless of the type of project, testing should be given special attention. Testing must be well planned, executed in a repeatable documented manner by qualified and trained people. Without this supervision it will be difficult to call tests effective.

The IBM Solution

IBM test management solutions can help you avoid common software development traps.

Lack of planning, lack of metrics, and collaboration with stakeholders, ineffective test management, and lack of test automation, all lead to problems. When we don’t measure how we’re doing and do not continually make improvements, the risk escalates and the project can get out of control.

IBM software test management solutions incorporate many best practices that help you avoid these common traps and enjoy the benefits. IBM Test Management is a collaborative, web-based, quality management solution that offers comprehensive test planning and test asset management from requirements to defects. It enables teams to seamlessly share information and use automation to speed project schedules and provides metrics for informed release decisions. It is available both on-premise or as a SaaS solution.

Key capabilities include:

  • Communications support – Support communication among teams that are geographically dispersed using features such as event feeds, integrated chat, review, approval and automated traceability.
  • Automation tools integration – IBM Test Manager integrates with many test automation tools including 3rd party tools, homegrown scripts and more. Execute tests with all kinds of tools and collect test results—all from a central location.
  • Advanced reporting capabilities – Address the needs and concerns of quality managers, business analysts and release management using advanced reporting capabilities – making it easier to assess readiness for delivery.
  • Comprehensive test plans – Provides test plans that clearly describe project quality goals and exit criteria, while tracking responsibilities and prioritized items for verification and validation.
  • Risk-based testing – Provides risk-based testing for prioritizing the features and functions to be tested based on importance and likelihood or impact of failure, supporting risk management best practices.
  • Requirement tools integration – Test Manager works with the IBM Requirements DOORS Next Generation tool. You can link test cases and mark them as suspect whenever requirements are modified.
Categories
Design Requirements Testing Workflow

Requirements Reconstituted: Unifying Stakeholders by balancing needs and speed.

In a prior LinkedIn post titled “Regulated Agile” Hmm, what’s that? I discussed the “need for speed” in traditional financial services institutions (FSIs) as they in an effort to provide differentiated products. The competitive market tilts in favor of FinTechs since they’re not encumbered with legacy infrastructure and regulation. In their competitive fight the FSIs have adopted various agile practices – lean, XP, scrum, iterative, etc. – yet get stuck with a hybrid process often referred to as Wagile or WaterfallScrum. Development teams have embraced and benefited from agile practices the most. Accordingly, agility has been frequently defined as ability to rapidly deliver acceptable code within incremental time frames. The frequently used acronym of MVP (“Minimum Viable Product“) reflects the notion of getting something to market quickly, and in turn connotes agility and efficiency.

With annual expenditures to debug software failures at 620 million developer hours and $61 billion dollars per a Cambridge University study one must wonder if we are racing past the facts. How effective are we, if our efforts require such massive rework? Where is the trade-off between efficiency and effectiveness? How do we balance the “need for speed” with the needs beyond the development team, i.e. customer centricity, compliance and audit?

Need implies requirements, including the needs of the many who are afterthoughts in the software development and delivery process. Software and System Requirements are multi-dimensional in that “Requirements Management” spans elicitation, review, analysis, validation, enhancement, versioning. 

No alt text provided for this image

Furthermore, “Requirements Management” implies a hierarchical dimension since a project requirement is most often a component of composite application which is delivered as a product or program. In that composite applications reflect the collection of code, they equally reflect the collection of requirements. Herein comes the concept of systems thinking. Today’s Financial Services IT systems are so complex that they require multiple teams to develop and manage them.

As lean, agile developers we are trained to value “working software over comprehensive documentation” (one of the four values in the Agile Manifesto) and per lean principles we must identify and remove waste, i.e. manual practices. Automated testing and code promotion have effectively eliminated tremendous amounts of manual effort in the Software Development Life Cycle (SDLC) yet other manual activities such as documentation system remain. 

It befuddles me that significant roles, e.g. audit and enterprise architecture, are 1) often overseen and undervalued and 2) seen as antithetical to agile implementations; after all, their deliverables memorialize systems and provide the basis for the “learning organization,“ a concept of lean software development. Regardless of the expressed need and adherence to an institutionalized practice of documenting systems, key stakeholder (compliance / audit) require documentation, especially the “functional lineage” or traceability. Traceability implies the linkage and dynamic association of requirements to code (bases) to test and project should be classified and coordinated to programs for fulfillment. The vertical alignment, if you will, is the association of system components to the required and desired product according to functional and non-functional requirements. Can we pass the Sarbanes Oxley 404 litmus test: was this piece of code was used at this point in time to produce this deliverable (report that will be signed by the CEO for the attestation of earnings)? How can we do that in an agile stream?

A robust requirements management tool, such as DOORS Next, organizes requirements – regardless if they are elicited through traditional or agile practices – into collections but more importantly fosters traceability and re-use. These two factors serve as a very powerful way to balance the need for speed with the information needs of all stakeholders. 

The financial services sector relies heavily on documents and documentation. Documents such as the 17 CFR Part 23, NY DFS Rule 500 or Proposed Rule Rel. No. 33-10515; Small Entity Compliance Guide dictate what we must do to fulfill industry mandates as we serve our customers. As evidence we must produce documentation showing that we have implemented the mandate. How great would it be if we could decompose these monolithic documents in components and dynamically reconstruct the evidence back into documents within our agile process? What if we reconstituted requirements or better yet adhere to the concept of “requirement reconstituted.“

The attached graphic shows how DOORS Next, a robust requirements management tool, can ingest machine readable test into a collection of requirements to be worked.

No alt text provided for this image

The outline structure of these documents facilitates the transformation into a collection (paragraph) and a requirement (i.e. sentence). Each requirement then reflects a series of attributes, state, traceability, link relationships and most importantly ownership. State is a critical in determining the completed work and open tasks to reach a state of compliance. Work can be prioritized, scheduled and managed through Kanban boards. All information is displayed in a configurable dashboard and tags support the dynamic search. That which is most compelling is the ability to produce reports at any point in time and version them.

No alt text provided for this image

Moreover, a robust requirements management tool like DOORS Next can visually represent the association and fulfillment of a specific requirement or a collection of requirements. The graphic shows the functional traceability and specifically how regulation has been decomposed and fulfilled. The green checkmarks show the fulfillment; if any component changes icon will dynamically change. Of course, there are tabular views and reports.

Effective adoption requires a shift in the mindset that organizations must move in unison by adopting automation technology and the discipline associated with training. No one player gets to the Super Bowl; rather, disciplined teams do. Winning teams embody star players, who know their role and responsibility to others, unified in a common goal. If you would like to explore this topic further or learn how to manifest these concepts within your organization let’s connect on LinkedIn.

No tags for this post.
Categories
Requirements Design Testing Workflow

Optimizing the engineering life cycle requires digital transformation

You need to login to view this content. Please . Not a Member? Join Us
No tags for this post.
Categories
Design Requirements Testing Workflow

Getting requirements right: avoiding the top 10 traps

Don’t get caught

A trap is a position or situation from which it is difficult or impossible to escape. Getting caught in product or software development requirement traps can be problematic. The traps of bad requirements definition and management result in cost overruns, missed deadlines, poorly designed products, and a failure to deliver what the customer needs.

Imran Hashmi Canadian Hub for Requirements Management

Unfortunately, requirement traps are common. The State of the IT Union Survey explored the development management practices that teams applied to either stay out of trouble or address problems after they are discovered. The online survey of respondents reveals how often product development teams anticipate that they’ll fall into traps. They pad budgets and schedules. They change initial estimates to match actual results. And they request additional resources. Figure 1 reveals the lengths teams and team leaders will go to deal with these traps.

Imran Hashmi Canadian Hub for Requirements Management

Poor requirements management results in inconsistent project outcomes.

Products today depend on software to deliver their value. A brake sensor on a car, a home appliance, a medical device—all contain software that plays an increasingly important role. The products are becoming smarter, and they involve more people and teams outside the typical value chain. Smarter management of the requirements process— the foundation of effective product and software delivery— is increasingly important for delivering these products.

This article presents 10 common mistakes that project teams make in defining and managing requirements. More importantly, it discusses how to avoid these traps so you can get your requirements right and develop the right product on time and within budget.

Trap 1: scope creep

Scope creep usually involves features being added to previously approved product designs without corresponding increases in resources, schedule, or budget. The potential causes vary, but creep tends to occur when project requirements are not defined and managed properly.

Creep can also occur when development teams create solutions before determining what the business needs. The business requirements of a project are typically seen by development teams as being too high level and vague and not applicable to them. They want to focus on detailed product requirements. However, business requirements are real requirements and they need to be sufficiently detailed to avoid scope creep. By meeting the product requirements and not the business ones, teams fail to develop solutions that provide value and may overcompensate by adding features.

Avoid the trap

  • Map detailed, real business requirements to product features that satisfy those requirements and provide value.
  • Manage change, be vigilant about focusing on business requirements prioritization.
  • Identify and work with stakeholders early and often to understand the business requirements, stakeholder priorities, and the effect on stakeholders when changes occur.

The payoff: Avoiding scope creep makes planning easier, helps keep budgets intact, and helps keep projects on schedule. Most important of all, it helps generate the desired return on investment.

Trap 2: asking customers what they want

This seems counter-intuitive. Teams are supposed to talk to customers and give them what they want in a product. But customers tend to talk about features, not what they truly need. The truth is that people often don’t know what they want. And when customers don’t know what they want and developers don’t understand the problem, poorly conceived solutions— and products— can result.

Avoid the trap

  • Ask customers why they need a particular capability. It may lead to a better understanding of their expectations and better discussions about specific requirements.
  • Guide the discussion away from focusing on features— ask customers what they want the product/software to do. Create a separate discussion for how the resulting products will be used.
  • Identify the right stakeholders. The target audience or end-user may not be the person who is responsible for the project or invested in its success. Find— and listen to— the right mix of users, customers, executives who fund the project, government representatives who impose regulations, project teams, support teams, and others.

The payoff: Asking customers what outcome they are seeking helps you determine the true and realistic product requirements that will deliver value to them.

Trap 3: inability to adapt to change

Setting requirements in stone early in development can be a recipe for disaster that results in an enormous waste in resources and an inability to stay on schedule. As recent changes in the global economy illustrate, outside influences can quickly change project requirements. Organizations have quickly changed their focus to doing more with less. Speculative or experimental pet projects are off the table, replaced by those with strong potential ROI. Yet in any economy, there are always new requirements to contend with as business priorities change, new government regulations are enacted, and new stakeholders are identified. Project teams need to accommodate those changes.

Avoid the trap

  • Expect and plan for requirements that change throughout your development process.
  • Re-prioritize requirements based on shifting circumstances such as business needs, customer importance, estimated effort, and cost.
  • Have a fine-grain plan that you adjust at regular intervals.
  • Keep your stakeholders informed as changes occur— get their input for prioritization and the rationale behind it.

The payoff: Accommodating and planning for change in project requirements helps mitigate risk and decreases costly rework.

Trap 4: failure to communicate effectively

Ineffective communication is often a root cause of project failure. The perspective of development teams, customers, end-users, and executives are different for each group, as are their needs for communication. If you don’t express requirements using methods your stakeholders can easily understand, you can’t possibly gain consensus on requirements.

Avoid the trap

  • Know your audience and communicate in ways that help them understand the information. Make use of diagrams, user stories, sketching, and storyboards.
  • Create glossaries, document templates, and feedback forms that are clear, concise, and easy to use.
  • Use prototyping to help stakeholders visualize the solution. This can either augment text or completely replace it depending on the level of detail required.
  • Elicit feedback from all of your stakeholder representatives. Remember that one or two people tend to be the most vocal. Don’t make the mistake of overlooking others’ feedback.
  • Always respond to feedback, preferably with some clear statement of status such as, “will incorporate,” “placed on a wish list” or “unable to accommodate” If you ask for input, acknowledge it.

The payoff: Effective communication makes the most efficient use of everyone’s valuable time and helps avoid misunderstandings that derail projects.

Trap 5: failure to communicate frequently

Failure to communicate with stakeholders early and often leads to one primary problem: rework. Developing a product for customers without consulting them while that product is being developed is just asking for trouble. The biggest reason it happens is that we often think we know what our customers want well enough that we don’t need to consult them. And stakeholders usually have different priorities.

Sometimes teams don’t communicate with stakeholders because they prefer to avoid confrontations. But if you want a positive result and minimum risk and rework, it is important to collaborate with stakeholders not just at the beginning of a project but throughout the entire process, from start to finish.

Avoid the trap

  • Identify key stakeholders, including customers. Choose a representative from each group to communicate with regularly.
  • For large, in-person stakeholder workshops, consider using skilled facilitators. Good facilitators are worth their weight in gold in keeping everyone on track for attaining the meeting objectives.
  • Establish regular checkpoints with your stakeholders. Determine at the beginning of the project how often you need to check-in.  Schedule time for keeping stakeholders up to date as unexpected changes occur.
  • Make it easy for your stakeholders to provide feedback. When they do, let others see their feedback to generate better discussions.

The payoff: Regular communication reduces risks, increases team productivity, and avoids rework. Ultimately it helps deliver the product the customer wants.

Trap 6: unwieldy documents and too much information

Do you have time to review and give feedback on a 200-page document? Probably not— and most likely, neither do your stakeholders. Doing more work than necessary and adding unnecessary detail to documentation costs both time and money. It is unproductive for the person creating it and a hindrance to the people looking for information they need to get their work done. Two common missteps include adding too much detail to requirements too early in the process and requiring more traceability than is necessary to facilitate effective lifecycle management.

Think quality, not quantity. Better to add just enough detail to your requirements and identify just enough traceability to get the job done— not the entire job, but the next piece or iteration that needs to be completed.

Avoid the trap

  • Large, dense documents are not very consumable by stakeholders. Invest in communication tools that efficiently gather and disseminate requirements information.
  • Use visual techniques to model business and product requirements. Business process diagrams and use case diagrams, storyboards, and sketches can help cut through text-heavy clutter.
  • Provide a glossary of industry terms, acronyms, and domain-specific terms to facilitate communication.
  • Create transparency of feedback. When your stakeholders can review each other’s feedback, the discussion is richer, problems come to light, missing requirements are identified and necessary details get filled in.
  • Add just enough information to your documents so the rest of your team members can complete their work.
  • Remember that requirements management is an ongoing process. There will be other opportunities to add more detail to requirements and to capture more traceability later when it may be more appropriate.

The payoff: Focused documentation and feedback loops increase the efficiency of all stakeholders. Reduction of extraneous details in both requirements and traceability increases quality by focusing on the most important information— while postponing further detail until it’s needed.

Trap 7: hidden project artifacts

Engineers, developers, and testers often aren’t aware of the project vision or can’t locate the documentation for the architecture or the business requirements— that is, if they’re created at all. Without easy access to these foundational documents, how can we possibly expect them to deliver models, code, and tests that solve the right customer problems? We can’t. Transparency to all project artifacts is critical to the success of any software project.

Avoid the trap

  • Keep all project artifacts in a central repository that is accessible by project team members. Having to search multiple sources for relevant documents is frustrating and time-consuming.
  • Make sure documents are categorized and managed in such a way that they are easy to find.
  • Ensure that when changes occur, the team is informed. Automatic notifications can help deliver this information.

The payoff: Accessibility and management of information and transparency of project artifacts reduces rework, diminishes waste, and promote reuse because it makes collaboration and communication easier.

Trap 8: Ambiguous requirements

Ambiguous requirements are the result of unclear or missing information. This leads to confusion and rework. Project teams spend too much time trying to get clarification so they can design, code, and test. It’s very difficult for engineers or architects to develop relevant models, developers to write defect-free code and testers to develop the right test cases without clear requirements. Unfortunately, reworking requirements are so common that it can become an accepted practice— rework is just built into the schedule and budget.

Ambiguity also tends to push risks into the next phase of the project. Requirements then have to be reworked, and that poses problems to project schedule and cost. This trap is especially damaging to fixed-cost projects.

What causes ambiguity? Poor writing, inaccurate information, and the assumption that the audience understands just as much as you do.

Avoid the trap

  • Use a writing reference, such as Elements of Style by William Strunk and E.B. White— which has long been considered the authoritative reference on writing crisp, clear text— before and during requirements creation.
  • Create a glossary, and make sure every acronym and technical term is included.
  • Pretend you are writing for a student just out of college or someone who recently joined the organization. Don’t assume the audience will know every term and understand every concept.
  • Augment text with visuals. It’s a great way to express both simple and complex concepts.
  • Step back. After writing any draft document, put it down for a while and read it later. A fresh perspective can reveal ambiguities.

The payoff: Clear, understandable requirements are the foundation of your software project.

Trap 9: failure to measure and assess requirements processes

Defining and managing requirements can be a complex task. Missing and ambiguous requirements can easily result in missed schedules, cost overruns, and decreased productivity and quality as downstream project deliverables fail to provide value to stakeholders. Don’t wait for disaster to strike— assess your project status regularly.

Organizations must have the ability to review, assess, and improve their requirements process. Having accurate insight into data, processes, and practices is a key component of success. Measuring project and process outcomes allow for continual process improvements across the software delivery lifecycle, which reduces project failures and lowers business costs.

Avoid the trap

  • As part of your process, conduct a “lessons learned” feedback session at the end of each development iteration or release.
  • Also, do a “lessons remembered” session before starting a new project. To encourage continual improvement, you need to not only capture lessons learned at the end of an iteration or release but also reinforce those lessons as you move forward.
  • Define and collect metrics that ensure your success. For example, measure the impact of changes to your requirements, test case coverage, priority, cost and effort of business, and product requirements. As you become more experienced with measurement, you’ll find just the right combination of metrics that allows you to continually improve your requirements process.

The payoff: Ongoing measurement of project performance reveals small problems before they become big issues.

Trap 10: Isolating your requirements

Viewing requirements as isolated entities, failing to capture relationships between requirements and other artifacts, and failing to recognize dependencies between requirements leads to increased project risk and rework. Re-prioritizing one requirement without considering its effect on other requirements results in increased project risk and costs.

For example, a risky trap that organizations often succumb to is not capturing the relationship between project requirements, business requirements, and other downstream deliverables such as models, test cases, and defects. When you fall into this trap, you deliver a product that doesn’t satisfy stakeholder needs.

Avoid the trap

  • Identify relationships between requirements and then manage them together.
  • Create the right level of traceability between requirements and downstream deliverables that balances the traceability needed for effective lifecycle management with support for productivity.
  • As you make changes to requirements and re-prioritize them, consider the effect of these changes to related requirements and your downstream deliverables.
  • Use tools that allow you to easily visualize the relationships you’ve identified.

The payoff: Identifying and managing relationships between requirements and other artifacts mitigates project risk; helps ensure alignment between your business requirements, product requirements, and downstream deliverables; and results in lower development costs.

IBM requirements solutions can help you avoid common software development traps.

There are many traps in software. Some of the most expensive ones occur in the requirements space because that is where the foundation for your project is laid. Lack of planning, lack of communication, and collaboration with stakeholders, ineffective requirements elicitation, and requirement management techniques all lead to problems. When we don’t measure how we’re doing and continually make improvements, the risk escalates quickly and the project gets out of control— something you may never recover from.

IBM software requirements solutions incorporate many best practices that help you avoid these common traps and enjoy the payoffs.

IBM’s requirements management solution enables you to capture, trace, analyze, and manage changes to requirements in a secure, central, and accessible location. These capabilities strengthen collaboration, increases transparency and traceability, minimizes rework, and expands usability. IBM solutions make it easier to adhere to standards and maintain regulatory compliance.

Key capabilities include:

  • Requirements traceability – Link individual artifacts to test cases for full visibility of changes in requirements as they happen. Capture all annotations, maintain them, and make them easily accessible.
  • Variant management – Manage the entire version and variant process while monitoring the progression of the system through a shared dashboard. Store data in a central location and present it in document format.
  • Compliance – Incorporate industry standards and regulations into your requirements to achieve compliance early on. Building compliance into the end-to-end engineering lifecycle makes achieving compliance less complex.
  • Quality – Using Watson Natural Language Service IBM provides the capability to evaluate requirement quality using guidelines from INCOSE for writing complete, clear, and testable requirements – to accelerate your review process and increase requirement quality.

For more information

To learn more about IBM requirement solutions for software or product development, contact your IBM representative or IBM Business Partner, or visit IBM Requirements Solutions.

Ovum Decision Matrix: Selecting an Application Lifecycle Management and DevOps Solution, 2019–20

IBM Engineering Requirements Management DOORS Next

IBM Engineering Requirements Management DOORS Family

IBM Engineering Requirements Quality Assistant

1, 2 Scott W. Ambler, “State of the IT Union Survey,” Ambysoft, July 2009, http://www.ambysoft.com/surveys/stateOfITUnion200907.html