Visual Models for Software Requirements: Selecting Models for a Project

Selecting Models by Project Characteristics

In addition to the project phase, you should take into account the characteristics of the project when selecting which models to use. Typically, the first questions to ask are:

• Is this system being custom built from scratch, or will it be purchased from a vendor?

• Will the system replace an existing system entirely, result in a new implementation, or enhance an existing system?

There are several common project characteristics that can be used as guidelines to help determine which models to use. The list of project characteristics in the sections that follow is not meant to be comprehensive but is meant to give you a starting point for determining which models might be appropriate for your project. Project characteristics are not mutually exclusive, so you probably will have multiple characteristics that apply. For example, a project to replace an existing system can also be a cloud implementation. A system that will exist in a large ecosystem might also be an analytics system.

To select models using this section, first decide which project characteristics apply to your project, and then consider the suggested models for those characteristics (shown in rows in the grid in each section) to determine which models will be helpful on your project. The recommended models grid shown in each project characteristic uses the key in Table 25-1.

Table 25-1 Key for Models by Project Characteristic

Meaning	Cell Value
Likely to be needed	L
Might be needed	M
Not needed based on this characteristic alone	blank

The meaning of blank cells is tricky and is important to understand so that you can interpret this information correctly. If a cell is blank, it means that the particular characteristic alone does not indicate the need for that particular model. The project might still need the model, though, because of another relevant project characteristic. Conversely, if the cell is filled in, it means the characteristic alone is sufficient to indicate that the model is needed for that type of project. For example, you might notice that the Business Objectives Model is not indicated for most of the characteristics. That’s because the use of a Business Objectives Model is dependent on a project having one of only a few of the characteristics; however, those characteristics are actually pretty common, and at least one of them will apply to almost all projects. Also, a project for implementing enhancements to replace existing systems functionality might need a KPIM, but it needs the KPIM because the project is replacing an existing system, not because it is an enhancement.

Objectives Characteristics

The following objectives characteristics help determine which objectives models are needed based on the type of project implementation.

Greenfield Projects

A greenfield project is one in which a brand new system is custom built from scratch because no system currently exists to provide the needed functionality. A primary consideration in these projects is scope, because it can easily balloon out of control. Many future users of these systems will offer input on features and requirements that they have for the system, and it is important to prioritize these requests in the context of a Business Objectives Model and Objective Chains. You should create a Feature Tree to show all planned features, and then tie each feature to a business objective so that the organization only builds the features that have the most value. A Requirements Mapping Matrix (RMM) is important to ensure that requirements ultimately map back to business objectives through other models.

Commercial Off the Shelf (COTS) Projects

The goal of a COTS project is to evaluate and select a third-party solution to solve a business problem and then implement it. We have broken the COTS project characteristic into two aspects, selection and implementation, because in many organizations they exist as completely separate efforts with differing model needs. Often the selection phase proceeds, but then COTS implementation does not occur because the team decides to build a new system or improve the existing system.

COTS selection The selection phase involves qualifying vendors, determining what the primary business objectives are, and ultimately selecting a system that meets an organization’s needs. Creating a Business Objectives Model and Objective Chain might be important to ensure that the selection process focuses on the systems that provide the greatest return on investment (ROI) as defined by the business objectives.

During the selection phase of a COTS system, many organizations create a list of features that the organization needs. This method is extremely weak because it does not address how the software satisfies the business process. To resolve this, you should use Process Flows and KPIMs to prioritize the Process Flows and determine the features that support the most critical business processes. You should use an Org Chart to ensure that you are talking to all of the right people about their Process Flows. During interviews with the vendor, you can use the highest-priority Process Flows to have the vendor demonstrate exactly how those processes and KPIs would be satisfied by using their software. You might still want to create a Feature Tree to help you quickly summarize the features deemed to be most important. An RMM helps you keep your features prioritized. In addition, a BDD should be used to ensure that there are no major discrepancies in data models between the software and the business needs. A Data Dictionary might not be needed because the individual fields typically do not require major changes. Finally, an Ecosystem Map should be used to ensure that there is a good understanding of the integrations that the COTS system will need to support. The vendor should be prepared to address gaps between the models and the COTS system.

COTS implementation The implementation phase of a COTS project could be part of an existing system replacement project, but it could also represent installation of a completely new system. If the COTS system is replacing an existing system, and there is little customization, KPIMs are better because they help ensure that business throughput is maintained at desired levels. If there is significant customization, then there are features that you can map to business objectives by using a Business Objectives Model and Objective Chain. If the COTS system is not replacing an existing system or is introducing a significant amount of new functionality, defining the business objectives and their relationship to features by using a Business Objectives Model and Objective Chain is crucial to prioritizing features.

Org Charts can help ensure that all existing users are represented. Process Flows ensure that those users’ functionality needs are understood. The RMM is helpful for ensuring that all requirements of the business processes are implemented in the new system. A Roles and Permissions Matrix is useful because many COTS systems allow you to configure roles out of the box, so this helps you decide who should have those roles and what permissions those roles should have. Ecosystem Maps and System Flows are important if the COTS system will be deployed in an existing ecosystem, to help identify integration points. BDDs and Data Dictionaries help ensure that data used in existing systems or processes is considered, whether it is to be converted to a new type of data or not. Most COTS software comes with standard reports, so Report Tables are important to define how those are deployed. Use Cases might be used to describe how users will interact with the COTS software directly. DAR models might be useful because tables can be created for each element in the UI that is configurable, to help capture the configuration requirements.

Enhancement Projects

An enhancement project makes a major change to an existing system by adding new functionality to the system’s capabilities. Because enhancement projects tend to primarily focus on new capabilities, focusing on mapping features to business objectives is paramount to minimize gold plating. The Business Objectives Model and Objective Chain are extremely important, because they allow you specifically to restrict the solution’s scope to the appropriate people, systems, and data. The RMM will help you continue the traceability by mapping requirements to other prioritized models to control scope. The Feature Tree can provide a quick view of all features that are in scope for implementation.

Because an existing system is being modified, often the data model is not changing. In these cases, a BDD is not necessary. By the same token, if the new features do not require additional integration, then an Ecosystem Map might not be necessary either.

People Characteristics

The following project characteristics are related to the users who use the system.

Systems with Extensive User Interaction

Systems with extensive user interaction are defined as those that have many users performing many types of operations in the system. You should focus on people models first. Typically, Process Flows will be used in a project that is heavily driven by the user interface (UI). Use Cases might be helpful to further describe user interactions. Roles and Permissions Matrices are helpful if you have a limited number of roles or types of user and need to implement a security model in the user interface. UI Flows and Display-Action-Response (DAR) models will be two of the most important models, because they illustrate visual aspects of the solution that Process Flows and Use Cases cannot capture. Each step in the Process Flows can then be linked to a DAR model to illustrate the UI in the level of detail needed.

If you are replacing an existing system or automating a process, KPIMs will probably be helpful because of the increased focus on end-user throughput and completion of tasks. If your project is an enhancement with an extensive UI, these models will be key in order to allow you to keep a consistent look and feel with the current software.

Customer-Facing Systems

Customer-facing systems primarily have users that are external to the organization that is implementing the system. There are typically a few internal roles as well, such as administrative roles, but most users are from outside the organization.

Because the users are external, Org Charts are typically not helpful. Roles and Permissions Matrices might be used to define the type of permissions necessary for security in the system. Process Flows and Use Cases might be important to describe how the customers will use the system. UI Flow and DAR models should be created to ensure that the user interface is easily navigated and used by external users. This is important even if there aren’t very many customer-facing screens.

Business Process Automation Projects

Business process automation projects either fully or partially implement the business’s processes in a system. These projects use KPIMs because the performance of existing manual processes can be measured to ensure that the performance levels are either maintained or improved in the new system. Org Charts are important to ensure that you talk to all existing business stakeholders who execute the process. Process Flows can be used to document existing business processes that will be performed using the new system. Use Cases might help describe how those activities will occur in the system. Furthermore, future-state Process Flows and Use Cases can illustrate how the system should function and provide a basis for new training guides.

Roles and Permissions Matrices might be important for putting a security model in place. BDDs and Data Dictionaries will be necessary to describe the business data objects and fields used and manipulated in the process.

Workflow Automation Projects

A workflow is a specific type of business process that has a heavy emphasis on approvals and routing of information between groups. A project that automates a workflow typically requires a Process Flow to describe context for the workflow. These projects usually have a BDD to show the business data objects that are manipulated during the workflow. State Tables and State Diagrams can help show how the objects change state during the workflow. Typically, these projects have security needs related to who can perform functions at different steps in the workflow, so Roles and Permissions Matrices are helpful.

Systems Characteristics

The following project characteristics are related to the type of system being worked on.

System Replacement Projects

A system replacement project replaces an obsolete solution with either a custom-built system or a COTS system. When an existing system is being replaced, the business objectives are often related to goals such as improving throughput, performance, reduction in license fees, or reduction in maintenance costs. These goals are often not achieved through implementation of specific new features. Even if there are new features, a majority of the functionality simply needs to be maintained as compared to the legacy system. The Business Objectives Model and Objective Chains aren’t as useful because their purpose is to map the value (for instance, return on investment) of features to business objectives. Unlike projects that trace their value up to business objectives, existing system conversion projects should use KPIMs for business processes to prioritize requirements and business rules. At a minimum, the new solution must be able to maintain the KPIs at their current levels—there should be no degradation in overall efficiency from switching to a new solution.

The KPIM is one of the most critical models because it helps analysts demonstrate to business stakeholders that even if the new system behaves differently, the business outcomes will be the same or better. One common challenge with existing system conversions is that new software might cause a reduction in the KPIs of one group while improving the KPIs of another group. Even though overall the throughput and business value are positive, the group that is negatively affected might not approve the system unless they understand that the negative impact is in the context of an overall improvement to the business. You should use KPIMs to reassure the business stakeholders that the new system, though different, will still let them get their jobs done.

With the use of KPIMs, you will also need Process Flows against which to map the KPIMs. Org Charts, Ecosystem Maps, and BDDs are all valuable to an existing system conversion project as well, because they help you understand all current users, the existing system integrations that might need to be replaced, and the full set of data the business cares about. Process Flows are needed to describe the activities that users perform in the existing system. Report Tables are needed because existing systems almost always have reports that need to be converted to the new system.

Real-Time and Embedded Systems

Real-time and embedded systems have significantly smaller or more primitive user interfaces than most user-facing systems. The goal of these types of projects might be to implement automation or controller systems. In real-time and embedded systems, System Flows are the dominant models. Ecosystem Maps and System Interface Tables might be helpful if the real-time system has interfaces with many other systems. Most people models will not be helpful, because a majority of the effort will focus on the steps within the system. Real-time and embedded systems often have very simple data models, so a BDD and a Data Dictionary might not be necessary. Although the system will obviously be dealing with data, it is most likely doing so at a technical level, so the business stakeholders are not concerned about the details of the data itself. State Tables and State Diagrams are commonly used, because these types of systems often have complex state changes that trigger behaviors.

Large-Ecosystem Projects

Projects with large ecosystems have many existing systems that interact. You should focus on the systems first by starting with an Ecosystem Map. System Interface Tables might be needed to describe the interface requirements between systems. Identify the business data objects to create BDDs, and then use Data Flow Diagrams (DFDs) to show the flow of data between the systems. Data Dictionaries will be necessary to describe the fields and rules for the data.

Internal IT Systems

Internal IT systems are systems in which all (or most) of the users are internal to the organization. These systems are deployed in one organization’s environment. Org Charts will certainly be used because the users are internal, and Process Flows are necessary because they define how the business will use the internal system. Roles and Permissions Matrices will probably be used to describe the security model for users. Ecosystem Maps are helpful to show how the system fits in with other existing systems in the IT organization, and System Interface Tables might be helpful if the interface requirements are important to the business stakeholders.

Hardware and Software

Systems that have both hardware and software components to be implemented typically have many inputs and outputs to be considered. Although people and data models are important, system models are the most critical to create for this characteristic. An Ecosystem Map shows how the components are related, System Flows show how the hardware and software interact, and System Interface Tables describe the inputs and outputs between each component. Keep in mind that although these models are similar to technical models, the purpose of these models is to derive the requirements—whatever the business stakeholders need. Leave the technical documentation to the technical team.

Packaged Software

Packaged software is software that is sold as stand-alone software. Packaged software should heavily use people and data models and will probably use few system models. Process Flows and Use Cases are helpful for showing how the users will interact with the software. Org Charts are not useful because the users are not common to one environment. Feature Trees are useful for actually building the “packaging” for the software. RMMs help control scope by mapping the requirements to Process Flow steps to ensure that extra features that are not anticipated to create significant value for the users are excluded. UI Flows and DAR models are important for modeling the user interface.

Cloud Implementation Projects

In cloud implementation projects, you are implementing a cloud solution to solve a business problem. The fact that the project is a cloud implementation does not influence the selection of requirements models as much as other the other characteristics do. For instance, if the cloud implementation is part of a large ecosystem, then an Ecosystem Map will be useful to show how the cloud part of the solution interacts with other parts of the system, a System Flow can help describe the system steps, and System Interface Tables might be necessary to describe the interfaces. The Org Chart might be useful in identifying users, and Roles and Permissions Matrices can define security access in the cloud for the user types. Process Flows can be used to describe how users will interact with the cloud. Also, state models are often useful because cloud implementations typically are based on user states, such as logged on, logged off, online, or offline.

Web App Projects

Web apps expose functionality and display data to users through a web interface. Because the web app is communicating to a back-end server, an Ecosystem Map is helpful for showing the architecture, but System Flows are most important for describing those interactions. Data models are important for showing what data exists in the system and is passed between the server and client, so you should create a BDD and a Data Dictionary. UI Flows and DAR models are often helpful for building the web interface, to ensure that it is usable.

Mobile Systems

Systems with mobile capabilities are intended to be deployed at least partially on mobile devices. Mobile systems should have Use Cases that precisely describe how users will interact with the mobile device, and they might use Process Flows to describe users’ goals with the device. Ecosystem Maps and System Flows might be helpful to show the interfaces and interactions between the mobile system and the servers it communicates with. Because mobile devices have limited screen size and sometimes slow interaction times, UI Flows and DAR models are helpful to ensure that the screens on the mobile device are designed efficiently and can be easily used.

Projects with Complex Decision Logic

Projects with complex decision logic automate a decision process. These projects typically have other characteristics that drive model selection. You should use Decision Tables and Decision Trees to model the complex logic. State Tables and State Diagrams might be needed because many decisions are based on states in the system.

Data Characteristics

The following project characteristics are related to the data needs of the system.

Analytics and Reporting Components

Systems that have analytics and reporting components are typically used in business intelligence to help people make decisions based on large data sets. In fact, these projects can be identified by their business strategy—any project that involves getting information to make a decision has significant data requirements.

Projects that involve significant volumes and use of data need several data models to accurately document the requirements. You can use the BDD to determine which types of data are involved in the project, DFDs to describe the flow of the data, and Data Dictionaries to further describe the data. Report Tables are a necessity if you are creating reporting requirements.

Often Process Flows and the other people models aren’t needed at all for a pure analytics project. However, keep in mind that Report Tables include decisions that need to be made. For a very large business intelligence project, prioritizing reports might require Process Flows for determining which reports support the most important processes and for articulating the decisions that need to be made. Also, decision models might be helpful on analytics projects.

Database Back-End Components

Many projects will have a database back-end component. These systems contain data that is used by and stored in the system. For these projects, you will need to identify all of the business data objects in BDDs and define their flow between processes, systems, and storage components in DFDs. You should also define the actual field-level details in Data Dictionaries. Keep in mind that you do not need to document the database schema or physical architecture of the database servers. Instead, focus on documenting how the business stakeholders think about the data.

Data Warehouse Components

Data-heavy systems contain many business data objects and pass a large volume of data between systems. You will probably use many non-data models, but you should focus on data first, by identifying business data objects to create BDDs, then completing DFDs. You can create Data Dictionaries to provide an increased level of detail for the data requirements.

Project Examples

An existing financial services system is to be replaced with a heavily customized COTS product that will integrate to several other existing systems. The system will be used by hundreds of thousands of customers every day. The team works with several departments that handle the various regions that are transitioning to the new system. A majority of the functionality will be maintained. Figure 25-2 shows the appropriate characteristics and most useful models for this project.

Another project is to build a single-user game for a mobile device. Figure 25-3 shows the appropriate characteristics and most useful models for this project.

A final project is to select and implement COTS software to manage a loan approval process. Figure 25-4 shows the appropriate characteristics and most useful models for this project.