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 definition and management result in cost overruns, missed deadlines, poorly designed products, and a failure to deliver what the customer needs.

Imran Hashmi IBM ELM engineering lifecycle 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 IBM ELM engineering lifecycle 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 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

Categories
Requirements

Why IBM Requirements Management is best in the market.

IBM Management is a comprehensive solution that allows organizations to manage requirements throughout the software development lifecycle. This software is designed to help teams collaborate, manage and track requirements, and ensure that products are developed according to their specifications. In this article, we will explore the key features of IBM Requirements Management and how it can benefit your organization.

Features of IBM Requirements Management

  1. Requirements Traceability: IBM Requirements Management provides end-to-end traceability, ensuring that requirements are linked to their corresponding design, development, and testing artifacts. This feature helps teams to understand the impact of changes to requirements and provides complete visibility into the development process.
  2. Collaboration: IBM Requirements Management promotes collaboration by allowing stakeholders to contribute to requirements at any stage of the development process. This feature ensures that everyone has a voice in the development process and that requirements are prioritized based on the needs of the organization.
  3. Agile Requirements Management: IBM Requirements Management supports Agile methodologies by allowing teams to prioritize and manage requirements using Agile techniques such as user stories, sprints, and backlog management.
  4. Change Management: IBM Requirements Management provides robust change management features that allow teams to track changes to requirements, analyze their impact, and manage approvals and sign-offs.
  5. Requirements Analysis: IBM Requirements Management provides tools for analyzing requirements to ensure they are complete, concise, and unambiguous. This feature helps teams to identify inconsistencies or conflicts in requirements and address them before development begins.

Benefits of IBM Requirements Management

  1. Improved Collaboration: IBM Requirements Management helps teams collaborate more effectively by providing a single platform for managing requirements. This feature ensures that everyone has access to the same information, reducing the risk of miscommunication and misunderstandings.
  2. Increased Efficiency: IBM Requirements Management streamlines the development process by providing tools for managing requirements, change management, and analysis. This feature reduces the time and effort required to develop software products and ensures that they are delivered on time and within budget.
  3. Improved Quality: IBM Requirements Management helps teams to develop high-quality software products by ensuring that requirements are complete, accurate, and consistent. This feature reduces the risk of defects and ensures that products meet the needs of the organization and its stakeholders.
  4. Reduced Risk: IBM Requirements Management reduces the risk of errors and delays by providing end-to-end traceability and change management features. This feature ensures that requirements are well-defined and that changes are carefully managed, reducing the risk of unexpected consequences.

Conclusion

IBM Requirements Management is a comprehensive solution for managing requirements throughout the software development lifecycle. This software provides tools for collaboration, change management, analysis, and traceability, helping teams to develop high-quality software products on time and within budget. If you're looking for a solution to manage requirements more effectively, IBM Requirements Management may be the solution you need.

Categories
Requirements

Best AI?: …

Best AI?: TRON, HAL 9000, C3PO or IBM?

I bet you have read a book or seen a movie that had an “all-knowing” AI. But have you seen a practical, pragmatic AI that can inexpensively help you do your job better for about $65 a month?

You may have seen IBM Watson defeat Jeopardy players a few years back. We have now applied that same machine learning technology to help you to reduce the time you spend on managing and reviewing .

This AI capability combined with our requirements management solution enables organizations to better manage software and product requirements – as well as compliance and regulatory requirements – to accelerate their delivery cycles and improve product and project quality. 

Interested to see if our AI Requirements Assistant can help you? Then reach out to me to see if it might be a fit for your organization.

Please let me know if your schedule allows for a quick call. Thanks again and looking forward to hearing from you.

Imran Hashmi

416-788-9101

[email protected]

PS Interested in learning more about our national language technology? – https://www.ibm.com/watson/natural-language-processing
     Looking for more information on our requirements management solutions? https://www.ibm.com/internet-of-things/learn/ai-for-engineering-requirements/

PSS – think you can't afford IBM? Our AI solution starts at about $65 a month and our complete requirements management solution at $270 a month

Categories
Requirements

Looking for help to get started with IBM DOORS NG?

Looking for help to get started with ?

IBM Rational is a web-based management solution for complex software and systems engineering environments. This playlist is for anyone who wants to learn about IBM . The topics are at a high level, providing an overview of key use cases and product features.

More information: http://goo.gl/eZ0cI Using DOORS NG with OSLC: https://jazz.net/library/article/1197 Latest DOORS NG information: https://jazz.net/products/rational-do… Intermediate list of RDNG videos: https://www.youtube.com/playlist?list… Advanced/Administration list of videos: https://www.youtube.com/playlist?list… Configuration management videos: https://www.youtube.com/playlist?list…

Categories
Requirements

What is IBM ELM/ALM?

What is IBM /ALM?

IBM® Engineering Lifecycle Management (ELM) integrates ELM products to provide a complete set of applications for software or systems development. ELM includes IBM Engineering Management DOORS® Next (DOORS Next), IBM Engineering Requirements Management DOORS (DOORS), IBM Engineering Workflow Management (EWM), and IBM Engineering Test Management (ETM), IBM Engineering Systems Design Rhapsody® – Model Manager (RMM), and IBM Engineering Lifecycle Optimization – Engineering Insights (ENI) with Jazz™ Team Server. This solution is designed for requirements analysts, developers, systems engineers, and testers. 

The following diagram shows the development lifecycle that the solutions support. To see overviews of the applications that are represented in the image, click the boxes. For example, clickValidate and verify to see an overview of ETM.

This image shows the functions in the development lifecycle supported by the solutions.

To support the development lifecycle, ELM products let you link artifacts across applications, as shown in the following figure and examples: Figure 1. ELM connects analysts, developers, and testers

This graphic shows the relationships between ELM disciplines, as described by the following examples.

Requirements:

  • Requirements are implemented by iteration plans and validated by test plans.
  • Requirements are elicited, documented, elaborated, and validated by analysts. Their implementation progress is tracked in work items, and their correctness is validated by test cases.

Implementation:

  • Project managers and development managers use iteration plans to implement requirements in the context of a development schedule.
  • Team leads plan the iterations using iteration plans, where the work is divided further into tasks.
  • Developers work on defects that are submitted by testers as a result of test execution.

Testing:

  • The test team links requirements to test plans and test cases. 
  • Testers link test cases to work items to ensure coverage of the implementation.
  • Testers run test cases and submit defects for test failures.

ELM integrates the work of analysts, developers, and testers by providing the following cross-application features:

  • Link between artifacts across applications: For example, you can link test cases to work items and requirements.
  • Hover over a link to see details about the link target: For example, testers can monitor the status of a defect that they reported to the development team.
  • Track status across projects by adding widgets from different applications to a dashboard: For example, you can add a widget that shows the defects that are blocking testers.

Jazz Team Server

The Jazz Team Server provides the foundational services, such as user management and license management, that enable the ELM applications to work together as a single logical server. In this way, the Jazz Team Server serves as an integration hub for the applications. After you install the ELMproducts, you install product license keys into the Jazz Team Server to permit access to the capabilities provided by the applications. For details about the topologies supported for new or upgraded installations, see Planning the deployment and installation.

Products and applications

For a detailed overview of the products and applications in ELM, see the following topics:

Part of the Jazz community 

ELM products are developed transparently on the open and extensible Jazz platform. On Jazz.net, you can download the products and their milestones, track development schedules, join discussion forums, open enhancement requests, and interact with the product developers. To learn more about the products, see the developer-written articles in the Jazz.net library or the topics about complex deployment scenarios on the Deployment wiki.

More information

To learn more about ELM, see these resources: 

  • ELM on Jazz.net: Learn about the new features, read the release notes, and download the binaries to install the solution.
  • ELM videos: These videos highlight the configuration management capabilities of the solution. 
  • ELM sandbox: You can try a series of exercises in an online sandbox to learn more about a broad range of capabilities across the application development lifecycle.
  • ELM on Jazz.net: Learn about the new features, read the release notes, and download the binaries to install the solution.
  • ELM demo series: This set of recorded demonstrations offers a full lifecycle walk-through, and videos that highlight specific industry needs, in-depth tools, and practice topics.