Courtesy of United Features Syndicate
You might avoid this kind of situation (or at least deal with it better!) after a look into last November’s Managing RequirementsYour Way series – or you can download the PDF whitepaper based on the series.
Happy New Year from Polarion Software!
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.
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:
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 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.
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 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.
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:
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.
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”.
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.
