17. Polarion for Requirements Engineers

Defining and managing requirements with Polarion provides significant advantages over legacy approaches:

Feature Availability Note

All Polarion products support basic requirements management. You can have a Work Item type Requirement which can be linked to other Work Items such as tasks. However, advanced requirements management features are present only in Polarion ALM and Polarion Requirements. This chapter mainly discusses the features and capabilities of these products.

Getting Started with Requirements Management

This section covers the main things you need to know to get started using Polarion for requirements definition and management.

Approaches to Requirements

Traditionally there have been 2 main approaches to requirements management that have been more or less mutually exclusive:

  • Document-centric approach: Requirements are defined in office applications like Microsoft Office Word or Excel, engineering and QA must work from copies (hopefully the right copies) of the requirements.

  • Tools-centric approach: Requirements are defined using data-driven software tools such as DOORS, Requisite Pro, and others. Engineering and QA can manage their processes more efficiently, but the business and domain experts who author requirements often resist the adoption, and extensive training becomes necessary when the tools approach is enforced.

Polarion supports both approaches, and even enables a hybrid approach where some requirements and other artifacts are document-based while others are tool-based. Document-centric workers can stay within the familiar document paradigm using Documents to author specifications, marking parts of the content as requirements artifacts that they and others can track, manage and trace throughout the life cycle.

People such as developers and QA testers who are accustomed to using data-driven tools can keep within that paradigm, using integrated tracker, workflow, and project planning and management features to work efficiently... even when artifacts like requirements live in Documents.

Polarion also makes possible a unique hybrid approach. For example, requirements, test cases, or other artifacts written up in Documents automatically create data in the background which is available in tools. Stakeholders can access their preferred presentation... Document or tools. It's quite easy to switch between these presentations, and people naturally tend to gravitate to the way that suits their needs.

Features to Explore

  • Definitely have a look at Documents. Within that topic, learn about the Word Import feature that lets you leverage existing assets authored in Microsoft Word, and the Word Round-trip feature that enables you to collaborate with external people who use Word, or work on your Documents offline and synchronize your changes with the portal.

Requirements Projects

Your requirements exist in the context of a Polarion Project. Polarion provides a Project Template specifically for requirements projects. The template contains pre-configured Work Item types, link roles, and workflow that are suitable for many requirements projects. We recommend that you create a test project in a sandbox area of your system, and explore if the requirements project template meets your needs, or if you will need to customize it (see Administrator's Guide Customizing Project Templates if you do).

When setting up any project, there are a number of things to consider and plan for. Before starting a new project for requirements, we recommend reading User Guide: Polarion for Project Managers: Project Management Features/Capabilities: Planning for a Project.

Integrating with Development and QA

Whether written up in Documents or authored with integrated tools, Requirements in Polarion are a type of Work Item, that is, an artifact that is tracked and managed through a process. You can customize your project configuration to support whatever semantics you use. For example, if your organization uses the Scrum methodology, you might call requirement Work Items "User Stories". Regardless of semantics, requirements are tracked and managed the same as any other artifact... development tasks and change requests, or QA test cases or defect reports. Artifacts created by other teams can be linked to requirements, which results in traceability. For example, QA can link Test Case Work Items to the Requirement Work Items that they verify, and Engineering can link Task and Change Request Work Items to the Requirement(s) they implement. Defects found by QA can be linked to an implementation Work Item, and easily traced back to that item's Requirement(s).

In getting started using Polarion for requirements, you will need to think about how the requirement Work Items you create will be linked to artifacts like tasks and test cases. For example, you will need to decide what processes will be managed in a given project. Will requirements have a separate project, or will they be part of the same project used to manage implementation and QA? Maybe Requirements and QA will have one project, and Engineering a separate project. All approaches are possible. Linking for traceability across projects is a little more involved than when all artifacts are managed in the same project, but it is still quite feasible. In any case, your requirements team will need to coordinate with these other teams to decide the best approach to projects.

Elicitation Phase

During the requirements elicitation phase there is typically a need for communication and collaboration, and for tracking the results of these, to finally come up with defined requirements. The following features can be used during the elicitation phase while you are still gathering input to process into actual requirements:

  • Documents: Create Documents in the portal, or import Word documents you already have. All stakeholders with access to your project can access Documents and collaborate on the content, with changes showing up in real time. For information, see User Guide: Documents and Pages Topic, and the section on importing from Microsoft Word.

  • Word Round-trip: If you have stakeholders who, for one reason or another, do not have access to Documents hosted on your Polarion server, you can use the Word Round-trip feature to share Documents with them. They can comment and/or modify content, depending on the permissions granted when exporting. Changes can then be merged into the Polarion document. For information, see User Guide: Working with Documents: Sharing Documents Using Word Round-trip.

  • Pages: You may find Info type Pages useful for collecting and collaboration on information and content that will eventually become requirements written up in Documents or created in the integrated tracker. For more information, see User Guide: Working With Pages.

Definition Phase

Polarion has several features that you may find useful during the phase when requirements engineers are actually defining requirements, prior to their review and approval/acceptance.

  • Documents: If you prefer a document-centric approach to Requirements, then use Documents to create specification documents and requirement artifacts for tracking and management.

  • Integrated tracker: If you prefer a tool-centric approach you can create requirements artifacts directly in the integrated tracker: Navigation > Work Items. Your project should be configured with the Requirement Work Item type, or whatever type corresponds to a requirement in your process and semantics. If you take this approach, we recommend you read over the User Guide chapter Managing Polarion Work Items.

  • Auto-assignment: This feature can save a great deal of work over the life of the project. You can configure Auto-assignment in your projects so that new requirements are automatically assigned to one or more owners. If your process involves parallel work on test cases for verifying requirements, you can configure Auto-assignment for new requirements to include the responsible QA person as an assignee. For information, see the Administrator's Guide topic: Configuring Auto-assignment

  • Linking: You can begin creating traceability even as you define requirements. For example, if you or your QA team develop test cases in parallel with requirements, test cases can be linked to the requirement(s) they verify. Likewise, if requirements you define involve change requests for your development team, you can create those artifacts and link to them to the appropriate requirement(s) so you have traceability right from the start.

    You can do some linking of requirements within Documents. See the topic Linking a Document's Work Items in the User Guide chapter Documents and Pages Topic. You can also link Work Items in the tracker (Navigation > Work Items), in the Table view or the Matrix view. See User Guide: Managing Work Items: Linking Work Items.

Approval Phase

Polarion makes the process of approving requirements simple and efficient. The following features are the ones to take a closer look at to support this phase:

  • Workflow: Review and approval is just one step (or maybe 2 steps) in a larger process. That process in defined in the Project's workflow configuration. Polarion comes with several Project Templates that support requirements elicitation, authoring, and management. These have preconfigured Document types and Document workflows suitable for many requirements projects. If the defaults don't reflect your exact process, Project Templates and/or individual projects can be customized to map your process in workflows of both Documents and Work Items.

    When your process is configured into the project workflow, then people always know the current status of a requirement, and what the next step is. For example, when a requirement is created, workflow might assign it a status of "Draft" and define the next possible action as "Send to review". When a user invokes that action, the requirement transitions to a new status... "Under review", for example... and the workflow might present 2 possible next actions: "Approve" and "Reject". Notifications go out to the relevant stakeholders when transitions occur. The workflow then defines what happens when either of these actions is invoked. For example, the "Reject" action might set the status back to "Draft" (which would trigger notification to the author), and "Approve" would set a new status like "Approved" (which could also result in notifications).

    The foregoing is a relatively simple scenario. It is also possible to set up Document-specific workflows that make Document content read-only when the Document has a given status - "In Review" or "Approved", for example. It is also possible to require an electronic signature by users transitioning a Document from one status to another, and/or to provide an electronic signature when approving an entire Document.

  • Auto-assignment: Once again, Auto-assignment comes in handy. For example, you could configure Auto-assignment to reassign requirements to someone when the status changes... to "Approved", for example. Possible assignees might include a developer in engineering, and/or a tester in QA. Again, appropriate notifications are sent when the status changes, so everyone who must do something with approved requirements automatically knows it's time to move forward.

    TIP: Be sure to have a project administrator look at the Notifications configuration (Administrator's Guide: Notifications, Events, and Targets) to ensure that your scheme of notifications works the way you need it to work and always notifications go to all the right people for every system event (such as a requirement status change).