Using the Stakeholder Collaboration Strategy with Rational Requirements Composer: Part 1. The Audience

This is the first in a series of four articles about configuring and using IBM® Rational® Requirements Composer. The series covers four key areas: audience, organizing project and repository space, linking strategy, and collaboration strategy. This reflects the need to determine the audience, decide which artifacts will help agree and validate requirements, and the need to plan a collaboration strategy with the audience. The last section sets out a plan for reviewing and improving the process for the next time.

Share:

Lisa Garrity (garrity@uk.ibm.com), IT Specialist, IBM

Author1 photoLisa Garrity works as a technical consultant for IBM Rational software in the UK. She has worked in the software development field for 16 years in consulting and technical sales roles. Her primary responsibilities have included eliciting, managing, and documenting requirements for business and systems analysis, as well as supporting customers in their quests for success in software development. Lisa is a Rational Requirements Definition and Management Regional Mentor in the UK and joined Rational software in 2002.



Paula White (paula.white@uk.ibm.com), Consulting IT Specialist, IBM

Photo of Paula WhitePaula White is a technical consultant for IBM Rational software in the UK. She has been working in the software development field for more than 19 years. She has worked as an architect, software engineer, trainer, coach, mentor, and consultant. Currently, she works as a Rational brand architect and leads the UK Rational Brand Architects team. She is a Requirements Definition and Management Regional Mentor in the UK. She joined Rational software in 2002.



17 August 2010

Also available in Chinese Spanish

Introduction

There are many problems faced in requirements definition and management today. Many people are considering their approach. Rational Requirements Composer may support these efforts. The table illustrates some of underlying reasons why RRC could be adopted.

Table 1. Problem statement
WhatHow
The potential problems Eliciting, defining, and communicating requirements throughout the solution lifecycle are complex tasks that cover several areas. This can lead to problems:
  • Businesses and IT are misaligned, so projects might not deliver the value expected
  • The original intent, content, and context of specifications can be misinterpreted
  • Heavily text-based documentation is difficult to understand
  • Stakeholders do not have access to full information when making decisions
  • Stakeholders misunderstand the documents that they are asked to review because of the overwhelming length, lack of visual techniques, non-targeted content, and an unclear scenario or context.
  • Authors might get a large amount of feedback from a review, and this can be difficult and time-consuming to process.
  • Unhealthy projects experience unclear vision, infrequent communication, and teams progressing on incorrect assumptions
  • Authors do not receive feedback or receive insufficient feedback when stakeholders either do not understand the artifacts provided or did not see them as their responsibilities
  • Developers cannot easily understand or clarify requirement context
  • Teams have difficulty communicating across geographical barriers
  • Teams that want to communicate changes find it difficult to do so
  • Disparate infrastructure creates a barrier to collaboration and to defining understandable requirements
The impact of this could be any of these circumstances
  • Additional work is created in respecifying, designing, developing, and testing the system.
  • Possible reuse and productivity is lost when stakeholders lack access to artifacts
  • Stakeholders don't deliver feedback proactively because it is difficult to find relevant artifacts
  • Stakeholders do not always deliver feedback at all or do not deliver high-quality feedback because it is difficult to understand the requirements
  • Testers cannot easily create tests when they can't find all relevant information
  • Geographically distributed project teams are less productive and successful
  • Change and responsiveness to the business is restricted
  • High amounts of costly, uncontrolled requirement churn that doesn't necessarily provide business value can result
  • Late delivery of the solution
  • Higher costs
  • Reduced quality and a solution that does not deliver expected value to the business
  • Reduced trust and impaired an relationship between business and IT units
  • Reduced IT credibility and reputation
A successful solution would Aid requirements elicitation, definition, validation and collaboration among stakeholders throughout the solution lifecycle
Result in an understanding of the business stakeholders' needs and stakeholder consensus on requirements that drive the development of a working solution that delivers value to business stakeholders

Introduction to Rational Requirements Composer

IBM® Rational® Requirements Composer software helps in both defining and managing requirements in context. The tool supports putting a dynamic infrastructure for requirements artifacts and collaboration about them. This series of articles provides a conceptual framework for an organization or a project to maximize the benefits that Rational Requirements Composer can provide by:

  • Considering options for use
  • Planning configuration based on choices at the beginning of the project
  • Aligning ongoing use as the project progresses with the stakeholders
  • Considering the usage model for the stage of development
  • Reviewing and refining use for the next stage or future projects

This enables teams to:

  • Find artifacts and requirements easily
  • Adopt the right set of artifacts and requirement types
  • Understand the context of the artifacts and requirements within and across projects
  • Target the appropriate audience:
  • Gain a greater level of relevant transparency and proactive feedback
  • Reuse artifacts within or across projects
  • Improve collaboration across roles across the team and organization
  • Gain earlier feedback from a broad range of stakeholders, particularly from the business

This could facilitate less rework, more reuse, accelerated delivery, and better business value.

Tip

Some small preconfigured items can make a considerable difference in productivity and accessibility. This article will help identify these areas.

Rational Requirements Composer provides a range of possibilities from just-enough specification and process to something more formal. In practice, creating an approach with some structure makes it easier to use. The approach and amount of structure varies, depending on the project and team. This tool is most suited for highly collaborative requirements definition and management. It is particularly useful in a geographically distributed or outsourced environment.

Rational Requirements Composer offers a whole-team collaborative environment that is suitable for a range of use scenarios:

  • Elaborating the user needs and stories of the items in the product and iteration backlog
  • Generating ideas
  • Developing projects from green-field to maintenance release
  • Creating contractual documents for project commissioning and inception

Much of the functionality of Rational Requirements Composer is intuitive. This series of articles provides a checklist just to help the team to get started in working together. Examples are given throughout the articles, and a summary is provided in the appendix.

These articles assume that readers are familiar with Rational Requirements Composer software, requirements definition, and management techniques and process. These articles also mention IBM® Rational Team Concert® and IBM® Rational® Quality Manager. At the time of initial publication, all these Rational products were in various releases of Version 2.

Note:
These articles do not replace the online help or documentation for any of these products.


The Stakeholder Collaboration Strategy

The result of considering these options is a Stakeholder Collaboration Strategy (SCS) that describes the approach to collaboration among stakeholders about requirements and how this activity would be supported by using Rational Requirements Composer (see Figure 1). You can use only the sections of this strategy that add value for your project.

The diagram that follows gives a pictorial overview of some of the areas for consideration when using Rational Requirements Composer and creating a Stakeholder Collaboration Strategy. Each area is a subject of a subsequent article in this four-part series (see "More in this series" for links):

  • Part 2. Organizing project and repository space
  • Part 3. Linking strategy
  • Part 4. Collaboration approach
Figure 1. Overview of the Stakeholder Collaboration Strategy
Strategy overview diagram

The Stakeholder Collaboration Strategy (SCS) sets out plans for eliciting, documenting, validating, and managing requirements. It helps determine how to configure Rational Requirements Composer to support the requirements definition and management process. Considering these questions can help shape the SCS:

Stakeholders
Who has a stake in the results of delivering a solution? What responsibilities does each stakeholder have with regard to delivering a solution? Are stakeholders developing or testing the solution? Are they requesting capabilities and business benefits? Are they providing expertise, validation, or approval
Artifacts
What artifacts will be developed? (Examples: documents, storyboards, use case diagrams, business process diagrams, and glossaries)
Folder structure
How will the information be organized so that it's easy to navigate? (See Rational Requirements Composer roles.) What needs to happen to make to the structure easy for Reviewers and Approvers to navigate?
Linking
What is the strategy for linking the artifacts together? How do team members need to navigate, and what makes sense to the team? (Examples: use case scenario to storyboard scenario or business process task to user interface sketch?)
Contextual information
Will reference material be collected and retained in Rational Requirements Composer? (Examples; photos of whiteboard work, documents, presentations that initiated the project)
Templates
What templates exist for requirements artifacts? (Examples: use case template, vision statement)
Collaboration
Which stakeholders need to collaborate on requirements? What is the plan for collaborating with your stakeholders? When will comments start? Are they ongoing? Will both formal and informal reviews be conducted?
Reviews
What reviews are required for each artifact or set of artifacts, and who will review them? What is the level of formality required for each review?
Reports
What reports are deliverables, and is there a specific format required?
Tagging
All of the requirements and contextual artifacts are contained in the Rational Requirements Composer project. Will tagging be used to make it easier to mark and find artifacts?
Tracking
What attributes will be tracked for each requirement? (Examples: source, priority, complexity, and type)
Change management to requirements
When will requirements move from informal commenting and reviewing feedback to formally managing requirements with change requests or work items?

Audience

Audience includes the wider team of business stakeholders, operations and support, and project team members, including those in specific Rational Requirements Composer roles.

Figure 2. "Audience" includes all stakeholders
Audience overview diagram

Stakeholders

Value of early feedback

When business stakeholders and operations are considered from the onset, you obtain valuable feedback early in the process. Operations, in particular, might refine requirements that could otherwise be missed or hide architectural risks. Eliciting this feedback early can improve responsiveness across the team and develop a shared sense of ownership.

Stakeholders include anyone who could be materially affected by the implementation of a new system or application (see the second citation in Resources). Even though some stakeholders might become end users, many others are affected by the business outcome of the system's delivery. As a result, stakeholders include all people who develop and deliver the system. Third parties that interact with the system or regulate the business are included, as are line-of-business people who are sponsoring the solution but not necessarily using it.

Insufficient stakeholder involvement can lead to missing requirements that are uncovered late in the development stage or not until the system goes lives. This often results in a delivered system that does not function as needed or work as intended.

The Stakeholder Collaboration Strategy needs to state:

  • Who the stakeholders are
  • What their responsibilities are in Rational Requirements Composer
  • If they are collaborators, how they will collaborate
  • If they are not collaborators, how their requirements and concerns will be addressed and included
  • What the Rational Requirements Composer roles of the stakeholders are

Use photos

Photos are useful for encouraging collaboration.Because photos are loaded through the Jazz web administration site, the server administrator can do this as part of creating user accounts.

Rational Requirements Composer roles

Table 1 describes the possible roles that people can play in Rational Requirements Composer processes. Most stakeholders are expected to retain Reviewer access for read-only review and full commenting capabilities. A few stakeholders may need Author access for creating artifacts.

Table 2. Rational Requirements Composer standard roles and responsibilities
RoleResponsibilities
Commenters Review (read) and comment on specific requirement artifacts and descriptions (they have read-only access by default)
Authors Write requirement artifacts or descriptions or modify existing ones
Administrators Create projects, add and remove users for a project, access the administration tab, and manage integrations to other tools
Project Snapshot Administrators Create project snapshots.
Server Administrator* Responsible for Rational Requirements Composer server maintenance and support using the IBM® Rational® Jazz™ Team Server interface. This may include creating new projects and assigning people to projects. If applicable, this role manages integrations to other tools, such as Ravenflow, iRise, IBM Rational Team Concert, IBM® Rational® Quality Manager, IBM® Rational® DOORS®, and IBM® Rational® RequisitePro®. This user has JazzAdmin and Rational Requirements Composer administrator rights.

* Server Administrator is not a formal role listed in the Rational Requirements Composer tool, but it is a useful one to assign. This role undertakes various administrator activities outside of the Rational Requirements Composer environment.

Tip:
You can also create custom roles and define them in the SCS.

Project stakeholder roles

Any solution delivered needs to provide value to the business, so it is worth reiterating the need to include line-of-business roles. Table 2, which follows, provides examples of possible business and developer stakeholder roles.

Commenters might primarily use the web interface to review and comment on requirements. The advantage of using a browser is easy access and no need for a client tool installation. Requirements authors and administrators use the rich client interface to create and modify projects and artifacts. It is useful to specify the type of access in the Stakeholder Table so that Rational Requirements Composer can be configured to reflect stakeholder needs.

Authors can include any role within development or the business. Organizations should consider to what degree they want to use Rational Requirements Composer for business and requirements analysis and also to what degree they would like to use it for systems analysis, design, and architecture. This decision will affect both which stakeholders are authors in Rational Requirements Composer and which artifacts they define.

Table 2 describes examples of many possible roles and corresponding responsibilities. Although the Rational Requirements Composer administrator roles are marked as optional for several project roles, specific people need to take on these roles. There is flexibility for all of the roles. It all depends on the team and how it works.

Table 3. Team roles and responsibilities corresponding to Rational Requirements Composer roles
Team roleProject responsibilitiesRational Requirements Composer role
Solution sponsors Responsible for steering the project delivery to meet business goals and objectives.
Providing organizational support as needed by finding funds or assisting in navigating the organization.
Commenter
Subject matter experts Responsible for validating and clarifying the business needs for the solution, as well as for deciding what is suitable for the business purpose. Commenter
End users Either direct or indirect users of the system (see the first citation in Resources for more about this) Commenter
Author (optional)
Insiders Managers of users, program or portfolio manager, developers working on other systems that integrate or interact with the one under development, maintenance professionals potentially affected by development and/or deployment of your system, auditors (see the first reference in Resources) Commenter
Author (optional)
Project manager or team lead Responsible for delivering the project. Leads and manages the project team.
Needs to understand the requirements in order to scope and plan the project in conjunction with other team members. Might be aware of when to take a snapshot (for example, when artifacts have reached a level of maturity or at the end of an iteration or review cycle).
Commenter or Author
Administrator (optional)
Project Snapshot Administrator (optional)
Product owner Defines and promotes the vision, goals, and capabilities of the product so the team can make decisions. Determines the scope and content of the release. Defines acceptance criteria for the release and determines when the system is ready for release. Author
Administrator (optional)
Project Snapshot Administrator (optional)
Business analysts Traditionally responsible for translating between business needs and delivery capabilities. Document the business problem and solution vision in a way that is clear to appropriate stakeholders. Clarify solution details among the business and solution delivery team members so everyone can agree a reasonable understanding of what will be delivered (and what's out of scope). The lead business analyst might be aware of when to take a snapshot (for example, when artifacts have reached a level of maturity or at the end of an iteration or review cycle). Author
Administrator (optional)
Project Snapshot Administrator (optional)
Architect Responsible for end-to-end solution architecture, which includes ensuring requirements are achievable and deliverable. Reviews requirements with this in mind. Architects can say whether it is possible to deliver the solution requested and present alternatives for getting around technical sticking points. These considerations need to be incorporated into requirements. Might be aware of when to take a snapshot (for example, when artifacts have reached a level of maturity or at the end of an iteration or review cycle). Author
Administrator (optional)
Project Snapshot Administrator (optional)
Tester Responsible for validating that requirements are testable and associated with actual test plans and tests. Review requirements with testability in mind and make recommendations or changes accordingly. Testers are concerned with ensuring that the requirements they test are equivalent and up-to-date with the requirements the development teams will deliver. Commenter
Developer Responsible for understanding the requirements described enough to design, write, unit test, and deliver code on assigned tasks in a timely manner. Commenter
Author
Team member Other duties. Many team members might have a range of the above roles, rather than specialist skills. Author
Commenter
Operations staff Responsible for keeping the systems operating and for maintaining systems in the production environment. Commenter
Author (optional)
Support technician Responsible for supporting end users who use systems in production. Commenter
Author (optional)

Table 3 represents an example of many possible stakeholder descriptions that are part of the SCS. The purpose of this is to document stakeholders' roles, responsibilities, and expected project contribution. By defining these roles, you can start to foster better collaboration. The collaboration and roles will be addressed further later in this series.

Table 4. Stakeholder Collaboration Strategy subset example of a stakeholder table
Business roleName Area Contact detailsOrganization, departmentRational Requirements Composer roleType of collaboration
SME Lisa New business xxxxx.xxx.xxx Sales Commenter Proactive ongoing comments, informal and formal reviews
Project sponsor Paula All xxxxx.xxx.xxx CFO Commenter Report only
Business architect Vivanne All xxxxx.xxx.xxx Business Change Author Initiate reviews, participate in peer reviews, daily collaboration
New development business lead Daniel New business xxxxx.xxx.xxx IT Author Initiate reviews, participate in peer reviews, daily collaboration
Business stakeholder Claire New business xxxxx.xxx.xxx Sales Commenter Proactive ongoing comments, informal and formal reviews
Deployment architect Robin All, compliance with group technical strategy xxxxx.xxx.xxx Group Technical Infrastructure Commenter Proactive ongoing comments, informal and formal reviews

Acknowledgements

The authors thank Robin Bater, Rational Requirements Definition and Management Community of Practice Architect, and Daniel Moul, Market Management Offering Manager for Requirements Definition and Management, for their technical reviews and encouragement.


Download

DescriptionNameSize
Stakeholder_Collaboration_Strategy_template.docStakeholder_Collaboration_Strategy_template.zip105 KB

Resources

Learn

  • Read:
    • Managing Software Requirements: A Unified Approach, 2nd edition, by Dean Leffingwell and Don Widrig (The Addison-Wesley Object Technology Series, 2003)
    • Outside-In Development (OID) is method developed within IBM Software Group. It is described in the book Outside-In Software Development: A Practical Approach to Building Successful Stakeholder-based Products by Carl Kessler and John Sweitzer (IBM Press, 2007)
    • Capturing Architectural Requirements, by Peter Eeles, (The Rational Edge, 2005).
  • Learn more on Jazz.net:
  • Start here to learn more about Rational Requirements Composer on IBM.com:
  • Learn about other applications in the IBM Rational Software Delivery Platform, including collaboration tools for parallel development and geographically dispersed teams, plus specialized software for architecture management, asset management, change and release management, integrated requirements management, process and portfolio management, and quality management. You can find product manuals, installation guides, and other documentation in the IBM Rational Online Documentation Center.
  • Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products
  • Explore Rational computer-based, Web-based, and instructor-led online courses. Hone your skills and learn more about Rational tools with these courses, which range from introductory to advanced. The courses on this catalog are available for purchase through computer-based training or Web-based training. Some of the "Getting Started" courses are available free of charge.
  • Subscribe to the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
  • Browse the technology bookstore for books on these and other technical topics.

Get products and technologies

Discuss

  • Join the discussion in the Rational Requirements Composer forum about all aspects of requirements definition, including both general, tool-independent concepts and tool-specific information.
  • Check out developerWorks blogs and get involved in the developerWorks community.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, DevOps
ArticleID=507454
ArticleTitle=Using the Stakeholder Collaboration Strategy with Rational Requirements Composer: Part 1. The Audience
publish-date=08172010