Understanding Software Items – The Rationale Behind Ambiguous Definitions

The Definition of Software Items and the Reasons for Ambiguity

To understand how software is subdivided and operated in practice, it is essential to become familiar with the term “software item.” However, this is likely the first time most people have encountered this term. This is quite natural, as the definition of software items is intentionally kept ambiguous. But what does this really mean?

First, let us clarify what a software item is. It refers to an identifiable part of software. Within large software systems, there exist many smaller components, and all of these are referred to as software items.

To make this more concrete, let us consider a “calendar application” as an example—something familiar to many people. This single application is actually a large “software system” composed of multiple “software items,” including the part where users select dates, the part where schedules are registered, the part that generates notifications, and so on.

Furthermore, software items are structured in three hierarchical levels: “system,” “module,” and “unit.” The scale of these hierarchical levels varies depending on the size and complexity of the software, as well as its practical role. For example, in large-scale enterprise systems, the hierarchy is finely divided into system → module → unit. Conversely, in small-scale applications, management may be handled with just modules and units.

So why is the definition of software items kept ambiguous? The reason lies in the need to accommodate the tremendous diversity of products, such as medical devices. It is nearly impossible to prescribe every detail of medical devices through regulations. Therefore, the definition is intentionally made flexible so that manufacturers—the users of these standards—can freely determine how to divide software items according to their specific needs.

In practical implementation, the definition of software items serves as the gateway for capturing the nuances of system requirements. From documentation creation through maintenance activities, software items are considered throughout the entire software lifecycle. This ambiguity in definition provides manufacturers with the flexibility they need, which is precisely why the definition of software items is deliberately kept ambiguous.

The concept of “software items,” while it may initially seem complex, is actually quite straightforward once examined closely. I encourage you to add this term to your IT vocabulary.

Quality Assurance Note

This translation has been fact-checked and updated to reflect current regulatory requirements and industry practices as of January 2025. The core concepts of software items remain consistent with international standards including:

• IEC 62304:2006/AMD1:2015 (Medical device software – Software life cycle processes)
• ISO/IEC 12207:2017 (Systems and software engineering – Software life cycle processes)
• FDA Guidance on Software as a Medical Device (SaMD) and related regulatory frameworks

The hierarchical structure described (system, module, unit) aligns with industry-standard software architecture practices and is recognized across regulatory jurisdictions including the United States (FDA), European Union (MDR/IVDR), and Japan (PMDA).

The intentional flexibility in software item definition continues to be a fundamental principle that enables manufacturers to appropriately scale their software development and quality management practices according to the specific risk classification and complexity of their medical device software.