Comparison of Change Management Systems

More documents

Recommendations

Info

38 Software Engineering What’s fundamentally wrong? Improving our approach towards capturing value basic in requirements specification intermediate advanced About the authors: Tom is the author of nine books, and hundreds of papers on these and related subjects. His latest book ‘Competitive Engineering’ is a substantial definition of requirements ideas. His ideas on requirements are the acknowledged basis for CMMI level 4 (quantification, as initially developed at IBM from 1980). Tom has guest lectured at universities all over UK, Europe, China, India, USA, Korea – and has been a keynote speaker at dozens of technical conferences internationally. www.gilb.com, twitter: @imTomGilb Lindsey Brodie is currently carrying out research on prioritization of stakeholder value, and teaching parttime at Middlesex University. She has an MSc in Information Systems Design from Kingston Polytechnic. Her first degree was Joint Honours Physics and Chemistry from King’s College, London University. Lindsey worked in industry for many years, mainly for ICL. Initially, Lindsey worked on project teams on customer sites (including the Inland Revenue, Barclays Bank, and J. Sainsbury’s) providing technical support and developing customised software for operations. From there, she progressed to product support of mainframe operating systems and data management software: databases, data dictionary and 4th generation applications. Having completed her Masters, she transferred to systems development - writing feasibility studies and user requirements specifications, before working in corporate IT strategy and business process re-engineering. Lindsey has collaborated with Tom Gilb and edited his book, “Competitive Engineering”. She has also co-authored a student textbook, “Successful IT Projects” with Darren Dalcher (National Centre for Project Management). She is a member of the BCS and a Chartered IT Practitioner (CITP). Abstract We are all aware that many of our IT projects fail and disappoint: the poor state of requirements practice is frequently stated as a contributing factor. This article proposes a fundamental cause is that we think like programmers, not engineers and managers. We fail to concentrate on value delivery, and instead focus on functions, on use-cases and on code delivery. Our requirements specification practices fail to adequately address capturing valuerelated information. Compounding this problem, senior management is not taking its responsibility to make things better: managers are not effectively communicating about value and Author: Tom Gilb and Lindsay Brodie demanding value delivery. This article outlines some practical suggestions aimed at tackling these problems and improving the quality of requirements specification. Keywords: Requirements; Value Delivery; Requirements Definition; Requirements Specification Introduction We know many of our IT projects fail and disappoint, and that the overall picture is not dramatically improving [1] [2]. We also know that the poor state of requirements practice is frequently stated as one of the contributing failure factors [3] [4]. However, maybe a more fundamental cause can be proposed? A cause, which to date has received little recognition, and that certainly fails to be addressed by many well known and widely taught methods. What is this fundamental cause? In a nutshell: that we think like programmers, and not as engineers and managers. In other words, we do not concentrate on value delivery, but instead focus on functions, on use cases and on code delivery. As a result, we pay too little attention to capturing value and value-related information in our requirements specifications. We fail to capture the information that allows us to adequately consider priorities, and engineer and manage stakeholdervalued solutions. This article outlines some practical suggestions aimed at tackling these problems and improving the quality of requirements specification. It focuses on ‘raising the bar’ for communicating about
value within our requirements. Of course, there is much still to be learnt about specifying value, but we can make a start – and achieve substantial improvement in IT project delivery – by applying what is already known to be good practice. Note there is little that is new in what follows, and much of what is said can be simply regarded as commonsense. However, since IT projects continue not to grasp the significance of the approach advocated, and as there are people who have yet to encounter this way of thinking, it is worth repeating! Definition of Value The whole point of a project is achieving ‘realized value’ (also known as ‘benefits’), for the stakeholders: it is not the defined functionality, and not the user stories that actually count. Value can be defined as ‘the benefit we think we get from something’ [5, page 435]. See Figure 1. Notice the subtle distinction between initially perceived value (‘I think that would be useful’), and realized value: effective and factual value (‘this was in practice more valuable than we thought it would be, because …’). Realized value has dependencies on the stakeholders actually utilizing a project’s deliverables. The issue with much of the conventional requirements thinking is that it is not closely enough coupled with ‘value’. IT business analysts frequently fail to gather the information supporting a more precise understanding and/ or the calculation of value. Moreover, the business people when stating their requirements frequently fail to justify them using value. The danger if requirements are not closely tied to value is that we lack the basic information allowing us to engineer and prioritize implementation to achieve value delivery, and we risk failure to deliver the required expected value, even if the ‘requirements’ are satisfied. It is worth pointing out that ‘value’ is multidimensional. A given requirement can have financial value, environmental value, competitive advantage value, architectural value, as well as many other dimensions of value. Certainly value requires much more explicit definition than the priority groups used by MoSCoW (‘Must Have’, ‘Should Have’, ‘Could Have’, and ‘Would like to Have/Won’t Have This Time’) [6] Software Engineering Figure 1 Value can be delivered gradually to stakeholders. Different stakeholders will perceive different value. or by the Planning Game (‘Essential’, ‘Less Essential’ and ‘Nice To Have’) [7] for prioritizing requirements. Further, for an IT project, engineering ‘value’ also involves consideration of not just the requirements, but also the optional designs and the resources available: tradeoffs are needed. However, these are topics for future articles, this article focuses on the initial improvements needed in requirements specification to start to move towards value thinking. Definition of Requirement Do we all have a shared notion of what a ‘requirement’ is? This is another of our problems. Everybody has an opinion, and many of the opinions about the meaning of the concept ‘requirement’ are at variance: few of the popular definitions are correct or useful - especially when you consider the concept of ‘value’ alongside them. We have decided to Figure 2 Example of Planguage requirements concepts define a requirement as a “stakeholdervalued end state”. You possibly will not accept, or use this definition yet, but we have chosen it to emphasize the ‘point’ of IT systems engineering. In previous work, we have identified, and defined a large number of requirement concepts [5, see Glossary, pages 321- 438]. A sample of these concepts is given in Figure 2. You can use these concepts and the notion of a “stakeholder-valued end state” to re-examine your current requirements specifications. In the rest of this article, we provide more detailed discussion about some of the key points (the “key principles”) you should consider. The Key Principles The key principles are summarized in Figure 3. Let’s now examine these principles in more detail. 39
Page 1: Engineering Productivity: Some ways
Page 4 and 5: 04 Welcome Editor’s note Quarterl
Page 6 and 7: 06 Management Agile software develo
Page 8 and 9: 08 Management driven development—
Page 10 and 11: 10 Management for are developing. O
Page 12 and 13: 12 Management Important factor here
Page 14 and 15: 14 Management behavior. They all lo
Page 16 and 17: 16 Management Figure 2 - Buffer man
Page 18 and 19: 18 Quality in Project Productivity
Page 20 and 21: 20 Quality in Project Engineering O
Page 22 and 23: 22 Quality in Project For example i
Page 24 and 25: 24 Quality in Project measure of en
Page 26 and 27: 26 Quality in Project Figure 1 What
Page 28 and 29: 28 Quality in Project early complet
Page 30 and 31: 30 Software Engineering Comparison
Page 32 and 33: 32 Software Engineering has a poor
Page 34 and 35: 34 Software Engineering or function
Page 36 and 37: 36 Software Engineering Let’s loo
Page 40 and 41: 40 Software Engineering Note, unles
Page 42 and 43: 42 Software Engineering Usability.I
Page 44 and 45: 44 Software Engineering Figure 11 A
Page 46 and 47: 46 Software Engineering cyclical le
Page 48 and 49: 48 Software Testing motivating if t
Page 50 and 51: 50 Software Testing This concept of
Page 52 and 53: 52 Software Testing defects, or the
Page 54 and 55: 54 Software Testing 5. A Critical M
Page 56 and 57: 56 Software Testing Equivalence par
Page 58 and 59: 58 Software Testing little more com
Page 60 and 61: 60 Software Testing Good, now let
Page 62 and 63: 62 Software Testing an important pa
Page 64 and 65: 64 Software Testing the software de
Page 66 and 67: 66 Software Testing Five Types of R
Page 68 and 69: 68 Software Testing Figure 2 A typi
Page 70 and 71: 70 Software Testing Figure 4 Typica
Page 72 and 73: 72 Software Testing Confrontation o
Page 74 and 75: 74 Software Testing Quality Managem

Comparison of Change Management Systems

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?