Polarion Software Weblog

It’s a brand new year, and Polarion Software is excited to announce the release of a brand new Polarion: Polarion 2010. This release delivers many new features that customers have asked for. We’ll tell you more about these below, and also where you can have a look at the new release online, and where you can download it. Let’s begin with new features.

Improved Navigation

The first thing you’ll notice is the simplified navigation. A single Navigation pane provides all resources and shortcuts for a project or repository. New Open button and dialog, with Windows 7 style Favorites, make it quicker and easier to open the project, project group or repository you want to work with.

Even More Robust Modules

• Outline numbering: You can now optionally add automatic outline numbering to work items (e.g. Requirements). These appear both in the portal and in PDF exports.

• Multiple Module reuse: reuse multiple modules at once , establishing cross-module links in the new modules. For example, you can manage a requirements specification module and system test module (with test cases) in one place, and reuse both of them at once when implementing some variant of the base specification. In the new modules the test cases will be linked to requirements.

• Move items within Modules: New buttons in the Designer view let you move an item before or after, or as the first or last child another item in the module structure .

• Bulk Move to Module: Now you can move work items from any module (or from normal storage) to another module. If you ever import work items from a Word document, you’ll appreciate this capability.

• Export Home page revisions to PDF: Module revisions are in effect baselines. By rendering module work items on e.g the Module’s Home page, you can export any revision of the page to PDF. (Revision export works for other wiki pages too.)

(NOTE: Modules are a feature of Polarion ALM and Polarion Requirements.)

(more…)

In this last post of the series, I will give you an overview of some basic concepts that are part of our own Requirements Management process at Polarion Software. This is not a process, it is just a bunch of hints that should help those people and companies who have no process in place. Try starting with these few practices (just as we ourselves did a few years ago) and then start building the best process in the world: yours.

Managing Requirements Your Way with Polarion

Are you unsure of which process is right for your organization? Is manual process a non-starter? Is an Agile process too light, and a formal process too heavy? The great thing about using Polarion is: you are free to design your own best practices for requirements management, and adopt a middle-weight balance that truly fits your organization.

This is in fact the path we have taken ourselves. With hundreds of stakeholders and half a million users, and a reputation for excellence to uphold, we take our requirements management process very seriously at Polarion. We have worked out a method that feels light and is easy to use, yet is secure, traceable, and cost effective. Let’s take a walk through some of the ways we (and you) can use Polarion to create a requirements process for your organization:

1. Use Polarion’s Wiki in the elicitation phase to write up your thoughts in Wiki articles with links to ideas, mashups, meeting minutes – basically any piece of information that might help to round out your thinking and provide a clearer picture of the product under development. Quickly and easily circulate information to stakeholders, inviting them to participate and comment, adding their own thoughts to the process, as well as links to their own information sources.
2. Use Polarion’s Wiki history to thoroughly track changes to articles and comments.
3. Extract formal requirements artifacts from these informal discussions, by highlighting the discussions you want included, and clicking on the tool’s extract requirement button.
4. Organize and group formal requirements into modules backed by explanatory wiki content, embedded acceptance criteria, and prioritization information.
5. If you choose, start your elicitation process by reusing requirements from Polarion’s requirements library. This approach can be very valuable for organizations that must include requirements for regulatory compliance or have safety constraints that must be addressed in every product. And if you do reuse requirements from the library and the initial requirements change, you can be automatically informed of any updates, and with one click, transfer these changes over to your project.
6. Use Polarion to define test cases as requirements are developed, and use powerful workflow to establish testing constraints on a requirement and to link requirements to test cases and plans.

(more…)

We’ve just released an updated version of our open source project SubTrain, our highly appreciated SVN training tool for new and advanced Subversion users and admins. In terms of downloads, it gets far less some of our other open source projects such as the 750,000 users of Subversive; but in terms of customer feedback – SubTrain is loved for its clarity of content, complete coverage of the most important topics, and efficient delivery!

Everyone agrees that SubTrain is a great Subversion training solution that helps cut migration and training costs. Why does Polarion invest time and money in SubTrain and provide it free to the world, when our competitors charge for such quality courseware?

(more…)

Several customers and friends reported to me that they would like to embrace Agile methodologies for their development team. Most of them are, however, concerned about how to Manage Requirements with such an approach. In this post I’m going to provide a few hints that could be beneficial to parallel Agile methods with some light-weight Requirements process.

The Agile Requirements Process

More and more development teams now embrace agile methodologies to enable more dynamic and accelerated project schedules. Agile methodologies such as XP and SCRUM acknowledge that business now moves at a fast pace, and that change occurs frequently and out of necessity in a changing competitive landscape. To that end, organizations have also evolved their requirements management processes – away from a waterfall approach, where requirements are developed up front and handed off to development – to a more agile requirements process that is more tolerant and adaptive to constant change.

An agile requirements process looks like this. First and foremost, elicitation, the initial phase of the requirements process, is not a separate and distinct phase covered by the Agile methodology. Rather, Agile assumes that the customer/end user is an active team member, who contributes to the discussion throughout every phase.

Discussion around requirements occurs during Agile meetings, possibly with Wiki support to facilitate discussion on complex designs and specifications. In the approval stage, user stories are created and assigned to developers on the team. In the verification stage of the process, the same developers present their designs, and explain the implementation of the user stories. During the acceptance phase, stakeholders and users check the product, but likely lack awareness of the existence of other user stories. If change is required, early user stories are simply discarded and forgotten. New user stories are created to correct behaviors and operations within the product.

Agile Process Pros

• Only a small tool investment required – open source or inexpensive defect/change tracking tools will suffice
• Low process overhead
• Developer-friendly
• Easily absorbs change

Agile Process Cons

• Applicable only to a software development project
• Poor process visibility
• Stakeholder interaction is difficult – stakeholders must remain in constant contact with development to remain up to date
• Change triggers a new development path
• No knowledge-sharing

A Better Way – Polarion Requirements + Agile = A More Dynamic Requirements Process

Polarion^® Requirements™ can dramatically improve the agile requirements process, enabling more effective collaboration between team members and remote/removed stakeholders, and facilitating reuse of knowledge. Here’s how:

1. In the discussion phase, team members can use the Polarion Requirements Wiki to capture and draft discussion notes, and document meeting minutes. The Wiki format allows freeform discussion to flow among team members, and invites collaboration and idea sharing.
2. The Polarion Requirements Wiki then feeds the creation of user stories, and manages the lifecycle of each user story.
3. Every stakeholder – even those remote or removed from the team, can participate and has visibility into the ever-changing process through Polarion, which provides complete traceability over discussion threads and project progress against key milestones.
4. Polarion’s seamlessly integrated Wiki and issue management support enables the Wiki to serve as the root and focal point for change tracking, allowing user stories to naturally evolve, but in a managed way with full traceability and control.
5. Polarion Requirements preserves and tracks the complete lifecycle of a user story over time, enabling the team and stakeholders to leverage knowledge and reuse for future projects, thus contributing to overall team efficiency, productivity, and cost control.

Seven Ways Polarion Requirements Benefits the Agile Requirements Process

1. All stakeholders are involved, including those remotely located.
2. There is complete traceability over discussions.
3. There is complete visibility over the project’s progress available to all.
4. Costs remain low as there is a minimal need for tooling (open source or low-cost issue/defect tracking).
5. Tool investments can be leveraged for both issue tracking and user story tracking.
6. Change can be tracked and managed.
7. There is full knowledge capture so future projects can reuse user stories and implementation experiences.

What’s next

In the next post we will address the Formal Requirements Management process, with some tips about how to apply and improve it in your environment.

---

Editor’s Note:
Stefano Rizzo is VP for Product Management at Polarion Software. He oversees the strategic development of Polarion’s software products. You can read his profile at http://www.polarion.com/company/people/index.php.

---

In the previous post we defined the requirements lifecycle and we outlined its formats and capture methods. Let’s now take a look at a few of the ways organizations approach requirements management today. Depending on an organization’s needs, the requirements management process can range from the most simple and rudimentary, to extremely formalized. We’ll also look at ways that Polarion Requirements™ can be used to enhance and improve each method of working.

In this post we will address the manual requirements process. In the next posts we will take a look into the Agile and Formal requirements processes, and then explore the “Polarion Way”.

The Manual Requirements Process

For many organizations, the requirements management process continues to be a manual process. Elicitation is not tool enabled, but is handled through face to face discussions, workshops and meetings. The capture mechanism is typically a Word document, Excel spreadsheet or PowerPoint presentation, sometimes backed by a UML model. In rare circumstances, a Mind Map will be used as the capture method. The discussion stage is handled through direct interaction over the document through meetings, or the document is circulated to stakeholders via email, and comments are gathered through these virtual interactions using the Track Changes feature in Word, or by saving comments conveyed in the email messages.

(more…)