How to Write a system analysis book

 

Source: http://blog.csdn.net/pplk/archive/2006/03/22/632235.aspx

I would like to share with you the first step we have done in software engineering: system analysis.

System Analysis, I personally think it should come out of the soul of the system documentation. Such a document should provide the following content (depending on the project ):

1. System Requirements

Describe what kind of system is, use existing systems on the market for analogy, and describe what kind of system the customer (or ourselves) needs to be complete. And describe the extensibility of the system (no system is OK now ). Explain what is different from the existing system, and explain the future development of the system and the foreseeable things such as the value portability.

2. System Resource Description

Describe the software and hardware resources required by the system. Describes all the TCO required by the system. All resources include personnel, time, equipment, system, one-time investment, and continuous investment.

3. system feasibility analysis

This paper analyzes the resources in the system implementation to explain the rationality and inevitability of the input, and reasonably quantifies All unforeseen input to explain the feasibility of the system implementation.

As a work in the early stage of development, I think it should also include the overall design and detailed design.

Overall Design

The key question that must be answered at this stage is: "In summary, how should we solve this problem ?"

First, several possible solutions should be considered. For example, the main functions of the target system are automatically completed by a computer or manually. If a computer is used, the batch processing or human-computer interaction is used; traditional file systems or databases are used for information storage ....... Generally, you should consider at least the following possible solutions:

Low-cost solutions.

The system can only do the most necessary work and cannot do more work.

Medium-cost solutions.

Such a system not only can well complete the scheduled tasks, it is easy to use, but may also have some features and features that the user does not specify. Although the user has not put forward these specific requirements, the system analyst determines based on his own knowledge and experience that these additional capabilities will prove very valuable in practice.

A high-cost "perfect" system.

Such a system has all the functions and features that users may want.

System analysts should use system flowcharts or other tools to describe each possible system, estimate the costs and benefits of each solution, and weigh the advantages and disadvantages of each solution, recommend a good system (the best solution) and develop a detailed plan for implementing the recommended system. If the user accepts the system recommended by the analyst, another major task of this phase can be completed.

The above work has determined the strategies for solving the problem and the programs required by the target system. But how can we design these programs? One basic principle of structure design is that the program should be modularized, that is, a large program should be organized by many moderately-sized modules in a reasonable hierarchy. The second major task of the overall design phase is to design the structure of the software, that is, to determine which modules the program consists of and the relationship between modules. A hierarchy chart or structure diagram is usually used to describe the structure of the software.

Detailed Design

In the overall design stage, a solution to the problem is proposed in a more abstract manner. In the detailed design phase, the task is to embody the solution, that is, to answer the following key question: "How should we implement this system ?"

At this stage, the task is not to write a program, but to design a detailed specification of the program. The purpose of this specification is similar to the engineering blueprint that engineers often use in other engineering fields. They should contain the necessary details so that programmers can write actual program code based on them. The detailed design results are usually described using an hipo diagram (A Hierarchy Diagram plus an input/processing/output diagram) or a PDL language (a process design language.

I think the idea of such a document system is a process of gradual accumulation. As some developers have said, we have too many formal things, it is not a system analysis/Design book that programmers really need. There are too many changes and changes to the system design, implementation, and final code and acceptance, we are living in a very nonstandard system, so we cannot have too many choices, so we can only handle things. Therefore, we need to find a document mode that is truly suitable for us. This mode or template can reduce the burden on our code work and bring more momentum.

1. The current application is very different from the previous one.

The current application is a huge integration, including cross-platform, network, database, etc. Moreover, the emergence of new technologies is getting faster and faster, and no one can master or even master all technologies. Simple Example: Who is proficient in windows, UNIX, Linux, SQL Server, Oracle, Sybase, and other databases, C ++, VB, and Delphi? If not, how can we determine whether Windows + SQL SERVER + Delphi is good or Unix + Oracle + C ++ is appropriate?

2. Customers have no requirements

I have worked as a bank, telecom, and other major customers, and have also worked as small customers. Without exception, they say "I want to create an OA system", "I want to create a Enterprise Network", and "I want to do one ...". But they cannot determine what to implement, because few users are actually working on projects due to business needs, and they are not clear about what to implement (because they do not understand notes, does not understand Enterprise Network ).

3. Changes in requirements and Environment

The customer has no substantive requirements before project development, and software developers are unfamiliar with the customer's business, which leads to constant changes in the development process, in severe cases, the analysis and design will be voided.

4. Object-oriented tools and procedural programs

Currently, the development tools are very object-oriented, while the programs we develop are very procedural. That is to say, although you strive to be modular and hierarchical, you can modify the source code as long as the runtime environment changes. This indicates that we need to modify the actual practice.

If a project is 80% clear about what a system looks like, I think it is a failure of the designer. I think that in the design stage, we should not only do a good job in the document and demonstration of traditional practices, but also do some specific design work. For example, the overall operating design of the system and the specific design of each functional module of the system. And these designs should have detailed design manuals. After these instructions are completed, looking for a programmer, he can start code development simply by reading the design specification of a function module without having to rethink how to do it, programmers are really just a designer's implementation tool here.

Of course, today's systems are becoming more and more complex and increasingly closer and closer to the Integration nature. It seems that few people can know what to use and what to do, but the key is here. Is it true that no one can do this? None! However, the current display is that the level of design personnel is low, and some company designers do not have much development experience at all. How can they understand too many systems. At present, the system design seems to be a job that takes more money to work less, but this is not a normal phenomenon. It doesn't take much effort to train a programmer. If a person is not stupid or stupid, give him a chance to master a certain technology or method. However, to master several methods, it is not possible to solve them quickly.

This is also the problem. At present, it seems that all system designers can design what they have. Actually not. Many people have knowledge limitations, which determines that they can only make decisions and designs on things in some directions. The customer does not know what to do, but we should know. In the early stage, if we were able to reach out to users and take the designer as a member of the customer's work, we would be able to truly understand the customer's needs, of course, we can also make a proper design for him.

As for the comparison between good and bad systems, I think nothing is absolute, and some are only trade-offs in some aspects. For example, performance or space trade-offs, price and performance trade-offs, or feature-focused trade-offs. Nothing in a computer exists, not including such trade-offs. Although it seems from the business perspective that users always want to persuade users about things, good things, and bad things, it doesn't matter technically. Some are just the differences and the problems they are targeting.

Therefore, it is not necessary for the system design personnel to queue for various solutions before the user decides. They only need to understand the user's needs, then you can make a specific design in a general direction.

From the perspective of past practices. First, I agree with two statements:

1. Project (or project) has three main aspects: function, time, and cost.

2. System Analysis task: converts users' business logic into program logic, computing time and cost.

Let's make a summary design:

1. Function: A simple information publishing system.

2. Based on the time and cost of the project, the system analyst puts forward the SQL SERVER + CORBA + Delphi solution based on the advantages and disadvantages of various solutions. ... The user is very satisfied. OK,

Start the detailed design:

1. Three-tier structure for ease of installation.

2. The client contains two modules: Information Distribution and query.

3. Use various graphs or languages to describe various functions, processes, modules, and layers. ...

Everything went well and started coding. ... After coding is completed, you can try it out. At this time, the user proposes that the client must be able to track information changes in real time, but you find that Delphi's CORBA does not support callback! It is impossible to switch to other solutions, and remedial measures are ineffective (for example, timer is used, but the customer's network environment does not allow frequent refresh by many users). What should I do?

Now let's analyze the problem:

1. Some people may say that the system analyst does not really understand the customer's needs, but this is impossible (the project time limit) and unrealistic (it is impossible for the analyst to perform operations at every position ).

2. Some people may say that the system analyst's knowledge and experience are insufficient, but the reality is that the analyst thinks it should be, the customer thinks it is unnecessary, and the customer thinks that the necessary analyst cannot understand it. This is because of different jobs. As the saying goes, the job is like a mountain.

3. Some people may say that the level of the system analyst is not enough, but the vast majority of the problem lies in the details rather than the generosity. Is it possible to grasp all the details? Here is a problem that has plagued me for a long time: details (rather than directions) are often the key to success and failure (note that success here includes time and cost ), the details cannot be fully discovered and analyzed.

How can we build a complete system on this incomplete requirement? Or is it impossible? I think the disadvantage in this process is that we have killed things and did not really think about it for users. Many people may consider implementation convenience most when designing, rather than system expansion and updating. You need to know that the user's needs are constantly changing. It is difficult to predict the outcome if we always make assumptions for the user in good faith before the design.

So I think that in the design phase, we should discuss all possible problems on the desktop, including their characteristics, effects, and consequences, rather than making assumptions for users ". In fact, the expansion performance of a system is a very important indicator for its system design advantages and disadvantages. There is no vision for a "dedicated" system simply tailored to something.