Polarion Software Weblog

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

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

Sprint Meetings

Meetings are possibly the most important assets of Scrum. As described in previous chapters, Scrum allows us to identify problems and help find ways resolve them. Meetings are the essential part when team commits to Product Owner on the amount of work (features) they will address over the sprint, they discuss the progress on Daily Scrums and, finally, access results on the end meeting.

In this post and the next I’ll describe how we manage those meetings with the Polarion development team.

(more…)

Iterative incremental Development

by Nick Entin, VP Research & Development, Certified ScrumMaster

Traditional development supposes long-term planning in advance and performing all relevant activities before product hits the market. Scrum recommends a highly-adaptive way of development with short iterations producing fully tangible results.

Figure 1

Major Benefits of Polarion Scrum Development

• Shorten time to release to the market
• Transparency to management/customers
• Faster reaction to market needs; confidence of customers in Polarion’s development
• Simplifies synchronization of distributed teams
• Faster feedback from the field
• Easier releasing – smaller stabilization sprint, less things to test
• Flexibility in prioritization, risk reduction

(more…)

by Nick Entin, VP Research & Development, Certified ScrumMaster

Why Scrum?

Today many software development companies are switching to Agile Processes and, particularly, to Scrum, for various reasons. Polarion also switched to Scrum for internal development. Why?

There were several reasons, some of them specific to the company (size, area of business, customers, etc.), and others quite general. In this blog I’ll focus on what played a role for us; I won’t try to describe how we would do “if”.
(more…)