ISSUE REPORT l 2025.12.24. IS-217
( Extra Bold 11pt 줄 간격 130% 작성 완료 시 이 글은 삭제) 
An AI Project Size Estimation Framework
- The Hidden Iceberg: Measuring Technical Scope -
Yoo Hoseok, Lee Yoonseok
This report was produced with support from the Information and Communications 
Promotion Fund of the Ministry of Science and ICT, and its contents
may differ from the official opinion of the Ministry of Science and ICT.
The contents of this report represent the personal views of the research team. If you 
have any questions regarding this report or if there
is a need for correction or supplementation, please contact us at the contact information 
below.
Yoo Hoseok, Principal Researcher
Software Policy & Research Institute  
hsy@spri.kr
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
  CONTENT
  
Ⅰ. Legacy Software Project vs. AI Project
Ⅱ. Limitations of FP-based AI Project Estimation
III. Technological  Size  Measurement  Complementing  the  
 Limitations  of  Functional  Size
IV. Size Measurement Model Reflecting Technical    
Requirement
V. Practical Applications 
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
Executive Summary 
As AI technologies advance rapidly, the number of AI project procurements 
continues to grow. Yet the traditional Function Point (FP) method shows clear 
limitations: in AI projects such as chatbots or Retrieval-Augmented Generation 
(RAG), the user interface may appear simple while massive data processing and 
complex computational workflows operate underneath. FP cannot capture the true 
size of these hidden engineering efforts, creating a risk that AI project budgets 
will be underestimated and ultimately unrealistic.
To address this gap, this report shifts the focus from AI model development to 
AI Application Service Construction (Engineering) and proposes a framework for 
size estimation. It recommends adopting the international SNAP (Software 
Non-functional Assessment Process) standard to quantify the technical 
complexity involved in back-end operations—such as data preprocessing, 
embedding generation, and vector-store construction—that FP cannot measure.
For a sound compensation system to take root, this report suggests key 
directions: discovering automated measurement tools for AI technical scope, 
accumulating AI project data, and fostering the AI engineering company 
ecosystem. Ultimately, these efforts will contribute to enhancing the accuracy and 
transparency of AI project size estimation.
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
5
Ⅰ. Legacy Software Project vs. AI Project
□
Legacy Software Business Value Chain
ㅇ
It fundamentally follows a linear flow: Planning → Implementation → 
Operation.
□
AI Business Value Chain
ㅇ
Rather than a linear flow,it must be continuously and iteratively   
optimized.
ㅇ
While significant effort must be invested in acquiring and training data 
and AI models, the effort directly contributed by human developers is 
relatively reduced.
* Source: SPRi (2024a)
[Figure 1] Characteristics of AI Projects: Iterative and Continuous Process Centered on Data
AI Application Service 
Planning
▶
Data Collection, 
Processing, and Analysis
▶
AI Model Development and 
Training
·AI Strategy and Roadmap 
Planning
·New Technology R&D
·Data Acquisition
·AI Governance Management
·Data Curating
·AI Data Engineering
·Data Analyst
·AI Architecture Design
·AI Engineering
·Model Training and Tuning
·Model Performance 
Evaluation and Optimization
AI Application Service 
Support
◀
AI Application Service·
Implementation
◀
AI Model Deployment
·AI Education
·AI Service Expansion
·AI Ethics Management
·AI Service 
Planning/Development
·AI Application Development
·AI Test Engineering
·AI Ops Engineering
·AI Cloud Operations
·Security/Access Control
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
6
[Table 1] AI Project Value Chain Components
Category
Definition 
AI Service 
Planning
AI Strategy & 
Roadmap Planning
Planning and overseeing AI business/projects
New Technology 
R&D
Developing new AI algorithms, model architectures, reinforcement 
learning theory, natural language processing technologies, Physical AI, 
and computer vision technologies
Data 
Collection,
Processing, 
Analysis
AI Governance 
Management
Managing data utilization formats, management cycles, and procedures 
in the process of collecting data required for AI learning (paid, free, 
government-released, etc.)
Data Labeling
Collecting, building, refining video, language, and other data for AI 
learning, and managing data quality
AI Data Engineering
Performs large-scale data storage management, data 
transformation/integration, selection and automated processing for AI 
training and analysis
Data Analyst
Performs data analysis for AI, defines machine learning objectives and 
application requirements, selects data algorithms, and optimizes models
AI Model 
Development·
Training
AI Architecture Design
Performs design and development of AI frameworks, large-scale 
distributed parallel training, inference, and service architectures
AI Development
Designs and develops AI models (machine learning, deep learning, etc.) 
suited to business objectives using data
Model Training and 
Tuning
Trains models with data and optimizes hyperparameters
Model Performance 
Evaluation·Optimization
Experiments, validates, compares, and optimizes developed model 
performance using various metrics
AI Model 
Deployment
AIOps Engineering
Ensures reliability, efficiency, and scalability of AI systems through 
various automation tools, scripts, CI/CD pipelines, monitoring, and 
infrastructure management, integrating the entire process from 
development to deployment and operations
AI Cloud Operations
Operations and management of distributed parallel training, large-scale 
inference, AI service systems, and cloud infrastructure for artificial 
intelligence
Security/Access 
Control
Securely protect models and data, systematically manage appropriate 
user permissions to block unauthorized access, and security policies and 
incident-response procedures.
AI Application 
Service 
Development/Im
plementation
AI Service 
Planning/Developm
ent
Commercialize various AI technologies and implement business models
AI Application 
Development
Develop solutions (services, agents, etc.) applying AI model-based 
technologies across various fields/industries, design user experiences, 
and develop APIs
AI Test Engineering
Manage testing and quality including AI model quality evaluation
AI Application 
Service 
Operations
AI Education
Provide education and training on artificial intelligence and related 
technologies/services
AI Solution Sales
Sell AI solutions or provide consulting to enterprises or individuals
AI Ethics 
Management
Research ethical and social impacts of AI technology, manage privacy 
and security, and propose related guidelines and policies
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
7
□
This report discusses the size estimation excluding  AI model 
development and training  among areas described above.
ㅇ
AI Model development and training phase, as a stage preceding 
application services, is heavily influenced by investment factors 
such as GPU computing resources, electricity costs, and other 
infrastructure costs.
ㅇ
This report focuses on size estimation in the field of AI service 
engineering (planning, data acquisition, deployment, application 
service development/implementation, and operation), which is 
closely related to end users or clients after AI model 
development.
Ⅱ. Limitations of FP-based AI Project Estimation
□
Overview of Function Points (FP) and Limitations in AI Service 
Size Estimation
ㅇ
Function Point (FP) is a concept introduced by IBM in the 1970s 
to objectify software development size
–
FP measures the logical size of a system by counting five 
elements—inputs, outputs, inquiries, internal files, and external 
interfaces—based on "Functional User Requirements" that users 
can recognize
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
8
[Table 2] FP-based Functional Size Estimation Method
Function
Complexity Assessment Criteria by Function
Simple
Normal
Complex
Screen
Input
· 0 or 1 
referenced file 
15 or fewer data 
elements
· 2 or more 
referenced
 files~ (and so on)
· 0 or 1 referenced 
file
16 or more data 
elements
· 2 or more 
referenced files~ 
(and so on)
· 2 reference files
16 or more data items
· 3 or more reference files ~ 
(and so on)
Output/
Inquiry
· 0 or 1 reference 
file
19 or fewer data 
items
· 2~3 reference 
files (and so 
on)
·0 or 1 reference file
20 or more data items 
~ (and so on)
· 2~3 reference files
20 or more data items
·4 or more reference files 
~ (and so on)
Data
Internal
/Extern
al File
· 1 sub-data,
50 or fewer data 
items
· 2~5 or more 
sub-data
(and so on)
· 1 sub-data
 51 or more data 
items ~ (and so 
on)
· 2-5 sub-data, 51 or 
more data items
· 6 or more sub-data 
~
(and so on)
 
   * Source: Function Point Measurement Practical Manual (Ver 4.3.1 Korean Edition, Korea 
     Software Measurement Institute)
ㅇ
The FP method is fundamentally based on counting user functional 
requirements; however, AI services have a high proportion of 
technical requirements that users cannot perceive
–
The core of the FP method is quantifying the number of 
"user-perceivable functions (what the software shall do)," 
premised on a structure where effort and project costs are 
proportional to the number of functions
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
9
–
AI services operate based on "internal learning logic" such as 
probabilistic inference, pattern recognition, and language 
generation, rather than executing predefined functions, thus 
limiting the explicit functions that can be counted using FP
* For chatbots or recommendation systems, user inputs and system outputs
  are not deterministic; they have non-deterministic characteristics where 
  results may vary even for identical requests
Functional elements of legacy 
SW
Functional elements of AI 
services
Countable
Functional elements such as menus 
and buttons can be counted
Difficult to count due to changing usage 
paths
Account 
manage
ment
Service
Example
   * Intuit's Mint App
   
*https://www.nairaland.com/3626189/feedback-ai-c
hatbot-send-money
[Table 3] Functional Requirement Comparison  : Legacy SW vs. AI Service
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
10
Ⅲ. Technical Size Estimation to Complement the 
Limitations of Functional Size
□
The Need for Integrated Functional + Technical Measurement
ㅇ
The utility of AI services heavily depends on technical factors 
such as "accuracy, response speed, training data quality, and model 
stability"
* For example, "response naturalness" in generative chatbots, "precision 
and recall" in recommendation systems, and "response speed and stability“
 of AI APIs are all technical requirements expressed as technical 
characteristics and quality attributes, not explicit functions
ㅇ
Ultimately, sizing AI services faces the challenge of measuring 
invisible technical requirements more than visible functions
[Figure 2] AI Services with a High Proprotionof Invisible Technical 
Requirements Like an Iceberg Below the waterline
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
11
□
Functional Measurement Quantifying 'What' vs Technical Requirement 
Measurement Quantifying 'How'
ㅇ
Differences in Measurement Targets, Units of Analysis, and Scope 
of Application
–
Technical element measurement quantifies additional effort based 
on data structure complexity, UI design difficulty, performance 
requirements, and platform integration levels, even for identical 
functions
–
The unit of analysis also differs: functional requirement are 
evaluated as "business function units from the user's 
perspective," while technical requirement are evaluated as 
"technical element units from the system's perspective 
(components, interfaces, platforms, performance requirement, etc.)“
–
In terms of scope, function points focus on the development 
process of requirements analysis–design–development, while 
technical element points focus on operations and quality 
management stages including performance, security, scalability, 
and data management
  * For example, for the same "Q&A function," a simple FAQ-type chatbot
    might score 10 function points and 0 technical element points, whereas 
    an AI chatbot utilizing LLM for natural language understanding and
    reasoning would reasonably be quantified as 10 function points 
    (example) + 35 technical element points (example)
ㅇ
Therefore, technical element measurement is not a substitute for 
functional measurement but rather a complementary means that 
quantifies the size of technical requirement that function points 
cannot capture, serving as a practical approach to measuring the 
effort of technical personnel required for high-technology 
implementations such as AI services
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
12
IV. Size Estimation Model Reflecting Technical Requirement
□
(International Standards) After identifying and separating 
functional/technical requirements, calculate each size separately
ㅇ
In the figure below, the functional area uses the existing 
FP(Function Point) standard, while the non-functional area can be 
measured using the SNAP(Software Non-functional Assessment 
Process) standard
*
IFPUG (International Function Point Users Group) first published the 
SNAP Measurement Manual (APM v1.0) in 2011 and began its 
dissemination to quantify the size of non-functional requirements that 
are difficult to measure with Function Points (FP) alone
*
It was approved as IEEE 2430-2019 (IEEE Standard for Software 
Non-Functional Sizing Measurements) in 2019, and achieved ISO 
international standard status when published as ISO/IEC/IEEE 
32430:2025 "Software engineering — Software non-functional size 
measurement Standard" in 2025
[Figure 3] Integrated Measurement Procedure for Functional and Technical 
         * IFPUG (2017)
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
13
ㅇ
Scope of Application
–
(FP) Broadly applicable across all functional requirements
–
(SNAP) Applicable to technical requirements represented by 4 
categories and 14 subcategories, including data validation, 
formatting, interface design, multi-platform, batch processing, 
and component architecture (see figure below)
ㅇ
Basic Concepts
–
(FP) 2 data functions (Internal Logical File, External Interface 
File), 3 transaction functions (External Input, External Output, 
External Inquiry)
–
(SNAP) Identify technical size for each category, but the two 
sizes must be managed separately without combining with FP
[Figure 4] The 4 Categories and 14 Subcategories of SNAP Measurement
      * Appendix 1. SNAP Category Descriptions
ㅇ
Measurement Procedure
–
(FP) Define scope/boundary → Identify 5 function types → 
Identify complexity for each function type → Sum functional sizes
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
14
–
(SNAP) Map technical requirements to subcategories → Apply 
subcategory measurement rules → Sum Technical Size
[Table 4] Comparison of SNAP Measurement Target vs. FP Measurement Target
ㅇ
The following content focuses on measuring the Technical Size of 
AI projects and presents examples of actually measuring Technical 
Size using the SNAP standard
Category
SNAP (Technical Size)
FP (Functional Size)
Standard
ISO/IEC/IEEE 32430:2025
ISO/IEC 20926:2009
Measurement Target
Size by subcategory of non-functional 
requirements(See figure above)
User functions
(Transaction /Data functions)
Ke
y
AI
Tec
hni
cal
 
Req
uire
me
nt
1.2 Logical and  
   Mathematical  
   Operations
Reflects algorithm complexity
Does not reflect algorithm 
complexity in size
1.4 Internal Data 
   Movement
Reflects movement between partitions 
within application boundary in size
Only reflects data movement into/out 
of application boundary in size
3.2 Database 
   Technology
Reflects physical table elements such 
as code data(code/view/partition/index, 
etc.)
Physical tables are not 
recognized as size (only logical 
composition is recognized)
3.3 Batch Process
Recognizes as size the batch jobs 
within the boundary that are not 
recognized as functional 
requirements(Transactional Function).
Only reflected when recognizable 
by users across application 
boundaries
4.  Architecture
Number of reusable components, etc. 
Architecture complexity is reflected in 
size
Architecture complexity is not 
reflected in size
AI size estimation 
applied
- Operational and quality 
   characteristics such as latency,   
availability, security, platform, 
deployment, and UI guidelines are 
quantified as separate size.
- Operational and quality load of AI
   systems such as model response 
time/format validation, multi-format 
output
* multi-platform deployment, and 
batch pipelines are reflected in size
- Only user-recognizable
  functional flows such as chatbot 
UI or AI responses are 
measured
- Technical difficulty is rarely    
   reflected in size
    * Only reflected through some    
      adjustment factor methods
* SNAP Category Descriptions (see Appendix 1)
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
15
□
(Use-case) Building RAG to deliver internal knowledge to LLM
ㅇ
(Background) RAG(Retrieval Augmented Generation)  for obtaining user 
(enterprise)-specific answers rather than general answers from AI
 - With internal information stored in a Vector DB*, when a user 
queries the LLM, it searches for specialized information in that 
Vector DB, and the LLM generates a comprehensive response
*
While legacy DBs store structured data (numbers, text) as-is, Vector 
DBs convert unstructured data such as documents, images, and videos 
into vector values (embedding) for storage
[Figure5] General RAG Implementation
* Image source: AWS Korea (2024)
 - This RAG implementation process requires measuring technical 
elements to determine the size, and since these are not functions 
recognizable by the client, the FP method cannot be used; instead, 
technical size measurement methods such as SNAP must be 
applied
 - The following provides an example of measuring only up to the 
process (storage) of ❷ Store Vector data within the dotted box 
in the above image, based on SNAP
*
For step ❸,where the user submits a query,it is advisable to estimate 
the cost through a separate measurement procedure(retrieval) rather 
than as part of the storage process.
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
16
ㅇ
(Measurement Example) This example demonstrates SNAP 
measurement for the process of ①Parsing, ②Chunking*, and ③
Embedding data from corporate disclosure documents, followed by 
storage
*
Chunking refers to splitting data into physical sizes (Tokens) that the Embedding 
Model can accept at one time. Data can be split by sentence, page, or other units.
[Figure 6] RAG Implementation with Technical Requirement such as Input Data, 
Parsing, and Chunking
1) (Unstructured data) Technical size of business description for Vector 
Embedding : 187 SP(SNAP Point)
*
7 items including business description and shareholder composition within 
1 business report file(DET;Data Element Type)assumed natural language. 
The process of storing datasets in Vector DB.
*
Each cell in the table below is calculated as [Complexity (Low/Average/High) × 
Number of DETs], refer to Appendix 2 for complexity
[Table 5] Example of Technical Sizing for Storing Corporate Business Reports via RAG
- Measured as having the highest technical size due to the parsing effort required for the 
original document
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
17
SNAP
Category
① Parsing
(70 SP)
② Chunking
(42 SP)
③ Embedding
(63 SP)
1.2 Logical and 
Mathematical 
Operations
28 = 
4(Low)×7DETs
*1 business report file 
(FTR) has complexity 
'Low' × 7 DETs
-
-
1.3 Data 
Formatting
14 = 
2(Low)×7DETs
*Simple type conversion 
× 7 data elements
14 = 2(Low)×7DETs
*Simple data decomposition × 
No DET increase from physical 
decomposition (7 maintained)
 35= 5(High)×7DETs
*Large-scale conversion to 
vector format × 7 data types
1.4 Internal 
Data Movement
28 = 
4(Low)×7DETs
*Simple movement from 
1 location to 1 location 
(FTR) × 7 data elements
(Original → Parsing)
 28 = 4(Low)×7DETs
*Simple movement from 1 
location to 1 location (FTR) 
× 7 data elements
(Parsing→Chunking)
28 = 4(Low)×7DETs
*Simple movement from 1 
location to 1 location (FTR) 
× 7 data elements
(Chunking→Embedding)
4.1 
Component-Bas
ed SW
④ Common Architecture (12 SP)
12 = 4(Third Party Component) * 3
*Composed of 3 third-party components (Parsing+Chunking+Embedding)
Total
 (SNAP Point)
187 SP = ①70 + ②42 + ③63 + ④12
* SNAP Detailed Category Measurement Table (see Appendix 2)
2) (Structured data) Technical size of with financial statements added : 292 SP
*
Assuming 5 fields (DET) of numerical data such as revenue and operating 
profit from financial statements, adding technical sizing for storing these 
additionally in Vector DB
[Figure 7] RAG implentation with financial data input added to Figure 6
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
18
[Table 6] Technical sizing measurement example with financial statement data 
added to Table 5
- High complexity Embedding (Vectorization) process has the highest technical sizing - 
SNAP
Category
① Parsing
(100 SP)
② Chunking
(72 SP)
③ Embedding
(108 SP)
1.2 Logical 
and 
Mathematical 
Operations
<Business Report> 28 
*Since financial statements 
consist of structured data, there 
is no Parsing, meaning no logical 
or mathematical operations are 
performed.
-
-
1.3 Data 
Formatting
<Business Report> 14 
<Financial Statements> 10 
= 2(Low)×5DETs
*Simple type conversion × 5 data 
types
<Business Report> 14 
<Financial Statements> 
10 
= 2(Low)×5DETs
*Simple data decomposition × 
Physical decomposition does not 
increase DET (maintained at 5)
<Business Report> 
35
<Financial Statements> 
25 
= 5(High)×5DETs
*Large-scale conversion to 
vector format × 5 data 
types
1.4 Internal 
Data 
Movement
<Business Report> 28
<Financial Statements> 20 
= 4(Low)×5DETs
*Simple movement from 1 
location to 1 location (FTR) × 5 
data types
<Business Report> 28
<Financial Statements> 
20 
= 4(Low)×5DETs
*Simple movement from 1 
location to 1 location (FTR) 
× 5 data types
<Business Report> 
28
<Financial Statements> 
20 
= 4(Low)×5DETs
*Simple movement from 1 
location to 1 location 
(FTR) × 5 data types
4.1 
Component-B
ased SW
④ Common Architecture (12 SP)
<Business Report + Financial Statements Common> 12 
Total
(SNAP Point)
292 SP = ①100 + ②72 + ③108 + ④12
* SNAP Measurement Table by Detailed Category (see Appendix 2)
ㅇ
The above SNAP standards and examples indicate that the size of 
AI services increases according to the type and volume of 
structured and unstructured data input to the AI
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
19
V. Practical Applications 
□
Securing Automation Tools for AI Technical Size Measurement
ㅇ
Necessity and Technical Feasibility of Measurement Automation
–
(Limitations of Manual Measurement) Due to the complexity and 
unstructured nature of AI projects, manual measurement by 
experts requires excessive time and cost, making the transition 
to automation urgent
–
(Technical Size Measurement Opportunity for Automation)Unlike 
Function Points (FP), which involve significant subjective judgment such 
as interpreting user intent, Technical Size (SNAP) is based on objective 
and physical attributes such as data processing volume, algorithm 
complexity, and number of components, resulting in lower dependence on 
human judgment and making automation implementation much easier.
–
However, automation tools for measuring the size of AI technical 
elements are still absent
[Figure 8] Currently, only tools exist that automatically calculate FP size by 
specifying functional requirements
        
* LeadMC Corp., < Quanter, The Smart AI Estimation >, ISMA 2025 (Seoul) Presentation 
Materials
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
20
ㅇ
Development of Automation Tools for AI Technical Size (SNAP) 
Measurement
–
Automation Tool Development: Explore tools that apply Natural 
Language Processing (NLP) technology to automatically extract 
Technical Size scores (SNAP) from AI requirements documents
–
Leveraging the characteristics of AI projects with clear technical 
patterns such as RAG pipelines (preprocessing, embedding, 
vector DB, etc.), focus on developing algorithms that 
automatically identify non-functional technical elements and 
convert them into SNAP scores
–
Secure an automation engine that calculates Technical Size based 
on data pipeline complexity and the volume/type of input data, 
rather than simple Lines of Code (LOC)
ㅇ
Establishing a Data-Driven Intelligent Estimation Ecosystem
–
Virtuous Cycle of Data Accumulation and Automation: Anonymize 
the size and cost data of AI projects collected through 
automation tools, accumulate them in a central database 
(tentatively named AI Project Data Bank), and establish a 
virtuous cycle structure that utilizes this data to improve the 
prediction accuracy of automation tools
–
Productivity Innovation: Transition to an intelligent estimation 
system where 'AI estimates AI project costs,' enabling 
measurement experts to move away from simple repetitive 
estimation tasks and focus on high-value-added work such as 
project value assessment and risk management
□
Accumulating performance data of AI project
ㅇ
Necessity of Data Accumulation: Connecting Size to Budget
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
21
–
(Lack of Empirical Data) Current AI projects suffer from 
insufficient historical reference data, limiting proper unit size 
estimation; empirical data is needed to demonstrate the 
relationship between 'measured size (SP)' and 'actual effort/cost' 
from completed projects
ㅇ
Benchmarking Case: International Software Benchmarking Standards 
Group (ISBSG) Model
–
(Reference Case for Data-Based Size Estimation) ISBSG is a 
non-profit organization that collects and analyzes development 
and maintenance data from IT projects worldwide, providing it to 
the industry as a best practice model for objective size 
estimation
–
(Participation Incentives) By providing free benchmarking reports 
and purchase discounts to companies that submit data, a virtuous 
cycle ecosystem for voluntary data contribution has been 
established
[Figure 9] isbsg.org homepage promoting incentives for submitting project size 
and budget data
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
22
ㅇ
Implementation Plan
–
Data collection referencing the ISBSG model to immediately 
reflect rapidly changing market conditions
–
Deriving appropriate budget ranges (Price per SP) based on data
□
Fostering the AI Engineering Corporate Ecosystem
ㅇ
Expanding Industry Focus from SW Development to 'AI Service 
Engineering'
–
(Value Chain Transformation) As the core added value of AI 
projects shifts from functional implementation (UI/UX) to 
non-functional technical engineering areas such as data 
preprocessing, vector optimization, and LLM architecture design, 
there is a need to expand the industry's focus toward 'AI 
Engineering'
–
(Cultivating Specialized Companies) Identifying and nurturing「AI 
Data/Technology Engineering Specialized Companies」possessing 
advanced technical capabilities in areas difficult to compensate 
through Function Points (FP), such as data pipeline construction, 
embedding model tuning, and vector store optimization
ㅇ
Establishing a Fair Compensation System Based on Technical Size
–
(Recognizing Value of Technical Requirement) By quantitatively 
acknowledging invisible back-end technical effort and providing 
appropriate compensation, a fair ecosystem is created where 
technically capable SMEs and startups can generate legitimate 
revenue
–
(Resolving Low-Price Bidding Competition) Transitioning from 
wasteful competition focused on manpower deployment to a 
'technical value'-centered competitive structure that addresses 
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
23
technical difficulty and complexity, thereby inducing qualitative 
growth in AI projects
ㅇ
Developing AI Size Estimation Experts
–
(Cultivating Convergent Talent) Establishing a new training 
program for「AI Cost Engineers」who understand AI technology 
structures (RAG, fine-tuning, etc.) and can apply them to size 
estimation models such as SNAP, thereby creating a trusted 
communication channel between project owners and contractors
ㅇ
Establishing a virtuous cycle structure for sustainable growth
–
Incentives for reinvestment: Completing the industry's virtuous 
cycle of 'revenue-investment-quality improvement' where profits 
secured through fair compensation lead to corporate R&D 
investment and recruitment of talented personnel, which in turn 
results in the development of high-quality AI services
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
24
[Appendix 1] SNAP Category Descriptions
ㅇ
The SNAP Framework is used to satisfy non-functional 
requirements (NFR) It consists of four major categories (areas) that 
classify components, processes, or activities
Category
Sub-category
Name
Description
Name
Description
1. Data 
Operations
Measures the 
complexity of internal 
data processing tasks 
performed to meet 
quality requirements 
such as data accuracy, 
consistency, and 
integrity. This includes 
complex data validation 
logic, extensive 
logical/mathematical 
operations, and internal 
data movement between 
partitions. 
1.1 Data 
Entry 
Validation
Measures complex data validation and 
error handling logic to meet quality 
requirements such as data accuracy, 
consistency, and integrity.
1 1.2 Logical 
and 
Mathematical 
Operations
Measures the complexity of mathematical 
operations that go beyond simple 
calculations and include extensive logical 
decisions or complex algorithms. (e.g., 
complex interest calculations for financial 
products, critical path analysis for project 
schedules)
1.3 Data 
Formatting
Measures the complexity of data 
structure or format changes for 
non-functional purposes rather than 
functional purposes. (e.g., data 
encryption/decryption, compliance with 
standardized message formats)
1.4 Internal 
Data 
Movement
Measures the complexity of moving and 
processing data between different 
components (partitions) within an 
application (primarily related to 
performance and architecture 
requirements).
 1.5 Delivering 
User Value 
Through Data 
Measures the size of activities that add 
new functionality or business value 
solely by modifying reference data or 
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
25
Category
Sub-category
Name
Description
Name
Description
Configuration
configuration files without code changes.
2.Interface 
Design
Measures the 
complexity of design 
and interaction elements 
where users interact 
with the software. This 
area includes 
adding/changing user 
interface elements for 
Usability and 
Accessibility 
improvements, providing 
help functions, and 
supporting multiple 
input/output methods 
(e.g., web, barcode, 
smartphone). 
2.1 User 
Interface
Measures the complexity of 
adding/changing attributes or appearance 
of screen elements (UI Elements) for 
quality requirements such as Usability, 
learnability, and accessibility.
2.2 Help 
Methods
Measures the complexity of Help Objects 
(e.g., tooltips, pop-up help, manuals) 
that provide users with software usage 
instructions or supplementary information.
2.3 Multiple 
Input 
Methods
Measures the complexity of work that 
supports multiple input media or 
technologies (e.g., keyboard, smartphone, 
barcode reader) while performing the 
same function.
2.4 Multiple 
Output 
Methods
Measures the complexity of work that 
supports multiple output media or 
technologies (e.g., print, PDF, SMS) 
while performing the same function.
3.Technical 
Environme
nt
Measures complexity 
related to the technical 
foundation for software 
3.1 Multiple 
Platforms
Measures the complexity of supporting 
operation across two or more different 
environments (e.g., different operating 
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
26
Category
Sub-category
Name
Description
Name
Description
operation. This includes 
measuring the size of 
multiple platform 
support (e.g., multiple 
operating systems or 
browsers), database 
technology (e.g., adding 
indexes for performance 
improvement), and 
internal batch processes 
(user-identifiable batch 
jobs without external 
input/output). 
systems, different programming language 
families, different browsers).
3.2 Database 
Technology
For non-functional requirements such as 
performance improvement or data 
integrity, the database structure itself 
measures the size of changes made (e.g., 
adding indexes, creating views, query 
tuning).
3.3 Batch 
Processes
Measures the size of user-identifiable 
batch jobs that execute within the 
application, which cannot be measured by 
Function Points (FP) due to the absence 
of external inputs/outputs.
4. 
Architectur
e
Measures the structural 
complexity of the 
system. This includes 
the utilization or 
4.1 
Component-
Based 
Software
Measures the complexity of building or 
utilizing components to enhance 
reusability or to integrate through 
standard interfaces.
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
27
 * Source: IFPUG (2017)
Category
Sub-category
Name
Description
Name
Description
construction of reusable 
software components, as 
well as work to 
replicate/add identical 
interfaces for 
performance or capacity 
expansion without 
functional changes. 
4.2 Multiple 
Input/Output 
Interfaces
For capacity expansion or performance 
improvement without functional changes, 
replicating or adding existing input/output 
interfaces measures the size of work 
(e.g., through additional servers interface 
replication)
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
28
[Appendix 2] SNAP Detailed Sub-category Measurement Table
ㅇ
The SNAP framework measures the size of software 
Non-Functional Requirements (NFR), using 4 Categories and 15 
Sub-categories
Category
Sub-category
SNAP 
Counting Unit
Complexity Parameters
SNAP Points 
Calculation Formula
1. Data 
Operation
s
1.1 Data 
Entry 
Validations
Elementary 
Process
1. Complexity of Nesting 
Level
2. Number of unique DETs 
used in all validations
Complexity (Low: 2, 
Average: 3, High: 4) 
× Number of DETs
1.2 Logical 
and 
Mathematical 
Operations
Elementary 
Process
1. FTR Density (0-3, 
4-9, 10+ FTRs)
2. Process Logic Type 
(Logical/Mathematical)
3. Number of DETs
Constant varies by 
FTR density and 
elementary process 
type (3, 4, 6, 7, 10) 
× Number of DETs
1.3 Data 
Formatting
Elementary 
Process
1. Conversion Complexity 
(Low: Simple conversion, 
Average: 
Encryption/Decryption using 
API, High: Local 
encryption/decryption)
2. Number of DETs 
converted
Complexity (Low: 2, 
Average: 3, High: 5) 
× Number of DETs
1.4 Internal 
Data 
Movement
Portion of 
elementary 
process that 
crosses 
boundaries 
between 
partitions
1. Number of unique DETs 
transferred between 
partitions and 
processed/maintained 
2. Number of unique FTRs 
read or updated by the 
elementary process in both 
crossing partitions
FTR Complexity 
(Low: 4, Average: 6, 
High: 10) × Number 
of DETs (calculated 
for each partition 
crossing)
1.5 Providing 
User Value 
through Data 
Organization
Elementary 
Process per 
logical file
1. Number of unique 
attributes related to the 
elementary process
2. Number of records 
organized (Low: 1-10, 
Average: 11-29, High: 
30+)
Record Complexity 
(Low: 6, Average: 8, 
High: 12) × Number 
of unique attributes
2. 
Interface 
Design
2.1 User 
Interface
Set of 
screens 
defined as 
elementary 
process
1. Sum of unique attributes 
configured for each UI 
element in SCU (Low: 
<10, Average: 10-15, 
High: 16+)
2. Number of unique UI 
elements affected
UI Complexity (Low: 
2, Average: 3, High: 
4) × Number of 
Unique UI Elements
2.2 Help 
Method
Help Objects
Whether screenshots are 
included in help items
No Screenshots: 
(Number of Help 
Objects / 16). With 
Screenshots: (Number 
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
29
Source: IFPUG (2017)
Category
Sub-category
SNAP 
Counting Unit
Complexity Parameters
SNAP Points 
Calculation Formula
of Help Objects / 16) 
+ 2
2.3 Multiple 
Input Methods
Elementary 
Process
1. Number of DETs in SCU 
(Low: 1-4, Average: 
5-15, High: 16+)
2. Number of Additional 
Input Methods.
DET Complexity 
(Low: 3, Average: 4, 
High: 6) × Number of 
Additional Input 
Methods
2.4 Multiple 
Output 
Methods
Elementary 
Process
1. Number of DETs in SCU 
(Low: 1-5, Average: 
6-19, High: 20+)
2. Number of Additional 
Output Methods.
DET Complexity 
(Low: 3, Average: 4, 
High: 6) × Number of 
Additional Output 
Methods
3. 
Technical 
Environm
ent
3.1 Multiple 
Platforms
Elementary 
Process
1. Characteristics of 
Platform (Software, 
Hardware). 2. Number of 
Platforms Required to 
Operate On.
Sum of Constant 
Factors Determined by 
Platform Category and 
Number of Platforms 
(e.g., Category 
1-Software: 2 
Platforms = 20 SP)
3.2 Database 
Technology
Elementary 
Process
1. FTR Complexity (based 
on DETs and RETs)
2. Number of 
Database-related Changes
FTR Complexity 
(Low: 6, Average: 9, 
High: 12) × Number 
of Changes
3.3 Batch 
Process
User-identifie
d Batch Job
1. Number of DETs 
Processed in the Job
2. Number of FTRs Read 
or Updated in the Job 
(Low: 1-3, Average: 4-9, 
High: 10+)
FTR Complexity 
(Low: 4, Average: 6, 
High: 10) × Number 
of DETs
4. 
Architect
ure
4.1 
Component-b
ased Software
Elementary 
Process
1. Component Type 
(Internal Reuse/Third-party 
Component)
2. Number of Unique 
Components Related to the 
Elementary Process
Component Type 
(Internal: 3, 
Third-party: 4) × 
Number of Unique 
Components
4.2 Multiple 
Input/Output 
Interfaces
Elementary 
Process
1. Number of DETs in the 
SCU (Low: 1-5, Average: 
6-19, High: 20+)
2. Number of Additional 
Input/Output Interfaces
DET Complexity 
(Low: 3, Average: 4, 
High: 6) × # 
Additional Interfaces 
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
30
References
1. Domestic References
■
AWS Korea (2024), 'RAG Architecture – From Concept to Implementation'
  - https://www.youtube.com/watch?v=zI7rin2S_Ak&t=651s
■
SPRi (2024a), Analysis of the Impact of Generative AI on Software Developer 
Tasks
■
SPRi (2024b), From AI Infrastructure to AI Services - Exploring AI Adoption 
Models and New Service Models for SW Companies
2. International References
■
IFPUG(2017), ‘Software Non-functional Assessment Process(SNAP)’, Release 2.4
■
GetGenie(2024), ‘AI Native in Action’
SPRi Issue Report IS-217                                        An AI Project Size Estimation Framework 
[Software Policy & Research Institute]Created by [SPRI Report]is available under the Korea Open 
Government License Type 4(Attribution-NonCommercial-NoDerivatives)terms of use.
Notice
This report is a research report conducted by the Software Policy & Research 
Institute. 
When presenting the contents of this report,
it must be clearly stated that this is research conducted by the Software Policy & 
Research Institute.
An AI Project Size Estimation Framework
      - The Hidden Iceberg: Measuring Technical Scope - 
22, Daewangpangyo-ro 712beon-gil, Bundang-gu, Seongnam-si, Gyeonggi-do, Global R&D Research Building 
(B) 4th Floor
Global R&D Center 4F 22 Daewangpangyo-ro 712beon-gil, Bundang-gu, Seongnam-si, Gyeonggi-do 
www.spri.kr