Polarion Software Weblog

You’ve done your homework and you know you’ve come across a great solution (namely Polarion ALM or Polarion Requirements!) that would be a major benefit to your organization. But management wants you to show them the “Return on Investment” (“ROI” in execu-speak). What? You manage development projects, you’re not a number juggler. You know Polarion is worth every (Euro or US) cent, but how do you get that across to the boss? Never fear… help is at hand! Polarion has a handy online tool that will help you deliver solid justification for investing in Polarion solutions, and this article will tell you everything you need to know about how to use it. So let’s get down to it.

Understanding ROI

Return on Investment (ROI) is a performance measure used to evaluate the efficiency of an investment and compare it to alternative investments. ROI tells you how and how soon an investment pays back, and how much total return you end up with. In essence, it’s a way of gauging BENEFIT in concrete terms. But benefit is different with different investments.

For example, suppose you invest in a spiffy new sports car. The only benefit is fun, and the benefit kicks in immediately when you sit in the driver’s seat with an empty highway before you. The only person to question the investment is you. (Well, some spouses/”significant others” may have something to say about it too.) But in business, the benefit accrues not to you personally (although your workday may well improve as a result) but to the entire organization, and payback typically takes some time.

That’s enough background to go on. Let’s move on to the Polarion Online ROI Calculator and learn how to use it to justify your proposed investment in Polarion lifecycle management solutions.

Where is it?

The ROI calculator is here: www.polarion.com.roi/ (Yes, you should bookmark it now!)
(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.
(more…)

While Agile methods are becoming more and more popular in Software Development shops, Requirements Management is a formal discipline widely adopted and adapted in System Engineering and in general inside those companies that have to comply with strict regulations and norms.

The Formal Requirements Process

The formal requirements process evolved first in industries such as the military aerospace and automotive sectors where organizations are subject to strict regulatory compliance and to external quality pressures. Projects are typically large in scale, and span longer time periods – months to years, involve large teams of staff (tens of hundreds of engineers, software developers, project management experts, stakeholders) and the products under development frequently have software and hardware components that must move forward in parallel.

The product development process here is typically quite linear (Waterfall) in nature. Requirements are elicited by requirements engineers in a formalized way – using an established methodology for specifying requirements such as Volere. Information is captured through JAD sessions, meetings, interviews, and questionnaires, involving multiple stakeholders and external partners and gathered through elicitation and is captured in meeting minutes, and then copied onto individual cards or recorded into a requirements management system. Requirements analysts may also leverage requirements elicitation tools, modeling tools such as UML diagrams, block/ball/comic diagrams, mash ups, mind maps, technical diagrams and schemas to round out a picture of the system being designed. Change to requirements within specification documents can be difficult to manage, especially when they occur at a fast rate or in high volumes.

(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.
(more…)

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…)