Polarion Software Weblog

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

Intro

In this Blog series I will try to reveal new ways to improve your requirements process – regardless of your starting point or requirements process. In this post I will define the requirements process and outline the various capture methods available today. In future posts we’ll look at the pros and cons of various common approaches used by organizations today to manage requirements, from the simplest manual process, to agile processes used in software development organizations, through to the most formal requirements process – and in each case, outline ways Polarion Requirements can be leveraged to better each process method.

Finally, for organizations that are approaching the requirements discipline for the first time, or who have a requirements process that is in-between the processes we’ve described – not too agile or not formal – I will share some recommended best practices for requirements management that we at Polarion have cultivated through our own experience in developing software, all of which can be easily enabled with Polarion Requirements or Polarion ALM Enterprise and implemented within any organization.

Why requirements?

In computing science terms, requirements management remains an immature discipline. While best practices surrounding the requirements management process and tooling continue to advance, there is tremendous opportunity for organizations to tighten up their product development process through greater maturity of the requirements management discipline.

Failure to properly define and manage requirements is often at the root of software project and product failure. It is a business reality that customers and management rarely know, or can describe in exact terms what they want at the end of the day. And too often, these same business sponsors will change their mind midstream – causing requirements to change. The impact of change even early in the project causes a downstream ripple effect, impacting project schedules, deadlines, delivery dates, and staffing commitments.

The ultimate goal of requirements management is, at the end of the day, to ensure that the final product meets the needs of the business. While this seems like a simple task, the process of articulating business needs or specifications, especially for complex products or software applications, is immensely difficult and requires significant elicitation and communications expertise plus advanced technologies to absorb, and manage detailed requirements and groups of requirements through to successful product/project delivery.

Organizations are individual in their approach to requirements management. Some companies and teams continue to rely upon manual processes – opting for a simple, tool-free approach that costs nothing and presents no learning curve. Others, such as a software development team who have embraced an agile development process, such as SCRUM and XP, demand a more fluid and transparent requirements process and lightweight tools that allow for iteration and frequent change. And finally, there are organizations with complex product development processes or in regulated industries that need a highly formalized and rigid requirements process and significant tooling support.

(more…)