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
|The potential problems|| Eliciting, defining, and communicating requirements throughout the solution lifecycle are complex tasks that cover several areas. This can lead to problems:|
|The impact of this could be any of these circumstances|
|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.
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.
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
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:
- 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
- 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?
- 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)
- What templates exist for requirements artifacts? (Examples: use case template, vision statement)
- 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?
- 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?
- What reports are deliverables, and is there a specific format required?
- 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?
- 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 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
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
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
|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.
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 role||Project responsibilities||Rational 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.
|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 |
|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|
|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|
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|
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|
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|
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|
|Team member||Other duties. Many team members might have a range of the above roles, rather than specialist skills.|| Author|
|Operations staff||Responsible for keeping the systems operating and for maintaining systems in the production environment.|| Commenter|
|Support technician||Responsible for supporting end users who use systems in production.|| Commenter|
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 role||Name||Area||Contact details||Organization, department||Rational Requirements Composer role||Type 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|
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.
- 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
- Download IBM Rational Requirements Composer and try it, free.
- Download trial versions of other IBM Rational software.
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Tivoli®, and WebSphere®.
- 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.