Managing Requirements your way (Part 4)

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.

Due to the size and scope of the team and stakeholders involved, and due to storage methods for requirements – which provide limited to transparency for stakeholders, discussion in a formal requirements process is nearly impossible to achieve outside of formal meetings. Ad hoc feedback into the process is very difficult to capture and manage.

The approval phase in the formal requirements management process is handled through the generation of a requirements document that can easily run to 100s of pages in length. This document may be generated by hand, or exported from the legacy requirements tool, and then circulated via email to team members and stakeholders, who will review the document and either accept it, or reject it. Accepted and rejected versions of the document are returned to the requirements engineer, who is burdened with sifting through the various versions, reviewing comments, and piecing together any requests for change. This manual effort is painful, time consuming, and prone to error, as it is easy to miss changes, or improperly reconcile the required edits. The next edition of the document is created to fold in all feedback, sent out to the troops for comment, and the painful review cycle begins again.

Verification in a formal requirements process can be performed through a questionnaire, detailed inspection or walkthroughs, or various forms of testing driven by a separate and dedicated team, who may also play a hand in the creation of acceptance criteria.

It is in the acceptance phase of the formal requirements process that the customer finally has an opportunity to participate. The client, who was locked out of discussion, and had no ability or access to review requirements in the system, now has an opportunity to inspect the near final product. And more often than not – is dissatisfied with the result. Change is demanded, but as the product is essentially all but complete at this stage, change also requires the launch of a new project. Change midstream in this formal requirements process is almost completely unthinkable – and if change is introduced, or new requirements added, it is impossible to assess the impact of change on the project’s timeline, costs or resourcing.

Formal Requirements Process Pros

• Well suited to highly regulated industries, projects with external quality or safety pressures, and large projects where a high degree of control over information is needed


• Supported by established methodologies, tooling, and templates for elicitation, verification, and approval

Formal Requirements Process Cons

• Heavy weight and overbearing for smaller organizations and teams


• Ad hoc or informal communication within this process is challenging and difficult to track across widespread team members


• Change comes from multiple sources, may conflict, and is painful and time consuming to merge


• Risk of customer dissatisfaction with the final product is high

A Better Way – Polarion Requirements and the Formal Requirements Process

Polarion Requirements can be an instrumental boon for organizations that must follow a formal requirements management process. Polarion’s unique Web-based collaborative model can overlay a formal RM process and fix many of the communication and collaboration problems that bog down each phase of the requirements lifecycle and directly contribute to project delays, cost over runs and failed products. Here’s how Polarion Requirements can improve a formal requirements process:

1. In the elicitation phase, use Polarion Requirements to transform what today is a static and non-collaborative process into one that is dynamic, and participative.


2. Information and requirements elicited from users by requirements engineers and contained in Word documents, Wiki discussion threads, text files or UML models become dynamic web-based entities via Polarion LiveDocs™, and can be easily shared among geographically distributed team members, partners and stakeholders.


3. Enable large distributed organizations to collaborate faster and with greater ease, through the overlay of Polarion’s Web-based Wiki and discussion threads – with direct hyperlinks to underlying requirements.


4. Completely track all changes to requirements documents and maintain a granular version and history of requirements and entire requirements documents with automatically generated links to tasks, diagrams, Wiki articles, discussion threads, source code, and other development artifacts.


5. Use Polarion to build a repository of process knowledge for your team, providing you with one centralized place where states, constraints, business rules, and metrics can reside.

Seven Ways Polarion Requirements Benefits the Formal Requirements Process

1. Increase visibility into complex and highly formalized processes for stakeholders, executives, auditors, and partners.


2. Facilitate discussion and collaboration among large, distributed teams


3. Construct process knowledge within the tool, to accelerate process maturity without the need for training


4. Reduce misunderstandings and improve clarity- build the right product


5. Record and archive all artifacts related to requirements – including prototypes, models, and mashups


6. Maintain a full history of requirements and requirements documents over time


7. Out of the box change management and impact analysis to understand the ripple effect of change on timelines, schedules, costs and resourcing

What’s next

In the next post I will address Polarion Software’s way, that is, our special way in managing requirements while developing a huge application… Polarion itself.

---

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.

---