REQUIREMENT ENGINEERING FOR TECHNOLOGY PROJECTS: IT HAS TO BE CRISP

Organisations invest significant effort in selecting technology systems that meet the functional, technical and financial criteria. However, since most systems need to be customised to specific requirements of the organization, the effectiveness of requirement definition is a critical determinant of a successful system roll-out. This article describes an approach for ensuring that requirement specifications accurately reflect expectations of end-users.

Requirement engineering is a phase within an IT project where functional/ nonfunctional requirements and user interface designs are discussed with business and documented as the basis for development of technology solutions.

The statistics regarding the importance of this phase in IT projects is staggering: Typical issues faced by IT teams in requirement engineering include scope creep, neglecting technical feasibility, inconsistent or ambiguous requirements inconsistently, and inability to trace requirements back to the solution components.

Effective management of the requirements elicitation and elaboration phases continues to pose one of the greatest challenges to IT organisations. In an age of increasing complexity of IT systems in which software programmes and functionalities are getting more intertwined, management of the requirement engineering process can make or break the projects.

PITFALLS IN APPROACH TO REQUIREMENT ENGINEERING

Most organisations tend to undertake requirement engineering within their IT Team because business usually does not have the requirement resources to dedicate to this activity. Alternatively, they engage product vendors to help them in requirement engineering, assuming that they are best placed to define requirements since they are owners of the underlying ‘product’. This leads to the requirement engineering process getting undermined by several limitations:

• Inadequate skillset: preparation of requirement specifications is a specialised job, requiring a blend of technical and functional skills. Most organisations do not possess these skills in-house.
• Vendor bias: the downside of engaging a product vendor for requirement engineering is that vendors often define requirements in a way that benefits their own interests.
• Insufficient review by business: business users are typically bogged down by their regular work routine and do not get sufficient time to prepare or review the requirement specifications. As a result, many crucial requirements are left unstated, and these requirements surface as unmet expectations during the testing phase.
• Accountability: project teams often struggle to fix accountability related to the quality of requirement specifications. Both business and technology vendors usually do not consider it a part of their core responsibility. As a result, this crucial activity is often given inadequate focus.
• Misalignment with functional specification documents (FSDs): vendors prepare FSDs aligned to business requirement documents (BRDs) but many organisations lack internal resources to validate the alignment between the FSD and BRD documents.

REQUIREMENTS SHOULD BE CRISP

Ideal requirement specifications meet the ten criteria given in the figure below:

The CRISP framework can help in ensuring

that requirement specifications serve as the basis for high quality technology solutions. Each dimension of the CRISP framework can be measured as follows:

The CRISP framework helps organisations to define requirement specifications that accurately reflect business expectations. The following key elements help in smooth requirement engineering based on the CRISP framework:

• Consultative skills: seasoned business consultants capable of engaging with business and documenting requirements.
• Requirements repository: a predefined set of requirements for each solution, which accelerates the process of documentation and lets business focus on the true differentiators.
• Access to best practices: authors of requirement specifications have access to best practices and innovations so that they can embed them into the requirements and truly help in developing a future-ready solution.
• Tools: requirement assurance team use tools that help in documenting, indexing and cross referencing the requirements.

REQUIREMENT ENGINEERING METHODOLOGY

To meet the requirements of the CRISP framework, the requirement specification team should follow a welldisciplined methodology for eliciting and documenting the requirements. The requirement engineering team should use a number of accelerators to facilitate the solution development process.

A typical cycle for requirement engineering consists of the following phases:

CONCLUSION

IT teams should approach the requirement engineering phase with the

principle of ‘well begun is half done’. A well-defined set of requirements serve as the basis for a robust IT solution design, which in turn leads to a solution that truly aligns to the users’ needs.

Author | Sudeep Nair

For a further conversation on this subject of Cedar View or how we may be able to help please reach us, Cedar at india@cedar-consulting.com

Download PDF