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.

Managing Requirements Your Way with Polarion

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:

1. Use Polarion’s Wiki in the elicitation phase to write up your thoughts in Wiki articles with links to ideas, mashups, meeting minutes – basically any piece of information that might help to round out your thinking and provide a clearer picture of the product under development. Quickly and easily circulate information to stakeholders, inviting them to participate and comment, adding their own thoughts to the process, as well as links to their own information sources.
2. Use Polarion’s Wiki history to thoroughly track changes to articles and comments.
3. Extract formal requirements artifacts from these informal discussions, by highlighting the discussions you want included, and clicking on the tool’s extract requirement button.
4. Organize and group formal requirements into modules backed by explanatory wiki content, embedded acceptance criteria, and prioritization information.
5. If you choose, start your elicitation process by reusing requirements from Polarion’s requirements library. This approach can be very valuable for organizations that must include requirements for regulatory compliance or have safety constraints that must be addressed in every product. And if you do reuse requirements from the library and the initial requirements change, you can be automatically informed of any updates, and with one click, transfer these changes over to your project.
6. Use Polarion to define test cases as requirements are developed, and use powerful workflow to establish testing constraints on a requirement and to link requirements to test cases and plans.

(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.

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