tag:blogger.com,1999:blog-20659000662255756782024-03-09T00:21:57.793+00:00The Nexus - Stakeholders, Requirements and ValueContributions to stakeholder, requirement and problem-solving topics. ("Requirement" is defined as stakeholder value, with qualification. "Problem" is defined as a subset of stakeholder value: which value for which stakeholder. "Stakeholder" is defined, operationally, as the advocate for value.)AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.comBlogger28125tag:blogger.com,1999:blog-2065900066225575678.post-73360150003116904742008-01-30T09:41:00.000+00:002008-01-30T13:20:12.307+00:00Perception, Misperception and CounterfactualsAn alternative title for this post would be "Requirement Underpinnings".<br /><br />To begin, let's fence off the philosophical brink of solipsism. The practical world of providing value to stakeholders (whatever that means) is grounded by the assumption that there is a "real world" that is capable of change. This "real world" is assumed to be the source of sensory inputs that lead to perception. In this context, "perception" is distinguished from "reception". That is, for example, whereas the eye receives sensory input in the form of photons interacting with the retina, the mind perceives an image. Exactly how this happens need not concern us; suffice it to say that it is a complex distributed process that is less than perfect.<br /><br />Perception, then, is an imperfect representation of an external reality: a model, a set of beliefs, a theory. So how does it differ from misperception? Psychologically, there is no real distinction, at the time of (mis)perception: misperceived reality is as real to the misperceiver as perceived reality is to perceiver. This is similar to the semantic distinction between knowledge and belief. Part of the distinction, skirting the epistemological minefield, is that knowledge is "true" by definition. Likewise, perceptions are "more accurate" beliefs whereas misperceptions are "materially inaccurate". Another distinction between knowledge and belief, also applicable to (mis)perception, is the degree of conviction. For a belief to be a plausible candidate for the epithet "knowledge", within the mind of the believer, the believer must be convinced of its "truth".<br /><br />It is to be hoped that "requirements" are underpinned by accurate perception rather than inaccurate misperception. Although in practice this cannot be assumed to be the case, we can assume that it is for the purpose of this exposition. When a mind contemplates the "real world" being different from how it is, it is operating in the domain of "counterfactuals", rather than "misperception". The psychologigal reaction to the difference between (perceived) actuality (or "real world") and the (contemplated) counterfactual is some combination of attraction and aversion. Leaving aside deeper consideration of the theory of mind, it seems to be in the interplay between such reactions to the counterfactual that the intention to sustain or alter the actuality arises.<br /><br />To some extent, such reactions may be rational. And to some extent, non-rational reactions may be perceived by the mind itsef as rational. This, however, is a topic for another time. The term used here to represent the complex intention of the mind is "value". We put to one side the psychological processes that lead to the perception of "value", together with the underlying conflicts that, in practice, are often the source of inconsistency. So our focus is on the conscious and rational perception of value in the mind. This is not to suggest that "requirements" cannot arise from the non-rational or non-conscious, however.<br /><br />So we move on to effecting or preventing real change to the actuality. Because the mind perceives positive or negative value from a contemplated change, it makes decisions that it believes will increase the likelihood that its more valued state of affairs will be the actuality. By the effect of these decisions, "words" and "deeds" (and silence and inaction), another mind draws inferences about what is valued. There is, in short, "communication". Communication is necessarily imperfect, since it is a form of perception; the perceiving mind incorporates beliefs about the other mind into its model of external actuality (and, indirectly, into its couterfactual models). The important point is that communicated value is qualitatively different from uncommunicated value. Under what circumstances either should be considered a "requirement" is, of course, purely a question of semantics. But it is only in the realm of communicated value that the "requirements practitioner" can operate, whether by stimulating or responding to the communication.<br /><br />How communicated value translates into explicit requirements (however imperfectly specified) is considered in <a href="http://www.gilb.com/community/tiki-download_file.php?fileId=125">an earlier post</a>.AlanAJ01http://www.blogger.com/profile/02622385662655064132noreply@blogger.com3tag:blogger.com,1999:blog-2065900066225575678.post-38737528112480576462008-01-29T14:19:00.000+00:002008-01-29T16:00:28.402+00:00Requirements RevisitedA recent post on the <a href="http://requirements.seilevel.com/messageboard/forumdisplay.php?f=3">Seilevel Forum</a> asks: <a href="http://requirements.seilevel.com/messageboard/showthread.php?t=843"><i>What do Testers Test?</i></a> Is it against the requirements or the design specification. A partial answer is "either or both, it depends". The standard v-model of testing suggests that there is testing appropriate to each level of specification. How much you do of each is a classic trade-off question.<br /><br />But it seems to me that the received wisdom overlooks an important consideration, one that is generally missing from requirements practices. The important point is that specifications do not generally specify absolute outcomes (so they're a bit of a misnomer in that regard). What they do specify is a range of valuable outcomes, what <a href="http://cauvin.blogspot.com/">Roger Cauvin</a> has referred to as the <a href="http://cauvin.blogspot.com/2005/06/definition-of-requirement.html">"least stringent condition"</a>.<br /><br />Clearly, if the design specification calls for behaviour that is more stringent than the requirement specification, compliance with the design specification implies compliance with the requirement specification, so testing both involves redundancy. More importantly, though, what you really want to test against is the <strong>most</strong> stringent condition or, perhaps, the most stringent condition <strong>of value</strong>.<br /><br />This post is entitled <em>Requirements Revisited</em> because that is what we ultimately need to test against. Not what we think is wanted; not what we asked for; but what we're told we've got! Or, at least, as much of what we're told we've got as we think is valuable.<br /><br />If our super developers claim to have given us extra performance or potentially useful unrequested function, testing provides evidence for such claims (though it is not the only source of evidence). But if we don't need it, why prove it works? Only because (or when) the risk of not doing so exceeds the cost. I have worked on extremely flexible systems in the past where the extent to which a capability had been tested was more of a limitation, in some cases, than the function or performance. We lacked a formal approach to revisiting the requirement specifications, so we could end up with change requests whose only impact was additional testing or risk assessment.<br /><br />In short, for each element of any level of specification, there is (or should be) a claimed level of satisfaction. After testing (or other validation), there is a proven level of satisfaction. Any case where the claimed level of satisfaction exceeds the proven level is an identified risk. Signoff on testing constitutes acceptance of the identified risks.AlanAJ01http://www.blogger.com/profile/02622385662655064132noreply@blogger.com2tag:blogger.com,1999:blog-2065900066225575678.post-74579740081553482832008-01-26T16:01:00.000+00:002008-01-26T16:35:50.891+00:00My Introduction to Luke HoughtonI promised I would share which <a href="http://lukehoughton.com/blog">Luke Houghton</a> post was the first I read. The title of this post links to it. In part, what impressed me most immediately about this post, in the first few words, was the almost casual way he shrugged off the reader's preconceptions. In this way, it calls to mind the brilliant beginning of Diderot's <span style="font-style:italic;">Jacques le Fataliste</span>.<br /><br />Bloggers of the world, you have about 2 seconds to retain and augment my interest. So far, none has succeeded as effectively as Luke. Of course, in part that is due to my own state of mind at the time. But the immediacy of the connection is largely Luke's responsibility, whether achieved by contrivance or the mysterious operation of a spark of genius. <br /><br />Once he'd grabbed my attention, he had to deliver! And he did. The ideas weren't the best I'd come across that day, but they were worth reading. There is no need for a detailed critique. You now know where to begin. Begin!AlanAJ01http://www.blogger.com/profile/02622385662655064132noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-23062357961767689082008-01-23T00:15:00.000+00:002008-01-23T00:37:36.293+00:00AgoraphiliaI'm not a natural blogger.<br /><br />The only reason I created this blog was as a publicly accessible link between my contributions on other people's blogs and fora.<br /><br />I've found it useful, myself. But I wonder how useful others have found it...<br /><br />Well, little by little we learn. Until now, I suppose I've been more concerned about the possibility than the occurrence. Now, I think it may be time to give social networking a try. I've signed up for del.icio.us and subscribed to the requirement tag. Perhaps that's why you're here?<br /><br />Welcome!AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com1tag:blogger.com,1999:blog-2065900066225575678.post-86865900822884201642008-01-20T14:46:00.000+00:002008-01-20T19:15:21.153+00:00Discovering Luke HoughtonIn a later post, I'll create a link to the first <a href="http://lukehoughton.com/blog">Luke Houghton</a> blog post that I came across, via a link from someone else's blog. I'm just grabbing bragging rights here: I spotted the Luke Houghton phenomenon before it began. Reading that very first blog, I recognised someone with <i>eine ganz besondere Weltanschauung</i>. In a little while, I'll begin to explain what makes Luke Houghton special. For the time being, let's just be content to read his blog and reflect. And if you already have, why not read mine and leave your mind open to the possibilities of synthesis...AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com2tag:blogger.com,1999:blog-2065900066225575678.post-39465694413254501232007-09-12T15:37:00.000+00:002007-09-12T15:39:31.493+00:00Why Separate Business Rules from Requirements...and if you do, what requirements are left?AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-13860140466589279052007-09-11T16:13:00.000+00:002007-09-11T16:19:55.297+00:00Prioritization and Value Maximization [Tyner Blain]Very powerful introduction to the value-driven approach.AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-39068035497109170192007-09-11T15:55:00.000+00:002007-09-11T16:13:31.699+00:00Writing Good Requirements: The Big Ten Rules [Tyner Blain]There are actually twelve mentioned. We discuss the relative priorities in the comments.<br /><br />There's far too much good reading on the <a href="http://tynerblain.com/blog/">Tyner Blain blog</a>!AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-58290726376836689062007-09-11T13:33:00.000+00:002007-09-11T16:26:25.149+00:00Are Business Rules Requirements [Tyner Blain]Yes!AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-80574161270481445822007-08-18T17:04:00.001+00:002007-08-18T17:04:52.154+00:00David Crystal's blogAlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-61036948082297906712007-08-18T15:13:00.000+00:002007-08-18T15:16:43.907+00:00My Seilevel requirements discussion postsI feel the need, one day, to integrate the ideas in my posts to the <a href="http://requirements.seilevel.com/messageboard/search.php?searchid=4108&pp=25">Seilevel forum</a>. Until that day arrives, my contributions can be found by following the link.AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-37057237163912078162007-08-18T10:48:00.001+00:002007-08-18T10:48:44.547+00:00Weinberg on Writing: Writing Exercise 1. The Missing Letter<a href="http://weinbergonwriting.blogspot.com/2006/04/writing-exercise-1-missing-letter.html#links">Weinberg on Writing: Writing Exercise 1. The Missing Letter</a>AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-2673472916470382282007-08-18T10:48:00.000+00:002007-08-18T10:57:17.643+00:00Weinberg on Writing: Breaking the Reader Trance<a href="http://weinbergonwriting.blogspot.com/2007/06/breaking-reader-trance.html">Weinberg on Writing: Breaking the Reader Trance</a><br /><br />This helped crystallise some thinking on the question of the true or false dichotomy between the role of stakeholder and user. See: <a href="http://requirements.seilevel.com/messageboard/showpost.php?p=3020&postcount=23">Breaking the Stakeholder Trance</a>AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com1tag:blogger.com,1999:blog-2065900066225575678.post-57098916729892275012007-08-17T18:42:00.000+00:002007-08-17T18:42:17.471+00:00Weinberg on Writing: Writers' delusions<a href="http://weinbergonwriting.blogspot.com/2006/04/writers-delusions.html#links">Weinberg on Writing: Writers' delusions</a><br />If Jerry says readi it, you'd better read it!AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-7807789698596354062007-07-05T12:56:00.000+00:002007-07-05T13:17:58.116+00:00Requirement QuestionsMy original post to the Portland Pattern Repository appears to have emerged unscathed (as at the date of this post). Comments here or there much appreciated, of course.<br /><br /><blockquote>What are the benefits of meeting the requirement (or the consequences of not meeting it)? [Value] <br /><br />Is the purpose of a required feature documented? [Purpose] <br /><br />Who is accountable for the organisation's achievement of the stated purpose? [Owner] <br /><br />How might the extent to which the requirement is met be ascertained? [Measure] <br /><br />Who is interested in the extent to which the requirement is met? [Stakeholder] <br /><br />What is the business context within which the requirement should be met? [Context] <br /><br />Within what timescales should the requirement be met? [Timing] <br /><br />What risks are associated with the requirement? [Risk] <br /><br />Does the requirement have a single purpose? [Atomicity] <br /><br />What is the immediate 'parent' requirement? [Parent] <br /><br />Does meeting all the 'child' requirements equate to meeting the requirement itself? [Complete] <br /><br />With what other requirements does the requirement conflict? [Conflict] <br /><br />What requirements (other than its parent) does the requirement support? [Support] <br /><br />What are the underlying assumptions? [Assume] <br /><br />Why has the requirement been documented? [Motive] </blockquote>AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-12834509436428544192007-07-05T08:18:00.000+00:002007-07-05T11:59:08.903+00:00Stakeholder Value Trade-offsI've been thinking quite a bit recently about "knowing when to stop" or, at least, pause. My Seilevel post (title link) addresses this in a particular context from a theoretical perspective, and also suggests that practice differs from theory.<br /><br />My current thinking is that this sort of low-level decision is a <strong>stakeholder value trade-off</strong> even though it is rarely treated that way in practice. Stakeholder value trade-offs are a special case of <strong>value decision</strong> or what I call <strong>value decision deltas</strong>.<br /><br />In this context, a "delta" is a change rather than a dendritic multifurcation. The connotations of the latter, and the implication from calculus in the former of infinitesimal changes have influenced my settling on this term.<br /><br />I have written an elucidation of the following, but for the time being, let it stand on its own many feet:<br /><br /><strong><blockquote>The level of “decidedness” is optimal (for the time being) when all positive and negative decision deltas have non-positive risk-adjusted net stakeholder value.</blockquote></strong>AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-44109906140691767832007-07-04T16:07:00.000+00:002007-07-04T16:47:39.625+00:00Tom Gilb's Concept Glossary<a href="http://www.gilb.com">Tom Gilb</a> has updated his <a href="http://www.gilb.com/community/tiki-download_file.php?fileId=125">Concept Glossary</a>, including my comments on his definition of the requirement concept (below), which he is kind enough to describe as "a particularly well thought out notion of requirement". <br /><br />(The numbers in parentheses, preceded by an asterisk, refer to other concepts in Tom's glossary. The numbers in brackets refer to footnotes in the original; these follow the main text.)<br /><br />1. The people whose ends a system (*145) serves are one class of stakeholders. They value the actual results, or <strong>receive</strong> benefit (*009)[1].<br />2. The people who consider the future of a system and/or agree to the suggestions of others are a different class of stakeholders. They <strong>perceive</strong> potential value (*269).<br />3. If these people take ideas forward (deciding to act or persuading others to decide to act, or considering the desirability of action), they can be described as “Founders”[2] of the resultant system or course of action.<br />4. The arena within which action may occur is variously described as the “problem domain”, “scope” (*419) or “context”[3].<br />5. A perception of value within a particular context for action is a potential requirement.<br />6. A potential requirement coupled with authority (*005) or discretion[4] to pursue its satisfaction is a requirement. The person[5] who confers the authority is the requirement’s “Sponsor”.<br />7. So, a requirement is a perception of value in a particular context for action coupled with the authority to pursue[6] its satisfaction: the <em>authorized and contextualized pursuit of value</em>.<br />8. The substance of a requirement (what is required) is the value. That of which it is a requirement is a future system[7]. The context within which it is a requirement includes the project or endeavor (“development environment”) and the anticipated operating environment. Explicit or implicit authority to pursue the requirement (within a particular context[8]) is a status of the requirement (in that context).<br /><br />There are footnotes in the original:<br /><br />[1] Because these stakeholders can only receive benefit from an operational system, they can be referred to as “operational stakeholders”.<br />[2] Or “Originators”<br />[3] This is not the same as Context (*483). None of these terms is entirely satisfactory, but “context” comes closest to the idea of a simple “frame of reference” or environment within which action may take place (including the operation of a system). <br />[4] “Discretion” might best be described here as “implicit authority”. Implicit or explicit authority could be regarded as the result of “stakeholder prioritization”.<br />[5] Ideally, a requirement should have a single Sponsor. A group may be collectively responsible, but even then, it is preferable for one among them to take on the role of Sponsor. <br />[6] “…for the time being” could be added, authority always being conditional. If the conditions are not met, the authority is no longer valid and, as an immediate and automatic consequence, the “requirement” reverts to being a “potential requirement”. <br />[7] Strictly, either a sub-system or an attribute (*003) of the system (*145).<br />[8] We can distinguish here between transitional context (e.g. a project) and operational context (where “environment” is a common alternative term). If the transitional context is undefined, we can refer to the requirement as an “orphan requirement”. If the operational context is undefined, we can only say that the Requirement Specification (*508) is defective; the status of the requirement itself is undecidable (but decidedly not authorized).AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com1tag:blogger.com,1999:blog-2065900066225575678.post-64896697282396977692007-06-29T09:57:00.000+00:002007-06-29T20:59:37.142+00:00Roger Cauvin's Requirement DefinitionI have never subscribed to the IEEE "definition" of requirement, and I'm not convinced that Roger's adaptation makes it acceptable. It certainly makes it more acceptable, so "well done, Roger!"<br /><br />Where do we go from here?<br /><br />First, can we equate "least stringent condition" to <a href="http://www.gilb.com/community/tiki-page.php?pageName=Competitive%20Engineering%20Glossary">Tom Gilb's "Fail" concept (*098)</a>, "the leading edge of a Failure Range"?<br /><br />If so, what do we do with the other interesting points on Gilb's continuum, reproduced (slightly modified) below?<br /><br />•••••••[!!!!!!====>____>••••••[!!!!!!====>____> <br /><br />•• is a catastrophe range. <br />[ is a lower survival level. <br />!!!!! is a Failure Range. <br />==== is an acceptable range. <br />> is a Goal level. <br />_____ is a success range.<br /><br /><br />My view would be that the requirement, if not more fully characterized in some way similar to Gilb's, is for "success", as opposed to the avoidance of "failure" or "catastrophe". It is the latter that Roger's "least stringent condition" suggests (to me).<br /><br />Of course, I find even Gilb's exposition simplistic, but we have to run before we can walk! For practical purposes, it is useful to reduce the requirement concept to "measurable, valued outcomes". Observing or hypothesizing how much, and how differently, changes to outcomes are valued by diverse stakeholders is a powerful technique for establishing what might constitute success, but it is still one-dimensional. Leaving the whole multi-dimensional trade-off between benefits (including but not limited to avoided costs) to one side, what emerges from such an exploration is (hopefully) agreement about the level of outcomes to pursue. I would call this an objective rather than a requirement but, to me, objectives are a type of requirement.<br /><br />What, though, of "raw" function? Here it is crucial to be very precise about the context. It is, in practice, always possible to move backwards and forwards along a cause-and-effect chain, dragging the "system boundary" one way or another (hypothetically, at least). Determining the "border zone" is, in my view, a requirements activity. This is what constructing use-cases is all about. The problem, it seems to me, is that use-cases implicitly assume an immovable boundary. The reality is that some boundaries are clearer than others; some more the result of design, some more a matter of policy or practical constraints. Defining a range of required function is key.<br /><br />In this view, we recognise a distinction between "core" function, the absence of which is unacceptable, and "contingent" function, which must be present in some form in the universe, but not necessarily in the system being specified. Performance characteristics are unavoidable for all function. The valued performance characteristics are what drive the distinction between "core" and "contingent", I think, and, more relevantly, inform the ultimate decision about what "contingent" function is a necessary, desirable, unnecessary or undesirable inclusion in the final system.AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com3tag:blogger.com,1999:blog-2065900066225575678.post-13563578436325488492007-06-28T19:25:00.000+00:002007-06-28T20:22:27.757+00:00A random blog: Seilevel Presentation<a href="http://speakercity.blogspot.com/2006/02/seilevel-presentation.html">A random blog: Seilevel Presentation</a><br /><br />I've made a few contributions to the Seilevel forum, though I'm not convinced we're on the same wavelength.<br /><br /><a href="http://requirements.seilevel.com/messageboard/showpost.php?p=2641&postcount=13">...about checking rates</a><br /><br /><a href="http://requirements.seilevel.com/messageboard/showpost.php?p=2639&postcount=4">...about Tom Gilb, Agile and INCOSE 2007</a><br /><br /><a href="http://requirements.seilevel.com/messageboard/showpost.php?p=2638&postcount=3">...about Maslow's Hierarchy of Needs, mobile phones, trading off performance</a><br /><br /><a href="http://requirements.seilevel.com/messageboard/showpost.php?p=2630&postcount=7">...about decision-making processes</a><br /><br /><a href="http://requirements.seilevel.com/messageboard/showpost.php?p=2452&postcount=8">Three Cheers for the Worry-Stack (prioritization)</a><br /><br /><a href="http://requirements.seilevel.com/messageboard/showpost.php?p=2486&postcount=13">Let the Market Decide (prioritization)</a><br /><br /><a href="http://requirements.seilevel.com/messageboard/showpost.php?p=2451&postcount=7">...how worse can be better</a><br /><br /><a href="http://requirements.seilevel.com/messageboard/showpost.php?p=2449&postcount=69">...the final word on Goals vs. Businesss Objectives</a><br /><br /><a href="http://requirements.seilevel.com/messageboard/showpost.php?p=2300&postcount=3">...to copy or link: maintainability vs. usability</a>AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-81009017483744298122007-05-02T17:03:00.000+00:002007-05-02T17:25:00.380+00:00Effective Requirement Process<p>I waited a month before replying to a question on <a href="http://www.gilb.com/community/tiki-view_forum.php?forumId=16">one of Tom Gilb's forums</a>. This is only partly because I wanted to avoid doing the student's assignment. The main reason was so that I could canvass opinions on <a href="http://www.linkedin.com/answers/business-operations/project-management/OPS_PRJ/35369-3902425">LinkedIn's new(ish) Answers facility</a>. Interesting results from LinkedIn were:</p><ol><li>A general distrust of KPIs (Key Performance Indicators)</li><li>The absence of any reference to possible KPIs, however flawed or dangerous</li><li>A belief in the impossibility of measuring the effectiveness of requirement processes</li><li>A fairly low number of responses (7). Is that because it's a hard question or an uninteresting one, I wonder.</li></ol><p>I may yet re-open the question with my own thoughts included as clarification. For the moment I must leave a little time for others to comment on my Gilb post.</p>AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-56448412246573561222007-04-13T00:21:00.000+00:002007-04-13T00:25:32.063+00:00TRAID: Tasks, Risks, Assumptions, Issues, DependenciesIn the end, I went for the "Less is More" approach. I kept trying to add more, but that just led to a whole heap of other things that I would also need to say.AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-91363373509094264692007-04-12T22:06:00.000+00:002007-05-02T21:17:38.339+00:00Just-inTime Requirement SpecificationSlightly edited for formatting, my original post follows...<br /><br />[quote=achen]...savings from doing requirements right? [/quote]<br /><br />I think you have to talk about "savings from getting requirements right sooner".<br /><br />MTalbot is right that the costs of getting things wrong can be incalculable, but only if wrong requirements are actually implemented. It is quite straightforward to talk about the (estimated) cost of fixing a requirement during design, say, versus during acceptance testing. Only rarely, if at all, is it cheaper to fix requirements later rather than sooner.<br /><br />Averaged statistics are not particularly helpful, however. Some defective requirements can be fixed almost as cheaply at the end of development. And I'm not just referring to "cosmetic" defects. Take, for example, legal caveats or wordings prescribed by statute. If we know early on <strong>that</strong> these are required but not exactly <strong>what</strong> is required, we can generally proceed with development at little additional risk while the precise text is hammered out by an army of lawyers, copywriters, focus groups and officials. Often all we really need to do is plan accordingly.<br /><br />So for every requirement we can repeatedly apply what I call the "so what?" test:<br /><br />[QUOTE]<br />This requirement may be wrong, so what?<br /><br />The answer is often that it <em>probably</em> doesn't matter very much <em>at this stage</em>.<br /><br />So when will it begin to matter more?<br />[/QUOTE]<br /><br />Finalizing a requirement before it begins to matter very much saves you next to nothing. Delaying development while you try to finalize such requirements, on the other hand, can cost a very great deal, both in terms of "burned" resources and delayed, or increased risk of late, implementation.<br /><br />As a general rule, we do not want to use up valuable elapsed time now unless there is a fair prospect that it will save us more elapsed time in the future. Too often, this debate refers only to cost in terms of (mythical) manhours, overlooking the simplest of critical path analyses. Even if, as is usually the case, getting the requirement right now does cost several times less in terms of effort, this "saving" may be more than outweighed by the costs of an extended critical path.<br /><br /><<<--post ends <br /><br />This received some <a href="http://requirements.seilevel.com/messageboard/showpost.php?p=2223&postcount=12">positive feedback</a>. "I think this is actually a really great point. In an SRS, how have you typically handled or called our requirements that you know are incomplete/wrong at the time of writing?"<br /><br />Now I guess I'll have to come up with <a href="http://alanaj-nexus.blogspot.com/2007/04/traid-tasks-risks-assumptions-issues.html">an answer</a>!AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-35183139694287693982007-04-11T17:07:00.000+00:002007-04-11T17:11:24.296+00:00Seilevel Forum<a href="http://requirements.seilevel.com/messageboard/showthread.php?p=2220#post2220">Just-in-Time Requirement Specification</a><br /><br /><a href="http://requirements.seilevel.com/messageboard/showthread.php?p=2216#post2216">http://requirements.seilevel.com/messageboard/showthread.php?p=2216#post2216</a>AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-84110909702657556962007-04-11T15:31:00.000+00:002007-04-11T22:59:43.540+00:00Tom Gilb's ForumI've been contributing to Tom Gilb's forum for longer than it has existed. Some of the posts are a little difficult to find so long after the event. There are apparently 10 of them, but I can only find these 6...<br /><br /><a href="http://www.gilb.com/community/tiki-view_forum_thread.php?forumId=16&comments_parentId=104&comments_maxComments=1&comments_style=commentStyle_threaded">Re: Theory on why it is hard to distinguish Requirements from Design</a>, in Project Management & Product Development<br /><br /><a class="link" href="http://www.gilb.com/community/tiki-view_forum_thread.php?forumId=16&comments_parentId=86&comments_maxComments=1&comments_style=commentStyle_threaded">Re: Gilb 88</a>, in Project Management & Product Development<br /><br /><a href="http://www.gilb.com/community/tiki-view_forum_thread.php?forumId=10&comments_parentId=83&comments_maxComments=1&comments_style=commentStyle_threaded">Re: Re: Definition</a>, in Inspection, Quality Control & Defect Prevention<br /><br /><a href="http://www.gilb.com/community/tiki-view_forum_thread.php?forumId=10&comments_parentId=73&comments_maxComments=1&comments_style=commentStyle_threaded">Re: Definition</a>, in Inspection, Quality Control & Defect Prevention<br /><br /><a href="http://www.gilb.com/community/tiki-view_forum_thread.php?forumId=10&comments_parentId=67&comments_maxComments=1&comments_style=commentStyle_threaded">Re: Classifying defects as Major/minor</a> in Inspection, Quality Control & Defect Prevention<br /><br /><a href="http://www.gilb.com/community/tiki-view_forum_thread.php?forumId=15&comments_parentId=16&comments_maxComments=1&comments_style=commentStyle_threaded">Design Methods</a>, in Design, Industrial Design, Solutions<br /><br />I also have a <a href="http://www.gilb.com/community/tiki-index.php?page=UserPageAlanAJ">Gilb wiki home page</a>, which links into my Gilb wiki contributions.AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com0tag:blogger.com,1999:blog-2065900066225575678.post-62369088012031238132007-04-11T13:06:00.000+00:002007-04-11T22:37:22.278+00:00Forum PostsI should get round to extracting specific forum posts soon enough, but contributions so far have been principally to:<br /><br />Tom Gilb's website, <a href="http://www.gilb.com">http://www.gilb.com</a><br /><br />The Seilevel Requirements Discussion forum, <a href="http://requirements.seilevel.com/messageboard/forumdisplay.php?f=3">http://requirements.seilevel.com/messageboard/forumdisplay.php?f=3</a>AlanAJhttp://www.blogger.com/profile/02109956243066058539noreply@blogger.com2