Design Article
Better requirements analysis eliminates design defects
Mark Pitchford, LDRA Ltd.
11/27/2012 9:01 AM EST
Faulty specs problems
With up to 70% of all project defects traceable to faulty requirement specifications, it is sheer madness to relegate the management of requirements to a low-priority task. Evidence demands that requirements management and traceability should be a key, over-arching activity on any project where quality and stakeholder satisfaction is a concern – and the advent of the ISO 26262 standard with its insistence on it provides a new stick to supplement this carrot.
Project managers need to apply the same enthusiasm for investment in requirements analysis as they do for design and coding. Where system and software modelling has been adopted to increase clarity, reduce ambiguity and achieve abstraction, introduce Use Cases or User Stories for the very same reasons. Where source code is subjected to automated rules checking (e.g. MISRA) and quality analysis (e.g. cyclometric complexity), introduce similar automated checking of requirement specifications (e.g., the presence of particular keywords, the absence of imprecise phrases). Where trace links are specified between code components and the design elements which they implement, add further trace links to requirements and confirm that (i) all requirements in scope have been implemented and (ii) there is no design or implementation element which cannot be traced to a requirement.
Requirements are the foundation of every project. A weak foundation results in high numbers of defects, unforeseen remedial work, spiralling costs, missed deadlines and worse litigation for on-the-road failures. Investment in requirements management, equal to that made for design and coding, is necessary to secure a firm foundation on which to construct a successful project.
1 Software Quality Assurance and Management, Michael W Evans & John J Marciniak, 1987.ISBN 0-471-80930-6
About the author:
Mark Pitchford, a senior FAE, has more than 25 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally including extended periods in Canada and Australia. Since 2001, he has specialised in software test, and works throughout Europe and beyond as a Field Applications Engineer with LDRA Ltd.
With up to 70% of all project defects traceable to faulty requirement specifications, it is sheer madness to relegate the management of requirements to a low-priority task. Evidence demands that requirements management and traceability should be a key, over-arching activity on any project where quality and stakeholder satisfaction is a concern – and the advent of the ISO 26262 standard with its insistence on it provides a new stick to supplement this carrot.
Figure 2: Requirements management and
traceability should be a key, over-arching activity rather than
a low priority task
Project managers need to apply the same enthusiasm for investment in requirements analysis as they do for design and coding. Where system and software modelling has been adopted to increase clarity, reduce ambiguity and achieve abstraction, introduce Use Cases or User Stories for the very same reasons. Where source code is subjected to automated rules checking (e.g. MISRA) and quality analysis (e.g. cyclometric complexity), introduce similar automated checking of requirement specifications (e.g., the presence of particular keywords, the absence of imprecise phrases). Where trace links are specified between code components and the design elements which they implement, add further trace links to requirements and confirm that (i) all requirements in scope have been implemented and (ii) there is no design or implementation element which cannot be traced to a requirement.
Requirements are the foundation of every project. A weak foundation results in high numbers of defects, unforeseen remedial work, spiralling costs, missed deadlines and worse litigation for on-the-road failures. Investment in requirements management, equal to that made for design and coding, is necessary to secure a firm foundation on which to construct a successful project.
1 Software Quality Assurance and Management, Michael W Evans & John J Marciniak, 1987.ISBN 0-471-80930-6
About the author:
Mark Pitchford, a senior FAE, has more than 25 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally including extended periods in Canada and Australia. Since 2001, he has specialised in software test, and works throughout Europe and beyond as a Field Applications Engineer with LDRA Ltd.
|
|
|
|
|
Navigate to related information
WKetel
11/28/2012 3:37 PM EST
Of course it is true in any design or building effort that inadequate plans lead to inadequate results. So the majority of the effort needs to be spent in designing the specifications. After that, the project is just writing code. Of course, writing good and efficient code is no small task, it is a major challenge, no doubt. BUT the first part of the effort is in the development of an adequate specification. Defining responses to all possible exceptions at each stage of a program is both hard and tedious indeed. But if the task were trivial than everybody could do it well, and we can see that is not what happens.
Sign in to Reply