Defining system boundary goldway published on 9:22:00
When defining requirements, you must define the boundaries of the computer system to be developed, that is, to determine which are system requirements and which are system-related operational process requirements, which are outside the scope of the system.
Demand providers often do not know what the system should contain, so they may make inappropriate demands. The system boundary definition should be used to preliminarily remove those obviously out of the system scope, so as not to interfere with the subsequent analysis process.
Check each original requirement and separate them into system requirements, process requirements, and requirements that should be rejected. Consider the following:
- Is a requirement based on incomplete or unreliable information?
- Is the implementation of a requirement out of the database defined by the system required?
- Is a requirement related to the core functions of the system?
- Does a requirement involve the performance of functions or devices outside the system?
For problems 1 and 2, you can determine whether the request is a process requirement. If the request is a process requirement, the system operator is required to provide the information. Otherwise, you need to review the data to be processed by the system.
For problems 3 and 4, you can determine whether it is a requirement beyond the system boundary. If yes, it may be unnecessary or impossible to implement.
Technical and economic arguments must be prepared to explain the reasons for rejection of requirements beyond the boundaries of the system. These arguments should be based on the business objectives defined by the Organization or the results of the system feasibility study.
The definition of system boundaries and the inspection of requirements must be carried out through the review of requirements. Before the review of requirements, you can define appropriate analysis and testing tables, such:
| Check table items |
Description of inspection content |
| Hasty Design |
Does this requirement contain immature design or implementation information? |
| Combination requirements |
Is it a separate requirement or can it be subdivided into several different requirements? |
| Additional requirements |
Is it just the decoration of the system, not the real necessity? |
| Use non-standard hardware |
Must non-standard hardware or software be used for this requirement? |
| Meet business objectives |
Does this requirement meet the defined business objectives? |
| Demand Ambiguity |
Does this requirement have a different understanding of different people? |
| Demand Realization |
Based on the existing implementation technology, can this requirement be fulfilled? |
| Demand Testability |
Can the test engineer export the test results from the requirement statement to determine whether the system meets the requirements? |