# 3.3.6 System, ISO 42024 ## Published contents Contents1 Scope2 Normative references3 Terms and definitions4 Architecture concepts4.1 Overview4.2 Architecture and architecting4.3 Architecture design and solution design4.4 Architecture definition and communication4.5 Stakeholder concerns and architectural aspects4.6 Architecture viewpoints and architecture views4.7 Architecture frameworks and architecture description languages4.8 Architecture descriptions and architecture models4.9 Reference architectures and reference models4.10 Life cycle and life history4.11 Architecting precepts5 Architecting principles5.1 Introduction to the principles5.2 Principles about the purpose of an architecture5.3 Principles about the focus of an architecture5.4 Principles about architecting outcomesTerms 3.2 Architecting concepts 3.2.1 Architecture3.2.2 Architecture feature3.2.3 Architecting3.2.4 Architecting principle3.2.5 Architecture principle3.2.6 Architecture framework3.2.7 Reference architecture3.3 Entity related concepts 3.3.1 Entity of interest3.3.2 Solution entity3.3.3 Environment3.3.4 Context3.3.5 Enterprise3.3.6 System3.3.7 Aspect3.3.8 Dimension3.4 Architecture design concepts 3.4.1 Design (noun)3.4.2 Architecture design3.4.3 Architecture information package3.4.4 Engineering effort3.4.5 Solution design3.4.6 Solution information package3.4.7 Stakeholder3.4.8 Stakeholder perspective3.4.9 Concern3.5 Architecture description concepts 3.5.1 Architecture description3.5.2 Solution description3.5.3 Architecture view3.5.4 Architecture viewpoint3.5.5 Model3.5.6 Metamodel3.5.7 Reference model3.6 Entity life cycle concepts 3.6.1 Life cycle3.6.2 Life cycle phase3.6.3 Life cycle stage3.6.4 Life historyAnnexes A.1 Architecture design and solution related entitiesA.2 Architecture expressed as a set of modelsA.3 Life cycle and life history conceptsA.4 Enterprise and system conceptsA.5 Duality of architectural decomposition and architectural synthesisB.1 BackgroundB.2 Aligning architecture in designB.3 Duality of architectureB.4 Pursuit of opportunities Home / Glossary Entity related concepts · 3.3.6 # System A grouping of parts or elements whose combined behaviour or meaning is stated and is not present in any part alone. A complete system includes the equipment, facilities, material, programs, firmware, documentation, services and people needed for operation and support. - definition - Term - ISO/IEC/IEEE DIS 42024 - Last updated: 2026-10-21 ## What this term settles The definition makes the system boundary depend on the stated behaviour. That is a useful discipline: the boundary is not whatever the team finds convenient, it is the smallest arrangement that produces the behaviour in question. The second sentence also stops the common habit of calling software a complete system when it depends on people and facilities. ## What to do in your practice For each system, write the behaviour that the arrangement produces and that no part produces alone. Then list the equipment, people, facilities and services the behaviour depends on. If the list includes people outside the team control, the system boundary is wider than the delivery boundary, and that difference should be explicit. ## Who it binds The role that owns the practice area the term governs. A definition binds nobody on its own; it binds the reader who adopts the term in a method, a description or a contract. ## Evidence an auditor or regulator asks for - A system boundary statement with the stated behaviour. An auditor asks what the system is supposed to do and where it stops. - A dependency list covering people, facilities and services. Shows the boundary is complete rather than convenient. - A record of interfaces at the boundary. Lets a reviewer test whether the behaviour can actually be delivered. - The owner of the stated behaviour. Gives the boundary an accountable role. Ask your teamWhat behaviour does this arrangement produce that no part produces alone, and who owns that behaviour? ## Common gaps this page catches - The system boundary is the application boundary, while the behaviour depends on people and suppliers. - No stated behaviour exists, so the boundary is contested at every change. - Interfaces are listed for software only. ## What to prepare before publication Take one system and write the stated behaviour in one sentence. Then list everything the behaviour needs, including people. The difference between that list and the current boundary is the first scope correction in the plan. ## Common questions What does System mean in ISO 42024? A grouping of parts or elements whose combined behaviour or meaning is stated and is not present in any part alone. A complete system includes the equipment, facilities, material, programs, firmware, documentation, services and people needed for operation and support. What evidence should we keep for 3.3.6? A system boundary statement with the stated behaviour. A dependency list covering people, facilities and services. A record of interfaces at the boundary. ## Related units - 3.3.1 - 3.3.2 - 3.4.9 Source. ISO/IEC/IEEE DIS 42024, Clause 3.3.6, Terms and definitions. Open the official record. Retrieved 21 October 2026. https://www.iso.org/obp/ui/en/#iso:std:iso-iec-ieee:42024:dis:ed-1:v1:en ISO catalogue record 87510, the status, stage and page count. Claim level: definition. The definition is in the public preview. This page states it in our own words and does not reproduce the text. Last updated: 2026-10-21 · Markdown version · Check your practice Source: https://iso-42024-revision-checker.theartofservice.com/glossary/system/