Two limitations of abstract argumentation frameworks: (i) irrelevance is acceptable and (ii) the last one wins

I often review or otherwise comment on research publications which build on abstract argumentation frameworks to develop some novel formalism, typically for modeling specific kinds of decisions.

By abstract argumentation, I mean a Phan Minh Dung abstract argumentation framework [1], defined as a pair of sets, (i) a set of arguments, and (ii) a set of attack relations over arguments. The two sets give you a graph of arguments and attack relations. You can label each argument as accepted or not by ensuring these are satisfied by the labels on the graph: (a) any argument which is not attacked is accepted, (b) if an argument is attacked by an accepted argument, then the former is not accepted, (c) an argument is defended if every argument which attacks it is attacked by an accepted argument.

There are two problems that you inherit by building on top of an abstract argumentation framework.

One, an argument can point to, or refer to any proposition. Because all that matters for acceptability are attack relations, it does not matter how the argument actually reads. Hence, there is no notion of relevance in an argumentation framework. By “relevance”, I mean something like what Wilson and Sperber say in the following:

“When is an input relevant? Intuitively, an input (a sight, a sound, an utterance, a memory) is relevant to an individual when it connects with background information he has available to yield conclusions that matter to him: say, by answering a question he had in mind, improving his knowledge on a certain topic, settling a doubt, confirming a suspicion, or correcting a mistaken impression. In relevance-theoretic terms, an input is relevant to an individual when its processing in a context of available assumptions yields a POSITIVE COGNITIVE EFFECT. A positive cognitive effect is a worthwhile difference to the individual’s representation of the world – a true conclusion, for example. False conclusions are not worth having. They are cognitive effects, but not positive ones.” [2]

This is often difficult for many people to understand, that you can have acceptable arguments which are, so to speak, non-sensical, or irrelevant. the confusion is due to a poor choice of terms, as acceptability of arguments obtains a technical definition in an argumentation framework, while that same term probably has a very different intuitive interpretation for you. It is, however, not strange at all. The formalism of argumentation frameworks is not designed to address this. But if you want to use it to do something where relevance matters, the argumentation framework cannot help you – you can use it, but you have to deal with relevance with something else in your own method or formalism that builds on top of it.

The second interesting limitation is this: if you ask for people to provide arguments, and you set a deadline by which they can do so, the last person can determine fully which arguments end up being acceptable. Since irrelevance is acceptable (see above), it only matters that they provide an argument – regardless of what that argument is. Again, this is counterintuitive, because how could someone possibly determine the outcome of potentially complex arguments and attacks being put forward, simply by being last. If you understood the former point about irrelevance, and how acceptability is computed in the graph, this should be obvious, even it may remain odd.

Despite being an elegant and attractive seemingly all-purpose formalism, argumentation frameworks should be used with caution.

[1] Dung, Phan Minh. “On the acceptability of arguments and its fundamental role in nonmonotonic reasoning, logic programming and n-person games.” Artificial intelligence 77.2 (1995): 321-357.

[2] Deirdre Wilson, Dan Sperber. Relevance Theory. G. Ward, L. Horn. Handbook of Pragmatics, Blackwell, 2002.

Posted by Ivan Jureta

Structure of a Specific Management Framework

A management framework is specific when it is designed for use in one organization; or if it crosses boundaries of several, then only in those organizations. It cannot be moved to a different organization, and work without substantial changes.

I wrote in a different text that a management framework identifies an opportunity or problem in the coordination of people within a single, or across organizations, and proposes (i) how to think about that opportunity/problem, (ii) how to identify its instances, and (iii) what to do – how to change the organization – in order to address it.

A specific management framework includes the following.

  • Objectives to achieve through the use of the framework;
  • Measures to describe progress to objectives;
  • Responsibilities (if complex, then they become standalone roles), through which individuals or groups get to be accountable for the achievement of objectives;
  • Processes that describe how to progress towards objectives (read more here on what goes into processes);
  • Guidelines on how to decide and act in processes, especially when there are complicated actions and decisions to take (those where inputs are not easy to find, make, or buy, and the production of outputs is not through clear cut steps with certain outcomes);
  • Rules, that is, mandatory guidelines, those which must be satisfied when progressing to objectives;
  • Tools, or anything that can be made up front (concepts, templates, software, hardware, etc.), and can be used when executing processes, with the aim of ensuring best practices are promoted, that there is consistency and coherence in how processes are executed, risks are managed, and uncertainty to target outcomes is reduced;
  • Terminology, which defines the ideas and things that matter to the framework, i.e., which are mentioned in objectives, measures, and other components of the framework, and which have a definition local to the framework.
Posted by Ivan Jureta

Credit card spend as another signal of ongoing sharp drop in consumer spending

Credit card payment statistics (from Denmark in this case) are an easy illustration of changes in what is being purchased, and what isn’t at this time.

These aggregates bundle together probably important differences in revenue between companies which have more or less developed e-commerce and distribution. The longer the crisis takes, the more these capabilities becomes important, and it wouldn’t be surprising if physical locations become less important as we ease into a new normal. This crisis is accelerating changes in behavior that would have taken much longer. The chart from the Danish central bank, their analysis “Danish and international economy hit by pandemic“, published on April 1st, 2020.

Posted by Ivan Jureta

Take the money, calm down, and wait

Three charts, data over the past 28 days: credit risk, cost of money, and media perceptions of economic uncertainty in this crisis. The hope is that the second eventually pulls down the left and right ones.

Charts are over at https://28.ivanjureta.com; data is up to April 6th, 2020, from public sources referenced below each.

Posted by Ivan Jureta

Generic vs Specific Management Frameworks

A management framework identifies an opportunity or problem in the coordination of people within a single, or across organizations, and proposes (i) how to think about that opportunity/problem, (ii) how to identify its instances, and (iii) what to do – how to change the organization – in order to address it.

It is useful to distinguish generic from specific management frameworks; a generic one is not specific to a single organization (or a group of identified organizations), while a specific one is.

Here are two well known examples of generic ones:

Kaplan & Norton’s Balanced Scorecard is concerned with the problem of broadening the range of decision criteria across an organization, and specifically, it tries to reduce the focus on financial criteria. It suggests that optimizing for financial criteria disregards others which affect the ability of the business to generate value sustainably, such as the perspective (or expectations) of customers, the importance of improving internal processes, and the ability to innovate. It suggests to identify organization-specific criteria over the four categories, and measure expected and actual outcomes over these criteria.

Porter’s firm-level value chain framework is concerned with the problem of understanding why and how the business generates its margin, or what inside the business determines its margin (at least part of it, in case external factors influence it most). It suggests to think about all internal activities as split into supporting ones and primary ones, the latter having the most important influence on the ability to generate ideally above-average margins (within, roughly speaking, an industry; or better, among competitors). It recommends focusing on improving primary activities.

When a management framework is generic, it comes with claims that it applies across types of organizations, industries, markets, and other many parameters or dimensions which highlight differences between organizations. Both the Balanced Scorecard and Value Chain are generic, as are many others – the resource-based view, the five forces, and so on.

What if you want to make them work in a specific organization?

If these frameworks are generic, then this begs the question of how they are different from a specific management framework, one which is used within one organization, or if it crosses over others, is still specific to that network.

A specific management framework needs to satisfy harder requirements than a global one.

The specific framework must be proven relevant in the context of the organization which uses it.

Relevance here means that people who use the framework make different decisions than in absence of the framework, and they actually perceive and report that the framework makes the difference – these reports may well be vague, since they inevitably involve what-if speculations.

It needs to be clear who should apply it, how they should do so, what resources they will use, what outcomes they are expected to produce, how to measure progress in the use of the framework, and how to improve one’s use of the framework, and/or the framework itself.

From personal experience, a local framework can be complicated, having to have many parts which all need to be carefully designed.

The specific framework should be connected to the organization – in terms of roles, responsibilities, authority, lines of reporting, and so on. Its design should be explained so that people can be trained in it. Its effects must be measurable, so that we can show which kind of value, and how much of it, it is generating; otherwise, it will not be used/adopted.

What goes into a local management framework? How to design and roll it out? More on these in future posts.

Posted by Ivan Jureta

The Value of Disagreement over New Ideas

Loads or Shipments? Truckload or LTL?

“Why is it a problem to have stops? Stops are common. We should be able to add them to a live load.” He was insisting.

This made no sense to me.

“You mean a shipment, right? The load becomes a shipment once matched.” I waited for his confirmation. It wasn’t happening.

This got me thinking about what it means to add stops for loads too. What was this about live loads? We’d have to change how matching algorithms work. It took us months to research, design, redesign, and have everyone align on. My next meeting with design, engineering, and quality teams will not go well. I can’t keep revising the short-term roadmap, nothing will get done.

“That’s what I meant. Was it truckload only? We did say LTL too?” He was one of the founders, and an important investor.

“No. We said truckload, and we agreed at the time that this was full truckload only. LTL is a different business altogether. You know it. You built a business in FTL before, and I don’t think you did LTL. Different customer needs, suppliers, service, technology. We’d have to do new research. Do you want to wait for another year? Differentiators are different. Everything is different.” I was Head of Product at the time, which meant that I was responsible for aligning everyone on what the product is, what it could be, and getting everyone to agree what it should be. In this venture, the initial ideas came from investors, what one might call a “product vision”. It was also on me to make sure the product satisfies everyone, from customers to engineers who make, release, maintain, and improve it.

“Can we stick to truckload only for now? We know it’s a big opportunity, we’re early, and it’s complicated enough.” I hoped this would stop him, or at least postpone this.

He was silent. I continued. “So, there’s no such thing as ‘live load’. I know someone may be calling freight that’s moving a ‘live load’, but we aren’t. Remember, the load is what the customer asks us to move, and it stays a load until it’s matched to a carrier; at that point, it becomes a shipment. Loads and shipments are described in a different way, the information about the load is only some of the information we then need to have and keep a record of, about a shipment.”

It might have been the tenth or 20th time we had essentially the same issue; I lost count. It wasn’t specific to the two of us. We had been working together for a while. There were no bad intentions. It was happening frequently in our other teams. It was in conversations, brainstorming, planning. What we used to communicate didn’t make much difference — emails, chats, remote or live meetings. It was faster to resolve in live meetings, but that lasted only until the end of the meeting, or at most until the next one.

Unpacking Disagreement

At some times, we used the same names for different new ideas, and at others, we used different names for similar new ideas. We disagreed frequently. Even when we might have agreed quickly, we couldn’t. If the same words stand for different ideas, and if these ideas are new (and therefore, do not come with an established definition), you are never sure if you agree or not.

Disagreements we had over “load”, “shipment”, “truckload” and “LTL” were an insignificantly small sample of confrontations we had over four years when I was involved in the logistics venture. Innovation there was never-ending. As our customers changed their minds about what worked best for them, as we acquired new customers with new expectations, conventions, constraints, practices, we kept coming up with new ideas internally for how to change our organization, products, services, systems, in response.

In such an environment, it is more useful to develop an appreciation for disagreement, than to prefer stability. This is not only to accept it as a frequent phenomenon, but also to learn to analyze it, so you can then better decide how to address it.

Part of the problem with “load” and “shipment” was that we used same words for different new ideas. The cure for polysemy is obvious if we could pick one of a few available definitions for “load” and “shipment”: we should review available ones and agree on one for each word.

Disagreement over new concepts is more subtle, of course, for three reasons.

Firstly, it is naïve to expect to reach the agreement easily — disagreement is not simply over which definition we will pick among a few, it is over the scope of the system, product, service to design, build, run, manage, and improve.

There are significant ramifications of adopting one or other definition of a new concept; the definition affects where we want to go, how we will get there, and what resources we will need.

If we defined “load” as being anything fitting in a dry van, this would not remove the possibility of shipping smaller loads for different customers on the same truck (the same trailer), and would lead us to LTL.

Secondly, disagreement over “load” may not be local to the definition of “load”. What we agree for “load” may lead us to have to change our definition of “shipment”, “customer”, and others.

New concepts depend on each other, in that the meaning of one will be tied to the meaning of others. If definitions ought to represent some of that meaning, then changing the definition of one new concept will affect definitions of other concepts which mention it. If the definition of X mentions Y, then changing the definition of Y may require us to change the definition of X.

Thirdly, we were creating new ideas, and the first version of a new idea is rarely the best. It wasn’t that we disagreed over general-purpose or even established specialized definitions of “load” and “shipment” — we used these words in new ways, specific to inventions we were coming up with, within the local context of the innovation process we were involved in. Even if he had a specialized, industry-standard definition in mind for “load”, it didn’t matter, since I was looking for an idea of load which was new, and which fitted our aims and our constraints and the innovation we wanted to get to.

The problem that the novelty of an idea introduces, is that disagreement we have now is not going to be the only disagreement we will have: the new idea will go through many changes, which will be motivated by various disagreements over time.

Disagreement over new ideas is a problem that intensifies over time and with more people. The more successful the venture became, the more this problem became pronounced, and the more it cost to solve. If communication leads to disagreement over meaning of words, how can you tell that the teams are in sync? How could you possibly assess and manage the risk of planning one thing, then being delivered another?

Disagreement about who meant what, while working on new ideas, may seem a straightforward issue to solve. Let’s get together and talk it through. But you first need to detect disagreement, then spend time solving it. You might detect it late, after damage is done. Handling it means more communication, not less. Could you have avoided this?

When you know that there is a risk for this kind of disagreement to occur, how do you detect it? Moreover, how do you detect it early, when it involves fewer people, before more is invested, and may only have affected inconsequential decisions? How can you make detection and correction part of a routine, instead of just hoping it will all go well?

Is Disagreement an Anomaly?

There’s “new” in the term New Concept Networks. The focus is on new concepts, those which are invented to fit specific purposes when we design and build new products, services, systems.

Disagreement about new concepts is quite different from disagreement established concepts.

When we disagree on established concepts, there is a reference that we can look up, to settle our differences and reach a common understanding. This could be a dictionary, an encyclopedia, a terminology accepted in a domain — something that we can both accept, along with others, as an authoritative source.

However, when we disagree on new concepts, then there will be no authoritative source, someone other than the two of us, or a passive source — a book, database, knowledge base, or otherwise — which we can both go to. Instead, we have to create and define the new concept.

This is exactly what was done in the logistics venture, where we had a new and our own “load” and “shipment” concepts, among many others.

The same happened in other businesses I was involved in during the last decade: I was in teams which were tasked with inventing, creating, testing, delivering, and running new products, services, systems which targeted specific opportunities and problems in various industries. We were coming up with new concepts, and had to make specific definitions for them — part of it was so that we can agree internally on what to do with and about them, the other part being that we have to be clear how our innovation differed from what was already available.

Disagreement over established concepts and disagreement over new concepts are two different kinds of anomalies. The former signals the need to point everyone to the authoritative reference, which provides the agreed-upon concept. The latter begs a different question: Is disagreement a signal that the concept in question should change? And if so, how do we change it so as to avoid disagreement later?

The key point is that disagreement over established concepts signals an anomaly, something to detect and correct without changing the concept, while disagreement over new concepts is part of their formation, that is, is a step in the creation of such concepts, and in their maturing up to the moment when they become accepted by, and thereby established in a community. At that point, there is an authoritative source, an accepted definition, and disagreement is an anomaly.

Posted by Ivan Jureta

New Concept Networks – A counterintuitive tool for faster innovation

Innovation stands for various actions we take to create something new and useful.

To prove novelty, we have to explain how the outcomes of all that effort – the invention – relates, and specifically differs, from all that’s already available, so-called prior art.

To prove usefulness, we have to produce evidence that it is being used by our target audience.

To show both novelty and usefulness, we have to define the invention. Its definition, as long as it precisely, accurately, and clearly identifies its properties, will help us identify comparable ideas, artifacts, products, services, and from there let us build an explanation of novelty. The invention’s definition is crucial to generating evidence for (and against) usefulness: to build, deliver, and see if and how it is used, we must define it.

How and when do you make a definition of an invention? A patent specification, an integral part of a patent application, is an example of an exhaustive definition of the invention. However, a patent specification is made after the ideas around the invention are stable, when the inventors are ready to submit a patent application. That moment is only the end of an innovation process, during which inventors came up with new ideas, researched prior art, prototyped (parts of) the invention to try it out with a sample of their target audience, collected feedback, changed their ideas, and performed many such iterations over and over, to build confidence that the invention will in fact become an innovation, once it goes to market.

Here is a simple observation: during innovation, inventors have to describe new ideas in order to communicate about them, and they have to do this well before these ideas are stable enough to justify the effort of producing their exhaustive specifications, or detailed and structured definitions. These descriptions are necessary for coordination – how else can we agree on what to prototype, make, deliver, and get feedback on?

If innovators have to produce descriptions of their new ideas throughout their innovation process, because they have to communicate and coordinate with others about them, and if we eventually want to have an exhaustive definition, or specification of the invention when ideas on it are mature enough, then we should consider the following question.

What if we wanted to have precise, accurate, clear, documented definitions of the invention during the innovation process, from its earliest moments, and not only at its end?

This question motivated my efforts when working with inventors over the past ten years, and eventually led to the tool called New Concept Network. Any New Concept Network is made of

  • new terms used to describe and explain the invention,
  • their definitions,
  • relationships between definitions of new terms, and
  • relationships between definitions of new terms and definitions of “old” terms, that is, those which have not been newly defined or redefined in descriptions and explanations of the invention; “old terms” will carry over their definition from ordinary language, or if they are technical terms of a specific discipline, the technical definition they there have.

Making an New Concept Network during innovation forces everyone involved to be precise, accurate, and clear about new ideas, and about how these new ideas relate to established ones, even if these new ideas may be changed or thrown away soon after they are defined.

With the question above, and New Concept Networks, I wanted to understand if producing precise, accurate and clear definitions throughout innovation impedes innovation, or if it can be done in a way which is helpful.

It is non-controversial to say that we want to innovate faster rather than slower. We want to rapidly go from early new ideas to more mature new ideas, since the faster we go to market, the earlier we will see the invention in all its glory, or see it fail. But the first new ideas are rarely the same as last new ideas an innovation process: an innovation process will rarely stabilize the earliest new ideas; instead, there will be disagreement about the new ideas, learning about what works and what doesn’t, ideas will be confronted with the behavior and expectations of a sample target audience.

Innovation can involve many iterations, during which new ideas will give place to newer ones, that is, the invention itself will be changing. If change is the constant of innovation, then why invest an additional effort into producing precise, accurate, and clear definitions of ideas which we know will change, and can change very quickly?

Why not go through the chaos of innovation with low quality descriptions, and wait for there to be enough confidence to be bothered with precision, accuracy, and clarity of the invention’s definition?

I argue that we should invest effort to produce precise, accurate, and clear definitions of new ideas during innovation, even if we reject them immediately after producing such definitions. In other words, I argue that innovation processes should embrace the paradox of wanting to be precise, accurate, and clear about unstable ideas.

The reason to embrace the paradox turns out to be simple. During innovation, new ideas change through confrontation: innovators confront each other on how to change the invention to improve it, they confront the realities of the environment in which the invention is expected to be used, they confront expectations and existing behaviors of their target audience, and so on. In absence of confrontation, why change the earliest new ideas? Why have them in the first place?

If confrontation is central to progress through new ideas in an innovation process, and if we want faster innovation, then we should generate confrontations more more rapidly. This is where definition comes in: if one is imprecise, vague, ambiguous about one’s new ideas, then it is harder to find what to confront them on. Instead, if one is precise, accurate, and clear, then it is easier for others to identify what they disagree with. In other words, being precise, accurate and clear about new ideas in innovation, is an open invitation for disagreement, one which is easier to accept and act on for others.

Over the past ten years, I have been leading and participating in innovation processes in companies in USA, UK, Denmark, Belgium, and Israel, where we invented new software products and services, and eventually helped build new organizations around them. We dedicated substantial effort to make precise, accurate, and clear definitions of new ideas from the very start of each innovation process, when new ideas were changing daily.

These definitions were related, as each used terms from others. Definitions and their relationships formed what I call ”New Concept Network” in this book; as we will see, this is neither a terminology, nor an ontology, but can be a precursor to either.

We recorded, documented, designed, and improved a New Concept Network in each innovation process. They were available to everyone involved: inventors, investors, lawyers, product designers, product managers, software architects, software engineers, and non-technical staff. It was relevant in all topics, from corporate strategy and finance, marketing and sales, production, business operations, research and development, delivery, maintenance. Benefits went beyond facilitated communication and teamwork, for local and remote team members. The NDN became a core asset for preserving, analyzing, improving, and documenting intellectual property, spanning business documentation, requirements and software specifications, marketing and sales material, as well as serving legal professionals who assisted the assessment and protection of intellectual property.

Posted by Ivan Jureta

What to look for in a process specification?

If you work with requirements, you have to work with descriptions of processes or workflows which satisfy requirements. What makes a relevant workflow specification or model?

Let’s start with the basics:

“The workflow concept has evolved from the notion of process in manufacturing and the office. Such processes have existed since industrialization and are products of a search to increase efficiency by concentrating on the routine aspects of work activities. They typically separate work activities into well-defined tasks, roles, rules, and procedures which regulate most of the work in manufacturing and the office. Initially, processes were carried out entirely by humans who manipulated physical objects. With the introduction of information technology, processes in the workplace are partially or totally automated by information systems, i.e., computer programs performing tasks and enforcing rules which were previously implemented by humans.” [1]

A workflow is a description of what people and machines do, with a focus on showing separate units of work, usually called tasks, activities, actions, or such, and specifically the sequence and synchronization across these units (what’s first, second, third, what waits for what else to be done, what needs to be done in parallel, and so on). It is safe to say that a business process is a synonym of workflow [2]. 

Although there are many ways to describe workflows [3], i.e., workflow modeling or specification languages, knowing them is necessary, but far from sufficient to make relevant workflows for a requirement or a goal, within and across organizations, industries, and markets.

So, what should you want to see or include in a workflow specification?

Think about this in terms of the kinds of questions you want a workflow specification to answer. I group these questions into “layers” of a workflow.

Each workflow has one or more of these layers:

  • Communication layer, describing:
    • Who communicates with whom?
    • What are they communicating about?
    • What is the purpose of the communication? For example, joint work, negotiation, exchange of paperwork, etc.
    • Does that communication have a pattern, which is repeated over and over? 
  • Incentives layer, describing:
    • Who gets what benefits from whom?
    • How important are these benefits for them, relative to their other benefits?
    • Who has which costs (loses)? 
    • How important are these costs for them, relative to their other costs?
  • Financial layer, describing financial flows between the parties involved;
  • Regulatory layer, describing steps done because of regulatory rules or guidelines;
  • Technology layer, describing which, how, and why IT tools are used in each step;
  • Base layer, describing steps which do not belong to other layers.

Each workflow can be over several or all layers, and is made of:

  • Steps, which can be, for example:
    • Tasks to complete;
    • Goals to achieve;
    • Approvals to obtain;
    • Reports to make;
    • Tests to perform;
    • Etc.
  • Relationships between steps (for a deeper discussion, see [4]), such as:
    • Sequence (next step, previous step);
    • Parallel steps;
    • Alternative steps;
    • Cycle;
    • Etc.

Each step’s description or definition should, ideally, answer the following questions:

  • Who (which position in the team or organization) is responsible for doing that step?
  • What should be done or achieved in that step? How should the step be done?
  • When should that step be done (which conditions need to be satisfied)?
  • What are the inputs (documents, approvals, etc.) needed to start a step?
  • What are the outputs of the step?
  • Which criteria and measures are used to evaluate how well the step was done?

References

  1. Georgakopoulos, Diimitrios, Mark Hornick, and Amit Sheth. “An overview of workflow management: From process modeling to workflow automation infrastructure.” Distributed and parallel Databases 3.2 (1995): 119-153.
  2. Decker, Gero, et al. “Transforming BPMN diagrams into YAWL nets.” International Conference on Business Process Management. Springer, Berlin, Heidelberg, 2008.
  3. Van Der Aalst, Wil MP, and Arthur HM Ter Hofstede. “YAWL: yet another workflow language.” Information systems 30.4 (2005): 245-275.
Posted by Ivan Jureta

Why the quality of requirements cannot fully be controlled at design time?

Quality of a service (such as, e.g., a flight) correlates negatively with the gap between what you expect from the service and what you experience through that service [1]. The greater the gap, the lower the quality. You expected more than you got. The smaller the gap, the closer the experience to expectations, and the greater the quality. Saying that you got more and better than expected is to say that the gap was negative – you expected less than you experienced.

This translates to the quality of software. If you think of software as being something that delivers services, or to make it simple here, one service, then software quality correlates with the gap between what you expected that service to be, and what you experienced when software delivered the service. Your perception of quality of a flight booking software, correlates negatively with the gap between what you expected it to do for you, and what it ended up doing. As above, it could be low quality (some positive gap) or high quality (some negative gap), or somewhere in-between (gap close to zero, from either side).

How does this translate to the quality of requirements? The service requirements should do for you, is that they should guide the engineering of the system-to-be in some specific way you are interested in. You give a requirement in order to have, eventually, the system do something you expect. So if it does not, then requirements, however good they may have seemed at the time, ended up giving you the experience which is different from the expectations you had. It follows that the quality of requirements is only partly determined by such properties as their precision, clarity, absence of vagueness, ambiguity, how they have been specified, validated, and so on – namely, by the many things which could be controlled when requirements are being elicited, analyzed, specified, verified, and validated. In other words, you cannot fully control the quality of requirements at design-time.

Simply put, it is because the evaluation of quality of the system-to-be will happen at run-time, that there is always going to be uncertainty about the quality of its design-time requirements.

References

  1. Parasuraman, Anantharanthan, Valarie A. Zeithaml, and Leonard L. Berry. “A conceptual model of service quality and its implications for future research.” Journal of marketing 49.4 (1985): 41-50.APA
Posted by Ivan Jureta