Polarion Software Weblog

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

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