The document discusses factors to consider when starting a new requirements management project in IBM Rational DOORS Next Generation. It recommends understanding project goals, environment and constraints to optimize the requirements process. Key questions to address include which artifacts define scope, how artifacts will be organized and tracked, what relationships are important, and which development methodology is being followed. The document also discusses configuring artifact types, attributes, link types and modules to structure requirements information in the project.

1. 2217, Factors to consider when starting a brand-new requirements management project

2. 1
2217, Factors to consider when starting a brand-new requirements management project

3. Rational DOORS Next Generation is build on the
Jazz application framework.
Is part of an integrated set of development
software that are intended to connect the work of
analysts with development and test teams.
Rational DOORS Next Generation is part of the
Rational solution for Collaborative Lifecycle
Management (CLM), and the Rational solution for
systems and software engineering (SSE). These
integrations provide a common approach to
artifact linking, dashboards, security, and user
interface frameworks. The tools include: IBM
Rational Team Concert (RTC), IBM Rational Quality
Manager (RQM), IBM Rational DOORS Next
Generation (RRDNG) and Rational Rhapsody
Design Manager
Plan: Integrated planning; Effort estimation; Task
Management;
Define: Specifications: module/ rich‐text
documents ; Diagrams: Process, Use Case ;
Storyboards, UI sketching & flow; Project
glossaries; Templates
Monitor: Customizable dashboards; Analysis
views; Collections; Milestone tracking & status
Collaborate: Review & Approval ; Discussions;
Email Notification
Manage: Structure, Attributes/Types; Traceability,
Filtering, Tags; Baselines, Change History; Reuse
(reqs & types); Reporting Metrics & Doc.
Lifecycle: Central requirements, test, &
development repository ; Common administration
and role‐based user licensing; Warehouse
reporting;
2
2217, Factors to consider when starting a brand-new requirements management project

4. 3
2217, Factors to consider when starting a brand-new requirements management project

5. Understand the goals, environment, and constraints of
each project, and optimize your requirements process
for that project with these factors in mind.
Not all requirements projects are the same; therefore,
think through your project. The answers to the
following questions shape how you implement a
project in IBM® Rational® DOORS Next Generation:
Which artifacts will be the “contract” that determines
scope?
What project structure will you use?
What artifacts will you capture?
How will you organize the artifacts using folders,
attributes, collections, and tags?
What information about artifacts, or attributes, will
you track?
What traceability relationships are important?
What activities do you plan to engage in, with whom,
and when?
Will you use a phased approach? If so, what will that
approach be?
What artifacts are to be captured? In which phase of
the project will they be captured?
Are reviews required? Is so, when in the process and
by whom?
When would you create collections and how would you
organize them?
What type of development methodology do you
follow? The methodology can affect how you want to
proceed with development of artifacts. For example:
In an agile methodology, people might develop user
stories. In a use case methodology, people might
develop use‐case specifications. In a traditional
waterfall methodology, people might develop different
types of artifacts.
Artifact types classify requirements information. You
capture requirements information in artifacts. When
you create an artifact, you make it of a particular
artifact type. Each artifact type is automatically
assigned a default editor, a defined set of attributes,
and preferred link types.
Artifact types and their default formats, attributes, and
preferred links are defined during the project
configuration. Project administrators can create
custom artifact types, attributes, data types, and link
types.
1 Within a project area, a user who is designated as the administrator has read‐
write access for that project area, and does not require any Jazz administration
privileges. For more information, see the Understanding licenses, permissions,
and access control help topic in the documentation for the Rational solution for
4
2217, Factors to consider when starting a brand-new requirements management project

6. Map out how your process and
requirements management planning
are to be implemented
Once you know the tools, you can now
customize them to fit your
"development process". You can
configure RTC to have the proper work
item types, defect work flow, releases
and sprints. You can customize RRC to
have the requirement types you need
with the proper attributes, traceability
link types and req type preferences for
those links.
(1) RTC process configuration, as you
noted (i.e. set up sprints, releases,
workflow, approvals, work item types,
stream delivery rulesetc), but also (2)
type system settings for RRC (e.g.
Feature, Use Case, etc. and their
attributes)
5
2217, Factors to consider when starting a brand-new requirements management project

7. 6
2217, Factors to consider when starting a brand-new requirements management project

8. Understand what kind of information
you are capturing and how it is related
to each other.
Each layer of requirements has its own
stakeholders. Requirements should be
written at the correct level and
organized accordingly
A link schema should be put in place
to capture relationships between
requirements information.
A requirements lifecycle is important
regardless of whether it aligns with
standards such as Capability Maturity
Model Integration (CMMI), Business
Analysis Body of Knowledge (BABOK),
or some other set of guidelines.
Consider creating a folder to hold top
level information that one may need
to refer multiple times during the
development, or that one may need to
know before getting started. The link
schema is such an example.
7
2217, Factors to consider when starting a brand-new requirements management project

9. Properly adhering to a link schema will
make analysis easier
8
2217, Factors to consider when starting a brand-new requirements management project

10. Link types capture relationships
between requirements information
across the project.
Notice that each type relationship
labels which are directional and
typically differ at either end of the
link. For example, a risk may be
mitigated By a system requirement,
while the requirement mitigates the
risk.
Some link types are system defined,
but users can define their own link
types within the requirements project.
Only system defined links can be used
across projects. User defined links
cannot be used across projects.
9
2217, Factors to consider when starting a brand-new requirements management project

11. 10
2217, Factors to consider when starting a brand-new requirements management project

12. 11
This slide focuses on RM projects.
Project areas are containers for managing,
organizing, creating, and viewing different types of
artifacts.
Artifact is a general term for something that is
part of a project, such as a module artifact, a
specific requirement, a diagram, or other
information.
In a project, you organize artifacts in folders.
Each artifact has a set of attributes, which you can
use to record and track data about an artifact.
Artifacts are customizable. Artifact values can be
tracked by the system or you can enter them. You
can use attributes to organize artifacts and
manage projects.
By using links, you can create relationships
between requirements artifacts. Links are
mechanisms for referring to related information.
You create some links manually; however, other
links are created automatically when you
complete certain tasks. Links are useful for
managing projects.
You can categorize artifacts by using tags. Then,
you can use tags to filter and create different
views of artifacts.
A comment is a textual discussion item that is
associated with an artifact or an element in an
artifact. Comments are useful for providing team
feedback during the development of an artifact.
You can comment on an artifact as a whole and
on specific elements in the artifact.
Note: Permissions can be assigned at the project
or team level. Team‐level permissions provide
granular control over who can create and modify
artifacts, folders, attributes, and links. Team
ownership can be assigned at the folder level to
control who can modify artifacts in that folder.
2217, Factors to consider when starting a brand-new requirements management project

13. A module is a special type of artifact that provides
a logically and hierarchically structured document
of artifacts that are individually structured.
When a requirement is individually managed, you
can link directly to that requirement, track its
history, and more. A module looks like a
spreadsheet; attributes and link information are
displayed in columns.
A module is different than an artifact of the Text
format, where contained requirements are not
individually managed and attributes cannot be
revealed in columns.
A module is also different than a collection. In a
collection, you can group artifacts, but cannot
organize them logically and hierarchically.
Advantages:
A module looks like a document, but acts as a
spreadsheet.
Modules present information logically and in
context.
Modules present information hierarchically. You
can collapse, move, promote, demote, or remove
sections.
Artifacts in a module are individually managed.
Artifacts in a module can have hyperlinks or
embed other artifacts.
You can create requirement artifacts while you
edit.
You can sort artifacts in modules.
You can filter artifacts in modules.
You can apply views to get different perspectives
of data.
You can edit artifacts in place. For example, you
can edit an artifact’s links or attributes in context.
Modules support the reuse of artifacts. The base
artifact, which is artifact at the project level, is
scoped within the module and has module‐specific
tags, comments, and links.
12
2217, Factors to consider when starting a brand-new requirements management project

14. Modules contain artifacts. Some
artifacts are used to provide structure,
others to provide context, and others
to hold the requirement. Example of
artifacts contained in a module:
Heading, Information, Requirement,
Usecase.
Artifacts consists of the main content,
and a number attributes. Attributes
include system defined (ID, Last
modified by, Last modified on), and
user defined (status, owner)
Attributes collect information based
on their datatypes. Example of data
types include enumerated lists,
Boolean, text etc.
Data types and attribute definitions
are shared in the project.
13
2217, Factors to consider when starting a brand-new requirements management project

15. This table lists a few artifact types, their format,
and some attributes that they may contain. In a
newly created project, such artifact types,
attributes, and link types do not exist and thus
must be defined by the administrator. If you
started the project form a template, then some of
this type structure may be in place.
Artifact types are defined by the administrator of
the RM project. Artifact types are based on
defined and supported editors, attributes, and
preferred link types.
Attributes can also be defined by the
administrator. Attributes are based on the
predefined and user‐defined types, and can be
single or multi valued. Attributes can be based on
a drop‐down list or be limited between a range.
A few link types are predefined, but more can be
defined by the administrator.
Team members must understand the artifact
types before they use them to capture
requirements information. Depending on which
artifact type you use, you are assigned a default
editor, attributes, preferred link types, and the
possibility of the artifact being used in a glossary.
For example, a vision document, stakeholder
requirements document, and system specification
can all be of the Requirements Specification type,
and therefore have the same attributes.
However, even though artifacts that are of the
Business Goal, Vision, Information, and
Stakeholder Requirement types have text as their
default format, they can have type‐specific
attributes and preferred link types. They can also
be based on a particular template which may
guide their content.
14
2217, Factors to consider when starting a brand-new requirements management project

16. 15
2217, Factors to consider when starting a brand-new requirements management project

17. A project starts with one team area, but more can be
created.
Each Team area contain Roles. Users are assigned to
a team area and to one or more roles. Roles identify
the functions of team members. You assign
permissions to perform specific operations to roles.
Therefore, a user’s role or roles determine which
operation the user can perform.
All users in the repository have the default Everyone
role, even if they are not part of the project, the are
part to the Everyone role for that project area.
Out of the box RM project process role and
description
Commenter A Commenter can view artifacts such as
requirements, sketches, and diagrams; participate in
reviews, comment on artifacts; create personal tags
and apply them to artifacts; create personal filters. A
Commenter must have a Rational DOORS Next
Generation Contributor or Analyst client access
license or any client access license that allows read‐
write capabilities.
Author In addition to the Commenter capabilities, an
Author can create and delete artifacts such as
requirements, sketches, and diagrams; add links to
artifacts; create personal and shared tags and apply
them to artifacts; create shared and personal filters;
move resources between folders; create reviews. An
Author must have a Rational DOORS Next Generation
Analyst client access license or any client access
license that allows read‐write capabilities.
Administrator In addition to the Author and
Commenter capabilities, an Administrator can add
and remove users in a project; manage templates;
manage artifact types, attributes, attribute data
types, and link types; access the Administration
project page. An administrator must have a Rational®
DOORS® Next Generation Analyst client access
license or any client access license that allows read‐
write capabilities.
Project Baseline Administrator Users with this role
can create and remove a project baseline. This role is
typically used in conjunction with the Administrator
or Author role.
16
2217, Factors to consider when starting a brand-new requirements management project

18. In requirements management project areas,
you can restrict access to specific requirements
artifacts, such as folders, to members of a team
area.
You can assign permissions at the project level,
or for more granular control, at a team level.
1. Create a team area.
2. Add users to the team area.
3. Assign process roles to the users in the
team area.
4. Modify the process roles for the roles in
that team area.
5. Assign team ownership based on location
in the folder hierarchy or to specific
artifacts or modules.
17
2217, Factors to consider when starting a brand-new requirements management project

19. 18
2217, Factors to consider when starting a brand-new requirements management project

20. A revision is created each time that you save an
artifact. Read‐only revisions are organized by time
period, such as today, yesterday, past week, past
month, or earlier.
More detailed history can be seen from the Audit
History tab.
A suspicion profile identifies a set of link types,
artifact types, and attributes to watch for changes.
When artifacts that match the profile criteria are
changed, the linked artifacts are marked with a
suspicion indicator to alert team members of the
possible impact of the change.
Administrators can create suspicion profiles that
correspond to different roles or areas of interest
in a project.
Suspect profiles can be used for projects,
modules, and artifacts.
To select a suspicion profile, click the Suspicion
Profiles icon in the toolbar.
When you open a saved view that includes
suspicion profiles, your current suspicion profile is
set to the profile or profiles that are in the saved
view.
The suspicion profile selection is stored as a cookie
in your browser. The profile is active in all sessions
with that browser, unless you clear the browser
cookies.
19
2217, Factors to consider when starting a brand-new requirements management project

21. 20
2217, Factors to consider when starting a brand-new requirements management project

22. 21
2217, Factors to consider when starting a brand-new requirements management project

23. 22
2217, Factors to consider when starting a brand-new requirements management project

24. Create views that organize and
represent data that is relevant to your
teams.
Views can help with reviews because
they present data consistently.
Views can also be private, only visible
to you.
23
2217, Factors to consider when starting a brand-new requirements management project

25. There are Project, team, personal
dashboards.
Views, comments, reviews, and other
information, are all accessible from
the dashboard.
Notice the above dashboard
represents Requirements,
Development, Tests.
24
2217, Factors to consider when starting a brand-new requirements management project

26. Templates are a great way to start
organizing the data. Standard bodies
such as IEEE, ISO, DoD, Objectory,
Military and others, have defined
templates that are widely used.
Templates provide a consistent layout
of the data, and will help keep your
documents clear and easy to follow.
25
2217, Factors to consider when starting a brand-new requirements management project

27. Another best practice when creating
requirements documents is to use
consistent terminology.
Glossaries assure that teams use
consistent –agreed upon terminology.
IBM Rational DOORS Next Generation
maintains a central glossary that can
be accessed across documents and
across projects, assuring document
consistency, and thus a better
understanding.
With documents and spreadsheets
glossaries are kept separate, making it
difficult to reference or use them.
In Rational DOORS Next Generation
the glossary can be access at any time
Notice that each term within the
glossary is individually managed. It
has its name, description, and
approval status. The term also links to
related information, where it is
referenced and if it references any
other terms.
26
2217, Factors to consider when starting a brand-new requirements management project

28. For more information about suspect
traceability, see “Viewing and clearing
suspect traceability” in the
documentation
The Suspect icon shows the source of
the change that caused the suspect
state:
• If the icon shows a black arrow
that points out of the icon, the
change is in the current artifact.
• If the icon shows a blue arrow
that points into the icon, the
change is in the linked artifact.
• If the icon shows a red double
arrow, both the current artifact
and the linked artifact were
changed.
In the Links section, you can see both
incoming and outgoing suspect links.
On the Artifacts page, you can see
only incoming links.
27
2217, Factors to consider when starting a brand-new requirements management project

29. Comments can be created against an
artifact. Comments can be assigned a
priority, and directed towards one or
more individuals. The conversation is
recorded with the comment.
Don’t lose information in email.
28
2217, Factors to consider when starting a brand-new requirements management project

30. Review individual requirements
E.g. are these the new
requirements we wanted to
capture from the meeting?
Review modules
Sign‐off based on role
29
2217, Factors to consider when starting a brand-new requirements management project

31. 30
2217, Factors to consider when starting a brand-new requirements management project

32. • Simple in concept, think carefully
about how to use
• Changes to contents and
attributes will be reflected
everywhere artifact is used.
• Generally a good thing –
but watch unintended
consequences!
• Links, tags, comments are still
module specific
31
2217, Factors to consider when starting a brand-new requirements management project

33. The version 4.0.6 release of the Requirements
Management (RM) application can host
extensions that you write and reuse across
the enterprise.
While extensions are defined by using an XML
file, their core capability comes from a
combination of HTML and JavaScript.
Typescript is an extension of standard
JavaScript that provides the capability to
write strongly typed scripts. For more
information, see the Typescript website at
http://www.typescriptlang.org/. The
JavaScript API for RM comes with a typescript
interface definition file that facilitates
developing extensions in typescript. The
interface definition file is included in the
server installation. You can download the file
from a running server by using a URL; for
example:
https://example.com:port/rm/web/com/ibm/
rdm/web/extensions/api/interface/RM_API.d
.ts
For a wide range of typescript interface
definition files that are available for common
third‐party libraries, see the DefinitelyTyped
website at
https://github.com/borisyankov/DefinitelyTy
ped.
For more information:
https://jazz.net/wiki/bin/view/Main/RMExten
sionsMain
32
2217, Factors to consider when starting a brand-new requirements management project

34. 33
2217, Factors to consider when starting a brand-new requirements management project