The purpose of the software system is to solve the problem, so the most important step at the beginning of modeling is to analyze and define the problem, and on this basis to conclude the model, so as to obtain a practical and effective model. The process of defining a problem involves understanding real-world problems and user needs and coming up with solutions that meet those needs.

1 Problem Analysis

The goal of problem analysis is to have a better understanding of the problem to be solved prior to development. To achieve this goal, there are usually five steps: reaching consensus on problem definition, understanding the nature of the problem, identifying project stakeholders and users, defining the boundaries of the system, and determining the constraints of system implementation.

1.1 Reach a consensus on the definition of the problem

The easiest way to find out if there is a consensus on the definition of a problem is to write it out and see if it can be agreed upon. To make this process more effective, the questions should be written in a standardized format, which, according to UP, should include the following elements.

  • Problem overview: in a few short sentences, will understand the nature of the problem described;
  • Impact: State which stakeholders will be affected by the issue;
  • Results: Determine what impact the problem will have on project stakeholders and business activities;
  • Advantages: Outline the solution and list the main advantages of the solution.
  • By agreeing on a problem definition, you can effectively align the understanding of the development team with the needs of the users, thus enabling the development of the entire system to move in the right direction.

1.2 Understand the nature of the problem

Every description will be mixed with the narrator’s personal understanding and judgment, so it is a very key task in the problem analysis stage to penetrate the surface into the essence and understand the problems behind the problem. One such technique is “root cause” analysis, which is a systematic approach to suggesting the root cause of a problem or its symptoms. In practical application, causality fishbone diagram and Pareto diagram are often used.

(1) Causal fishbone diagram

Cause-and-effect fishbone diagram is an effective technology to explore the root of the problem. It finds out all the potential causes of the problem or phenomenon through intuitive graphics, so as to track down the root of the problem. It helps people put the causes of problems in the first place and provides a way to use collective intelligence to solve problems. In use, usually follow the following steps.

  1. Write the question succinctly in the box on the right;
  2. Identify the main categories of potential causes of the problem and attach them to the fish’s spine;
  3. Brainstorm reasons and categorize them.

Figure 1 is an example of a fishbone diagram.

(2) Pareto diagram

Pareto diagrams, which take the form of a histogram, are arranged in descending order according to the relative frequency or size of the problems to help designers focus on the important problems. It finds the key 20% reason for 80% of the problems, and it can show the relative importance of each problem at a glance, helping to prevent the phenomenon of solving some problems, but making others worse. In use, usually follow the following steps.

  1. Define the problem: that is, the definition of the problem agreed upon above;
  2. Find out the various possible causes of the problem: Brainstorming is usually used to collect opinions and make a comprehensive analysis by referring to accumulated information and operational data;
  3. Selection of evaluation criteria and investigation period: the most commonly used evaluation criteria include frequency (percentage of total causes) and cost (impact), and the investigation period should be representative of the corresponding problems, not the longer the better;
  4. Collect frequency and cost data for various causes;
  5. Rank the causes in order of frequency or cost;
  6. Placing causes on the horizontal axis and frequency or cost on the vertical axis produces the result shown in Figure 2.

This allows the key causes of the problem to be captured to guide the design of a solution that is more appropriate to the needs and better able to solve the problem.

1.3 Determine project stakeholders and users

Effective problem solving requires an understanding of the needs of users and other relevant project stakeholders (anyone who will be materially affected by the implementation of the new system or application). Different project stakeholders often have different perspectives and needs on the problem, which must be taken into account when solving the problem. In fact, many of the stakeholders are users of the system, and this part is usually easy to identify; But there is also a less recognizable but important part of the project where stakeholders are indirect users of the system, or even just business results that are affected by the system.

When looking for stakeholders, consider: Who are the users of the system? Who are the customers (buyers) of the system? Who else is affected by the output of the system? When the system is complete and operational, who will evaluate it? Are there other customers inside or outside the system whose needs need to be considered? Who will maintain the system in the future?

1.4 Define system boundaries

The boundary of the system is the boundary between the solution system and the real world. In the system boundary, information flows into the system in the form of input and output and flows from the system to users outside the system. All interactions with the system are carried out through the interface between the system and the outside world. In defining the boundaries of a system, the world is divided into two parts: the system and the things that interact with the system. There are two ways to describe the boundaries of a system: a “context scope diagram” in structured analysis and a “use case model” in object-oriented analysis.

(1) Context scope diagram

It is also the top-level diagram in the data flow diagram, which is a model reflecting domain information and can clearly show the job responsibilities of the system and the beginning and end of the responsibilities of adjacent systems, so that we can understand the system from a macro level. Figure 3 is a context scope diagram describing the “stockbroker system.”

(2) Use case model

The use-case model describes “things that interact with the system” by introducing actors. Once the actors are identified, the boundaries of the system are naturally established. When looking for participants, consider the following questions: Who will provide information to the system? Who uses information in the system? Who removes information from the system? Who will operate the system? Where will the system be used? Where does the system get its information? What external systems are interacting with the system?

Then, according to the functional requirements of each participant, the use cases that represent the functions of the system are identified to define the boundaries of the system.

1.5 Determine the constraints of system implementation

Due to the existence of various factors, there will be certain restrictions on the choice of solution, which is called constraints. Each constraint affects the final solution, and even whether a solution can be proposed at all.

When considering constraints, we should first examine different sources of constraints, These include schedule, return on investment, people, equipment budgets, environment, operating systems, databases, host and client systems, technical issues, administrative issues, existing software, overall corporate strategy and procedures, choice of tools and languages, personnel and other resource constraints, etc.

2 Problem Definition

Through the careful and thorough analysis of the problem, it can be defined comprehensively. A complete definition of a problem usually includes objectives, functional requirements and non-functional requirements.

2.1 the target

Goals are the reasons for building the system. They are the highest level of user requirements and business requirements, and functional and performance requirements must contribute in some way to that goal. When describing goals, you should pay attention to the following aspects.

  1. Advantages: The goal should be not just to solve problems, but to provide a business advantage;
  2. Measurement: Not only must the business benefit be stated, but it must also provide metrics for measuring that benefit;
  3. Rationality: The rational solution is to ensure that the amount of work required to complete the solution is less than the business advantage gained;
  4. Feasibility: Find a solution that meets the metrics;
  5. Reachable: Whether the organization has the skills to acquire the system and operate it once the build is complete.

2.2 Functional Requirements

Functional requirements are used to specify what the system must do, and only the existence of these behaviors can have the value of the system’s existence. Functional requirements should be derived from business requirements that are related only to the problem domain, not the solution domain. That is, a functional requirement is when you talk to a user or a business person and they describe what they need to do in order to do some part of their job.

When designing a solution, there are constraints that are part of the “system requirements,” but should be specified in the form of design constraints or non-functional requirements. Pay attention to the level of detail when specifying functional requirements. Because these requirements are business requirements, they should be validated by business people. That is, users should be able to indicate whether the system is functional enough to be useful; Whether it functions correctly considering the results of the work. In addition, when describing functional requirements, attention should be paid to the ambiguities of requirements. The ambiguity is mainly reflected in the following aspects.

(1) Words with the same name: there are many words with the same name but with different meanings in natural language, and their influence should be carefully excluded. (2) Pronouns: In the requirement description, the pronoun often has the phenomenon of unknown referent, so it should be avoided as far as possible and replaced with subject and object.

An effective way to check the ambiguity of functional requirements is to read them out loud, listen to them and discuss them together so that they can be refined over time.

2.3 Non-functional requirements

Nonfunctional requirements are attributes that a system must have, which can be viewed as features or attributes that make a product attractive, easy to use, fast, or reliable. Nonfunctional requirements do not change the function of the product; they characterize the work.

There is a useful mode of thinking when distinguishing functional requirements from non-functional requirements: functional requirements are characterized by verbs, while non-functional requirements are characterized by adverbs. Non-functional requirements mainly include the following types.

(1) Perception demand: namely, the spiritual essence of product appearance, that is, a group of attributes related to the perception of user interface; (2) Ease-of-use demand: that is, the ease-of-use degree of the product and special usability considerations, usually including user acceptance rate, production efficiency improved by the introduction of the product, error rate, availability of special groups and other indicators; (3) Performance requirements: that is, constraints on how fast, how reliable, how much processing capacity and how accurate a function can be implemented. For example: speed, accuracy, security, capacity, value range, throughput, resource efficiency, reliability (mean time to failure), availability (downtime), scalability, etc. (4) Operability requirements: measure the operating environment of the product and the problems that must be considered for the operating environment; (5) Maintainability and portability requirements: expected changes and the time allowed to complete the changes; (6) Security requirements: product security confidentiality, usually reflected in confidentiality, integrity and availability; (7) Cultural and policy needs: special needs brought by product developers and users; (8) Legal requirements: which laws and standards are applicable to the product?