4.2 Defining the Business Problem and User Requirements

How to Determine a Business Problem

A business problem is any obstacle to business operations that causes variance in the expected outcome. These variances can have a significant impact on an organization’s bottom line, affecting its ability to maintain healthy operations and sustain itself among its competitors. While variance or some level of uncertainty is expected in business, when variances occur, business leaders need to know how to effectively address them. Consider the scenario that occurred during a busy holiday season in 2013, when the CIO of Target was made aware by the company’s security team of a security breach of its POS terminals in which the credit card information of customers was being compromised.² Let’s suppose you are the CIO of a major corporation, and its network security is threatened by sophisticated malware. How do you determine a business problem, the extent of its impact, and the possible solutions that are timely, feasible, and responsive to the problem? You need to follow these steps to define the problem, determine and then implement solutions, and evaluate how the solution worked.

1. Define the problem: Defining the problem can be as simple as starting with general questions to further explore the situation. Asking questions may elicit or uncover the general problem and may help you to think through the problem from a critical lens. The “five whys” refers to an iterative interrogative technique that can be used to explore the cause-and-effect relationships underlying a particular problem, and it is an example of how to approach the process of defining the problem by asking questions. The technique was invented by the founder of Toyota nearly a hundred years ago, gained popularity in the 1970s, and is still used today to solve problems. The idea behind the technique is that asking questions may help you gain a deeper understanding of a problem. An opening question might be “Why is that a problem?” “Why did it happen that way?” or “Why did it happen now?” Subsequent questions are then posed to help further your understanding of the problem, such as: “What areas of the business is the problem affecting?” and “What business roles or teams are impacted?” In theory, asking continuous “why” questions to dig further into an issue should help to identify the problem by the fifth “why.” To add further value, organizations may use techniques like this to engage the help of employees, stakeholders, and others in defining the problem, which can lead to a more thorough and effective evaluation process, provide individual value to team members, and result in an effective resolution—all means by which the business can build opportunities for its success.
2. Determine possible solutions: Once there is a good understanding of the problem, the process of determining possible solutions can begin. Using data collected when defining the problem plus the insights gained from those participating in the process, brainstorm potential solutions that may solve the problem. It is important to consider the “do nothing” option, along with its ramifications from a near- and long-term planning perspective. The solutions should consider cost, impact, time, resources, and other factors that qualify their viability as options.
3. Assess, select, and implement a solution: Review the options presented and weigh the pros and cons of each. For example, suppose the organization depends on a preferred piece of hardware that is delayed with an international supplier. Should hardware be replaced with a lower-cost, regional option that may not be as reliable, or should the organization wait for the supply to come in? The cost of waiting for the preferred hardware may be significant, but the regional part may pose a quality risk, causing the organization to make amends to save the relationship. The organization should select and implement the option that is the most feasible and viable the—one that delivers the most benefits with minimal disruption.
4. Evaluate the solution: How well did it work? When a solution succeeds, it is common to apply that solution to similar problems. But for those solutions that do not work out well, the process of defining the problem may need to be restarted, and solution options may need to be reevaluated. A different option may be selected to provide the desired result. As part of the closing process of a project, it is important to reflect on opportunities for improvement and catalog best—as well as next—practices. The key is to avoid making the same mistake more than once and building on the solution that was successful through broader and deeper application.

Tools and Techniques Used to Identify User Requirements

Solving business problems requires understanding what is requested by the users or owners of the product/service and needed to support their business functions. The user requirements are aspects of a solution that are specified by stakeholders and needed to support specific needs and expectations of a business process or product. For example, in seeking a Human Resources Information System (HRIS), the users of this system (HR managers, HR support staff, organizational employees) may request features to manage hiring, employee performance evaluations, payroll, and employee benefits. User requirements are often recorded in specification documentation and can be further categorized as either functional or nonfunctional requirements.

A functional requirement is the feature or function of an application that is needed for the affected business area to accomplish its tasks. These may include business rules, transactions, administrative functions, audit, authentication, authorizations to external interfaces, and reporting functions. With respect to the HRIS example, a functional requirement may be a simple search function that involves using an ID number to search for an employee and, if found, returns results relating to that employee.

A nonfunctional requirement is an attribute of the system that enhances its functionality or operation. Nonfunctional requirements are often viewed as those items that describe the general properties of the system or how the system should behave and work. These may include performance, scalability, security, flexibility, operating constraints, usability, interoperability, maintainability, availability, and capacity. In the hiring example, HR managers would require that the HRIS system is secure from vulnerabilities and threats. They would also require that payroll runs smoothly and adjusts accurately for yearly tax updates, rates, and withholdings. All of these are nonfunctional requirements.

Requirements are generally determined by a team of individuals including stakeholder users, analysts, and/or IS team members with general knowledge and expertise about the system being designed or modified. Administering user observations, interviews, cross-functional meetings, questionnaires or surveys, documentation analysis, brainstorming, and interface analyses are methods used to elicit requirements needs from these individuals.

One means of storing this information is a requirements traceability matrix (RTM). Generally a spreadsheet or similar, the RTM is used to record each requirement along with supplemental information, such as its type (functional/nonfunctional), description, objective, business need/justification, priority, department, and the status of its development. Many organizations also use this document as a testing reference to ensure each requirement has been thoroughly reviewed, tested, and confirmed. In addition, the RTM helps with the verification and validation of the requirements/needs and wants analysis.

Another tool used in gathering user requirements is a design diagram, which is a simplistic drawing or elaborate depiction that helps design teams as it is simple to understand, universally accepted, and easy to compare. It plays an important role in design presentations as they allow viewers to visualize systems, structures, and the relationships between them. There are, however disadvantages of design diagrams, including the time involved in creating them. Consultation with other stakeholders or further research may be needed to complete the design diagram, causing it to be a time-consuming process. As more specialized design software programs become available, design diagrams can be costly. Moreover, they can be misleading, inaccurate, biased, or confusing if they have been conceived incorrectly or are purposefully minimizing or highlighting certain aspects.

Some design diagrams can be generally categorized as maps, charts, or graphs, while others are specific in type and can provide a specific view of the data being presented. Some examples include:

• A flowchart is a diagram that displays sequential relationships between data, systems, programs, or processes. They are often used by technical and nontechnical persons to document, plan, and communicate ideas in a simple-to-understand visual format. Flowcharts utilize specific symbols, diagrammatic arrows, and connectors to aid in the visualization.
• User stories are explanations from the user perspective, usually written in an informal format, of specific systems functions. The components of user stories are referred to as the 3 Cs: cards (the user role, general task, and goal to be achieved), conversation (discussion with the development team in which users gain clarity about the user requirements), and confirmation (agreed-on acceptance criteria for satisfying the user requirements).
• An As-Is/To-Be process map details the “current state” and “future state,” respectively, of a specific process or function within an information system. The As-Is process map details how things currently work, while the To-Be process map describes what should be done to reach the desired future state.
• A use case diagram is also a visual representation of system features that displays how specific users interact with the specific functions of a system. These diagrams usually contain the following components: actors (human or any external entity), a box representing the system itself, and directional arrows that show the relationships between the actors and the systems that indicate the flow of data, to and from the system. Figure 4.10 shows a use case diagram depicting the system setup of a boutique seeking to expand by opening a brick-and-mortar store and online store that use the same system. Customers (actors) would face different decisions based on where they were making a purchase. This diagram might be accompanied by the written use case, which would include specifics about the account creation process for an online purchase and the process for in-store transactions.
• A context diagram is a high-level diagram that visualizes a system or parts of a system and the environmental actors with which it interacts using diagrammatic arrows to display the flow of data. These indicate the highest level of interaction between the system and business processes.
• A mind map is a free-form depiction of ideas with branches displaying the flow of information and thoughts, and they are generally used for brainstorming.

Figure 4.10 A use case diagram for a boutique would outline the various aspects of the system based on whether the customer was an online customer or an in-store customer. (source: attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Consequences of Incorrect or Incomplete User Requirements

The requirements-gathering process doesn’t always result in a perfect set of instructions to address the business problem. Often, the RTM can be fraught with missing or incorrect user requirements, and this can significantly impact the delivery of a final product and may cause challenges for the project team working to deliver the product. Not only will there be associated costs (resources, regulatory penalties, delays to market), but the impact may include undocumented processes, conflicting requirements, communication challenges with end users, and a misguided focus on the visual aspects of the design instead of the functioning elements.

In the spirit of continuous improvement, systems analysts can iteratively address poor requirements by doing the following:

1. Do thorough research: Increase knowledge of the business problem by understanding the factors and driving forces contributing to the business need. Research should focus on the context in which the business exists and include both internal factors (like organizational culture and business processes) and external factors (such as market conditions, regulatory requirements, and competitors). Ask: Are other organizations experiencing the same business challenges or opportunities? What are other organizations doing to address this? The research may validate or refute the gathered requirements, or identify new requirements to consider.
2. Revisit the business problem or opportunity: Once the research is completed, use the knowledge gathered to revisit the business problem or opportunity. The situation may be viewed differently and can provide additional insight. Is the business problem or opportunity what was envisioned? Can the business problem or opportunity be spoken about more confidently to support the team? Can insights be offered that may support a more comprehensive requirements document?
3. Conduct requirements review sessions: Initiate sessions to review the requirements with all stakeholders. Feedback from these sessions may elicit additional valuable input. Be sure to include visuals in the review sessions (data maps, flowcharts, diagrams, reports) as they can often convey information with greater clarity.
4. Seek approval: Final review and approval from stakeholders and business owners may prove useful in addressing incomplete or missing requirements as well as validating the requirements gathered.

Consider how the requirements gathering process might be applied to establishing intramural competitions at a university, which are often student-led initiatives. A student has been assigned responsibility for their college’s intramural sports leagues throughout the year. This involves setting up team registration, recording payments, keeping track of scores, setting up tournaments, and reserving space on campus for games. The leagues have been getting more popular and the old way of managing the process is no longer as effective. A faster, electronic process is needed. Also, as students graduate, there needs to be a plan in place to train and transition to a new manager. Having an app or similar type of system to manage the aspects of the league would be helpful. The students would need to get help from both the IT and athletics departments. It would also be important to get feedback from team captains or coaches as to whether they would use the app to register teams and track their progress through the season. Some tools that might be useful include a design diagram and a flowchart. The flowchart can be used to show how a team will work its way through the system as the league progresses to the eventual championship tournament game. Finally, a key consideration is cost. There is a very limited budget to develop the application, so it would be ideal to be able to access existing technologies in use at the college. These are just some of the considerations when designing the intramural app and how key stakeholder input can be incorporated into the final product.

Defining a Business Problem and Determining User Requirements: Case Study

Dr. Singh has had a thriving medical practice, Hometown Physicians Group, for several years and is looking to expand her practice by opening another location in a neighboring town within the next six months. Dr. Singh is concerned that her current practice is fraught with challenges that she does not want to carry over to the new practice location. These challenges include manual billing and accounting practices; the use of multiple operating systems, hardware, and software systems; lack of security as staff use personal devices to record patient visit information; and older patient records in paper files. Many of these challenges can be resolved with a new electronic health record (EHR) system. Such a system could also help ensure the office is in compliance with medical privacy regulations and using it may improve the practice’s compliance with industry regulations. Lastly, Dr. Singh would like her patients to be seen in either office.

Additional information about Hometown Physicians Group:

• There are twenty-five additional employees, including clinicians (doctors, nurses, and medical assistants) and support staff (billing and accounting, practice management, and reception).
• The office must upgrade to a new EHR as the relationship with the old one will be ending in six months.
• The transporting of manual files between offices needs to be eliminated, as does the practice of using personal devices for patient recordkeeping.

Assume the role of the designer and user experience researcher in this scenario. Recall the designer’s role is to provide guidance in the early stages about the system that will meet the business needs. The user experience researcher is focused on making sure the system design meets the needs of the stakeholders—in this case study, Dr. Singh and her associates. Think about the process to accurately define the problem and which tools could be used to visualize the problem and the system for Hometown Physicians Group. You might consider whether there are other key stakeholders who might be important to include in the conversation. Consider the following as you work through the design process:

• How would you approach the requirements gathering process?
• Who are the stakeholders involved and how would you engage them in the analysis?
• What tools would you use to understand the business processes and the opportunity presented?
• What questions would you like to ask Dr. Singh that would assist you in your work?

Let’s begin by defining the business problem. Keep in mind that the circumstances do not need to always be problematic. Instead, as is the case here, Dr. Singh has a new opportunity to expand the practice. This opportunity might involve some challenges, but sometimes the use of the words “business problem” implies a negative situation, whereas this expansion is positive. Dr. Singh has provided initial information to give context to the existing issues in the office’s current operations and how they may present additional challenges in the new business model. Begin with the five-whys method or other appropriate questions. For example, you might ask why the current billing system is a challenge for the office staff. You can also probe into how the different operating systems currently present issues.

In addition, it would be important to engage Dr. Singh in a conversation about the other stakeholders who need to be included in the initial design stages, and in the testing and evaluation phases of the project. This could be done through a requirements review session. During these initial stages, tools such as the RTM, flowcharts, and use case diagrams could help you visualize the overall business problem and the system requirements. Moreover, it could be helpful to use a design diagram to show Dr. Singh how the current system functions and the relationships that currently exist.

Once you feel confident in the business problem definition, move on to the next stage of determining possible solutions. During this phase, you can continue engaging with Dr. Singh and the office associates and utilizing some of the tools mentioned. You will want to address the user requirements (functional and nonfunctional) in the proposed solutions. Try to offer a couple of solutions, and for each be sure to include information such as cost factors, time, and training required to implement the solution. This is a good time to revisit the RTM to ensure that the proposed solutions meet the needs and wants of the practice. You could also consider creating a new design diagram to show how the proposed solutions differ from the existing system.

Next, the project would move on to the selection and implementation phase. During this stage of the process, the proposed solutions are evaluated, and a final solution is selected. It is helpful to generate a pros and cons list for each and to engage the key stakeholders in the conversation. Ultimately, you should implement the option that is the most feasible and viable for the office, one that gains the most benefits with minimal disruption.

The final phase is to evaluate the solution. This phase is likely to not have a specific endpoint. You might deploy tools for Dr. Singh to evaluate the functioning of the system on her own. But initially, the design team will want to evaluate how the system functions to meet the user requirements and the needs of the office during the transition. As the users interact with the system, it is likely that the need for improvements or changes will arise. You might consider establishing a process by which these system changes and improvements can be communicated to the design team. The feedback could be provided as the issues arise or be compiled and shared with the team on a regularly scheduled basis, such as quarterly. The goal is that once the system is operational, feedback from the users is solicited to evaluate the efficacy of the system in meeting the needs of the medical office. This evaluation stage is crucial and should reflect back on the business need that was identified in the early stages of the project.

This case study provides a general framework and some factors you might consider as you work to develop your solution to this problem. You might have other ideas on how to approach the problem, uncover user requirements, and produce creative solutions.