수소 기술 전과정평가 계산 모듈 요구사항 정의 및 분석

Ⅰ. 서 론

환경 문제로 인해 저탄소 발전, 친환경 에너지 사용의 필요성이 대두되고 있다. 지속가능한 사회를 위해서는 신재생 에너지 활용, 온실가스 포집 등의 노력이 동반된다. 바이오매스 등의 여러 친환경 에너지원 중 수소 에너지는 반응물로 H₂O가 배출되는 청정 에너지원이라고 할 수 있다. 따라서 수소 기술의 발전은 친환경 사회를 달성하기 위한 가장 청정한 방향이라고 할 수 있다[1]. 하지만 수소를 생산하는 과정에서도 이산화탄소 배출에 따라 그린 수소, 그레이 수소, 블루 수소 등으로 구분되며 생산 단계에서도 기술에 따라 환경 영향력이 달라진다[2]. 따라서 객관적인 기술의 평가를 위해서는 정확한 기준을 갖는 평가 방법이 필요하다.

수소 기술을 포함하여 친환경 발전을 위한 다양한 기술들의 환경적인 영향을 평가하기 위해서는 국제표준에 따른 체계적인 분석이 필요하다[3]. 이러한 국제표준으로는 국제표준화기구(ISO, International Organization for Standardization)가 제정한 국제표준이 대표적이다. 이 중 ISO14000 시리즈는 환경 경영과 관련된 국제표준을 제시하고 있다.

ISO14000 시리즈는 환경 경영 시스템, 환경 관리 시스템 등 조직 운영이 환경에 부정적인 영향을 미치는 방식을 최소화하기 위해 정의된 국제표준이다. 이 중 ISO14040과 ISO14044는 전과정평가(LCA, Live Cycle Assessment)에 대해 국제표준을 정의한다. ISO14040은 전과정평가의 원칙과 프레임워크를 제시하고, ISO14044는 전과정평가의 구체적인 절차와 방법을 정의하고 있다.

수소 기술 도입을 통한 환경 영향 분석을 위해서는 국제표준기구에서 정의한 체계적인 방법론을 따라 생애 전 주기에 걸친 분석을 통해 현재의 기술, 또는 다른 대체 기술과의 비교 분석이 필요하다. 또한 수소의 생산, 운송, 활용에 이용되는 다양한 기술이 존재하는데, 각 기술 사이의 환경 영향력을 비교하여 전과정평가를 통해 수소 기술의 효과적인 도입을 위한 최적의 공정 구성을 정의하는 데에 활용할 수 있다[4].

A. Valente는 90여 개의 수소 생산 시스템의 전과정평가 결과 비교 분석을 위해 문헌에서 수집한 500여 개의 사례 연구를 비교했다. 조사한 사례를 열화학적 생산, 전기화학적 생산, 생물학적 생산으로 분류하고, 각 생산 방법에서 가장 많이 분석된 공정을 정리하여 수소 생산 공정 연구 현황을 파악할 수 있다. 또한 각 공정의 전과정평가 결과를 정리함으로써 수소 생산 기술의 방법론 선택에 따른 환경 성능을 분석하였다. 하지만 전과정평가의 방법론 선정의 차이로 인해 결과 해석이 달라질 수 있음을 명시하고 있다[5]. 수소 에너지가 주목받고, 생산 기술, 활용 기술들이 발전하고 있음에도 이의 환경적 영향 평가를 위한 LCA의 방법론이 확립되어있지 않으며, ISO14044에서 정의된 요구사항도 목표 및 정의, 데이터 수집 및 품질, 영향 평가, 보고서 작성 등에 대해 정의되어 있지만, 계산 과정에 대해서는 정의되어 있지 않다.

이러한 배경하에 국제표준 가이드를 기반으로 하는 수소 기술의 전과정평가를 위해 전과정목록 분석과 전과정영향평가 계산 모듈을 개발하고자 한다. 이를 위해서는 계산 모듈 개발을 위한 요구사항 조사와 정의가 선행되어야 한다.

요구사항의 조사는 대부분 인터뷰, 워크숍, 설문 조사 등을 통해 실시되고, 이 과정에서 요구사항은 이해관계자와의 대화, 토론, 질의응답의 형태를 통해 조사된다. 이러한 조사 과정을 통한 요구사항 정의에는 자연어 형태로의 정의가 불가피하다. 하지만 자연어로 정의된 요구사항은 불명확한 표현으로 인한 오해를 유발하거나 중의적인 표현으로 인한 다양한 해석이 가능하여 정상적인 기능 개발을 방해하는 요소가 된다[6].

불명확한 요구사항을 구체화하지 않고 시스템을 개발하는 경우 서비스 단계에서 큰 문제를 유발할 수 있다. 2013년 미국의 건강보험 개혁법에 따라 만들어진 건강보험 마켓플레이스인 healthcare.gov를 론칭하였으나, 초기부터 기술적 문제와 성능 저하로 인해 심각한 문제를 겪었다. 당시 분석된 프로젝트 실패의 주요 원인은 1. 모호한 요구사항 정의, 2. 부실한 프로젝트 관리, 3. 시간 압박으로 정리된다. 위 사건은 IT 분야에서 명확한 요구사항 정의의 중요성을 잘 보여주는 대표적인 사례이다[7].

본 연구에서는 수소의 생산, 운송, 저장 및 활용에 걸친 수소 가치 사슬에 대한 전과정평가 계산 모듈 개발을 위한 요구사항을 정의 및 분석하였다. 이를 위해 여러 분야의 이해관계자를 대상으로 기능 및 비기능 요구사항에 대한 조사를 통해 자연어 기반으로 요구사항을 정의하였고 이 과정에서 적용된 자연어 기반의 요구사항이 초래하는 문제상황을 극복하기 위해 유스케이스 등의 텍스트 아티팩트를 함께 활용함으로써 요구사항을 구체화하였다.

Ⅱ. 요구사항 조사 방법

요구사항 조사는 ①관련 문헌 조사와 ②이해관계자 조사의 두 가지 방식을 통해 수행되었다. 먼저 관련 문헌을 분석하여 계산 모듈의 일반적인 요구사항을 결정하였다. 전과정평가 대상 기술은 수소 기술이므로 이에 해당하는 이해관계자를 정의하고 인터뷰와 워크숍을 실시하였다.

관련 문헌 조사를 통해 전과정평가 절차와 계산 모듈의 필수적인 기능과 개선 방안 등을 분석하였다. 이를 통해 대상 수소 기술의 공정 흐름 정의와 이에 따른 계산 수행 전반에 관련된 요구사항을 도출하였다.

또한 수소 기술 분야와 전과정평가 분야의 이해관계자를 정의하고 이들을 대상으로 인터뷰와 워크숍, 설문 조사 등을 실시하였다. 전과정평가 분야에는 전과정평가 실시와 전과정목록 구축을 구분하여 이해관계자를 정의하였다.

이해관계자와의 요구사항 조사 과정에서 수소 기술과 LCA 분야에서 실무적으로 요구되는 사항과 제한조건 등을 구체화하였다.

2.1 관련 문헌 조사

ISO14040에서는 그림 1과 같이 전과정평가의 수행 원칙을 제시하고 있다. 이 두 국제표준은 제품이나 서비스의 전체 생애 주기 과정에서 발생하는 환경적인 영향을 평가하기 위한 가이드라인을 제공한다.

Fig. 1.

Principle for conducting LCA

‘목적 및 범위 정의’ 단계에서는 평가 대상과 평가하고자하는 환경 영향 인자를 정의한다. ‘전과정목록 분석(LCI, Life Cycle Inventory)’ 단계에서는 전과정평가 수행을 위한 투입/산출/수송/유통 등의 데이터를 수집한다. ‘전과정영향평가(LCIA, Life Cycle Impact Assessment)’ 단계에서는 전과정목록 분석의 데이터를 분석하려는 환경 영향 범주에 따라 재가공한다. ‘전과정해석’ 단계에서는 전과정목록 분석과 전과정영향평가 결과를 평가 및 해석함으로써 전과정평가가 이뤄진다.

ISO14044에서는 전과정평가의 구체적인 절차와 방법을 규정하고 있다. 전과정평가의 절차는 그림 1에서 정리한 바와 같이 목표 및 범위 정의, 전과정목록 분석, 전과정영향평가, 전과정해석의 단계로 구성된다.

ISO14044에서는 전과정평가의 절차뿐 아니라 각 절차에 대한 요구사항 또한 규정하고 있다.

1) 목표 및 범위 정의 요구사항

- LCA의 목적과 범위는 명확하게 정의되어야 하며 일관성이 있어야 함

2) 전과정목록 분석(LCI) 요구사항

- 전과정목록 분석의 그림 2의 단계를 따라 수행되어야 함

Fig. 2.

Life Cycle Inventory analysis(LCI) procedure

3) 전과정영향평가(LCIA) 요구사항

- LCIA 수행을 위해 충분한 품질의 계산 가능한 LCI 데이터 요구
- LCIA의 불확실성 고려

4) 전과정해석 요구사항

- LCI 및 LCIA 결과에 따른 이슈를 식별함
- 전과정평가 결론, 한계 및 권장 사항 정리

5) 보고서 작성 요구사항

- 평가 결과, 데이터, 가정 및 제한 사항 등을 밝히며, LCA의 상충 관계를 이해하도록 충분히 자세한 설명을 제시하여야 함

2.2 이해관계자 조사

수소 기술의 전과정평가 계산 모듈 개발을 위해 여러 분야의 이해관계자를 통해 요구사항을 수집하였다. 요구사항 조사를 위한 이해관계자는 표 1과같이 전과정평가 방법론 구축, 전과정목록(LCI) 구축, 전과정평가 플랫폼 개발 등 여러 분야를 대상으로 식별 및 정의하였으며, 이들로부터 인터뷰, 워크숍, 조사 설문을 통해 각 분야의 요구사항을 수집, 정리하였다.

Table 1.

Stakeholder identification

의뢰인 범주와 사용자 범주로부터는 개발하고자 하는 계산 모듈이 필수적으로 갖춰야 하는 기능을, 도메인 전문가 범주로부터는 전과정평가 방법론, LCI DB, 수소 기술 등 각 분야에서 반영이 필요한 기능, 또는 기능 구현을 위한 연계 방안을 정의하였다. 또한 연구 개발자 내부로는 계산 모듈에서 요구되는 구성과 기능 구현을 위한 요구사항을 정의하였다.

특히 최종 목표로 설정한 수소의 생산, 운송, 저장, 활용에 걸친 전 생애 주기에 대한 평가를 고려한 요구사항을 기능과 비기능 요구사항으로 구분하여 수집하였다.

Ⅲ. 요구사항 정의 및 분석

3.1 요구사항 정의 방법

요구사항 정의에는 정형 기법과 비정형 기법이 있으며, 각각의 표현법과 목적에 따라 구분하여 활용한다. 정형 기법은 수학적 기호와 정형화된 표기법을 사용함으로써 요구사항을 정확하고 간결한 표현이 가능하지만, 표기법이 어려워 사용자가 이해하기 어려운 단점이 있다. 비정형 기법은 자연어를 기반으로 서술하거나 다이어그램으로 작성하기 때문에, 내용의 이해가 쉬워 의사소통이 수월하지만, 요구사항의 해석 결과가 달라질 수 있다[8].

그림 3은 정형 기법 중 VDM(Vienna Development Method)의 예시를 나타내고 있으며, 앞서 명시된 특징을 뚜렷이 보여준다[9]. 예시는 일반적인 플랫폼에서의 사용자 로그인 과정에 대한 요구사항을 명세하고 있으며, 표현된 VDM의 요구 내용은 다음과 같다.

• 1. 로그인 페이지에는 두 개의 텍스트 상자에 사용자 ID와 비밀번호를 입력하라는 메시지 표출
• 2. 제출 버튼을 누르면 지정된 값이 인증
• 3. 유효한 인증을 위한 환영 메시지와 함께 홈페이지 표시
• 4. 인증이 유효하지 않은 경우, 사용자 ID와 비밀번호를 다시 입력하라는 오류 메시지와 함께 로그인 페이지가 표시

Fig. 3.

Formal specification technique (VDM)

그림 3에서 살펴본 바와 같이, 정형 명세 기법은 비전문가가 요구사항을 파악하기에는 어려움이 있다. 이에 본 연구에서 요구사항 정의 기법은 수소의 전과정평가 계산 모듈 개발에 있어서, 여러 분야 이해관계자 사이의 원활한 의사소통이 요구되기 때문에 비정형 기법을 활용하였다.

이 과정에서 자연어 표현으로 인해 유발될 수 있는 요구사항의 불명확성과 요구사항의 상호 충돌 등의 혼란을 피하고자 다른 형태의 텍스트 아티팩트(Textual artifacts)를 활용하였다.

X. Franch et al.[10]은 여러 기업의 실무자 대상의 설문 조사를 통한 경험적 연구 결과, 자연어는 유연성과 보편성 등의 이유로 가장 많이 사용되지만, 요구사항 정의 과정에서 여러 문제를 야기하는 것으로 확인하였다. 이를 극복하기 위해 다른 형태의 텍스트 아티팩트를 함께 활용하는 것이 효과적임을 조사하였다. 이를 통해 자연어만으로의 표현이 불러올 수 있는 문제를 보완할 수 있다.

텍스트 아티팩트에는 유저 시나리오(User scenario), 유스 케이스(Use case), 유저 스토리(User story), 와이어프레임(Wireframe), 유저 플로우(User flow) 등이 있다. 표 2은 각각의 정의와 특징을 나타낸다.

Table 2.

Types and characteristics of textual artifacts

표 2에서 정리한 텍스트 아티팩트 중 유스케이스는 복잡한 서비스의 요구사항을 정의할 때 유용하다. 유스케이스의 예시를 통해 이의 구조와 기능을 파악하고 전과정평가 계산 모듈 요구사항 정의에 적용하고자 한다.

유스케이스의 예시로 그림 4는 간단한 전화 시스템을 나타낸다[11]. 발신자가 지역 전화 또는 장거리 전화를 통해 수신자에게 전화를 걸고, 청구 시스템에서는 고객 청구 정보를 검색할 수 있고, 고객은 통화 내역을 조회할 수 있다. 예시에서 확인할 수 있는 바와 같이 유스케이스는 시스템 자체에 대한 정보가 아닌 시스템의 기능을 요약하여 전달하는 것에 그 목적이 있다.

Fig. 4.

Use case for Telephone system

그림 4에서 나타나는 것과 같이 유스케이스는 시스템의 기능을 요약, 전달하며 표 2에 정리된 특징과 같이 복잡한 요구사항 정의에 적합하다. 이에, 유스케이스를 활용하여 수소 기술 전과정평가 계산 모듈 요구사항 구체화를 실시하였다.

3.2 요구사항 구체화

이해관계자와의 인터뷰 및 워크숍 등을 통해 정의한 요구사항은 자연어 형태로 정의되기 때문에 명확한 의미 전달이 어렵다. 이를 극복하기 위해 2.2 요구사항 정의 방법에 기술한 바와 같이 유스케이스 형태의 텍스트 아티팩트를 함께 활용하여 요구사항을 구체화하였다.

그림 5는 주요 기능 요구사항 중 ‘수소 기술의 단계별 모델링’의 유스케이스를 나타낸다. 사용자(액터)가 공정 흐름 정의(유스케이스 명)를 진행하기 위해서는 수소 생산 공정 정의가 먼저 이뤄져야 한다. 이를 위해서는 전과정목록(LCI)으로부터 투입물/산출물과 기준물질이 정의되어야 한다. 또한 환경적 영향 평가를 위해 해당하는 지표를 관련 DB로부터 불러온다. 위 과정을 거쳐 수소 생산 공정을 정의하면 수소 수송 단계에 대해 정의가 가능하다. 수소의 수송에는 수송 수단과 수송 거리에 대한 정의가 필요하다.

Fig. 5.

Use case for requirement of process flow configuration

그림 5와 같은 유스케이스를 통한 요구사항 구체화를 실시함으로써, 단순히 ‘수소 생산 단계 모델링’의 요구사항이 ‘전과정목록 DB를 통해 수소 생산 공정 선택에 따른 투입물/산출물 및 기준물질 정의’, ‘단위 공정의 환경 영향 지표(DB 구축)에 따른 환경영향분석 실시’로 구체화 된 것과 같이 보다 명확한 요구사항의 정의가 가능하였다.

표 3은 그림 5의 유스케이스를 통해 구체화 된 기능 요구사항 중 생애 주기 모델링을 나타낸 것으로, 요구사항 제안자 외 이해관계자의 더욱 명확한 이해가 원활하다.

Table 3.

Functional requirement – Modeling across life cycle stages

표 3의 개선 전 요구사항에서 보이는 것과 같이 자연어로만 기술된 요구사항은 데이터가 어떤 조건에서 측정되고 기록되어야 하는지, 해당 데이터의 포맷이 어떻게 관리되어야 하는지에 대한 세부 사항이 불명확하다. 이러한 문제를 극복하기 위해 비정형 기법을 사용하여 투입물과 산출물 데이터가 각 프로세스 단계에서 어떻게 수집되고, 어떤 기준으로 분석되는지 명확하게 정의할 수 있다. 이를 통해 데이터에 대한 요구사항을 구체적으로 명시함으로써 모호성을 크게 줄였다.

이러한 요구사항 구체화 과정을 거치면서 개념적 차원에서 정의된 요구사항이 상세한 정보를 담게 되어 여러 분야의 이해관계자 사이 원활한 의사소통이 가능하도록 개선되었다.

여러 분야의 이해관계자와의 의사소통을 고려하여 비정형 기법을 함께 활용함으로써 1. 시간 절감;, 2. 데이터 관리 시스템 개선; 등의 측면에서 효과를 보였다.

기존 방식에서는 요구사항 해석에 대한 논의와 수정 작업이 여러 차례 반복되었으나, 비정형 기법을 도입한 후 이러한 수정 빈도를 약 20% 줄일 수 있었다. 이는 요구사항의 명확성이 높아짐에 따라 개발 과정에서 발생하는 의사소통 오류가 감소한 결과이다.

또한 비정형 기법을 통해 수소 생산 공정 등의 데이터 관리 모듈에서 요구되는 성능과 기능에 대한 요구사항을 세부적으로 정의함으로써, 모듈 개발과정에서의 불필요한 기능의 추가 / 삭제 과정이 줄어들었다.

기존의 자연어 기반 요구사항 정의 방법과 비교하여 본 연구에서 제안한 요구사항 정의 과정은 높은 명확성과 효율성의 특장점을 갖는다.

기존 자연어 기반의 요구사항 정의에는 요구사항의 모호함으로 인해 해석의 차이가 발생할 수 있는데 반해 본 연구에서 제안한 방법을 통한 요구사항 정의는 시각적인 요구사항의 표현하여 명확성을 향상시킬 수 있다. 이로 인해 기존의 자연어 요구사항 정의는 수정 및 재정의가 빈번하여 시간과 비용이 증가하지만, 제안 방법에 의한 요구사항을 통해 요구사항 상호 충돌 및 수정 빈도가 감소하여 시간 비용 절감 효과를 갖는다.

하지만 기존 요구사항 정의 방법에 비해 초기 비용과 시간이 증가하고 텍스트 아티팩트 형태로 재구성하기 위한 소프트웨어나 요구사항 관리 도구의 기술적 지원이 요구되는 한계를 갖는다.

3.3 요구사항 분석 결과

2.1 요구사항 조사 방법에 기술한 바와 같이 ① 관련 문헌 조사, ② 이해관계자 인터뷰 및 조사 설문을 바탕으로 기능 및 비기능 요구사항을 정의하고 분석하였다.

기능 요구사항은 수소 기술 생애 주기에 따른 전과정평가를 위한 사항과 결과물 형식에 관한 내용이 주를 이룬다. 비기능 요구사항은 계산 모듈의 성능과 유지보수를 위한 내용이 주요 내용이다.

① 관련 문헌 조사로부터는 ‘환경적 영향 평가’ 및 ‘결과 시각화 및 보고서 생성’ 요구사항에 대해 정의하였으며, ② 이해관계자 조사로부터는 ‘데이터 입력 및 관리’, ‘생애 주기 단계별 모델링’, ‘결과 시각화’ 등의 기능 요구사항과 비기능 요구사항을 정의하였다.

3.3.1 기능 요구사항

1) 데이터 입력 및 관리

데이터베이스와 연동되어 계산 모듈에 입력되는 데이터의 저장과 처리, 정합성에 대한 요구사항이다. 계산 모듈의 데이터 입출력이 데이터베이스와 플랫폼 서버와의 연계를 통해 이뤄지기 때문에 데이터 입력 형식 및 저장, 정합성 등에 대해 요구사항을 정의하였다.

2) 생애 주기 단계별 모델링

계산 모듈의 범용성을 위해서는 수소 기술의 생애 주기 단계에 따른 가치 사슬의 구성이 가능하여야 한다. 따라서 생산, 운송, 저장, 활용 등의 공정 중 목표 공정을 선택하여 전체 공정을 구성할 수 있어야 한다. 구성하는 수소 가치 사슬의 시스템 경계는 표 4의 유럽 표준인 EN 15804에 따라 모듈 A~D로 표현 가능하도록 정의하였다.

Table 4.

Definition of system boundary in EN 15804

수소 기술의 생애 주기 단계인 1) 수전해, 개질 등의 수소 생산 기술; 2) 운송 수단과 운송 거리; 3) 생산 수소의 저장 수단; 4) 연료전지, 수소 철도, 건물 활용 방식 등에 따른 에너지 소비량, 온실가스 배출량 등을 산출하여 환경적 영향 평가를 수행하기 위한 요구사항을 정의하였다.

3) 환경적 영향 평가

수소 기술의 단계별 환경적 영향을 평가하기 위해 평가 요소와 이에 대한 기준선(Baseline)이 정의되어야 한다.

기술 분야에 따라 환경 영향 범주의 선정은 달리질 수 있으며, 한 예로 건축 분야에서는 지구온난화, 오존층 파괴, 자원 고갈, 산성화, 부영양화, 광화학 산화 등을 평가하기도 한다[12].

수소 기술을 대상으로는 ISO 14040과 ISO 14044를 기준으로 하여 온실가스 배출을 포함한 다양한 환경적 영향 평가를 선정함으로써 계산 모듈의 활용성을 넓히기 위한 요구사항을 정의하였다.

4) 결과 시각화 및 보고서 생성

전과정평가 결과를 보고서 형식으로 정의하기 위해 국제표준의 결과 보고 요구사항 등을 고려하여 정의하였다.

3.3.2 비기능 요구사항

1) 성능

데이터 처리량, 처리 시간과 정상 구동 및 시스템의 안정성 확보 등 전과정평가 계산 수행에 요구되는 성능을 정의하였다. 여기에는 장애 발생 시 복구 시간, 오류 처리 시간, 시스템 다운 방지 방안 등이 포함된다.

2) 호환성

계산 모듈의 반응형 디자인을 통한 화면 규격 맞춤형 UI 구성, 운영체제 및 브라우저의 호환성 등 계산 모듈 구동을 위한 여러 환경 조건에 대하여 요구사항을 정의하였다.

3) 보안

개인정보 보호를 포함하여 서버 및 데이터베이스를 보호하기 위한 방화벽, 로그 기록 및 암호화와 함께 사용자별 접근 권한을 관리하여 기능을 제어함으로써 인적 사고로 인한 내부 보안 방안 등을 정의하였다.

4) 유지보수성

원활한 유지보수를 위해 계산 모듈의 기능을 각 단위 기능으로 구분하여 모듈화된 설계를 적용하는 등의 요구사항을 사전에 정의하여 반영하고자 한다.

Ⅳ. 결론 및 향후 연구

본 연구에서는 수소 기술의 객관적 평가를 위해 국제 표준인 ISO 14040과 ISO 14044로부터 전과정평가 계산 모듈 개발을 위한 요구사항을 분석하였다.

먼저, 수소 기술을 대상으로 수소의 생산, 운송, 저장, 활용 단계에 따라 전과정평가 계산 모듈의 요구사항을 정의 및 분석하였다.

이 과정에서 자연어 기반의 불명확성을 극복하기 위해 요구사항 정의에는 비정형 기법을 활용하였다. 이를 적용함으로써 다양한 분야의 이해관계자와의 원활한 의사결정을 가능하게 함과 동시에 비교적 명확한 요구사항의 정의가 가능하다.

여러 비정형 기법 중 목적에 따라 유스케이스를 적용하여 수소 기술의 단계별 모델링 요구사항을 구체적으로 정의하였다. 초기 최종 목적만을 기술한 요구사항에서 이를 구현하기 위한 과정을 상세히 정의한 요구사항으로 정의하였다.

이와 같이 유스케이스를 통해 구체화된 요구사항은 수소 기술의 특정한 단계뿐 아니라, 생산부터 활용에 이르는 전체 공정 흐름에 대한 환경영향평가 계산 모듈 개발에 유용하게 적용 가능하다.

요구사항 정의 단계에서 비정형 기법을 도입하는 것은 기존 자연어 기반 요구사항 정의 방식에 비해 명확성, 효율성, 적용 등의 측면에서 뛰어난 장점을 보여주었지만, 초기 비용 및 시간의 증가와 복잡한 시스템에 적용할 때의 부담이 한계로 작용할 수 있다. 이러한 제한점은 도구의 자동화 및 사용성 개선을 통해 해결 가능하며 향후 연구에서는 이를 보완할 방안을 추가적으로 제시할 예정이다.

또한 본 논문에서는 목표 기술에 대한 요구사항의 정의와 구체화 과정에 집중하였다. 향후 연구에서는 랜덤 포레스트와 딥 뉴럴 네트워크 등의 머신 러닝 알고리즘을 통해 요구사항의 변화와 시스템 사이의 상호작용 실시간 분석 및 평가를 통한 요구사항 검증 시스템에 관한 연구를 진행하고자 한다.

Acknowledgments

본 연구는 국토교통부/국토교통과학기술진흥원의 지원으로 수행되었음 (RS-2024-00417444)

References

• Qcells Column, https://qcells.com/kr/blog/blog-detail?blogId=BLG231221155334013, [accessed: Aug. 20, 2024]
• E. Cetinkaya, I. Dincer, and G. F. Naterer, "Life cycle assessment of various hydrogen production methods", International Journal of Hydrogen Energy, Vol. 37, No. 3, pp. 2071-2080, Feb. 2021. [https://doi.org/10.1016/j.ijhydene/2011.10.064]
• S. J. Jang, D. W. Jung, J. Y. Kim, and Y. W. Hwang, "An Evaluation of Net-zero Contribution by Introducing Clean Hydrogen Production Using Life Cycle Assessment", Journal of Hydrogen and New Energy, Vol. 35, No. 2, pp. 175-184, Apr. 2024. [https://doi.org/10.7316/JHNE.2024.35.2.175]
• L. M. Luz, A. C. Francisco, C. M. Piekarski, and R. Salvador, "Integrating life cycle assessment in the product development process: A methodological approach", Journal of Cleaner Production, Vol. 193, pp. 28-42, May 2018. [https://doi.org/10.1016/j.jclepro.2018.05.022]
• A. Valente, D. Iribarren, and J. Dufour, "Life cycle assessment of hydrogen energy systems: a review of methodological choices", Ther International Journal of Life Cycle Assessment, Vol. 22, pp. 346-363, Jun. 2017. [https://doi.org/10.1007/s11367-016-1156-z]
• K. Ryan, "The Role of Natural Language in Requirements Engineering", Proceedings of the IEEE International Symposium on Requirements Engineering, San Diego, CA, USA, Jan. 1993. [https://doi.org/10.1109/isre.1993.324852]
• L. Thompson, "HealthCare.gov Diagnosis: The Government Broke Every Rule Of Project Management", Forbes Magazine, Dec. 2013.
• N. Ali and R. Lai, "A method of software requirements specification and validation for global software development", Requirements Engineering, Vol. 22, pp. 191-214, Nov. 2015. [https://doi.org/10.1007/s00766-015-0240-4]
• S. Sengupta and R. Dasgupta, "Integration of Functional and Interface Requirements of an Web based Software: A VDM based Formal Approach", Proceedings of IASTED International Conference on Software Engineering, Vol. 10, pp. 2013-796, Feb. 2013. [https://doi.org/10.2316/P.2013.796-017]
• X. Franch, C. Palomares, C. Quer, P. Chatzipetrou, and T. Gorschek, "The state-of-practice in requirements specification: an extended interview study at 12 companies", Requirements Engineering, Vol. 28, pp: 377-409, Apr. 2023. [https://doi.org/10.1007/s00766-023-00399-7]
• K. Bittner, and I. Spence, "Use case modeling", Addison-Wesly Professional, pp. 3-18, 2023.
• T. H. Hong, C. Y. Ji, and K. B. Jeong, "Environmental Impact Assessment of Buildings based on Life CCycle Assessment(LCA) Methodology", Korean Journal of Construction Engineering and Management, Vol. 13, No. 5, pp. 84-93, Sep. 2012. [https://doi.org/10.6106/KJCEM.2012.13.5.084]