Requirements Lifecycle Mgmt - Key To Successful Projects

Whether you are producing a product, an application, a system, or a service, requirements drive the development process. Industry studies show that poor requirements definition and requirements management practices are the largest contributor to project failures, while good requirements definition and requirements management practices are a major contributor to project success.

The requirements definition and requirements management process isn’t just a one-off, upfront step in the project lifecycle. Requirements form the thread that connects all the disciplines of development and quality assurance together around common objectives; furthermore, requirements provide the contract between the customer and the development team. Requirements Lifecycle Management practices, techniques and tools cover the whole requirements process:

• Requirements elicitation (requirements capture)
• Requirements definition
• Requirements validation
• Requirements analysis
• Requirements modeling
• Requirements management
• Requirements traceability
• Requirements-based testing

Requirements definition and management is recognised as a necessary step in the delivery of successful systems and software projects; the discipline is also required by standards, regulations, and quality improvement initiatives like CMMI.

Creating and managing requirements is a challenge for IT, systems and product development projects or indeed for any activity where you have to manage a contractual relationship. Organisations need to effectively define and manage requirements to ensure they are meeting needs of the customer, while proving compliance and staying on schedule and within budget.

The impact of a poorly expressed requirement can be devastating; it can have a domino effect that leads to time-consuming rework, inadequate deliveries and exceeded budgets. Even worse, a poor requirement can bring a business out of compliance or even cause injury or death.

As requirements are the foundation of any development project, teams need to understand the attributes of a ‘good’ requirement. The best requirements are:

• Correct (technically and legally possible)
• Complete (express a whole idea or statement)
• Clear (unambiguous and not confusing)
• Consistent (not in conflict with other requirements)
• Verifiable (it can be determined that the system meets the requirement)
• Traceable (uniquely identified and trackable)
• Feasible (can be accomplished within cost and schedule)
• Modular (can be changed without excessive impact)
• Design-independent (does not pose a specific solution on design)

Writing better requirements is an activity that can deliver a high, fast return on investment. This paper explains the characteristics of a ‘good’ requirement and presents ten best practices for writing better requirements:

Best practice 1: Structuring requirements

Duplicate requirements can cause work to be performed twice, lead to conflicts, and eventually double your maintenance cost. Omitted requirements may lead to missing functionality or cause shortcomings. Requirements should be structured to enhance understanding while avoiding duplication and omission. Traceability to higher- and lower-level requirements enables teams to assess coverage.

Best practice 2: Managing and linking customer needs, requirements and contractual documents

Organisations typically collect the customer’s needs, captured ‘as-is.’ These needs undergo an internal translation to requirements in a format that meets the ‘good’ requirements characteristics described above. They may also be made more generic and less customer-specific (so the system can meet multiple customer needs). There is also often a stable contractual agreement, a legally binding third document.

Best practice 3: Managing constraints

Requirements must not only describe functional behavior. Non-functional requirements, also called constraints, can be critical for compliance and regulations and add quality to the system. Typical non-functional requirements can specify:

• Performance
• Interface
• Security
• Safety
• Reliability
• Availability
• Maintainability

Best practice 4: Visualising requirements

Most requirements analysts find augmenting textual requirements with modeling helpful, whether this means drawing pictures on a white board, utilising presentation tools such as Microsoft PowerPoint, or simply creating a mental model. These representations should be managed alongside the requirements to ensure consistency, traceability, and change control. Visual requirements modeling provides a simple and powerful way to communicate with and elicit requirements from customers and end users. It also helps clarify requirements and create a common understanding between all development team members and stakeholders.

Best practice 5: Testable requirements

An efficient way of writing better requirements is to ensure they are clearly mapped to test cases. Making sure each requirement is clearly verifiable from the start not only helps prepare later phases of the project, it also puts the writer in the correct state of mind. Note that this is true for the nominal functional mode (making sure the system or software does what it’s supposed to do). Requirements and their associated tests must also indicate what the system should not do.

Best practice 6: Bridging the chasm between business and development

In many cases, writing better requirements is aided by having fewer requirements. Projects cannot always offer the luxury of implementing all customer requests, marketing ideas, and business suggestions when they also have to meet budget and deadline objectives. Rather than trying to manage every requirement, project and product managers must be able to make decisions on those requirements that bring the most value to the customer and help the business improve innovation. This can be achieved by combining value and priority information from stakeholders and defining the right combination of requirements.

Best practice 7: Requirements change control

In most projects, requirements are subject to continual change. As a project progresses, organisations need to remain agile, adapt to engineering imperatives, and respond to evolving market situations and customer needs. Writing a perfect first requirement is insufficient if its evolution isn’t well-managed – poorly controlled change can lead to inadequate systems and software, rework effort, and loss of revenue.

Best practice 9: Example knowledge database

By providing examples and counter-examples of good requirements and documents, organisations can enhance the quality, consistency, and completeness of their requirements. These can originally be templates, industry standards and rules inside a repository, or a corporate intranet.

Best practice 10: Smart reuse of requirements

When a good requirement has been written for a previous project and it is applicable to a present situation, the natural reaction is to re-use it, generally by copying and pasting the description. This unfortunately breaks the traceability and eliminates impact analysis. A smarter approach to re-use is to maintain a link between the two requirements (for example, creating a ‘re-use’ type link). This enables analysts to access the original requirement at any time to check allocation of implementation, for instance. Likewise, any changes made to the original requirement (issues detected, updates needed) can lead to the notification of reusing teams.

*Source: Telelogic whitepapers

Kadambi is practice manager - RM & CM, Telelogic.