Complex systems integration involves the development, interconnection, and integration of many different kinds of hardware and software which work together in a cooperative fashion to solve complex business problems (i.e. form heterogeneous systems). There may be many different representations of data in a heterogeneous system, for example, different representations for integers, byte streams, floating point numbers, and character sets. Most of this type of data can be marshaled from one system to another without losing significance.
Some components in the distributed system may have different capabilities than other components, generally including faster clock cycles, larger memory capacity, bigger disk farms, printers and other peripherals, and different services. Different instruction sets may also exist between systems. An application compiled for one instruction set cannot be easily run on a computer with another instruction set unless an instruction set interpreter is provided.
When it comes to solving business problems, heterogeneous systems have to deal with a large number of business requirements, which are defined as specifications of what a business wants, the purposes for initializing a specific project, what the needed achievements for the project will be, and the quality measures for the project. These requirements are generally expressed in terms of broad outcomes rather than specific functions that a system may perform. Other types of requirements comprise functional requirements and component requirements. Specific design elements are generally outside the scope of a requirement, although design standards may be referenced if needed.
Business requirements may be traced through each stage of progress by a traceability matrix, which is an example of a cross matrix. High level concepts are matched to scope items which will map to individual requirements, and the individual requirements will map to corresponding functions. This matrix should also take into account any changes in scope during the life of the project. At the end of the project, this matrix should show each function built into a system, its source and the reason that any stated requirements may not have been delivered.
Traditional requirements management and system traceability matrices generally involve a linear model for traceability and emphasize discipline and rigor as they descend down the levels of requirements. The linear model works well for some software development projects, but suffers from significant limitations when applied to complex system integration projects. The linear model scales poorly for these systems, especially where there are thousands of requirements. In general, interfaces within the systems are absent or not handled at a level that supports a cogent high-level view (e.g. unable to indicate how the system supports a high level business capability). Also, the linear model is unable to systematically translate high level capabilities to the systems and interfaces that must work in concert to realize them. This results in either a glut of requirements at the front end of a traceability matrix or an unmanageable profusion of technical statements at the lower levels of the traceability matrix.
Thus, there is a need for improved methods and systems that address the above problems, as well as others.
USPTO Backgrounds
USPTO Backgrounds