Open

Revisiting Software Specification and

Design for Large Astronomy Projects

DKIST Data Center

REVISION SUMMARY:

Date: 22 Jan 2019
Revision: A
Changes: Initial version

Table of Contents

1 ABstract 1

2 INTRODUCTION 1

3 MetaHow Process Overview 1

4 Strategy 3

4.1 Overview 3

4.2 Goals 4

4.3 Scope diagram 5

4.4 Sticky subjects 6

4.5 Key concepts 6

4.6 Process approach 7

4.7 Key performance indicators 8

4.8 Last pass review 8

5 Process Definition 9

5.1 Overview 9

5.2 Process and data 9

5.3 Rules 11

5.4 Roles and responsibilities 11

6 Solution Architecture 12

7 Gap Analysis 13

8 Next steps 14

9 Comparison to traditional software requirements solicitation 14

10 Conclusion 15

ABSTRACT

The separation of science and engineering in the delivery of software systems overlooks the true nature of the problem being solved and the organization that will solve it. Use of a systems engineering approach to managing the requirements flow between these two groups as between a customer and contractor has been used with varying degrees of success by well-known entities such as the U.S. Department of Defense. However, treating science as the customer and engineering as the contractor fosters unfavorable consequences that can be avoided and opportunities that are missed. For example, the “problem” being solved is only partially specified through the requirements generation process since it focuses on detailed specification guiding the parties to a technical solution. Equally important is the portion of the problem that will be solved through the definition of processes and staff interacting through them. This interchange between people and processes is often underrepresented and underappreciated.

By concentrating on the full problem and collaborating on a strategy for its solution a science-implementing organization can realize the benefits of driving towards common goals (not just requirements) and a cohesive solution to the entire problem. The initial phase of any project when well executed is often the most difficult yet most critical and thus it is essential to employ a methodology that reinforces collaboration and leverages the full suite of capabilities within the team. This paper describes an integrated approach to specifying the needs induced by a problem and the design of its solution.

Keywords: Requirements, Systems, Process, Specification, Strategy

INTRODUCTION

The need to revisit the specification of software was borne from the experience of delivering and maintaining software. Clear communication between stakeholders (be they scientists or business leaders), and engineers is obviously critical to success but not as obviously difficult to achieve. To understand where communication begins to get difficult, we must assume the stakeholder wants their problem solved, and the engineer wants to know what needs to be done. This difference in perspective creates a gap that is closed through a detailed requirements specification process where the capabilities of a software tool are decomposed in gory detail. The resultant documented requirements are phenomenal at facilitating the management of a contract because it can make subjective completion purely quantitative and allows success to be defined separately by the parties. When the stakeholder organization is the same as the engineering organization this isn’t of much value since there can only be one type of success, mutual. The requirements are also excellent at breaking down into small units the development work that needs to be accomplished which facilitates the engineering perspective. By contrast they are not as clear at depicting the larger problem to be solved which is the perspective of the stakeholder.

Poorly written requirements, be they ambiguous, contradictory, or victim of any number of other pitfalls, are invariably going to lead to trouble. The subtler issue is that even a masterpiece of requirements will lead to trouble if the system they specify was conceived without a detailed plan for the use of the system and the broader goals that are to be achieved. A system in and of itself rarely if ever solves the stakeholder’s problems. but instead it is the process that system will live within plus the system itself that make the solution. Therefore, it is necessary to capture the system needs (requirements) from the stakeholder in the context of the process that it will be used within.

Just like the system, the process also requires design. There is a give and take between system and process as each can make life more challenging or simpler for the other. A methodical process for capturing the integrated needs of the process and system as well as maximizing the simplicities each can offer each other is described below. The description is augmented through the use of a real-life example for the specification and design of a procurement management system.

MetaHow Process Overview

The following descriptions are of a methodology for defining processes that will have a software system support them and is referred to in this document as the MetaHow. There are four phases to the MetaHow that are used to illuminate the requirements for the system:

• Strategy: This phase provides the foundation for the remaining phases by collaboratively framing the goals, scope, and a cohesive approach to achieving the goals within scope.

• Process definition: The approaches from the strategy are expanded upon in this phase with more detailed tasks, associated flow, roles responsible, and data involved. The process is, to the greatest extent reasonable, designed in a manner that is agnostic of any system support.

• Solution architecture: The solution architecture is essentially the design phase but instead of basing design on a list of specifications, the design is constructed to support a process where the boundaries are not rigid. There is an expected give and take between process and system when designing the final solution that can be leveraged to optimize the effort involved in development and use of the system.

• Gap analysis: The gap analysis adjudicates the give and take between the system and process that was designed. Additionally, it provides an opportunity to confirm the system needs in the context of a process designed to achieve the originally established goals. The end result will be a collaboratively produced process that includes system capabilities supporting it.

The phases progress in a mostly serial fashion with each increasing in detail and dependent upon the previous stage (Figure 1. MetaHow process flow). The strategy phase may be iterated over should additional decomposition be necessary. It is important to note that should this iteration occur, each component strategy would require all of the subsequent phases.

Open

Figure 1. MetaHow process flow

The breakdown of these stages is conceived to help overcome one of the greatest challenges in needs solicitation, communication. One aspect of overcoming the communication challenge is to correctly calibrate the level of detail necessary to facilitate clear understanding by both stakeholders and engineers in any given stage. This approach places a great deal of importance on getting the initial stages correct since significant error can cause re-work in subsequent stages. On the positive side, successfully getting through a stage will make the subsequent stage easier (Figure 2. Communication challenge curve).

Figure 2. Communication challenge curve

For the purpose of illustrating of the concepts being described in this article, the example of soliciting requirements and designing a solution for a procurement management system will be used. As with any example, it can be a fine line to walk where the example is close enough to reality that it is informative, but not so detailed that the reader gets focused on the example more than the point it is helping illustrate. Procurement was selected since most people have at least tangential experience with ordering goods within an organization and ideally the subject won’t tempt reader into the finer points of the topic.

Procurement processes in a large organization, and particularly those funded by the U.S. Federal Government, have software systems that support them. The life cycle of the procurement process we are interested in begins with the request for materials and concludes with the receipt and payment for them. There are a few steps in between that will be illuminated throughout the article.

Each person who read the previous paragraph was left with a different vision of what a procurement process and system that supports it would look like. In thinking of the process, some may be coming from the perspective that you go to a website, add the item to your cart, purchase, and get reimbursement later. Still others may instantly perceive the process as a rigorous set of approvals prior to ordering, and the actual placement of the order being handled by someone else in accordance with a tome of regulations. Just as there will be many varieties of initial process perspective, there will be many perspectives on a tool that will support these processes. At a high level some processes ideas will mesh with some system ideas, and some won’t but the permutations of process and system differences that we start out with is still large. It is the varying perspectives of the parties involved that we use as our starting point to exemplify the application of the MetaHow process to achieve a thorough shared understanding of the needs. Those perspectives will be brought together as follows.

• Isolating what procurement management is and is not

• Defining what processes make up procurement management

• Clarifying understanding of those things we are calling procurement processes and how they work together

• Picking off a piece of one process to expand our understanding in more detail

• Evaluating that detailed understanding to design in system support

• Making sure the designed in system support is understood, documented, and agreed to

Strategy

Overview

The strategy phase is the foundation of the MetaHow process and is made up of six components which are goals, a scope diagram, key performance indicators, sticky subjects, process approaches, and key concepts. The purpose of the strategy phase is to establish a manageable scope and cohesive approach to achieving the goals for the subsequent phases. The cohesiveness of the approach produced by a strategy is determined by the high-level problems being solved in a way that logically work together. In other words, there are no mutually exclusive or contradictory approaches to solving the problem. The manageability of the scope is subjective and determined by the number of high-level problems the team is comfortable solving (cohesively) at one time. Decomposing a strategy enhances that manageability of the strategic scope. Effort should be made to limit this where possible as it can make maintaining logical cohesiveness between strategic components a challenge.

In our procurement example the procurement processes are isolated strategically from other related processes. While procurement is focused on getting goods in the door, it is closely related to the processes of inventory management. The relationship between these two strategic areas is important to know but probably too large to tackle with just one strategy. In this case the strategy could be decomposed into separate strategies, one for procurement and one for inventory management where their key relationships are captured in a supply chain strategy (Figure 3. Supply chain strategy decomposition). Subsequent MetaHow steps would then be executed upon the procurement and inventory strategies but not the parent supply chain strategy.

Figure 3. Supply chain strategy decomposition

Goals

The goals component of a strategy are succinct statements about the needs the strategy is being created to meet and gathered through the first rounds of needs solicitation with stakeholders. While they are very much like top tier requirements, less emphasis is placed on their wording instead relying on the other components of strategy for disambiguation. The goals also must avoid prescribing how a need must be achieved but instead what the need actually is. Starting with goals when developing a strategy is ideal, but as will be true for all of the components, they will be a work in progress throughout the strategy phase. Therefore, completing them is not required to move on to the next component but instead should be managed throughout the phase.

In the procurement management strategy, the goals would include perspectives on value and constraints. Below are some example goals.

Looking at the example goals it is clear they are not enforcing a certain system to be used. In fact, pens and post it notes would probably cut it if the scale were small enough. Also note the word “shall” is absent. Understanding is still evolving and saying something shall happen doesn’t leave room for evolving with the understanding. People generally don’t like being wrong, so there is no need to back people into a corner so quickly when the point is to gain understanding (not specification).

Scope diagram

After an initial set of goals has been established, a visual representation of the boundaries of scope should be developed. The visual representation should use process areas interconnected by a broad description of the information exchanged. The process areas should be broad groupings of processes that will be necessary to achieve the current list of goals. It is helpful to identify process areas outside of the scope boundary that the strategy will necessarily interface with. The process areas identified outside of the scope aid in communicating actual scope by making explicit things that are simply not in scope but are interfaced with it. Should this result in the identification of processes that should be in scope or interfaces that weren’t anticipated, then the goals likely need revision as well. At the conclusion of creating a mutually acceptable scope diagram a high-level understanding of what problems need to be solved, and the process areas involved, should be forming. These process areas will be expanded upon further in the process approach diagrams.

For the procurement example, we need to establish some form of functional breakdown of our goals into process areas. This is accomplished through conversation about the general flow of information. Attempts are made to group like ideas and then generally define the input and output data (Figure 4. Procurement scope diagram). The beginning and ending of a process are typically the easiest to define whereas the middle gets tricky. In this case we know that goods are requested and presumably are eventually placed in the hands of the requestor. In between, we have some goals that require accomplishment such as approval, and capturing receipts for payment. The evolution of the diagram parallels the evolution of understanding coming from the conversation between stakeholders and engineers. Nuggets of information that hadn’t been previously considered will inevitably be discovered such as discovering that inventory can also request material and that this request, in contrast to a person doing the request, does not require an approval. Lastly, with the flow of information through some process areas, a line is drawn (dotted blue) to depict what are processes that procurement cares about or is merely interfaced with. Should we have been tempted to draw line straight through a process area box then it would need to be broken apart.

Figure 4. Procurement scope diagram

The procurement scope diagram successfully grouped procurement process and isolated them from out of scope needs. The process of doing so increased shared understanding and in so doing constrained the problem. Further, it has set the stage for process approaches which will expand upon each identified process area.

Sticky subjects

As the goals and process areas involved are discussed, issues will start to arise. It is important to capture them as they are thought of, both to ensure that they are recorded but also, so as to not derail an ongoing discussion. These issues are captured in a succinct sentence or couple of sentences and are affectionately referred to as sticky subjects. The sticky subjects can be technical, logical, informational, or just unknowns. The idea behind the sticky subjects is to capture those items that can cause the strategy difficulty and/or are difficult to communicate. They are neither good nor bad but simply must be resolved or accepted. Due to the nature of the process, understanding is increased as the strategy is developed. This results in both the creation and resolution of sticky subjects throughout the process. Resolution or acceptance must simply be annotated with the resolution/reason for it to be closed.

In the procurement process example, a sticky subject could have been recognized as soon as the goals were revised to handle the difference between special orders and reordering. The sticky subject could be written as simply as “How to handle special ordering something that’s already stocked?”. In this case it is just noted but will need to be resolved before the strategy is complete.

The example sticky subject is the product of having a slightly more constrained problem and thinking about it. At its heart, the entire process serves to iteratively increase the problem constraints and then evaluate where you are at. Particularly in the strategy phase, these sticky subjects can show up frequently since the problem is starting in a largely unconstrained state.

Key concepts

Key concepts are those subjects that could use additional clarification within a strategy. The subjects could be related to the nature of the problem or the approach to solving it. These concepts can vary greatly in their representation and are simply designed to enhance communication. There are no minimums or limits when it comes to key concepts. It is however likely that one or more of the sticky subjects that are identified could use a key concept to clarify the issue or resolve it.

A conceptual data model of the different entities that exist within procurement management makes an excellent example of a key concept (Figure 5. Purchasing conceptual data model). Understanding what concepts are important enough to name and understanding their cardinal relationships can be priceless when facilitating a conversation between stakeholders and engineers. It is important to note that this is a conceptual model as opposed to a logical one and the level of detail should be kept to the most important entities and relationships.

Figure 5. Purchasing conceptual data model

The example conceptual model achieved its goal for clarifying important subjects. It reinforces that orders are related to requests but need not have one. It expands understanding by revealing that orders could have multiple receipts and in turn each receipt multiple invoices. These realizations were arrived at through conversation about the details of the subjects as they were introduced.

Process approach

The process approach is a flow chart that identifies in more detail how each process area identified in the scope diagram will flow from an operational viewpoint. There are typically fundamental decisions and concepts that are going to alter the course of how a problem is solved and these must be identified and captured as part of the process approach. The idea is to bite off just part of the problem and to pick a significantly impactful part. A pitfall to avoid in this stage is getting too detailed since the foundation is not yet solid enough to do so. The process approach serves as the key link between strategy and process definition so there will be plenty of opportunity to expand upon details but not to reengineer the decisions made in the process approach. Critical components are captured along with information about their order and triggering actions. Some detail is saved for later phases such as what roles are performing the actions, what data they are collecting, and subtler concepts of flow. Sticky subjects are frequently identified and solved through the process approach and key concepts are put into use. In some ways the strategy is complete at this point, but it lacks polish.

For the procurement example, a process approach for the purchase request and approval process area is depicted below (Figure 6. Purchase request process approach). An opportunity to address the sticky subject raised earlier presents itself. The process approach introduces the idea that checking for material already being in stock is part of requesting goods. Only if the material is not in stock should the process proceed through the meat of the request and approval process. Additional ideas add to the picture of what the process will actually look like such as the requestor’s supervisor being the approval authority. This in turn could raise another sticky subject, “What if the requestor has no, or more than one, supervisor?”

Figure 6. Purchase request process approach

The procurement example shows how the single process area box is expanded but not into gory detail. The impactful chunk of problem that was bitten off is the integration of stocked inventory and how it affects the process. A good guideline for the process approach is to keep it to ten boxes or less while there will not be a limit when we enter process definition phase.

Key performance indicators

Key Performance Indicators (KPIs) is a list of questions one would ask of the process to ensure that it is healthy. The purpose is to identify data that may not be collected otherwise but is important to managing the process. Having the questions in the strategy does not imply that it is a goal of the system being scoped to provide the answers (though it could be an explicit goal) but instead protects against not having the data down the road when operating the process and system. The shift in perspective required to produce the list of questions may simply result in having a nice list of questions but may also result in revising the process approach, goals, sticky subjects, and key concepts.

For a procurement process there are a number of best practices with regard to managing the process. One of these is tracking vendor performance. The specifics of what vendor performance will mean to this procurement process need to be articulated to ensure the proper data is captured. For this case we will measure a vendor’s performance just by their on-time delivery. This will imply that the ordering process must capture an estimated delivery date which may not have been captured otherwise without knowing that we would like this question answered. Another implied piece of data to capture is a unique identifier for the vendor itself so we can track this vendor over time. It is likely that this would have been captured in the course of the process without having this question, but having the question simply reinforces the need for the data being collected.

The example shows how thinking of operating the process in advance uncovers needs that wouldn’t otherwise be addressed. Vendor performance in this example is not critical to fulfilling a request but it is critical to an optimally operating procurement process.

Last pass review

A final review of all the strategy components created thus far is an important step since it can take a while from the start to the finish of the strategy phase and there can be drift in understanding. The goal of the strategy phase, and therefore the last pass review, is to have a well described, manageable problem with a cohesive approach to solving it. The goals and scope should still make sense. All the sticky subjects should be accepted or resolved. The key concepts should still be valid. The process approaches should be in scope, align with the key concepts, and further the achievement of the goals. Last, but not least, the understanding of all these artifacts is shared and agreed to by the parties involved. It can seem like an awful lot of work up front but, if it’s done right, one of the biggest challenges (communication) only gets easier from here.

In our procurement example we would want to review all the material generated up to this point. It is at this point that it may come to light that we have an unresolved sticky subject, “What if the requestor has no, or more than one, supervisor?” The actual resolution would depend on the organization itself but for simplicities sake, we’ll say that the organization does not have people with more than one supervisor and that we are fine with the CEO not generating purchase requests so we will simply accept the sticky subject.

Process Definition

Overview

The process definition phase leverages the boundaries and approaches provided by the strategy phase to focus on more detail. Since the completion of this phase marks a transition in focus from needs to design of processes, it is necessary to be very thorough in the capture of the stakeholder expectations. The system capabilities will eventually be layered on top of the process definition, but it is important to stay as agnostic as is reasonable of the software solution. The detail of this phase is documented in four components which are Process, Data, Roles and Responsibilities, and Rules.

Process and data

The process, as the name of the phase would imply, is the key component of the process definition phase. It is a direct extension of the process approaches created in the Strategy phase where the individual flow chart tasks are expanded into more precise tasks with the addition of data elements that are collected and additional flow control.

Each process approach should have at least one process that expands upon it. It is likely that there will be processes produced that do not trace directly to a process approach as well since the process approaches necessarily only tackled a limited number of problems. A common example of this is the need for processes associated with data management and the administration of the process as a whole (e.g. authentication/authorization).

While a flowchart is a powerful tool for facilitating the communication of the process it does have its limits. One should be careful to avoid the following common pitfalls.

The process definition in this example expands upon the process approach tasks for “Create Request” and “Send to Supervisor” (Figure 7. Purchase request process definition). Key elements to note include:

• Increase in the number and precision of the tasks

• Additional flow control to handle the increased task precision

• Addition of data captured in the form of call outs

• A new process for the management of employee supervisor information

We can also see how one of our sticky subjects, ordering something that is already stocked, is going to be handled. Specifically, that it will become a responsibility of the requestor to check inventory and determine if on hand materials meet their needs before ordering. The management of whether this process works could be a KPI.

Figure 7. Purchase request process definition

There are many different ways this process could have been designed. For example, the check for availability could have been done after the request was formed instead of before or to have all requests go through an inventory manager and they would handle the ordering. In the end, what is important is to actually have a process design. It can be refined when the system is overlaid on top of the process during solution architecture but without this design it can be very easy for the stakeholders and engineers to end up with different expectations about what is needed.

Rules

The rules component of the process definition captures in a list the most critical do’s and don’ts of the process. Having too many rules will inevitably limit the flexibility of the process and possibly its efficiency as a result. However, some rules likely need to exist in order to keep consistent the assumptions that are guiding the approach. Some of these rules may be captured in the process flow itself where there are no ways around certain decision boxes but there are likely more. The rules themselves may eventually be codified within the system as unbreakable or may be guidance that will be provided to users to follow lest they be visited with unpleasant results.

Our procurement process is going to have a number of rules to ensure that things flow smoothly or at least expectedly. Rules such as requiring three or more quotes before selecting a vendor would stem from regulations that must be followed (e.g. 2 CFR). Our process would need other rules that are unique to our situation as well. These may include:

• Requestors must use on hand material when possible

• The CEO is not allowed to make purchase requests

• Requests may not be modified after they are approved

The rules listed above serve to reinforce the assumptions that are being built into the processes. This is just another example of iteratively refining the constraints.

Roles and responsibilities

Roles and responsibilities is a list of the roles in the process and the different tasks they are expected to perform. The vast majority of these roles and their associated responsibilities will come directly from the process diagram. The process diagram should indicate what roles are relevant to a portion of a process either through swim lanes, color coding, or other easily understandable method. The existence of the role in the process diagram indicates that it needs to be listed. The majority of responsibilities for a role can be gleaned from individual or groups of tasks in the process diagram. While it is not always the case, some responsibilities, and very occasionally roles, will not be captured in the process and can therefore be captured in the Role and Responsibility list.

It is important to make the distinction between a role and an actual person. A person may have multiple roles and a role may be held by multiple people. In practice, some individuals can take on a large number of responsibilities which clouds what their role might actually be. In these cases, it is likely that they simply fulfill multiple roles. Being mindful of this fact is critical since the system solution will be implemented to support the roles that are documented and likely will not be as flexible with role definitions as management can be when dealing with employee turn-over. It is better to have multiple roles that you can apply to one person or multiple people as the operational situation dictates.

In the procurement process, we would annotate the process definition with roles that will execute the process (Figure 8. Purchase request roles). Certainly, all of the tasks reflected in process diagram would become responsibilities. An example of a responsibility that wouldn’t be apparent from the process would be for the requestor to use the charge code that most directly applied to the job material was required for.

Figure 8. Purchase request roles

Solution Architecture

The solution architecture phase marks the transition from definition of needs to the creation of a system design to support them. The main inputs to the solution architecture phase are the process diagram, rules, and roles and responsibilities. The other artifacts that have been created up to this point (goals, key concepts, etc.) provide context for those main inputs. Providing the context to the design team facilitates the understanding of why, or at least accepting that there is a why, the process looks the way it does. Not understanding or overlooking the context can cause inconsistency with the strategy thereby putting the whole endeavor at risk i.e. meeting the letter of a requirement but not the intent. The output of this phase is a reflection of how a system will support the process onto the process diagram.

It is expected that there will be opportunities discovered for simplifying the system function through process and vice versa. These opportunities should be taken and noted so that they can be verified in the gap analysis phase. In addition to opportunities for simplification, necessary additions may be discovered that apply to any or all of the main input artifacts (process diagram, rules, roles and responsibilities). Early and frequent communication with stakeholders is encouraged when either situation arises to protect the cohesiveness of the whole solution.

Depending on the project very little or a whole lot of information may already exist on the tools, languages, and frameworks that will be used to support the process. As a result of this variability limited prototyping may or may not be required. The goal of this phase is not necessarily to define the system architecture in full but to get the user facing aspects of the design to a mature level. There should be time allotted in the project for refinement of design elements such as the data model and architecture after the gap analysis verifies the design supports the process.

In an example showing the solution architected process for purchase request it is immediately apparent that a good deal of information has been added such as status of a purchase request and the fact that there would be a purchase request subsystem and a user management subsystem (Figure 9. Purchase request solution architecture). Highlighted in red are some the additions that were discovered to be needed while coming up with a solution.

Figure 9. Purchase request solution architecture

The example clearly identifies where the system is going to be involved with the process and to a large degree the capability it will support the process with. As solutions are formed the process can adapt as well as be facilitated. The diagram itself can now serve as a tool to facilitate conversation about what the system will ultimately be capable of doing and, even more importantly to the communication, why it must have a capability.

Gap Analysis

In the gap analysis phase, the results of the solution architecture are reviewed and updated accordingly. While the entirety of the solution architected process needs review, the following items should get additional attention.

Some of the artifacts created throughout the MetaHow process were intermediate products that do not need to be maintained. At a minimum the gap analyzed/updated process diagram, rules, and roles and responsibilities should be kept up to date through the systems lifecycle. Maintaining the strategy can have benefits as well such as when major enhancements are made but is not critical to the daily operation of the system.

For the solution architected purchase request process one of the additions to the process has brought into question whether the right role was actually chosen, that of human resources (HR) managing accounts. It had originally seemed logical to have HR handle the association of supervisors but since additional information is needed to support the process (email for notifications) it may be more logical to move the responsibility elsewhere. This is an issue that would need to be resolved before moving past gap analysis.

At the conclusion of the gap analysis the stakeholders and implementers will have a shared understanding of the functions the system will support, the context of usage of those functions, and a preliminary validation of the how the system will meet the strategically defined needs. This shared understanding is documented in a form that will aid all subsequent stages of the systems life cycle (development, verification/validation, operations, decommissioning).

Next steps

At this point the MetaHow has served the purpose of producing a set of agreed to processes that incorporate a system to facilitate its execution. This shared understanding is documented in the MetaHow artifacts and agreed to by virtue of completing the gap analysis. Depending on the software design, there may be additional design work such as would be necessary to refine a software architecture now that the full set of capabilities are known and agreed to. It is also possible that the solution is based upon a robust and existing framework that precludes such needs. Either way, implementation is on the immediate horizon once one final organizational hurdle is crossed.

Documentation of the results of the process can vary depending upon what the organization requires. The substance of the requirements and functional design are captured in the MetaHow artifacts of strategy and the solution architected processes. Should the organization require a traditional set of “shall” statements, the MetaHow artifacts can be mined for these statements. Top tier requirement will be harvested from the strategy, additional user and design requirements from gap analyzed process. To this end the MetaHow does not have to be an alternative to the system engineering processes of an organization but instead can be a means of facilitating them.

A traditionally undocumented component is the process that we have placed so much emphasis on. Due to this it is recommended that the gap analyzed process be incorporated into the documentation that is maintained by the organization. To lose the documented interchange between the system and the process is to sacrifice much of the credit that has been accumulated for use by the delivery and operations teams.

Comparison to traditional software requirements solicitation

The MetaHow process has a similar goal to a traditional software requirements solicitation process which is a detailed specification for what needs to be built. The methodology of becoming increasingly more detailed by breaking down the problem into smaller and smaller parts is just like that of decomposing requirements through tiers. The MetaHow can also be used as an augmentation to a traditional requirements process since the stages lend themselves nicely to being re-documented in “shall” statements.

Where the MetaHow process differs is that it places a more explicit focus on the successful operational use of a system above and beyond the specification of a system. This focus broadens the scope to include the process a system will work within, the cohesiveness of that process, and its synergy with the system. Expanding the focus in this way is of particular value to organizations who are also going to develop the systems they specify since holding the development team to a toxic requirement can be detrimental to the organization as a whole. Contrast this to enabling the adjustment of process and strategy to frame a less objectionable requirement. The bottom line is that there is more to a problem’s solution than software, and therefore more to the communication of the solution than requirements.

Use cases are a common tool for requirements solicitation that have many similarities to the processes produced as part of the MetaHow. As mentioned early on, communication is challenging, so ensuring that the use cases are cohesive and align with an originally stated goal can be very difficult without a framework keep the problem manageable. Another pitfall of use cases can be the scope of information the use case is evaluating being too system centric. This leads to solutions being stated in the form of a problem to be solved. Dissecting the system from the initial definition of the process aims to keep the focus on the problem being solved and the tasks that will be occurring whether or not a system is involved. Indeed, those non-system tasks needed design as well and may have been missed or misaligned with the system if the original use cases did not include them.

Requirements are a very precise but semantically poor method of communication. In other words, they often fail at creating an understanding of whole system that is similarly interpreted by multiple readers. The fact is that each requirement is less than the sum of all the requirements is overlooked when requirements are the only tool used for facilitating communication between the stakeholders and engineers. This compounds the issues that arise from neglecting the development of processes that surround the usage of a system. Indeed, it is common to only develop those processes at a time very close to the systems delivery. It is at these times where a conversation about an issue discovered operating a software system results in one party thinking a requirement is met and the other thinks the very same requirement is not. The MetaHow process incorporates the development of these processes early on as opposed to in conjunction with or after system validation.

The systems engineering V diagram is an elegant depiction and approach for the specification and acceptance of a system, but it may be upside down. Taking the perspective that gravity would make one side of the V easier than the other the development of requirements would be easier than the verification and validation. When the process surrounding a specified software system is not taken into account in the development of its specification, the ease and difficulty of each side of the V manifests itself. This is most apparent when the reality of what requirements have become is made available to stakeholders for validation. The MetaHow process works in an inverse way where the initial stages can be very time consuming due to need for process design as well as system design. The strategy and process facilitate clearer visions of the results including its efficiencies, inefficiencies, and constraints. Working towards shared understanding of these result aspects is difficult, but much better done when changes of direction don’t require the unacceptable rework that discovering them during validation can incur.

Conclusion

There are many right ways to solve a problem whether that be a software solution or a process to gather requirements. What is most important is that the whole problem and how it will be solved is understood by the parties involved. For a problem leveraging a software system, the system is only part of the solution, and its delivery is not the end of the problem. Revisiting the specification of software with an understanding of this reality resulted in the MetaHow process.

The MetaHow addresses the specification of a system from the broader perspective which includes the process the system will live within. The methodology bridges the communication gap between stakeholder and engineer by breaking the problem down into well-defined manageable phases build upon on each other. The artifacts are collaboratively produced and document shared understandings for use through the remainder of the system and process lifecycle. The journey of collaborative production does more than just facilitate a shared understanding but also develops an appreciation of the reliance both stakeholders and engineers have on each other for mutual success. This aspect of the journey can starkly contrast the team dynamic that is formed through repeated exchange of individually created documentation. The fact that both groups have a shared understanding of the interplay between system and process is priceless when working to collaboratively overcome challenges that will present themselves during implementation, delivery, and ultimately the operation of processes. Indeed, there is not only a foundation of understanding but also the experience of collaborating to overcome very similar challenges to achieve mutual success.