Requirement Analysis through Project Discussion

Background

I have been involved in the Personnel Archive Management System for nearly a year. This project has found many problems, in terms of software design, teamwork, and communication with users to obtain requirements, many problems have been exposed and many things have been learned, today, we will summarize the problems and gains in demand analysis.

Supply and demand exchange difficulties

In the software life cycle, the other four stages are oriented to software technical problems, and only the demand analysis stage is oriented to users. Requirement Analysis analyzes the user's business activities and clarifies what the software system should "do" in the user's business environment ". However, at the beginning, neither of us nor the users could accurately propose what the system would like to do? ". We are not an expert in the field of user issues. We are not familiar with user business activities and business environments, and cannot be clear in the short term. Users are not familiar with computer application problems. Therefore, the two sides do not understand each other's work and lack a common language, so there is a gap in communication.

How to obtain requirements
Requirement analysis is an important part of software engineering and directly determines the success or failure of the project. Requirement analysis is an important task and the most difficult task. There are many requirements analysis methods, such as process-oriented (top-down decomposition), Information Engineering (data-driven) (structured analysis method of data stream analysis), and object-oriented (Object-driven ). These methods are very practical and often used in the demand analysis process, but for developers who do not know the user business at all, the best analysis method is not used, I don't know how to break down the business layer by layer and cannot grasp the data flow correctly. I don't need to talk about object-oriented.
In the face of such a situation, we can only accept part of the user's needs each time, and then make a basic prototype. This prototype is a little more complex than the Prototype Method in the requirement analysis method. The prototype method of requirement analysis only requires us to quickly build a prototype system with some software tools. This system is just an interface, and then listen to the user's opinions to improve the prototype. In the future, the target system will be developed based on the prototype system. In reality, if we only make one interface, an empty shell without data, for users who do not know how to develop software or what is a prototype, it is still difficult for them to make suggestions and demand from such a prototype. Therefore, we have implemented all the prototype functions based on the prototype method, and used this as a prototype to further obtain the requirements.
When talking about prototype methods, we must talk about three types of prototype Methods: exploratory, experimental, and evolutionary.
Exploratory: the objective is to clarify the requirements for the target system, determine desired features, and explore the feasibility of multiple solutions.
Lab type: Before large-scale development and implementation, check whether the scheme is appropriate and whether the specifications are reliable.
Evolutionary type: the purpose is not to improve the specifications, but to make the system easy to change. During the prototype improvement process, the prototype is gradually evolved into the final system.

We mainly focus on evolutionary models, supplemented by exploratory models, and ultimately determine the feasibility of exploring user target needs. In this way, iteration overlays each feasibility on the basis of the previous feasibility, takes the Evolutionary Route, and gradually evolves the prototype into the final system.

Why is the customer's demand always changing?

Demand changes are the biggest headache. First, because we do not know the business, the user first took us with us, so that even if there is a problem with the user's requirements, we cannot identify the problem or give our suggestions to the user, avoid these risks and avoid future demand changes. From the perspective of users, it is difficult for them to accurately and completely put forward their functional and performance requirements. At the beginning, only a rough and fuzzy function can be proposed. It can be gradually clarified only after a long time of repetition. Sometimes the design and programming stages can be clarified. What's more, new requirements are still raised at the end of development. What's more, sometimes some specific implementations are implemented according to requirements, but users still need more, because the initial requirements are approximate, abstract, and fuzzy, once these requirements are transformed into implementation, it is inevitable that users will make some changes after a period of repetition. In the face of demand changes, we need to be prepared to respond to demand changes, minimize risks, and record demand changes.

Process the obtained requirements

When we get the user's requirements, sometimes such requirements only meet the local requirements of the software, to achieve these needs and integrate them with other modules, we also need to take macro control and make appropriate changes to these needs to meet the needs of users and the overall needs of the system, in this way, we can better serve the system.

Capture certain or possibly changing needs in the future

For future changes, I think it is far from enough to strictly control the application process for changes in demand and keep change records, because changes in demand are inevitable. We also need to reduce these risks in the software development phase. In the software development stage, we can adopt an object-oriented design idea. At the beginning of the design, we will apply a lot of design patterns, fully consider the needs to be changed, and reserve interfaces. On the other hand, software functions are decoupled as much as possible to achieve flexible configuration. The two methods have something in common. First, if we do not apply the design pattern, we only need a few methods of the class to meet the requirements, and we need to abstract the interface, establish connections between implementation classes. In this way, the meaning of simple problems is complicated. To make software functions flexible, we not only need to implement this function, but also need to make it configurable and manageable later, in this case, we need to add additional functions to configure and manage the functions to be changed, so that the changes can be controlled within a controllable range.

Summary in the past, system requirements were clearly defined, and prototype systems were used as a reference, which rarely highlighted the importance of demand analysis. Raise your own requirements and develop your own system. This significantly reduces many requirements, and the developed system can only be used by yourself. There are so many software engineering and many methods of demand analysis have been learned, but there are still few practical opportunities associated with practical applications. Therefore, our knowledge remains at the theoretical level, when you encounter a problem, you cannot do it. This is the first time that we have separated the demand provision from the development role, which determines that system development is no longer entirely based on our developers' own will, it is more about thinking about and solving problems from the user's perspective.