{"id":542,"date":"2019-08-13T23:13:11","date_gmt":"2019-08-13T21:13:11","guid":{"rendered":"http:\/\/p4dev.hardscrum.com\/?p=542"},"modified":"2026-03-11T11:23:45","modified_gmt":"2026-03-11T10:23:45","slug":"architecture","status":"publish","type":"post","link":"https:\/\/p4dev.hardscrum.com\/en\/architecture\/","title":{"rendered":"System Concepts & Capabilities, Solution Options"},"content":{"rendered":"

System concepts<\/strong> describe possible solutions for <\/span><\/span>system and product variants (applications = feature sets)<\/span><\/span><\/a> and their <\/span><\/span>requirements<\/span><\/span><\/a> . <\/span>System concepts implement the System Requirements within the <\/span>restrictions (contraints) and balance the quality<\/span><\/a> requirements <\/span><\/span>(Quality Attributes)<\/span><\/span><\/a>out. <\/span>The P4 framework explicitly provides several System Concepts as solution options for the implementation of System Requirements in the system backlog. <\/span>This means that several solutions to a problem may be identified and developed further (divergence in the solution space). <\/span>The goal of product development is to only develop so many different System Concepts (in parallel or in succession) until some concepts are disqualified and ideally a clear favorite emerges. <\/span>Depending on the degree of innovation in the development, this can be a very large number of concepts at first, or new concepts may even arise during product development.<\/span><\/span><\/p>\n

System Architecture<\/h2>\n

The static part of System Architectures describes the allocation of Functions<\/strong> and Capabilities<\/strong> to subsystems and Modules of the system, and their interfaces (Module Definitions<\/strong> and Interface Definitions<\/strong>). This is done e.g. by using the block diagrams from the SysML. The dynamic part describes the behavior of the subsystems and modules, e.g. using sequence diagrams, activity diagrams, diagrams of state machines of the SysML.<\/p>\n

The descriptive documents of the system (the specifications, user handbooks, …) are also often treated as “components” or deliverable objects. This ensures that the documentation grows synchronously with the functional scope and maturity of the system.<\/p>\n

Evaluation and selection of System Concepts<\/h2>\n

For the selection of System Concepts and alternative solutions, the P4 framework can use methods of classical systems engineering, such as …<\/p>\n