Ling Guo

Comparing COSMIC Functional Size Measurement: Expert vs. ChatGPT

Tue, 01 Sep 2026 00:00:00 +0000

Can ChatGPT perform COSMIC functional size measurement accurately?

In previous experiments, I asked both ChatGPT and Gemini to determine the functional size of a functional process using the COSMIC method.

To further examine the accuracy of ChatGPT in COSMIC functional size measurement, I conducted a small comparison using examples from the Course Registration System case study published by the COSMIC Group.

The requirements in this case study are described in sufficient detail for COSMIC measurement, and the corresponding measurement results have already been established by COSMIC measurement experts.

Two requirements were selected and submitted to ChatGPT for measurement. The results were then compared with the reference measurements.

Case 1: Search for a Course

The first requirement concerns searching for a course.

After entering the requirement into ChatGPT, the following measurement result was obtained:

In this case, the result produced by ChatGPT was consistent with the result provided in the COSMIC case study.

This example suggests that when the functional requirements are sufficiently detailed and relatively straightforward, ChatGPT may be able to identify the required COSMIC data movements correctly.

Case 2: Delete a Student Schedule

The second requirement concerns deleting a student’s course schedule.

The requirement was again submitted to ChatGPT for measurement.

This time, however, the COSMIC reference measurement contained two more function points than the result generated by ChatGPT.

A closer comparison showed that ChatGPT failed to identify two separate Exit (X) data movements:

displaying the student’s schedule; and
sending information to another system, the Course Catalog System.

Instead, ChatGPT grouped these outputs together with the error/confirmation messages and treated them as a single Exit.

Refining the Instructions

This result suggested that ChatGPT did not fully distinguish the COSMIC rules related to Exit data movements.

I therefore provided an additional instruction:

The returned schedule information needs to be displayed separately and should not be combined with the error/confirmation message. Updating the Course Catalog System also requires information to be sent to another system. Please identify the data movements again.

After receiving this instruction, ChatGPT identified all of the Exits separately.

However, this result was still incorrect.

According to the COSMIC rules applied in the reference case, error/confirmation messages without a clearly distinguishable object of interest should be grouped together rather than counted separately.

I therefore refined the instruction again:

Do not identify the deletion confirmation separately. Group all error/confirmation messages into one Exit, while keeping the display output and the information sent to the external system separate.

ChatGPT recalculated the measurement, but it still treated the successful deletion message as a separate Exit.

This was still inconsistent with the reference measurement because, in this context, the successful deletion message should also be treated as part of the error/confirmation messaging.

I therefore provided one more instruction:

The successful deletion message is also part of the error/confirmation messages and should be grouped with them.

After this clarification, ChatGPT finally produced the same measurement result as the COSMIC reference case.

What Can We Learn from This Comparison?

This small experiment highlights two important points.

First, COSMIC functional size measurement requires requirements to be described at a sufficient level of detail. If the available requirements are too vague, it becomes difficult to identify functional processes, data groups, and data movements reliably.

Second, understanding the COSMIC measurement rules remains essential.

Even though large language models such as ChatGPT are trained on large amounts of information, the quality and accuracy of the underlying knowledge cannot always be verified. As this example shows, ChatGPT was able to reach the correct result only after several increasingly specific instructions about the COSMIC rules.

Therefore, AI tools may be useful as assistants for COSMIC measurement, but their results still require review and validation by people who understand the COSMIC method and its measurement rules.

For professional or research applications, the role of the COSMIC measurement expert remains important.

This article is adapted from an earlier Chinese article written by the author.

Understanding the Relationship Between Triggering Events, Functional Users, and Functional Processes in COSMIC

Sat, 01 Aug 2026 00:00:00 +0000

COSMIC Measurement Manual Version 5.0 describes and explains the relationships among triggering events, functional users, and data groups. Understanding these concepts is particularly useful when identifying functional processes.

Functional Users and Data Groups

Let us begin with two relatively familiar concepts: functional users and data groups.

In the COSMIC software context model, there are three main elements: functional users, the software being measured, and persistent storage.

Functional users may include human users, other software components, other systems, or devices. A functional user is a sender and/or intended recipient of data associated with the functional requirements of the software being measured.

Data exchanged between a functional user and the software is conveyed in the form of data groups.

COSMIC defines four types of data movements:

Entry (E) — moves a data group from a functional user into the software.
Exit (X) — moves a data group from the software to a functional user.
Read (R) — moves a data group from persistent storage into the software.
Write (W) — moves a data group from the software to persistent storage.

For a functional user, therefore, only two types of data movements cross the software boundary: Entries and Exits.

From a Triggering Event to a Functional Process

A functional process must be initiated. At the beginning of a functional process, a functional user sends a data group to the software through an Entry.

But what causes the functional user to initiate the functional process?

This is where the concept of a triggering event becomes important.

A triggering event occurs outside the functional process. The occurrence of the event causes a functional user to initiate a functional process by generating and sending a data group to the software.

The relationship can therefore be understood as a sequence:

Triggering Event → Functional User → Triggering Entry → Functional Process

In other words, an event occurs first. In response to that event, a functional user sends a data group through a triggering Entry, which initiates a functional process.

Why This Relationship Matters

This relationship is particularly important when identifying functional processes.

A triggering event is an event outside the software functionality being measured. For example, it may be the receipt of an order or a monitored value reaching a certain threshold.

The functional user responds to this triggering event and sends a data group—the triggering Entry—to the software. This initiates the corresponding functional process.

COSMIC provides a series of examples illustrating the identification of functional processes from both business application software and real-time software perspectives.

Understanding the sequence among the triggering event, functional user, triggering Entry, and functional process can therefore help clarify where one functional process begins and how it should be identified.

Learning COSMIC Through the Measurement Manual

When learning COSMIC functional size measurement, it is useful to repeatedly consult Version 5.0 of the COSMIC Measurement Manual.

The manual is organized into three parts:

Principles, Definitions & Rules
Guidelines
Examples

When encountering an unfamiliar COSMIC term, the Principles, Definitions & Rules can be used to check its formal meaning. The Guidelines help explain how the concepts should be understood and applied, while the Examples provide practical cases for reinforcing that understanding.

Memorizing terminology is not the ultimate goal. More important is understanding the measurement logic behind the method so that COSMIC can be applied appropriately across different software contexts.

This article is adapted from an earlier Chinese article written by the author.

If Management Work Cannot Be Measured in COSMIC Function Points, How Can Its Effort Be Estimated?

Wed, 01 Jul 2026 00:00:00 +0000

I recently received a question from a reader about the relationship between functional size and effort:

Management activities are not directly associated with functional size. Should the cost of management work therefore be estimated separately? The question came from an organization where software development is outsourced to several suppliers. Front-end development, back-end development, and testing are performed by different teams, while project management and overall coordination are handled internally.

Different roles are typically charged according to the effort they spend on the project. The organization therefore wants to plan ahead and estimate the effort required by these different activities as accurately as possible for budgeting purposes.

They are using COSMIC functional size measurement for the front-end, back-end, and testing-related software, but they are unsure how to deal with management effort.

COSMIC Measures Software Size, Not Management Activities

COSMIC functional size measurement measures the functional size of software based on its Functional User Requirements (FUR).

Put simply:

If there is software functionality, its functional size can potentially be measured. If there is no software functionality, there is no functional size to measure.

Consider typical project management activities:

organizing project meetings;
monitoring project progress;
coordinating among teams;
preparing weekly reports and presentations;
reporting project status to management.

These activities do not correspond to software functionality delivered by the project. Therefore, their functional size cannot be measured using COSMIC.

However, having no COSMIC functional size does not mean that an activity requires no effort.

Functional Size and Effort Are Different Dimensions

Functional size and effort measure different characteristics of a software project.

We measure functional size partly because size can provide a useful basis for estimating effort. In this way, two different dimensions—size and effort—can be statistically related.

Importantly, this relationship does not have to be one-to-one.

For example, we do not necessarily need to use:

development size → development effort

or:

testing size → testing effort

A measured software size may also be used to estimate:

software size → testing effort

or even:

software size → project management effort

The important question is not whether the activity itself has a functional size. The important question is whether historical data show a useful relationship between software size and the effort required for that activity.

Historical Data Provide the Mapping

When sufficient historical data have been collected, organizations can investigate relationships between functional size and many other project variables they want to estimate.

For example, functional size can potentially be related to:

number of test cases;
test case preparation effort;
testing effort;
testing rework effort;
project management effort;
overall project effort.

Suppose we want to estimate the number of test cases required for a project.

Writing test cases is not itself software functionality, so we cannot measure the functional size of the activity “write test cases.”

However, this does not mean that the number of test cases cannot be estimated.

If historical project data show a relationship between software functional size and the number of test cases, we can build an estimation model:

Functional Size → Number of Test Cases

The same principle can be extended to effort:

Functional Size → Test Case Preparation Effort

Functional Size → Testing Effort

Functional Size → Testing Rework Effort

The relationship must be established and validated using historical data.

Different Production Lines May Have Different Productivity Patterns

The same idea can be applied when analyzing productivity.

Suppose an organization maps functional size and effort for projects belonging to several different production lines. The data may reveal that each production line has a different productivity pattern.

This information can support management decisions.

For example, directly comparing productivity across production lines may not be appropriate because each production line may have different characteristics. Comparisons within the same production line may be more meaningful.

If one production line consistently requires more effort per unit of functional size, the organization can investigate the underlying reasons and identify opportunities for process improvement.

Conversely, if another production line consistently requires less effort, its practices can be analyzed to determine whether some of them could be adopted elsewhere in the organization.

Conclusion

Functional size and effort are two different dimensions of software measurement. They do not have a strict one-to-one relationship.

Even when an activity cannot itself be measured in COSMIC function points, its effort may still be estimated by establishing an empirical relationship between software functional size and historical data for that activity.

A reliable functional-size baseline therefore provides much more than a measure of software size. Combined with sufficient historical data, it can become the foundation for estimating and analyzing many different aspects of software projects.

This article is adapted from an earlier Chinese article written by the author.

How to Learn COSMIC Functional Size Measurement Systematically

Mon, 01 Jun 2026 00:00:00 +0000

I recently received a question from a new reader about how to systematically learn COSMIC Functional Size Measurement.

For someone without a technical background who is transitioning into a COSMIC review role, the most important thing to learn first is not COSMIC Functional Size Measurement itself, but how to understand software requirements.

Most COSMIC review activities are based on software requirements specifications. Before learning COSMIC in depth, it is important to become familiar with how your organization or project teams write requirements—their formats, content, methods, and conventions.

This understanding can be developed by reading requirements documents, participating in project reviews, attending project meetings, and becoming familiar with the business domain.

Start with the COSMIC Measurement Manual

Once you have a basic understanding of the business and its software requirements, you can begin learning COSMIC Functional Size Measurement.

The COSMIC Measurement Manual Version 5.0 consists of three parts:

Part 1 — Principles, Definitions & Rules

Part 2 — Guidelines

Part 3 — Examples

A practical approach is to first read Part 1 to become familiar with the fundamental concepts.

When you encounter a concept that is difficult to understand, you can refer to the corresponding section in Part 2 for more detailed guidance.

Finally, Part 3 provides examples that can help you understand how COSMIC is applied in actual measurement activities.

The concepts required for COSMIC measurement can be found in the Measurement Manual. However, theoretical knowledge alone is not sufficient. A significant amount of practical exercise is also necessary.

Understand the Overall COSMIC Measurement Framework

Before beginning practical measurement exercises, it is useful to first build an overall framework and understand the logic of the COSMIC measurement process.

The COSMIC measurement process consists of three phases:

Measurement Strategy → Mapping → Measurement

The Measurement Strategy phase is a preparation phase. It is more oriented toward defining, at the organizational level, how COSMIC will be used.

Once the organization has determined the purpose of measurement, it can establish the corresponding measurement process and measurement templates. Requirements for the documents to be measured can also be clearly defined.

Measurement personnel—who may be requirements analysts or other people designated by the organization—can then proceed to the second phase.

Mapping Requirements to COSMIC Concepts

The Mapping phase primarily involves mapping the documents to be measured to COSMIC concepts and completing the measurement template according to organizational requirements.

The final measurement results are also recorded in the template, leading to completion of the third phase—the Measurement phase.

Below are several examples of measurement templates designed by participants in online COSMIC courses.

Decompose Requirements Before Measurement

Before mapping COSMIC concepts, an important step is to decompose the document to be measured into different levels.

A requirements document may contain multiple functional processes, and each functional process may contain multiple data movements.

The design of the measurement template should reflect this hierarchical structure.

The document to be measured should therefore be decomposed according to the definition of a functional process so that individual functional processes can be identified.

Some requirements are clearly written and functional processes can be identified relatively easily.

Other requirements may be ambiguous. In such cases, communication with the person who wrote the requirements may be necessary to confirm whether a functional process actually exists.

Connect COSMIC Concepts with Concrete Examples

Once the requirements have been decomposed into functional processes, the data movements within each functional process can be measured.

Simply memorizing COSMIC terminology can be difficult because many of the concepts are abstract.

A more effective approach is to connect each concept with a concrete example.

If you can understand how the COSMIC concepts correspond to the elements in a specific example, the same measurement logic can then be extended to other scenarios.

Practice Repeatedly

Becoming proficient in COSMIC requires repeated practice in two fundamental activities: decomposing requirements and identifying functional size.

The more requirements you analyze and the more frequently you apply the COSMIC rules, the more familiar you become with the method.

In addition to practicing independently with requirements documents, learners can also participate in free online classes, structured courses, and practical training.

COSMIC certification examinations can also be used to evaluate and validate learning outcomes.

Conclusion

To become proficient in COSMIC Functional Size Measurement, you should first develop a general understanding of its theoretical foundations. This can be achieved through self-study or structured courses.

More importantly, you should understand the overall measurement framework and the logic connecting the different measurement activities, rather than simply memorizing individual terms and rules.

Once the basic framework is understood, practical exercises can be used to reinforce the concepts and rules.

Through repeated practice, reflection, and experience, measurement accuracy and efficiency can gradually improve.

This article is adapted from an earlier Chinese article written by the author.

Five Questions That Test Your Understanding of COSMIC Functional Size Measurement

Fri, 01 May 2026 00:00:00 +0000

When delivering training on the COSMIC Functional Size Measurement (FSM) method, I often receive similar questions from participants.

At first glance, these questions may appear to concern specific COSMIC rules. In fact, they often go deeper: they reflect whether we really understand what software measurement is for, what should be measured, and how measurement should be used in practice.

Here are five questions that I frequently encounter.

Before reading my answers, try answering them yourself. Write down a few keywords for each question and see whether your reasoning covers both the COSMIC method itself and the broader purpose of software measurement.

1. Can COSMIC only be used to measure requirements?

Our company mainly develops software. Requirements are written by our customers. Can we still use COSMIC?

COSMIC can be applied at different stages of the software life cycle.

The essential point is that COSMIC functional size measurement is based on Functional User Requirements (FUR). These requirements do not have to exist in one particular document or format.

Depending on the stage of the software life cycle, information about the FUR may be derived from different artifacts, such as:

requirements clarification records;
software requirements specifications;
design documentation;
the software itself or its source code;
user manuals; or
software interfaces.

Therefore, the question is not simply, “Do we have a requirements specification?”

A more important question is:

What is the purpose of the measurement, and at what point in the software life cycle do we need the size information?

The appropriate source of information for identifying the FUR depends largely on that measurement purpose.

2. Our company has used its own sizing method for years. Do we need to replace it with COSMIC?

Not necessarily.

Being familiar with a sizing method does not automatically mean that the method is effective. But similarly, adopting an international standard simply because it is a standard is not sufficient justification for replacing an existing method.

A useful way to evaluate an organizational sizing method is to examine historical data.

For example, collect:

software size data; and
a target variable such as actual development effort.

Then investigate the relationship between them.

If the organization’s existing size measure has a strong and useful relationship with the target variable, such as development effort, the method may already serve its intended purpose within that organization.

Organizations often consider replacing or improving an existing sizing approach when problems arise, such as:

excessive subjectivity;
inconsistent counting rules;
poor repeatability; or
weak relationships between measured size and the variables the organization wants to analyze or estimate.

Therefore, before introducing a new functional sizing method across an organization, it can be useful to first evaluate the existing method using actual project data and make the decision based on evidence.

3. Why should we use COSMIC for functional size measurement?

COSMIC has several characteristics that make it useful as a standardized functional size measurement method.

For example, the method is designed to measure functional size from the perspective of functional user requirements and to be independent of the software implementation technology.

Its measurement principles and rules can also be learned through systematic training and measurement exercises.

When introducing COSMIC into an organization, one practical approach is to begin with a representative sample of projects rather than immediately deploying the method organization-wide.

The organization can then compare COSMIC functional size with historical variables such as actual development effort.

In many practical applications, the objective is to determine whether the measured functional size provides a useful basis for activities such as:

effort estimation;
productivity analysis;
benchmarking;
project planning; and
process improvement.

Where necessary, organizational measurement conventions may also be established while remaining consistent with the underlying COSMIC principles.

The decision to deploy COSMIC more broadly should therefore be supported by both measurement principles and empirical evidence from the organization’s own projects.

4. Why could I understand COSMIC during training but still struggle to perform real measurements?

Learning COSMIC is somewhat like learning to drive.

Understanding the rules is necessary, but understanding the rules alone does not automatically provide enough experience to handle real situations confidently.

After formal COSMIC training, organizations normally need practical measurement exercises using their own software requirements and projects.

This may involve:

hands-on functional size measurement;
reviewing actual measurement cases;
one-to-one guidance for project teams;
resolving ambiguities in real requirements;
collecting and validating measurement data;
integrating measurement activities into existing organizational processes; and
developing supporting procedures, templates, guidelines, and organizational measurement conventions.

In other words, there is an important difference between:

knowing the COSMIC rules

and

being able to establish and operate a functional measurement process in an organization.

Training is only the beginning. Practical measurement, feedback, calibration, and organizational integration complete the process.

5. Our requirements are too vague to measure functional points. How can we use COSMIC?

This is a common issue, particularly in the early stages of software development.

The underlying purpose of software sizing is to establish a consistent way of representing software size at the level of information currently available.

When detailed Functional User Requirements are not yet available, it may not be possible to perform a detailed COSMIC measurement directly.

Instead, organizations can explore higher-level sizing indicators based on the available information, such as:

requirement items;
requirement groups;
identified functional processes; or
other consistently defined early-size indicators.

COSMIC also provides guidance for early or approximate functional sizing when requirements are incomplete.

The key is to select a sizing approach appropriate to the available level of requirements information and then evaluate whether the resulting size measure is useful for its intended purpose.

For example, if the objective is effort estimation, historical data can be used to investigate the relationship between the selected size indicator and actual effort.

As requirements become more detailed, the measurement can progressively move toward a more detailed COSMIC functional size expressed in COSMIC Function Points (CFP).

From Learning COSMIC to Applying COSMIC

These five questions actually form a useful path from understanding COSMIC to applying it in practice:

What can be measured?
→ Understand Functional User Requirements and the measurement purpose.

Should an existing sizing method be replaced?
→ Evaluate the method using organizational data.

Why use COSMIC?
→ Understand the value of a standardized functional size measure.

Why is training alone insufficient?
→ Move from knowledge of the rules to practical measurement capability.

What if the requirements are incomplete?
→ Select a sizing approach appropriate to the available level of information.

If your answers to these five questions are broadly consistent with this reasoning, you have probably moved beyond simply learning COSMIC terminology and rules.

You are beginning to understand the more important question:

how functional size measurement can actually be applied within a software organization.

This article is adapted from an earlier Chinese article written by the author.