Factors to consider when starting a brand-new requirements management project - IBM Rational DOORS...

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

1


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; TemplatesMonitor: Customizable dashboards; Analysis views; Collections; Milestone tracking & statusCollaborate: Review & Approval ; Discussions; Email NotificationManage: 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


3


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


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


6


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


Properly adhering to a link schema will make analysis easier

8


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


10


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.


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


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


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


15


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


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


18


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


20


21


22


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


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


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


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 timeNotice 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


For more information about suspect traceability, see “Viewing and clearing suspect traceability” in the documentationThe 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


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


Review individual requirements

E.g. are these the new requirements we wanted to capture from the meeting?

Review modulesSign‐off based on role

29


30


• 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


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.tsFor 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/DefinitelyTyped. For more information: https://jazz.net/wiki/bin/view/Main/RMExtensionsMain

32


33


Factors to consider when starting a brand-new requirements management project - IBM Rational DOORS...

Technology

Transcript of Factors to consider when starting a brand-new requirements management project - IBM Rational DOORS...