Shulou(Shulou.com)06/03 Report--

Summary:

Everyone seems to understand that the design should be done according to the needs, but this is often not the case in practice. So we do not say the big truth, but directly through a "very simple" case to experience how good design should start with the analysis of requirements, and how architectural design takes into account all kinds of requirements, project duration and budget restrictions. and the level of the project team.

Outline:

1. What is a good design?

two。 Excellent design can save project workload.

3. Good design starts with the analysis of requirements

4. The software system is not a wooden bucket.

5. The "Great Truth" of Software Design

6. Planning system Framework-- Architecture Design

7. Building the essence of the system-- Database Design

8. Details determine success or failure-detailed design

9. Users feel good is really good-- user experience design

10. Continuously improve the design level

This article is one of a series of articles, if you have not read the previous article, it is recommended to read the previous article before reading this article, so that the effect is better.

3. Good design starts with the analysis of requirements

Everyone seems to understand that the design should be done according to the needs, but this is often not the case in practice. So we do not say the big truth, directly through a "very simple" case to experience how good design should start from the analysis of requirements.

3.1 case Challenge: software Design of attendance system

A company wants to do an internal attendance system, hoping to achieve the following goals:

1) standardize employees' behavior of commuting to and from work, asking for leave, going out to work, etc.

2) it is convenient to calculate the salary of employees.

3) it is convenient to manage all kinds of paid holidays.

How do you consider the design of this system?

You may say: shit, only three sentences of demand, how to do the design?

That's so good! When we do software design, the first step is not to design directly, but to analyze the requirements!

3.2 how to analyze the requirements?

When you accept the design task of a project, you may encounter an awkward situation, that is, there is a problem with the requirements!

The specific circumstances may be:

A) the requirement is simple, a few words or a page.

B) the requirements are very detailed, which may be dozens or even hundreds of pages, which are provided in the tender or directly provided by the customer. Don't think it's good to have so many requirements, which are usually a little contradictory, logically confused, or even confusing!

C) you have a special department or a full-time job to complete the requirements work and provide a requirements document. You should not think that this is a good thing, because it is likely that the provider of the requirements document thinks that the requirement document he has written is very good and high-level, but the development department responsible for the implementation thinks that the quality of the document is too poor. For example, it does not consider the possibility and difficulty of implementation, does not take into account the real needs of customers, and so on. Sometimes even the development department ignores the requirements department and directly asks the customer to re-investigate and rewrite the requirements document.

The above three situations are summed up in a word: there is a problem with the quality of the demand!

We need to reanalyze the requirements, first from a business perspective, and then from a software design perspective. Usually we need to think about the following questions in order:

1) who will use this system?

2) what functions of this system will different people use?

3) what other uncertain or unspecific demand points are there?

4) what are the requirements and requirements for the technology?

5) how should the general structure of the system be considered?

Let's look at a few pictures and think about the above questions one by one in order. This section answers questions 1 and 2, and the following sections answer other questions.

1) who will use this system?

Many technicians often analyze requirements from a technical point of view, and when you ask him about the users of the system, you may get two results:

A) there are no users, everyone is users, because the system only needs to configure permissions, anyone can use them.

B) there are two types of users in the system, namely, users and administrators.

Let's take a look at the possible users of the attendance system from a business point of view, please take a look at the following figure:

Figure 2.1 possible user analysis of the system

This figure lists the following possible users:

Employee: employee

Finance: finance

Receptionist: front desk

Manager: manager

Senior manager: senior manager

Administrator: administrator

The above-mentioned users also have such relationships: finanace (Finance), receptionist (Front desk), manager (Manager) inherits employee (employee); senior manager (Senior Manager) inherits manager (Manager).

What does it mean by the inheritance relationship between users?

We all know that class B (subclass) in the code inherits class A (parent class), and the subclass has the characteristics of the parent class. The inheritance relationship between users has the same meaning, so you can understand it by looking at the following figure.

The following figure will answer this question:

2) what functions of this system will different people use?

Figure 2.2 requirements analysis of the system

Figure 2.1 and figure 2.2 are use case diagrams for UML, which together represent the following issues in a more complete and systematic manner:

A) what roles will use this system?

B) what can these roles do through this system?

C) there may be inheritance relationships between roles, please pay attention to the things that the parent class can do, and the subclasses can also do, for example: employee can clock in, manager can also clock in, although manager in figure 2.2 is not directly connected to the "clock in", but figure 2.1 has explained that manager inherits employee.

UML is a powerful tool for requirements analysis, and I like to use UML in my work. But you may not have UML diagrams in your work or in your requirements documents, and whether you use UML diagrams or not, you need to think about these issues from a business perspective when analyzing requirements:

A) who (character) will use this system?

B) what functions of the system do these people (roles) need to use respectively?

Requirements analysis is actually a responsible and difficult topic, answering the above two questions is only the first step of requirements analysis, we also need in-depth analysis of the business, including business processes, business data structures and so on. If the previous requirements work is not in place, we need to immediately carry out software design work, in fact, there will be a lot of mines, endless consequences. For more sharing on requirements analysis, please pay attention to my other articles, or buy a copy of my book Fireball-UML Wars needs Analysis (advertisement, ).

3.3 identify design concerns

In this section, we answer these two questions:

3) what other uncertain or unspecific demand points are there?

4) what are the requirements and requirements for the technology?

Software designers need to have a keen sense of requirements and design. Look at figures 2.1 and 2.2 and sniff out some problems. Can you sniff out some problems?

Please take a look at the following picture:

Figure 2.3 Analysis of the design points of the system

Figure 2.3 re-examines the requirements from a design perspective. Here are some suggestions:

A) you need to think more deeply about your needs, taking into account different business scenarios and special situations, such as: how to approve leave when the leader is away from the company?

B) you need to think about the details of the requirements, such as: the specific form of the report?

C) you need to think about various technical solutions, such as the synchronization of punch-in data, whether the financial software should be docked, and so on.

D) you need to strike a balance and meet the demand with the right solution and as little work as possible.

3.4 preliminary architectural design for requirements

This section will answer this question:

5) how should the general structure of the system be considered?

Next you have to do the preliminary architectural design, architectural design is a very difficult thing, you need to fully consider the needs, consider the time limit budget constraints, consider the level of the project team, and make a balance. Please take a look at the following picture:

Figure 2.4 system architecture considerations

Figure 2.4 is the deployment diagram of UML, which is relatively rough, and in order to make it easier for you to read, I only use the most basic and minimal syntax of the deployment diagram.

Each three-dimensional rectangle in figure 2.4 represents a physical or logical device, which is connected by lines if there is a physical connection between the devices. The text enclosed by "{}" in each device is a further description of the device.

Diagrams may be the best way to express the design. It is recommended that we use UML to express the system architecture. It is more appropriate to use UML deployment diagrams, component diagrams and package diagrams. Most of the systems we design are distributed systems, not stand-alone systems, so it may be appropriate to use deployment diagrams to express the architecture design of distributed systems.

Figure 2.4 provides a preliminary response to the questions raised in figure 2.3. Figure 2.4 is a preliminary architectural design, which we need to refine in the future.

3.5 Summary: how to demand-driven design?

The examples in this article tell us:

1) good design starts with the analysis of requirements.

2) there may be problems with the quality of the requirements, so we need to re-examine them from a business perspective.

3) if we look at the requirements from the perspective of design, we will ask a lot of questions about the refinement of requirements and design solutions.

4) Architectural design is a comprehensive balance after considering all kinds of requirements, project duration and budget restrictions, as well as the level of project team personnel.

This article is the second in a series of articles, it is not easy to be a software designer, please pay attention to the follow-up articles!

Author: Zhang Chuanbo

Lecturer in Innovation Workshop Entrepreneurship Class (Agile course)

Senior consultant of software development management

Chief expert of CMMI

Author of Fireball-UML War demand Analysis

Founder of www.umlonline.org

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.