Awesome by Design

Awesome by Design

Requirements Elicitation and Analytics for Solution Development

By

Steven M. Price

Copyright © 2017 Steven M. Price

All rights reserved.

Distributed by Smashwords

Thank you for downloading this ebook. This book remains the copyrighted property of the author, and may not be redistributed to others for commercial or non-commercial purposes. If you enjoyed this book, please encourage your friends to download their own copy from their favorite authorized retailer. Thank you for your support.

Ebook formatting by www.ebooklaunch.com

Table of Contents

1. ELICITING REQUIREMENTS: THE CASE FOR CLARITY AND CONSENSUS

THE EMPIRICAL EVIDENCE OF NEED

THE ANALYST: AN INTRODUCTION AND EXPLANATION

THE LIMITS OF ELICITATION

THE QUANDARY OF METHODOLOGY

THE LIFECYCLE MINDSET

THE CHALLENGE OF ELICITATION

HOW THIS BOOK IS ORGANIZED

2. THE ORGANIZATIONAL ECOSYSTEM

THE ENTERPRISE TECHNOCRACY

THE PATHOLOGY OF ORGANIZATION

THE CULTURE OF THE ORGANIZATION

THE DOMINANT COALITION

THE NATURE OF WORK IS CHANGING

THE WORKFORCE ACTORS ARE CHALLENGING

UNDERSTANDING ORGANIZATIONAL CHANGE AND TRANSITION

THE HEALTHY ORGANIZATION ARCHETYPE

3. THE DESIGNED SOLUTION

TARGETS OF OPPORTUNITY AND THE NEED FOR CHANGE

DESIGN THINKING

THE ARTIFACTS OF DESIGN

EVALUATING TECHNOLOGY OPTIONS

ASSESSING ARCHITECTURAL POSSIBILITIES

THE ENTERPRISE DATA MODEL

THE DATA AND INFORMATION INTERPLAY

VALIDATED SYSTEMS ARE DIFFERENT

THE TESTING STRATEGY

THERE ARE NO PERFECT SOLUTIONS

4. THE NATURE OF REQUIREMENTS

REQUIREMENTS TEND TO EVOLVE OVER TIME

UNDERSTANDING FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS

THE POSSIBILITY OF TACIT REQUIREMENTS

UNDERSTANDING GOALS AND OBJECTIVES

POWER DYNAMICS

ORGANIZATIONAL TURBULENCE

HOW MUCH INFORMATION?

THE CHALLENGES OF ARTICULATION AND REPRESENTATION

ENSURING REQUIREMENTS COMPLETENESS

5. THE DYNAMICS OF THE ELICITATION PROCESS

THE NOTION OF INTERVENTION

THE ACTORS IN REQUIREMENTS ELICITATION: ROLES AND RESPONSIBILITIES

DESCRIBING THE PROBLEM SITUATION

THE PROBLEM WITH PROBLEM DEFINITION

APPRECIATING APPRECIATIVE INQUIRY

OUR INFORMATION PROCESSING PREFERENCES

EXPLORING PERSONAL EPISTEMOLOGY

OUR PERSONALITY PRECEDES US

THE ROLE OF ARGUMENTATION

PAYING ATTENTION TO HOW THINGS ARE SAID

SOMETIMES IT’S ABOUT WHAT IS NOT SAID

THE VALUES WE CHERISH

WORKING WITH SUBJECT MATTER EXPERTS

ENGAGING COMMUNITIES OF PRACTICE

INDIVIDUAL DYSFUNCTION

THE LIMITS OF STRUCTURED INQUIRY

THE CHALLENGE OF REPRESENTATION

6. REQUIREMENTS TO UNDERSTAND TECHNOLOGY INFRASTRUCTURE

THE INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY

UNDERSTANDING THE SERVICE CATALOG

PERFORMANCE AND SERVICE LEVEL AGREEMENTS REQUIREMENTS

SYSTEMS MONITORING

EXAMINING THE CONNECTIVITY MODEL

THE INFRASTRUCTURE ENVIRONMENTS

AVAILABILITY MANAGEMENT REQUIREMENTS

CAPACITY MANAGEMENT REQUIREMENTS

INFORMATION SECURITY MANAGEMENT REQUIREMENTS

IT SERVICE CONTINUITY MANAGEMENT REQUIREMENTS

UNDERSTANDING RELEASE MANAGEMENT

CHANGE AND INCIDENT MANAGEMENT

THE INFRASTRUCTURE CHALLENGE

7. REQUIREMENTS ELICITATION TO UNDERSTAND PROCESS

UNDERSTANDING THE BUSINESS MODEL AND MISSION

THE PROCESS IMPERATIVE

EVERYTHING IS A SYSTEM - REALLY

ESTABLISHING THE CONTEXT FOR SOLICITATION

UNDERSTANDING RELATIONAL PARADIGMS

THE COUPLING CONNECTION

THE ILLUSION OF CONTROL

A PROBABLE NETWORK STRUCTURE

INTERACTIONAL DYNAMICS

SYMPTOMS AND ADVANCED DIAGNOSTICS

BUSINESS RULES AND PROTOCOLS

COMPLETING USER STORIES AND USER NARRATIVES

COMPLETING USE CASES

THE PROBLEM WITH PROCESS

8. REQUIREMENTS ELICITATION TO UNDERSTAND INTERFACES

THINKING IN TERMS OF STYLE

THE SOLUTION STORYBOARD AND NAVIGATIONAL SCHEMA

USER-CENTERED DESIGN

ESTABLISHING THE VISUAL CONTEXT

WINDOW CONTROLS

MODAL DESIGN

THE NOTION OF USABILITY (UX)

ACCOMMODATING EXPERTS AND NOVICE USERS

DEVELOPING REPORTS AND FORMS

DEVELOPING CONTENT

ERROR MESSAGES AND WARNINGS

INTERFACE CHALLENGES ON THE HORIZON

9. REQUIREMENTS ELICITATION FOR NON-FUNCTIONAL REQUIREMENTS

REUSABILITY REQUIREMENTS

PORTABILITY REQUIREMENTS

INTEROPERABILITY REQUIREMENTS

MAINTAINABILITY REQUIREMENTS

TESTABILITY REQUIREMENTS

FLEXIBILITY AND SCALABILITY REQUIREMENTS

THE USABILITY FACTOR

SOLUTION DOCUMENTAITON AND KNOWLEDGE TRANSFER

THE FALLACY OF NON-FUNCTIONAL

ABOUT THE AUTHOR

REFERENCES

1 Eliciting Requirements: The Case for Clarity and Consensus

The case for analytical clarity and consensus is born of necessity because ours is a world of complex systems and the problems they spawn. Complex systems and complex problems are not new. They are the source of many current challenges and the catalyst for those emerging on the horizon.

Complex system problems are the problems of contemporary society of which exemplars abound wherever ‘the system’ and its human counterpart collide. Very often, the technology precipitates the collision. These problems do not have a single correct solution or answer - they cannot.

When problems get to a certain level of complexity there are no solutions - only compromises, controversies, and contention. Although complexity is arguably, an interpretation there can be little doubt of the ominous caliber of complex systems. We don’t solve complex systems problems, we design solutions based upon how we define and analyze the problem and its parameters.

Designing a solution is a subtle but fundamental shift in professional practice from solving a problem. This is not semantic jostling but more a paradigmatic shift from solving as a terminus toward engagement as a continuum; it is a calculus more than a conclusion. Thus, the solutions we seek are becoming more elusive.

Awesome by Design argues the software design and development process is not only a design exemplar it is a quintessential cognitive surrogate for problem engagement. The core of the design process lies with eliciting requirements that guide the design. Thus, it is the art and science of eliciting requirements that drives what the solution must accomplish.

The argument suggests adopting the thinking and methodological rigor of the elicitation process is an excellent analytical platform. Where else do technology, process, and people converge so elegantly?

Software design and development serves as an example of how knowledge work in its full plumage involves several players and processes. Software is the exemplar for the problem solving and design that is the hallmark of today’s knowledge workers. Thus, we have a cognitive and collaborative endeavor, through elicitation, to increase performance and productivity by leveraging technology.

The beauty of combining the cognitive influence of design with the practical influence of developing software is its pragmatic approach. The word ‘awesome’ has many meanings. It can mean to inspire awe, it can describe something that is mesmerizing, or it can be a feeling of wonderment.

The notion of ‘by design’ is a popular cliché that describes how ‘something’ that turns our right does so ‘by design’. When we think of positive events or outcomes, they can be fortuitous luck or they can be the result of hard work. In this case, ‘design’ is a conscious attempt to improve or create something new through design - it is our way of developing solutions or products.

The following sections outline many of the key issues that formulate the case for clarity and consensus. On one hand, clarity of requirements is imperative for understanding. On the other hand, consensus as to what the requirement must achieve and agreement on presentation is equally as important.

The Empirical Evidence of Need

The literature is replete[1] with reasons for software design and development projects failure. Although understanding why failure occurred such as unmanaged expectations, little comes from the linear cause-and effect pronouncements. Intuitively, most of us can pinpoint a defining moment or series of events that cascade into failure.

The literature is also replete with numerous methods and models used to improve software design and development. Oddly, the larger majority of these methods and models are variations on a theme. The theme being a logical, orderly progression of thought, purpose, and action that can be directed to improved performance.

Another shocking revelation (not really that shocking) is that information technology professionals themselves author the majority of the literature. In this sense, professionals define themselves by their own admission or perhaps by job title.

On one hand we have the academics who must ‘publish or perish’ as part of their mandate. They tend to craft well-researched narratives and generally reinforce each other’s academic interests. On the other hand, industry has produced aspiring authors who fervently want to share their insight and experience.

The net result of examining all aspects of the literature suggests there is a large volume of fragmented material and disconnected understanding of how the design process works. Invariably we have someone who is technology literate trying to draw upon multiple disciplines, outside their own, to espouse their view or make a reasoned argument.

The empirical evidence strongly suggests there is a need to understand the complexities of requirements elicitation. There is a large body of commentary linking ‘bad’ requirements with solution shortfalls or failures. In effect ‘bad’ requirements lead to bad solutions - hmmm this seems intuitive.

The conventional approach of gathering and examining solution requirements is Requirements Engineering (RE)[2]. The process evolves through elicitation, analysis, specifications, and validation. This depiction of RE leverages a review and approve approach common among project management methodology.

The focus of Awesome by Design is the most contentious and complex aspect of design - eliciting requirements. As an operative definition, design constitutes anything created, configured, or contrived as part of a solution.

The rationale suggests if requirements are clearly articulated and represented, then subsequent phases or tasks leading to a solution are satisfied. Surely there is no guarantee that perfect requirement equate to perfect results; they merely contribute.

The complexity of the elicitation process has been under served in the both the literature and in professional practice. The dominant problems of requirement elicitation are exactly those of the human-technology interaction.

The human component exemplifies the complexity of human behaviors and characteristics that make all of us who we are. The technology component is that of the complexities that technology tries to remove from the human condition; namely the tasks that can be more effectively and efficiently conducted by technology.

Thus, we find, with all complex systems problems, a condition that eludes us but that we recognize as complex. The problem of course is do we have the appropriate range of skills and competencies to engage complex systems? Arguably, we do not.

Awesome by Design contends that most treatments of the requirements elicitation process trivialize the complexities of human behaviors and characteristics. In doing so, the reliance on models and proprietary methods tend to diminish the importance of clarity and consensus.

Readers are encouraged to examine and explore the depth and breadth of Awesome by Design in comparison to other competing authors. Awesome by Design diverges slightly from the dominant foci of cause and effect to rejuvenate the notion of ‘there is a correct way’ - we just have to find it. In doing so, what constitutes profession practice becomes more malleable to the organization and environment we all face.

The Analyst: An Introduction and Explanation

Throughout Awesome by Design, the Analyst is prominent. In this regard, the Analyst is a surrogate for the knowledge work practitioner; an intellectual placeholder if you will. Thus, readers are encouraged develop their own practice strategies and garner useful tools and techniques. After all, we are all Analysts at heart.

One must realize that each of us brings a different perspective to the problem arena. Our level of education and experience heavily counterbalances the cognitive and psychological diversity. Oddly, even the proper mix of each can still fall woefully short in the heat of battle.

The role of the Analyst takes on special meaning when eliciting the problem situation and solution, assessing opportunities, and formulating design criteria. In this regard, the Analyst is an interpreter and a navigator. The interpreter translates the business needs into technical language and the navigator surveys the project terrain to coordinate and synchronize efforts.

Ironically the role, and for that matter the moniker, Analyst is an anachronism. It is old school classical thinking based on a mechanistic management model. In today’s technology-centric business enterprise there has never been a greater need for big picture or holistic thinking. In general terms, the Analyst remains:

1) Intermediary between the technology savvy and the decidedly non-technology business types

2) Interpreter of complex business needs into a technology-driven solution

3) Interrogator of business types to transform their contorted ideas and seemingly disconnected logic into a language and platform understandable by the technology types

Keeping these role perspectives in mind, the Analyst is reminded that paying attention to the solution pathway is both a control mechanism and powerful diagnostic tool. Although many renditions of what the Analyst is, the role is unmistakably a facilitator role.

The number of permutations that are possible when contemplating technology solutions can be overwhelming. The decision to proceed, to make a change by leveraging a technology solution is daunting because there are so many possible solution pathways.

Clearly, there is a predictable trajectory of thoughts, possibilities, and requirements that precede a solution. At times a pattern, other times free association. It is important for the Analyst to appreciate how these trajectories occur and why keeping track of our relative position in them is so helpful.

The brilliance of Stephen Covey’s fifth habit of highly successful people needs no introduction. Seek first to understand, then be understood is the penultimate expression of the solution requirements development process. The elegance of this truth cannot be overstated.

The solution requirements development process is largely an interpretive mechanism. One party has a business need or goal that another party must satisfy. The problem of course is the clarity of what is expressed, how it is captured and interpreted, and the ultimate task of explaining ‘what’ and ‘how’.

The challenge of articulation and representation is common to many complex problems faced in our organizational society. There always seems to be more variables than time or space to describe them. The number of moving parts in this complex puzzle remains troublesome and elusive.

The Limits of Elicitation

The elicitation process is many things, but simple is not one of them. By and large, elicitation is a communication process. Elicitation initiates a question and response repartee or perhaps a one-sided lecture. In either case, the exchange must produce a fundamental understanding of what requirements will produce a desired solution.

The inherent weakness comes from problem formulation. In a sense that which is problematic has spurred the desire to make a change from the current condition to a new condition, i.e. a solution to a perceived problem. Unfortunately, identifying and defining problems is not challenged very often - those who have the problem always seem to know best.

What we find during elicitation is a gradual disclosure of issues, ideas, and influences that have led to some condition or perhaps opportunity that warrants further consideration. The primary Actor within Awesome by Design is the Analyst; a knowledge worker with unique skills and analytical prowess. The Analyst at this point is a sounding board, a voice of reason, and an interpreter.

Like all communications, there is a message, a messenger, and a media that interacts between the players. The operative premise is that when a message is sent is can be interpreted and understood as it was intended. This is not always the case. An example might include the various levels of technical jargon in common use that may not be mutually understood.

Thus, the communication between the principal and the agent begins many of the issues and concerns that elicitation suffers. In a principal-agent relationship, the agent acts on behalf of the principal. Logically each has a vested interested in a favorable outcome. In this case, the Analyst is an agent for the principal.

A follow on to the message is its assessment among the parties involved. Analysis takes things apart to analyze them, to understand how their structure affects function. Conversely, synthesis is about putting things together. Synthesis focuses on function to reveal why things operate as they do.

Therefore, analysis yields knowledge and synthesis yields understanding. The former enables us to describe, and the latter, to explain. Quite often, this simple sequence is not understood and the misinterpretation begins early in the process. Thus, paralysis by analysis often stunts the larger picture of synthetic thinking.

Elicitation involves a host of players. Some may be very charming and insightful, others not so. Invariably chemistry develops between those who are investigating the problem encircling those with a problem. This is very much like a repair technician that answers an off-hours distress call - always appreciated and eternally grateful.

It can be said that the limitations of elicitation are those of the human condition. The very foibles we suffer as a species propagate into our interactions and understanding, only to be used as again, as interpretation allows. Thus, many of the limits of elicitation are of our own doing.

The Quandary of Methodology

As one could imagine there are numerous methods employed for requirements elicitation. Clearly, there is no single technique for elicitation - it is and always will be a combination of methods that will prevail[3]. It is worth noting that the techniques fall conveniently into a few categories.

1) Traditional: Traditional methods typically involve questionnaires, surveys, interviews, and examination of existing documentation to investigate.

2) Prototyping: This method creates early versions or renditions of the final solution to help examine how the final version will appear and function.

3) Group Techniques: Group techniques tends to involve active dialog typically facilitated using brainstorming, joint requirements planning, and idea capture

4) Contextual Techniques: Establishing context or observing how participants operate in action provides an understanding of working conditions and constraints.

5) Cognitive Techniques: These techniques involve more manipulation of the process such as protocol analysis that allows the User to describe what they are doing and why as a dialog or explanation.

6) Model-Driven Techniques: Models illustrate aspects of the solution, often diagrammatically, that allows participant to comment and conjecture using shared space.

The quandary of methodology comes from over-reliance on any one approach; possibly to the exclusion of others. Awesome by Design contends that clear communication is often a multichannel proposition. For example, a brilliant dialog can often be amplified when a diagram is also presented to gain mutual understanding.

The Analyst should carefully consider the audience in selecting the elicitation method. Again, at issue is not so much the method as what the intended result needs to be. This is one contributor to the case for clarity and consensus.

The Lifecycle Mindset

The ability to observe and identify patterns is a valuable skill. However, one must be careful with judging whether a pattern is actually something repeatable and permanent. Empirical research, anchored by statistics, has found a surprising number of patterns in the world. The natural expansion is to model the pattern and describe its components and their relational dynamics. Thus, we have the lifecycle.

Lifecycles are valuable as a management paradigm. It becomes a way to organize people and resources sequentially into a coordinated effort. Almost any key initiative involves a lifecycle of some kind. Our lifecycles have become our mindset and our mantra.

The real trouble with the lifecycle mindset is not realizing the lifecycle is not the process; it is an abstraction of process conveniently laid out in a diagram of some kind. Remember the map is not the terrain just as the lifecycle is not the problem; it is a mnemonic. All of us must understand the mantra of the lifecycle. Some initial observations for the Analyst to consider.

1) Lifecycles strive for repeatability and predictability of the process they model. This is a probable throwback to equating designed artifacts to those that must eventually be ‘manufactured’. In this sense, lifecycles ensure a smooth manufacturing process with definable phases, steps, or deliverables.

2) Many organizations are obligated to manage their processes or projects using a defined lifecycle. Naturally, they adopt the practices of their industry and the procedures that match their organizational culture and talent pool.

3) The lifecycle is not the process itself - it is a model of the process. The problem with modeling process is the high degree of variability between and within processes. There really are no clear demarcations between phases and stages; there is considerable overlap. In addition, the process is a metaphorical map that allows the user to take many paths.

So why is there an issue with sequential or perhaps ad hoc process? Does it not follow that our mind is programmed to take small steps as part of a larger, holistic analysis? Both are good questions that set the stage for evaluating problem solving using a lifecycle approach.

There are several lifecycle models in use within contemporary technology-driven organizations. The real difference on the surface is how formalized is the process within the organization (the notion of maturity) and how effective is the process for the type of solutions being design and developed?

Drawing any comparison between the lifecycle models is futile; they are simply different representations of a process. What does offer value is relating the lineage of these models as our technologies continue to evolve. The merit is not the model but understanding how the process of design and development evolves.

Thus, the following encapsulations are presented as a backdrop to inform the Analyst how different models operate or more specifically how each constraints the elicitation process. Each model is cyclic, attempting to capture the critical steps found in the design and development process.

1) Waterfall Model: