2B system decomposition


The book “effective requirements analysis” focuses on the requirements analysis of organizational application software systems, introducing 18 key tasks combined according to requirements, step-by-step guidance for each task, and the fragment template of “software requirements specification” output by each task. 

The system to be developed is sometimes quite complex and involves many different businesses. In order to control the complexity of analysis, we usually need to decompose it into smaller parts first. It can be divided according to the implementation structure,However, in the demand stage, it is more recommended to divide according to business

1. Business subsystem Division

Business subsystem division includes the following three steps:,

(1) Division of business subsystems: select appropriate division strategies for decomposition according to the characteristics of the system. There is no need to divide the system with simple system business and single user group. For the system based on legacy system development, it is more suitable to analyze the new, modified and affected subsystems. For relatively complex newly developed systems, the most commonly used strategies include,

·Breakdown by business function:Generally speaking, for such a system supporting and managing business, the most typical business subsystem division strategy is divided according to “department function”. The most typical department functions are production, marketing, supply and management. Before division, you can draw the organization chart related to the system, and then divide each business subsystem according to the similarity between organizations and departments.

·Breakdown by product / service:Usually, when developing “external service system”, we can sort out the “business structure tree” first, and then take different products / services as the division clue. Of course, in some “internal management systems”, it may also be divided from this perspective.

·Two dimensional division of functions / services:For some more complex systems, it may be necessary to use the two dimensions of “function” and “product / service”. First use one dimension for primary division, and then use the other dimension for secondary division.

·Breakdown by key characteristics:If the system to be developed is biased towards the theme of “computer domain”, it needs to be decomposed by another strategy, such as security system, identify the key characteristics from the perspective of the value of the system to users, and then do the subsequent demand analysis one by one.

(2) Identify the interface and determine the relationship: as the saying goes, “where there is decomposition, there is interface”. After decomposition, sort out the “business relationship” and “service relationship” between two business subsystems, and clarify the service interface between each subsystem.

(3) Presentation of business subsystem Division: select appropriate charts to present the division results according to the actual situation, so that readers can establish a clear and intuitive understanding. Commonly used models and charts mainly include hierarchy diagram, component diagram and data flow diagram.

In the case of only one-level decomposition, it is recommended to directly present it in a list. Generally, the hierarchy diagram is only used when there are two-level and multi-level decomposition. If there are horizontal behaviors, services and invocation relationships among various business subsystems that need to be presented, the most appropriate model is the component diagram.

Business subsystem description and description template,

2B system decomposition

The division of business subsystems is not an end, but a means to control complexity.

2. Business interface analysis

After identifying the service relationships among various business subsystems, it is necessary to analyze these service relationships (i.e. business interfaces) one by one. In three steps,

1. Clarify the purpose and business value of the interface, that is, why. This is the most important of the three steps.

Which subsystem is suitable to implement this interface? The principle of “unity of knowledge and practice” is adopted to judge, that is, the subsystem of the information required by the “knowledge” channel interface realizes the interface (i.e. “line”).

Which subsystems will be used and what value will be realized? That is, what is the business purpose achieved. This can help developers understand more effectively and is also conducive to testing.

What is the frequency of use? It is best to give typical frequency values, which can be accurate values or a range, and it is best to have some relevant scene information.

2. Two tools will be used to refine the interaction process of the interface: one is the sequence diagram, which presents the interaction process of the interface; The second is the data dictionary, which defines the composition of data packets in each interaction process in detail.

3. Determine the interface design constraints to see whether the customer’s technical management department requires the use of specific data, communication protocols, or restrictions caused by legacy systems; Secondly, the performance requirements of data transmission, data query, encryption and decryption are analyzed; We should also consider whether the deployment environment (such as server and network) and user characteristics (frequency and operating environment) of the system will bring some design constraints.

Business interface analysis template,

2B system decomposition

Business interface refers to the service relationship between different business subsystems. Therefore, as long as there are multiple business subsystems (including modified and affected subsystems) in the system, this task needs to be performed.