Polarion Software Weblog

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

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

We are proud to announce a brand new Polarion Portal – Polarion POP – the place to go for all kinds of extensions to our products. On Polarion POP you can find:

• Integrations with other solutions – Eclipse, Sparx Enterprise Architect, DOORS, just to name a few
• Project and document templates – these can save you time and effort setting up new projects
• Workflow configurations – useful automations to workflows that make life easier and save customization efforts
• Portal and wiki enhancements – custom charts and metrics, wiki utilities like task board, quick tour, Word import and various other practical examples.

…and many more, with new extensions being added all the time.

(more…)

by Nick Entin

Sprint Development

During a sprint, the development team continuously integrates all changes, and updated versions of the product are installed on the internal servers daily to prove stability and allow earlier testing of new functionality by other people (testers, doc writers, etc.)

The Polarion development process stipulates the following:

• An integration build is run at least once per day (usually nightly).
• In case of build failure, the problems need to be fixed ASAP and a new build triggered.
• Failed unit tests should be treated with highest priority, and a build should be triggered again to confirm fixes of the unit tests.
• 20% of each iteration’s development time is reserved as buffer for unpredicted activities (e.g. a critical defect or failed unit tests, or an urgent support request from a customer)
• If for some reason the buffer is exceeded, or senior management requires execution of some unplanned items, the iteration should be cancelled and a new plan created.

(more…)