Requirements

Note: This wiki is a work in progress, and may contain missing content, errors, or duplication.

---

1 Introduction

Requirements development and design uses a variety of elicitation techniques to gather a set of actionable, measureable, and traceable criteria (requirements). Some of these criteria are artifacts from previous work done, as described in the chapters on Strategy and Governance and Change Initiatives. The rest of the criteria are gathered by the requirements team to prepare for the construction (solution implementation) phase, described in the Construction chapter.

The requirements are said to belong to a particular domain — a specific sphere of activity or knowledge. A domain can correspond to the boundaries of an organization, a job function, or even a particular task.

These criteria/requirements are collected, analyzed, categorized, and documented in a series of artifacts, such as use cases, acceptance criteria, mockups, and market requirements. Finally, the criteria are morphed into a design for a product (good or service) or a set of product capabilities that meet the identified customer or organizational needs.

A design is a proposed solution, as described by a set of documents (and potentially, prototypes) that meets currently understood technical, nonfunctional, and business requirements. In essence, a solution specifies a set of changes to the current state of an enterprise that enable the enterprise to meet a need, solve a problem, or take advantage of an opportunity. In the requirements analysis phase of the project, the conceptual and logical designs of the solution are developed. The detailed technical design is created during the construction phase (see the Construction chapter).

Be aware that as the requirement analysis process is carried out, the requirements might change, both because of improved understanding of the domain and because of changing organizational conditions. This is especially the case during projects that use iterative (agile) development approaches, where only part of the domain is worked on at one time.

The scope of the solution defines the portion of the domain that is part of the implementation. It is typically narrower than the full scope of the domain within which it is implemented.

This chapter covers both the process of collecting the criteria as well as creating and managing the artifacts that the result from the requirements process.

2 Goals and Principles

The goal for the requirements analysis and design phase is to collect all the data information required to develop an effective solution for the problem domain. In general, there are several principles that need to be followed during this process, including:

• Ensure that the requirements are aligned to enterprise strategies and goals as well as EIT strategies and goals, as defined in the Strategy and Governance chapter.
• Ensure that the proposed conceptual and logical solution designs meet the objectives of the requirements.
• Develop requirements that are clear, unambiguous, usable, current, feasible, well-formed, and can be validated and traced.
• Provide the level of detail needed to understand and deliver the business capabilities and related features required to meet identified customer and organizational needs.
• Provide the level of detail needed to test and validate that the solution delivered meets the requirements.
• Provide the level of detail needed for customers or recipients to be ready to receive and use the delivered solutions.

3 Context Diagram

Figure 1. Context Diagram for Requirements Development and Design

Requirements development and design starts with a number of inputs. Many of these inputs are requirements defined by senior management. They indicate the enterprise’s plans and goals. They specify the desired business and EIT architecture. Inputs usually include a use case or scenario that describes in general terms the solution that management is looking for. Along with the enterprise requirements there should be a list of individuals who can supply important pieces of information or authority for the project.

The requirements project team often consists of several people who have a variety of skills including business analysis, solutions architecture, data modeling, user interface design, and project management. This team collects both high-level and detailed information during the project, and then documents, analyzes, and ensures that the solution chosen meets the enterprise requirements given to them by management. The team’s output should give the implementation project team enough information to create and deliver the solution. It should also give the stakeholder organizations the information that they need to prepare for the changes required to their business processes.

4 Requirements Analysis and Design Process

The requirements process includes several different activities:

• Reviewing the requirements that have already been established
• Figuring out what information needs to be collected
• Collecting the requirements
• Analyzing the requirements (such as decomposing, modeling, and resolving inconsistencies)
• Documenting the requirements in a form suitable to those who use them
• Comparing the requirements with existing standards to evaluate for exceptions
• Reviewing and validating the requirements with stakeholders
• Creating a sufficiently detailed conceptual and logical designs for the solution that is consistent with the requirements
• Reviewing and validating the design with the implementation team

Although these activities seem to follow one another, it is often the case that in the middle of a project all these activities are going on simultaneously — often on different parts of the domain.

In some strategies, the requirements development team first lays out the high-level architecture of the conceptual design. The team then fills out the requirements feature by feature or function by function. This process is often used in iterative projects, so that parts of the system can be under construction while other parts of the domain are being specified.

For each of these activities, there isn’t just one technique to use or list of things to accomplish. The size, complexity, and type of the project influences how the team steps through the requirements phase, what techniques the team uses to collect the requirements, and what artifacts the team creates to represent (communicate) the domain information to the stakeholders.

4.1 Requirement Types

Requirements fall into several categories. No one category is more important than another to define a successful solution.

• Business requirements are the critical goals, objectives, and needs of an enterprise that must be met by the solution. They should indicate why the project was initiated and what metrics are used to measure the success of the solution.
• Stakeholder requirements are statements of the needs of a set of stakeholders associated with the project. They describe the needs of each stakeholder affected by the solution as well as how the stakeholder interacts with the solution. Often stakeholder requirements are a bridge between the business requirements and the detailed functional solution requirements.
• Solution requirements describe the specific characteristics of the solution (such as an application or an infrastructure build-out) that meet the requirements of both the enterprise and the stakeholders. The development of solution requirements constitutes the bulk of the requirements analysis process.
  Solution requirements fall into two categories: functional and non-functional requirements. Functional requirements are those that describe specific behaviors or functions of the implemented solution (calculations, technical details, data manipulation and processing, and behavioral requirements). Non-functional requirements specify additional criteria often called qualities or just “-ilities” (execution performance, constraints, reliability goals, usability, security, testability, maintainability, extensibility, and scalability). The EIT Quality chapter describes the -ilities. Both types of solution requirements are important to ascertain and document.
• Transition requirements describe the capabilities that the solution must have to facilitate the transition from the current state of the enterprise to the desired state. Transition requirements are fulfilled when the transition to the new state is complete, and are associated with issues such as filling workforce skill gaps, creating new resources, and converting data to a new format.
   
  
  Figure 2. Types of Requirements

5 Enterprise Analysis and EIT Change Initiative Inputs

Requirements analysis typically starts with a request from the group who is in charge of enterprise change initiatives. In the best of all possible worlds, that request is a clear definition of the project including a set of enterprise-level artifacts (such as business and use cases, strategic plans, customer need descriptions, results of a SWOT analysis) that describe the problem and the end product or functionality desired, and guide the project to its fruition.

Unfortunately, few projects start the requirements phase with all this information collected and documented. So the requirements team must first gather the existing information and then fill in the holes. Without the enterprise-level requirements, a project cannot be successful, because there is no target and no meaningful way to measure success.

The requirements team needs the following information, which comes out of the enterprise strategy work (see the Strategy and Governance chapter) and the change initiative effort (see the Change Initiatives chapter):

• Associated enterprise goals and requirements
• Associated enterprise strategies and governance
• The business case for the project
• A specific definition of the solution and its scope
• A list of stakeholders associated with the solution

There are a number of activities that can be extremely useful in collecting this information, including:

• Gap analysis (or needs assessment) is a technique that explores and describes the gap between the current actual enterprise or group performance (the “as-is” state) and the desired performance with the solution (the “to-be” state). This analysis focuses on the use of resources such as time, money, and workforce to produce the organization’s desired level of performance. Gap analysis is a good tool to help define the solutions approach and scope.
• A strengths, weaknesses, opportunities, and threads (SWOT) analysis for the specific area of concern (often a specific objective) is an excellent tool to help focus the discussion on creating a solution that can have the optimum positive effect for the organization. It can guide requirements identification and analysis at all levels.
• Determining solution approach is an activity that investigates the most viable approach for a solution. It examines the business needs, organizational processes, and required capabilities, and ends up with a description of the approach that should be taken to implement the new set of capabilities. It requires documenting assumptions and constraints; ranking approaches based upon performance improvement estimations and benchmarking; and collecting performance requirements such as availability, response time, accessibility, and maximum throughput.

6 Domain Elicitation

A large portion of the requirements development process is associated with simply collecting the right information, referred to as domain elicitation. Simply, this activity is associated with gathering information from subject matter experts (SMEs), stakeholders, or consumers about how the solution should function. Let’s say that the solution is to provide expertise or guidance to a junior repair technician. The team must collect the repair expertise and guidance from an SME so that the solution can provide the correct repair guidance to the user.

There are entire books written about domain elicitation or knowledge acquisition as it is referred to in some areas. [1] Strong interviewing skills are a requirement for the team members. The interviewer develops an expertise over time for guiding the SME to deliver useful information in an efficient manner. In this section, we list a few basic approaches that can help.

6.1 Plan Your Approach and Prepare for the Elicitation

Planning for elicitation sessions is critical. There should be a plan for both the project as a whole, as well as a plan for each elicitation session. The overall plan should include the different sessions required, what needs to be collected, and the associated stakeholders. This is a high-level plan and evolves during the project.

The plan for each session should have significantly more detail. Among other things there should be:

• A well-defined goal
• An agenda
• A list of supporting materials needed at the session
• The stakeholders that must attend along with their role

Why all this structure? Staying focused on the task at hand is necessary for success in an elicitation session. Usually it is difficult to get stakeholders to attend meetings in the first place. It is critical to use their time wisely by collecting as much information from them as possible. In addition, collecting all (or most) of the information about one small topic is much more efficient that collecting pieces of the puzzle in multiple sessions. Having all (or most) of the information leads to better analysis results.

6.2 Conduct the Elicitation Activity

There are several tools that are extremely useful during the elicitation process:

• Scenarios — It can be extremely useful to go through a number of scenarios in detail. A scenario is an end-to-end walk through of a process, such as identifying a fault to repair, or maybe purchasing car insurance. It examines one path through the process and also includes rationale for any decisions or distinctions that are made during the process. The rationale can indicate why particular questions are asked of a user or why the solution takes a particular path, or why certain recommendations are made to a user. Document any paths that should not be used, as well.
  The amount of detail that you need to collect in the scenario depends upon the scope of the solution. At times, scenarios can be the most critical tool in the elicitation toolbox, because they provide not only a means to collect the information to create the solution, but also provide a basis for creating test cases for testing the solution after it is implemented.
  A domain might be small enough that only a couple scenarios are enough to guide the solution definition; however, some projects are large enough to require several hundred scenarios to cover the entire domain.
  Scenarios can become use cases in the requirements document.
• Observe people working or doing the activity — Sometimes people cannot describe what they do. For example, try to tell someone how to tie their shoes without looking at your own shoes. The elicitation team can, instead, watch the stakeholder or SME perform the task in question.
  This technique is really just a special instance of a case study. Asking clarifying questions while the SME performs the task can provide the critical knowledge required to develop the solution. This technique also identifies data sources and job aids that people use to perform the task that could become an important part of the solution.
• Stories — SMEs often tell stories about what has happened in the past that provide very useful information about both functional and non-function requirements. They might talk about an interaction with a customer or a problem that occurs frequently. The difficulty with stories is that people often ramble on without saying anything useful. The discussion is fun to listen to, but it doesn’t provide information that is useful to the final solution. It is up to the interviewer to keep the discussion focused on useful information. A skillful interviewer gently guides the storyteller back to the topic at hand.

6.3 Document the Elicitation Results

Notes about the elicitation sessions are very important. They need to be detailed, because it is often difficult to tell what information is important during or shortly after the interview. Sometimes, the team discovers that the SME dropped a true gem of information that is not recognized for several weeks. If the notes are detailed, you can go back and pick up the additional information at a later time. It may be useful to have someone taking notes who is not asking questions, to that each person can maintain focus on their specific activity.

The notes become input for the requirements analysis process and for documenting the requirements. At times, the scenarios discussed in the interviews only require polishing at those later stages.

Beyond documenting what you heard or saw during the elicitation process, you should also make notes about:

• Information collected that might indicate business requirements or transition requirements that have not been identified yet
• Areas of the domain that had not been identified yet
• Issues that are beyond the scope of that interview that need to be discussed
• Information that might contradict requirements that have been previously collected
• Other sources of information (maybe other SMEs)

7 Requirements Analysis

After the information has been collected through the elicitation process, it needs to be analyzed. This analysis process takes a careful look at all the information and puts it in context with the other information (requirements) that have been collected.

7.1 The Requirements Analysis Process

The analysis process can be described by a number of activities: organize, model, verify, remedy inconsistencies, define assumption, define constraints, prioritize, and ensure completeness. Although the type of project demands different amounts of time with each of these activities, all these activities are important for proper analysis of the information collected.

7.1.1 Organize

The most important activity is to organize the requirements (information) based upon type, level, and role. Typically, the information is organized into three groups:

• Processes associated with the domain — These are the steps in a flow of activities, whether high or low level. This information modeled in flow charts, Gantt charts, sequence diagrams, state diagrams, or other representations.
• The data required for or produced by the processes or tasks in the domain — Data can represent information at a number of levels. Low-level data consists of numbers, names, and other base-level information. High-level data consists of mathematical results or logical conclusions made based upon the base-level data. Data models are critical for designing databases and the solution’s data structures.
• The business rules that drive the solution — Business rules are statements that indicate whether an actor can or cannot do something. They also provide the conditions and criteria for making a decision. For example, “a user must have an account to make a purchase.” In essence, a business rule is an implementation of a business requirement.

To describe all aspects of the information collected during elicitation, there are several different kinds of documents created, as described in the Requirements Documentation section. These documents need to be comprehensive, complete, consistent, and understood by all stakeholders.

7.1.2 Specify and Model

Specifying and modeling the information takes the organization process to another level. The goal of this activity is to start formulating the details of the solution. Often this activity describes and models information, such as:

• Current state (“as-is”) state of the organization
• Needs and desires of the stakeholders for the (“to-be”) solution
• Models of the business logic currently being used
• Details about the data, and how it needs to be defined and organized
• How the data flows through the processes
• How decisions are made and the contexts that they are made in
• How the processes flow and what intermediates states can be identified
• Under what scope does each of the requirement, data, and processes apply

The result of the specification and modeling task are a host of analysis documents described in Requirements Documentation, including state diagrams, data modeling diagrams, business rule documents, sequence diagrams, and use cases. [7] [8]

7.1.3 Verify Completeness

One of the parts of the analysis process is verifying that you have collected all the information you need. It is often the case that the team discovers during analysis or documentation that they don’t have everything that they need to define a solution; there are holes in their information that can block the implementation team from finishing the solution. While the completion verification process is not easy, it is critical.

7.1.4 Identify and Remedy Inconsistencies

Not only is data often incomplete, it is also often inconsistent or even contradictory. Often, the inconsistencies are obvious; however, at times the inconsistencies are subtle, such as data being used as an integer in one context and a real number in another. Business rules might be contradictory in subtle ways, hiding the inconsistency until lower-level requirements based upon the inconsistent rules are identified as being inconsistent.

It is the role of the analyst to identify inconsistencies in the process as soon as possible, and then to go back to the sources to get the inconsistencies resolved. There are several techniques, such as using quasi-classical logic to resolve the issues. [2]

7.1.5 Define Assumptions

Assumptions are factors upon which design decisions are made, which are believed to be true, but have not been or cannot be confirmed at the time of collecting the requirements. Assumptions can affect all aspects of a project, and their associated uncertainty adds a certain degree of risk to the project. It is crucial to identify, document, and attempt to confirm all assumptions in order to manage their associated risks. Assumptions are one of the major factors associated with problem tracking and risk analysis.

Some assumptions are very high risk. For example, if you are running an app on a mobile device, you might have an assumption that Wi-Fi is available. Or maybe, you app depends on the user being able to hear the device. If either of these assumptions is incorrect, the application doesn’t work or isn’t useful as designed.

Assumptions can also be low risk. These are assumptions that define boundary or likely conditions for the solution, such as how a user is likely to respond to a particular situation.

7.1.6 Define Constraints

During the project, it is typical to identify constraints on the solution. Constraints are restrictions or limitations on solutions posed by outside influences whether by the EIT infrastructure, organizational policies and culture, legal requirements for safety, privacy, budget, available resources, or schedule. It is critical to identify, document, and publish constraints as part of the problem-tracking process. Constraints figure heavily in the prioritization process.

7.1.7 Prioritize

More often than anyone would like to admit, requirements conflict with one another. You might have a need for some functionality but no budget to implement it. You might have a requirement for putting the application on a smart phone or tablet, but require significantly more horsepower and space than is available on the device.

One of the tasks is to determine (and document) the relative importance of requirements based upon the value to the enterprise, business risk, technical risk, the difficulty to implement, or likelihood of success. Regulatory or policy compliance (legal) can also be a critical aspect. Even a requirement’s relationship to other requirements, such as a critical dependence, needs to be considered.

The difficulty with this task is that it often requires stakeholder approval — maybe approval from all the stakeholders. And, they often have differing opinions on the relative value and risk associated with requirements. Often there are “non-negotiable” demands and unrealistic tradeoffs that need to be addressed.

Several techniques are particularly helpful in this area, such as decision analysis, MoSCoW (acronym for Must have, Should have, Could have, and Would like but won’t get) analysis, risk analysis, time boxing, and budgeting.

7.1.8 Ensure Completeness of the Analysis

All of this analysis is useless if the analyst team does not make sure that each requirement is well-formed and completely specified, as described in Qualities of Well-Formed Requirements.

7.2 Qualities of Well-Formed Requirements

There are a number of sources that define the properties of well-formed or “good” requirements. [3] [4] These beneficial characteristics help ensure that the requirements process is complete and that it results in a successful solution implementation. The more critical and more complex the project, the more important these qualities are.

• Clear and unambiguous — Can all stakeholders and solution implementers understand the requirement? Is there any disagreement about what the requirement means? Each requirement needs to be specified (or modeled) in a way that is clear and unambiguous.
• Usable — Is the requirement useful in creating or defining the solution? Requirements that are not useful or usable confuse the situation and the solution definition process.
• Current — Does the requirement reflect the current situation or where the solution must head? Requirements should not conduct history lessons and should not tell stories about the past. They need to reflect the current situation or where the organization needs to head.
• Traceable — Do you know where the requirement came from? It is critical to know the source of each piece of information. Did it come from an interview with an SME? Is it from a particular manager or executive? If another requirement appears to be in conflict with it, do you know who to discuss the issue with?
• Granular — Is there only one criterion/data item in the requirement? It is critical to be able to distinguish between the pieces of information. This actually isn’t as easy as it seems. It is hard to get individuals to disambiguate issues, so they often develop requirements/goals that address both issues, when they should split the issues and then develop new business rules.
• Measurable success criteria — Is the requirement written in a way in which you can measure whether the requirement has been satisfied? Can these measurements be incorporated in tests and in release criteria?

7.3 Requirements Verification and Validation

Validation and verification happen frequently during the requirements, design, and construction processes. They ensure that the implemented solution truly fills the gap identified by the enterprise. Validation and verification during the requirements analysis phase has a particular slant:

• Requirements validation ensures that all requirements reflect the customer’s real needs. Because there is no prototype available at this point, this means asking the stakeholders to validate that the requirements and resulting analysis support their needs.
• Requirements verification ensures that the results of the analysis process are consistent with previously collected requirements. This process verifies robustness, correctness, and consistency among all requirements and analysis results.

8 Requirements Documentation

There are a number of ways to document criteria/requirements/data that is collected during the requirements analysis process. The techniques or document types that are needed depend on the type of domain and the nature of the solution. One size does not fit all; however, the list below includes the most commonly used documents. Each of these document types are text-based; diagrams (described below) can be added for additional clarity.

8.1 Text-based Documentation

• Interview transcripts — Interview transcripts can be relatively unstructured documents that follow the flow of the interview. There are a few characteristics that help them be effective documents. They should be dated and all participants should be listed. The purpose of the interview should be stated up front. The person making each statement should be clearly indicated. More advanced analysts also color code statements that indicate different kinds of information, or they add comments after the fact to shed light on the importance of a statement or action that needs to be performed because of the statement. It is also helpful to make notes about topics that should be covered in future sections.
• Scenarios and use cases — Scenarios and use cases are predominantly a list of steps that someone takes to perform a task. The steps often document an interaction with a system, such as a computer application, but they could be steps that a repairman takes to identify and fix a problem. Why use one versus the other?
  As mentioned earlier, scenarios go through a single path of the process. They don’t cover multiple possible outcomes or alternative flows. Scenarios are great elicitation tools and are often used by the QA team to create tests for a single logical path through the domain. The QA team can use the scenario as a gold standard of the interaction between the solution and the user.
  Use cases, however, cover multiple outcomes and alternated flows. Use cases are better at guiding the developer in building the solution. They describe all of the options available for the user at a given point. They build a more complete picture of the current state and all of the options that the user has. There are lots of templates available for use cases and they are often considered a critical tool in the solution-definition process. For a good how-to reference, refer to Writing Effective Use Cases. [5]
• Data dictionary — This document is a dictionary of data items. This repository of information describes each item including its meaning, its origin, how it is used, its data type, possible values, and its relationship to other data. A data dictionary is a critical repository for any application that contains a significant number of data items.
• Security, privacy, and data classification — Enterprise solutions require a security plan. These plans are usually separate documents that cover all the security risks and the means for addressing them. The plan should list all the assets that need to be protected, the associated risks with each assets, the way to protect the assets, and the cost of protection. Basic questions include: How are users going to be authenticated? How is personal data going to be protected? What data needs to be protected? [6]
• Business rules — Business rules defines how the enterprise operates. They are statements or conditions that indicate what actions particular individuals can perform or what decisions they can make. A business rule might be something like: An online store customer must have a valid email address. Business rules must be stated very precisely. Slight changes in wording can make a huge difference in how the requirements are developed. Rules need to have owners and they need to be easily found and tracked.
• Metrics for testing and release criteria — A key aspect of specifying requirements is identifying the criteria that are used to determine whether the requirement has been satisfied (the definition of Done). When requirements are well formed, they contain the measures of success for the intended application or solution. These measures need to be captured as the evaluation and acceptance criteria for the solution. In other words, how do you know when the solution is good enough? What conditions must the solution satisfy to be accepted by the stakeholders?
  Typically there is a document that collects these necessary conditions and labels them as release criteria. These criteria specify how the solution performs, as well as expectations of how the organization performs with the solution. These criteria are sometimes called the solution’s key performance indicators (KPIs). They should be included in tests and can be things such as the response time during a session, accuracy/relevance of a recommendation to a user, uptime of the solution, or mean time between failure. The key performance indicators for the organization can be metrics such as the level of customer satisfaction, the number of defects per 1000 units, labor spent per month, burn-down rates, or the return on investment (ROI).

8.2 Graphic-based Documentation

Diagrams are useful for illustrating what would take many paragraphs to explain. Diagrams do not stand alone as documentation — descriptions of the diagrams are also important.

• Sequence diagrams — These diagrams describe a process. They show how processes operate or interact with one another. They are often referred to as event diagrams or event scenarios. There is a specific visual language used with these diagrams.
• State diagrams — These diagrams are used to model behavior. There are several different kinds of state diagrams, but most represent states of a system (e.g., on and off) using objects (such as circles) with lines from one circle to another that represent an event or action taken to get from one state to another. State diagrams are not flow charts, which describe process flows.
  
  Figure 3. State Diagram
• Data flow diagrams — These diagrams are graphic representations of the flow of data through an information system. They show the flow of inputs and outputs through the system and its components, and where the data is stored. These diagrams can be used at a number of levels to describe the system.
  
  Figure 4. Data Flow Diagram
• Decision tables, trees, and rules — These tools are used to model decisions and their consequences. They model algorithms. They often lead from observations to conclusions. There are several different ways to use these representations and they are closely related to influence diagrams.
  
  Figure 5. Decision Table and Rules

8.3 Image Creation Best Practices

When creating diagrams for requirements documentation, there are some guidelines that can help make your images more readable and understandable.

1. Choose a direction for your flow. All arrows should point in the same general direction as much as possible. The reader then can start from one end of the diagram and follow the paths to the other end. Circular flows are acceptable, as long as there is a definable path.
2. Use a legend, and keep the legend in the same area of all images. Pick a corner or a side for the legend location. All legend elements should be in the same place on the diagram so the reader does not have to screen out multiple areas when reading the diagram.
3. Use the same size icons for the same things. Different sizes of icons for similar objects makes it appear that the items are different somehow, and is distracting if there is no reason for dissimilar sizes.
4. If possible, create templates for common image types so that all diagrams use the same icons for the same thing, similar to the way flow chart elements have a standard icon list.

8.4 Important Characteristics of the Documents

The documents themselves need to have many of the same characteristics of the requirements:

• Understandable and usable — The documents need to be understandable and usable, and not just by the person who wrote them. These documents are likely to be read and reviewed by many stakeholders including SMEs, users, management, and solution implementers. They all should be usable by all for the purpose of that particular reader. For example, a tester should find information critical to designing tests; someone writing a user manual needs to understand how the user’s actions are responded to; customer support needs to know how the solution works, such as if there are known problems and known workarounds; and so on.
• Consistent — The requirements documents cover the description of many requirements and it is critical that there is consistency of terminology, structure, and tone between the documents. For example, a characteristic of a situation that is used to make a logical conclusion in a case study should be included in the data dictionary. In addition, the name and the qualities of that item should be the same in both documents. Keeping the documents consistent takes considerable effort, but it is absolutely necessary to ensure a robust solution design.
• Current — These documents need to be kept current. These documents are not useful if they are behind the elicitation and analysis activities by weeks or months. They should be updated within days of collecting new information.
• Traceable — The information in each of the documents as well as the documents themselves need to be traceable. The owners of the documents should be clear. There should be a change-tracking system associated with these documents so that all stakeholders know when particular information was added or changed, and by whom.
• Organized and modifiable — It is inevitable that some requirement previously gathered will change when analyzed. Organize and label the requirements to enable searching.

9 Conceptual and Logical Design Development

The requirements elicitation and analysis process is inextricably intertwined with the development of the solution’s conceptual and logical design. You can’t have one team collect the requirements and data, and then have another team do the design, because having intimate knowledge of the requirements analysis results is critical. On the other hand, the solution design process requires skills beyond those needed for requirements gathering and therefore, team members who are solution design experts, such as UI designers, system architects, and data engineers, need to become involved as the requirements evolve in specificity.

At this point, it is important to make some distinctions about the design process. Most sources divide the design process into three phases:

1. The conceptual design describes the proposed solution in a functional manner that could be easily understood by a future user. It describes how the solution looks and behaves.
2. The logical design defines objects, entities, their attributes, and their relationships. It also describes the business rules associated with these entities.
3. The physical design is where the other two designs are converted to a definition of how the solution is implemented in hardware, software, and potentially other media. The physical (a.k.a. technical) design is developed by the construction team not by the requirements team (see the Construction chapter).

9.1 Solution Components

The majority of business solutions are composed of multiple components. Each component is associated with a subset of the requirements, and it is important to understand which requirements are driving the design of a particular component.

Solution components can include:

• Business policies and business rules
• Business processes to be performed and managed
• Job functions and responsibilities of the people who operate and maintain the solution
• Software applications and application components used in the solution
• Supporting hardware (such as servers) for processing efficiency, data storage, additional networking capabilities, or new capabilities like voice inputs, mobile applications, and 3-D printers
• Structure of the organization, including interactions between the organization, its customers, and its suppliers

9.2 Design Techniques

There are a number of techniques used during the design process that enable the team to develop an optimized solution for the set of requirements. A few of these are listed below.

• Impact analysis — Understanding the impact of each component and function is critical to determine what functionality is implemented in the solution and when it is implemented. Impact analysis identifies the potential consequences of a change or estimates what needs to be modified to accomplish a change, as defined in A Guide to the Business Analysis Body of Knowledge. [8]
  A good impact analysis report includes a detailed cost/benefit analysis. It outlines the risks, costs, and business requirements that are being met. It shows the links between requirements both in respect to dependency and traceability. The design team uses the impact analysis report to determine the scope and prioritization of the solution implementation. They may also find a need to refine the report as they work on the details of the scoping and prioritization.
• Prioritization of development — The design team works with stakeholders, the impact analysis, and the enterprise requirements to develop a priority order for the development of the requirements and components. Prioritization might also drive changes in project scope.
• Scoping — This process determines what is and is not included in the solution. This might include functionality, requirements, cost, timing, and personnel. Scoping is often an effective technique for staging the development of a solution. For example, an organization can implement low-cost and easy-to-implement solutions first, and then add the more expensive and harder components later.
  Iterative and incremental development approaches (such as Scrum, Agile, Lean, DSDM, and Spiral) split the total scope of the project into smaller chunks. This allows stakeholders to adjust a project’s requirements or goals after they see prototypes or demonstrations that have partial functionality. The stakeholders along with the development team determine the features to include at each iteration cycle. After each cycle, the next cycle’s features are selected and the requirements analysis, design, and construction phases occur for the new cycle. At times, the results of a cycle provide information that prompts an adjustment to the full scope of the project.
• Prototyping or proof of concept (POC) — This technique creates a preliminary version or model of the final solution. We often think of creating a prototype for computer programs or machines; however, the technique is equally valid for job aids, job descriptions, training programs, and so on. The job of the prototype is to illustrate the qualities and functionality of the component. Prototypes are especially effective, because users can experience them and give detailed feedback on how well they meet their needs. Prototypes are also effective vehicles for identifying faulty assumptions and missing functionality.
• Security design — Security design has become increasing important over the last 30 years. The team must understand the security requirements and design the features necessary to meet them. The design needs to take into account authorization and authentication, data encryption, user and data privacy, data auditing, non-repudiation, and conformance to standards. See the Security chapter for more information.

9.2.1 Alternatives Analysis: Functionality Reallocation

During solution design, it is often necessary to reallocate functionality between the different solution components. The reason for this is often the cost required to develop or maintain the solution. For example, it might cost too much to implement a computer application to provide some functionality, so simpler job aids are created instead. Or perhaps a desired new business rule requires too much manpower to implement to make it worth the benefit received. In general, when the design process is well underway and the cost to implement each component becomes evident, the team can determine which functionality allocations have the best cost/benefit ratio for the enterprise.

10 Solution Review, Verification, and Validation

One of the most important things to do after creating a conceptual and logical solution design is verification. Stakeholders must assess proposed solutions to see if they meet all stakeholder and solution requirements. This verification process ensures that requirement specifications, models, and prototypes meet the necessary standard of quality for the solution to be correct and of acceptable quality. The process determines whether a solution design component is ready for formal review and signoff.

One of the activities during this process is to validate that requirements are met. This means that the requirements, as they are manifested in the solution design, support the delivery of value to the business, fulfill the enterprise’s goals and objectives, and meet the stakeholders’ needs. To ensure that this is the case, it is often valuable to define detailed acceptance and evaluation criteria. Key metrics and key performance indicators for the solution are also often developed.

Sometimes a design appears to meet all the criteria, but when the stakeholders (especially future users) see the design through structured walkthroughs or interaction with a prototype, they point out issues with the design. Often these issues are associated with requirements that were never collected or ones that were not well understood. But often, the solution just isn’t mature enough. It is common for a design to be refined three or more times during the review and validation process.

A solution needs to be complete, correct, consistent, unambiguous, cohesive, testable, robust and feasible; if not, the solution should not be approved. Most of these qualities were covered with respect to requirements qualities (see Qualities of Well-Formed Requirements). There are three qualities that are specific to the conceptual and logical solution design:

• Feasible — The design can be successfully implemented.
• Cohesive — All components of the solution are well integrated and unified. In addition, the components of the solution are created in a way so that their role is clear, complete, and easily distinguished from the other components.
• Testable — A solution is testable when its functionality and its ability to address the goals of the project can be tested and measured.
• Robust — A solution design is robust when it covers not only the base-level functionality, but also the ability to cope with errors during use. That is, the solution can continue to operate in a reasonable way even if it receives abnormal inputs or encounters unforeseen situations.

The review with the stakeholders can take several forms. It can be a walkthrough of a paper solution component with the relevant stakeholders, users working with a prototype, or stakeholders determining which one of several competing solutions is the best. Each solution component has an associated method for review and validation. Each component should also have its own acceptance and performance criteria.

11 Requirements Management and Communication

Throughout the requirements and design process, managing and communicating the requirements, the state of analysis, and the solutions/designs is a vital activity. The success of the project often reflects the ability of the team to manage and communicate, and that often requires a requirements management plan. This plan defines the process of documenting, analyzing, tracing, prioritizing, and agreeing on requirements. It states clearly who attends and who approves during reviews.

At the heart of the communication process is developing a shared understanding of the requirements among all the stakeholders, dealing with conflicts and disagreements when they arise, and then securing approvals from the stakeholders.

When approvals for the requirements and solution designs have been acquired, the team transfers the package to the construction team. Sometimes the construction team is engaged before the requirements effort is done. It is common for the construction team to work on a subsection of the project, while the requirements analysis and solution design process continues on other sections. It is also important to note that transferring the package to the construction team often requires face-to-face training, or that a member of the requirements team works with the developers during the construction process to keep them from straying from the approved requirements and design, and answering any questions that may arise before rework is necessary.

The lifetime of the requirements does not end when the development phase is over; many requirements are valid beyond the scope of one project. It is essential that the requirements are maintained for long-term use (reuse) by the enterprise. As such, the requirements and other artifacts need to be well labeled and stored in a repository where other projects can get access to them. Subsequent projects on the same system may be able to reuse substantial parts of requirements to prevent changes to the system, and feed into regression testing requirements.

12 Summary

The requirements analysis or requirements specification process is often the most complex stage of defining and building an EIT solution. It takes a number of skills and knowledge of many techniques to create a complete and verifiable set of requirements. Expertise in requirements analysis takes years of work; it is best to learn as an apprentice, where one can watch an expert analyst work through the process.

The activities in this phase are not typically sequential. Many activities overlap and requirements analysis for one part of the domain may overlap with construction of another part of the solution. It is even necessary to feed back knowledge acquired during implementation into the requirements process.

This stage is a key to having a successful solution that meets the business criteria, stays within budget, and is easily maintained. For general books on the topics of software requirements and specifications, refer to [8], [9], [10], [11], and [12].

13 Key Skills

While many large companies have defined their own sets of skills for purposes of talent management (to recruit, retain, and further develop the highest quality staff members that they can find, afford and hire), the advancement of EIT professionalism will require common definitions of EIT skills that can be used not just across enterprises, but also across countries. We have selected 3 major sources of skill definitions. While none of them is used universally, they provide a good cross-section of options.

13.1 Skills Framework for the Information Age

The Skills Framework for the Information Age (SFIA) has defined nearly 100 skills. SFIA describes 7 levels of competency which can be applied to each skill. Not all skills, however, cover all seven levels. Some reach only partially up the seven step ladder. Others are based on mastering foundational skills, and start at the fourth or fifth level of competency. It is used in nearly 200 countries, from Britain to South Africa, South America, to the Pacific Rim, to the United States. (http://www.sfia-online.org)

SFIA skills have not yet been defined for the security chapter.

13.2 European Competency Framework

The European Union's European Competency Framework (e-CF) has 40 “competencies” and is used in the EU. (http://www.ecompetences.eu/) It uses five levels of competency. As in SFIA, not all skills are subject to all 5 levels. The EU has also created a mapping between e-CF and SFIA.

E-CF skills have not yet been defined for the security chapter.

13.3 i-Competency Dictionary

The Information Technology Promotion Agency in Japan has developed the i-CD, translated it into English, and describes it at https://www.ipa.go.jp/english/humandev/icd.html. . It is an extensive skills and tasks database, used in Japan and southeast Asian countries. Like SFIA, it establishes seven levels of competencies for skills. An example showcasing the skills and tasks relevant to this security chapter is given below.

14 Key Roles

***No content

15 Standards

***No content

16 References

[1] A. C. Scott, J. Clayton, & E. Gibson, A Practical Guide to Knowledge Acquisition, Addison-Wesley Publishing Company, 1991.

[2] S.A. Bohner and R.S. Arnold, Software Change Impact Analysis, IEEE CS Press, 1996.

[3] Jim Heumann, The Five Levels of Requirements Management Maturity, The Rational Edge, 2003; http://www.ibm.com/developerworks/rational/library/content/RationalEdge/feb03/ManagementMaturity_TheRationalEdge_Feb2003.pdf.

[4] IEEE Guide for Developing System Requirements Specifications, IEEE Std 1233, 1998 Edition; pp. 11-14.

[5] A. Cockburn, Writing Effective Use Cases, Addison Wesley Professional, 2000.

[6] C. Benson, Security Planning, MSDN Library, https://msdn.microsoft.com/en-us/library/cc723503.aspx.

[7] DAMA International, The DAMA Guide to the Data Management Body of Knowledge, Technics Publications, LLC, 2009.

[8] IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 3.0, 2015.

[9] M. Jackson, Software Requirements and Specifications: A Lexicon of Practice, Principles, and Prejudices (ACM Press), Addison-Wesley Professional, 1995.

[10] K. Wiegers, Requirements Analysis 3 (Developers Best Practices), Microsoft Press, 2003.

[11] D. Leffingwell, Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Agile Software Development Series, Addison-Wesley Professional, 2011.

[12] H. Podeswa, The Business Analyst’s Handbook, Cengage Learning PTR, 2008.