IBS Journal October 2015


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 organisation, the effectiveness of requirement definition is a critical determinant of a succesful system roll-out. Sudeep Nair, director at Cedar Management Consulting, 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/non-func- tional 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 are staggering. Typ- ical 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 require-


ments elicitation and elaboration phas- es 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 function- alities are getting more intertwined, man- agement of the requirement engineering process can make or break the projects


Pitfalls in approach to requirement engineering


Most organisations tend to undertake re- quirement 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’.


50


Figure 1: The need for effective requirements engineering Business requirement premium


10% 20% 30% 40% 50% 60% 70%


0%


Requirements Time


High Quality Budget


Low Quality Requirements


0% 20% Definition 40% Analysis 60% Design 80% Coding 100% Others


Budgetary Expenditure Consumption


60%


Premium paid on time & budget due to poor requirement practices


41%


of IT budget used by poor requirements


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 engag- ing a product vendor for requirement engineering is that vendors often define requirements in a way that benefits their own interests.


© IBS Intelligence 2015 www.ibsintelligence.com


20%


of companies invest in excellent, repeat- able business & software requirements


71%


of software projects fail due to poor requirements management


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 re- quirement 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.


analysis: requirement engineering


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60