https://www.ibm.com/internet-of-things/learn/aerospace-requirements-management/
Requirements Management
Building on the themes of ELM 7.0, our next release is just around the corner. Since 7.0.1 has come so soon after 7.0, we recommend that anyone planning to upgrade should go straight to 7.0.1. This blog covers releases of all requirements Management tools including:
One of the themes of DOORS Next V is to extend the overall scale of data that can be managed using a DOORS Next RM server. testing has continued in V7.0.1 and we can now support up to 1,000 concurrent users working on a single RM server using an Oracle database.
It is often the case that when using changesets to modify requirements, dependencies between changesets are created when multiple people change the same requirements or are making changes in the same module when there are changes to the structure of the module. DOORS Next V7.0.1 allows for dependencies to be overruled when selecting changesets for delivery.
Trace column information can be tailored to be more succinct in the information that is displayed, including the use of traversable Link Indicators rather than displaying more verbose URLs.
ReqIF has been improved in the way attachments and graphical elements are used as part of Requirements information. Where possible, DOORS Next will now import OLE elements from applications like DOORS directly into attachments in DOORS Next. DOORS Next will export graphical elements such as Diagrams in a format that can be seen, but not edited in other requirement tools, including DOORS.
DOORS V9.7 was introduced to enhance usability while focusing on integrating DOORS more closely with the IBM Engineering (ELM) portfolio as a whole.
Requirements Quality Assistant is a hosted solution with updates typically released monthly.
RQA scores requirements against criteria consistent with the INCOSE Guidelines for Writing Good Requirements. The tool is pre-trained to detect 11 quality issues and can be extended with more through the support of IBM services.
After analyzing requirements, see the issues found by RQA in the list of attributes in DOORS Next & DOORS. Use the issue guidance to modify requirements and reduce ambiguity. For more information, see Checking DOORS Next requirements with RQA
In recent releases, we have refined the accuracy and scoring and you can now measure the quality of your project or module and use Dashboard views to provide insights on problem projects.
These are only a few of the improvements introduced with DOORS Next, DOORS and RQA. A full list can be found in the product documentation: DOORS Next, DOORS, RQA
Thank you for your continued support and stay safe.
by Richard Watson
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.
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.
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
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
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
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
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
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
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
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
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
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
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:
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