Architecture of object-oriented software requirements

Architecture of object-oriented software requirements

Here, we need a specific way of thinking and a unique methodology. It is necessary to correctly understand and properly use the classical demand analysis theory.
1. establish a system's overall framework as soon as possible in terms of ideological methods, and generally locate the positions of various specific targets in the system framework and their roles in the overall system, at the same time, it is necessary to analyze the interaction and internal relationship between each part. At this stage, we often pay attention to the communication process and ignore the actual operation process. In fact, the purpose of understanding the demand through the visit process at the site is often to learn more quickly about the proposition, but also to grasp the design objectives more accurately.
2. on the basis of the overall framework, we will analyze the data sets and presentation methods of each application node to be generated or applied, and establish the internal connection between each business node in the data system as soon as possible, instead of simply understanding the application mode at the business layer.
3. It is only a one-way of thinking to establish a data system from the perspective of application. If necessary, it should be returned from the perspective of sound data system to see whether there are defects in application design. The conventional method is usually only for the basic requirements of the design. More changes will come from various variations and special cases that may occur in the business process.
4. The regularity of data applications has nothing to do with specific businesses. It is also an important perspective for reviewing the design scheme. If we can start from the universal data application model, we can easily find those easily overlooked in the original requirements. For example, the descriptions of application functions often ignore the existence of various auxiliary problems such as query, statistics, maintenance, and permission control, these functions are often based on an inevitable requirement of a specific application.
1.3.3.1 proactive
In the process of project delivery, secondary requirements are a common phenomenon, but this is an important standard for testing the quality of demand analysis. In the delivery process, the higher the secondary requirement and the larger the change, the worse the requirement analysis capability and effect. A good requirement analysis is on the contrary: users do not care about some functions at the beginning of the application. When the application reaches a certain level, many new ideas already exist in the system.
Forward-looking is an important means to shield secondary demands, but it is also one of the reasons for cost consumption. The key is that the orientation and scale of forward-looking needs should be well grasped. The general principle is that there should be fewer and less appropriate, strive for accuracy and reasonableness. The main factors that can make reasonable judgments include:
1. Inherent inevitability of things: for example, the topic perspectives commonly used in data statistics should be taken into consideration even if users do not mention them.
2. the general idea of managers for development: the methods and strategies that managers may change after the system is enabled. If they are familiar with the industry and have some knowledge of decision makers, there will be some potential demands in this regard.
3. The impact of changes in business habits: some business models will change after the adoption of information technology. In this case, we need to discuss potential possibilities with users.
A requirement similar to this will be very vague in the raw materials, and it is a vague feeling at most. But for the demand personnel, they should not only understand what to do now, you also need to know what will be done later. Accurately capturing these potential demand theme should be a kind of Professional Cultivation and should be taken especially seriously. Don't worry that this will increase development costs. As long as you have a moderate understanding, the effective investment in the early stage will be much more cost-effective than the continuous improvement afterwards.
From another perspective, we can grasp reasonable boundaries. A large amount of physical work will be generated for in-depth analysis of any simple requirement. Here we do not think that the deeper the demand research, the better. The key is to be moderate. Do not go from one misunderstanding to another. Both foresight and restraint are required. Based on factors such as project rules, economic costs, time costs, and current situation of human resources, a relatively reasonable and perfect task boundary is finally determined.
If you properly grasp the foresight, it will improve the project delivery capability and shorten the delivery cycle.
1.3.3.2 correlation
During the construction of the information system, the management process that can be described will inevitably exist in the form of data. The process of system construction is to study how management goals achieve business or management goals through data collection, evolution, and presentation. Data is the carrier for achieving management goals, while code implementation is to solve the channel and bridge between data management and business goals.
The management goal is the appearance of system design and the external manifestation of the data system, while the data system is the most essential physical existence to solve the design goal. The ultimate goal of the research design goal is to form data and make the data play its due role, which is the essence of the system structure.
The data system should be a complete system with relevance, internal correlation, and mutual constraints. Its structure is completely dependent on the structure of the design personnel, the basis of the construction is to fulfill the design objectives of the system. Its existence form determines the system's capacity to carry business requirements.
This is a level that users cannot address and is derived from a level that is higher than requirements. If you rely too much on the original material or use the original material as the design goal, the bearing capacity of the entire system will carry inherent or serious design defects.
1.3.3.3 integrity
The application system is an organic whole. Although the demand research process only faces basic materials that are not systematic, after the demand analysis, what we will get is a comprehensive description of the complete system structure. Raw materials must be taken, but not limited to raw materials. Be good at building independent business nodes into an organic business management system.
In a requirement report, if a complete system cannot be formed for the business model and Function Distribution of the application system, it should be the greatest failure of the author.
1.3.3.4 induction and abstraction
Although the induction and abstraction of raw materials is a necessary process, it is difficult to find a law that can be solidified. Therefore, induction and abstraction are a methodology that can only be discussed.
1.3.3.4.1 example of inventory management
For example, for a warehouse, there are only two basic statuses: warehouse picking and warehouse receiving. Although there are various expressions or operation logics in the business logic, however, this basic inventory change model will not increase or decrease.
Then we analyze the business model: purchase and sales are two basic business forms of inventory changes, and the return and sale of incoming goods belong to the same business model; the return and purchase of sales belong to the same business model; stock transfer and warehouse receiving are similar to stock transfer and warehouse receiving.
Based on this abstract result, we only need to design a set of warehouse management functions to carry all the warehouse management functions. Here is not a preaching, in many systems, we use this abstract mode to fulfill the management requirements of the entire project.
1.3.3.4.2 example of the approval process
Let's take a design example of the approval process. In a real business process, the process is always considered as a difficult design difficulty. After abstraction, we can see that the process is just to fill in some data for some records, and create the next owner to operate the data until the process ends.
Based on this idea, we can use the process and node parameter table to describe the process of data changes, and then use a standard process control interface to implement all processes and trial operations on all nodes. In the subsequent sections, we can see the conception process and implementation method of this classic solution.