Choosing the Right Requirement‑Analysis Strategy for Complex IT Systems

In the internet era, both individuals and organizations rely on information systems to greatly improve work efficiency, and the more complex the system design, the more business scenarios it supports. For large‑scale IT system design, product managers must consider how to create stable and powerful systems.

When dealing with complex, multi‑business scenarios, large systems are often broken down into smaller parts. Different segmentation dimensions lead to different design outcomes; requirements can be divided by business functions or by technical implementation. Which should be chosen?

Some prefer a technical‑centric division for feasibility reasons, which has clear advantages but also obvious disadvantages. This approach may prevent the system from perfectly supporting business needs, relegating user experience to a secondary priority and creating gaps between the system and actual operations.

User experience, though long present, has only recently been emphasized as a key factor because it directly determines user engagement, which in turn drives system value. Therefore, a business‑oriented requirement analysis is advocated.

Common business‑oriented strategies include division by business function, by product service, or a dual dimension of function and service.

Dividing by business function aligns each function with a subsystem (e.g., customer service, after‑sales, finance). Requirement research then focuses on each department’s complex processes, ensuring the system can handle special cases. For example, designing a customer service system involves categorizing typical issues, understanding how staff handle them, and estimating time saved by system support.

Business function division is department‑centric, resembling a product line. In contrast, product‑service division centers on basic user experience. Instead of describing what the system does, it identifies what the user wants to achieve, making the interface more intuitive—e.g., labeling a money transfer as “Transfer” rather than “Account Query,” which improves user retention and efficiency.

Analyzing from a service perspective also puts the user first, imagining a user with no software knowledge, leading to designs that are simple and easy to understand.

Compared with the product‑service angle, the business‑function approach better handles complex operations in large systems. Often, both are combined: start with a broad functional division for complex units, then highlight product services within specific services to enhance user experience.

There is no single best method; each has pros and cons. By combining strategies based on actual situations and continuously refining the approach, teams can create robust, user‑friendly systems.