Prevention better than cure – get requirements right first time
Conclusion: Unless the attributes of user stories (agile) or high-level requirements (waterfall) are succinct and testable, business systems specifications will lack rigour and could compromise the system’s integrity. To ensure these attributes, i. e. succinct and testable, are present, the stories and high-level requirements should be peer reviewed to identify content that is unclear or just expressing an unrealistic ‘want/wish’ list.
It is important the stories or high-level requirements contain sufficient context to enable systems requirements, i. e. functional and non-functional, to be developed because unless they do it will be difficult to prioritise them based on business drivers.
Similarly, the results of user acceptance testing should be peer reviewed to ensure the agreed requirements have been met and the output is verifiable.
About The Advisor
Alan Hansell
Alan Hansell is an IBRS advisor who focuses on IT and business management. Alan is able to critique and comment on IT and business management trends, ways to justify and maximise the benefits from IT-related investment, IS management development and the role of the CIO. Alan has extensive experience in IT management, consulting and advising senior managers in matters related to IT investment. He was a Director in Gartner's Executive program and adviser to over 50 CIOs and business managers and before joining Gartner a consultant with DMR Group. He also worked as an IS professional, manager and industry consultant for IBM for nearly 30 years. Alan is a CPA and Associate of Governance Institute of Australia.