스마트팩토리 프로젝트에서의 요구사항 분석

본 글은 글쓴이가 수행하는 프로젝트들에 요구사항 분석을 적용하기 위해 개인의 생각을 정리한 글입니다.

궁금증이나 의견이 있으신분들은 자유롭게 댓글로 말씀해주시기바랍니다.

0. 요구사항 분석이 왜 필요한가?

서로 다른 도메인을 가진 사람들이 만나서 협업한다는 것은 의사소통에서부터 mismatch가 발생하기 쉽다.

실제 해당 도메인에서 암묵적으로 가정하고 들어가는 배경지식이 있다면, 타 도메인의 사람에게는 전달 되지 않을것이다.

반대로 내가 생각하던 상대 도메인의 정보들이 정확한 내용이 아닐 수도 있다.

 

즉, 도메인 전문가(현업 등)와 IT전문가(데이터사이언티스트 등)가 하나의 프로젝트를 수행하는데 있어서,

도메인/IT 양 측면의 관점에서 해결하고자 하는 문제의 현상과 원인 그리고 해결이 되었을 때의 결과를 명확히 정의하고,

그 과정에서의 기능적 방법들을 검토하기 위한 목적으로 요구사항 분석을 진행하게 된다.

 

1. 요구사항이란?

요구사항에대한 기본적인 정의는 정보처리기사의 내용을 차용하였다.

1.1 요구사항의 개념 및 특징

소프트웨어(ML모델이)가 어떤 문제를 해결하기 위해 제공하는 서비스(예측결과 등)에 대한 설명과 정상적으로 운영되는데 필요한 제약조건.

소프트웨어 개발 및 유지보수 가정에서 필요한 기준과 근거 제공.

개발에 참여하는 이해관계자들 간의 의사소통을 원활하게 하는데 도움을 준다.

 

1.2 요구사항의 유형

1.2.1 기능 기반

기능 요구사항(Funcional Requirements)

시스템이 반드시 수행해야하는 기능 : 장비구성, 성능, 인터페이스, 데이터

비기능 요구사항(Non-Fincional Requirements)

보안, 품질, 제약사항

1.2.2  관점 기반

시스템 요구사항(System Requirements)

사용자가 시스템으로 부터 제공받고 싶은 요구

사용자 요구사항(User Requirements)

시스템이 사용자나 다른 시스템에게 제공해야할 요구사항

소프트웨어 요구사항이라고도 함

 

2. 스마트팩토리에서의 요구사항 분석

스마트팩토리에서의 요구사항 분석이라고 작성하였지만,

글쓴이가 현업 프로젝트에서 사용하려고 생각중인 절차로 정답이 아닌 의견임을 다시한번 말한다.

 

해당 글에서는 각 현업부서에서 발생한(또는 발생하왔거나 발생할 것으로 예상되는) 문제를 프로젝트 주제로 선정하였음을 가정으로 한다.

 

2.1 해결하고자 하는 문제  확인

현업에서 가져온 문제에 대해서 상세히 파악하는 단계이다.

"XX의 결함 판단하기"라는 주제로 가정했을 때 아래와 같은 질문을 던져볼 수 있다.

• 결함/정상의 명확한 정의
• 결함~정상간의 명확히 구분되지 않는 부분이 있는지(어느상태부터가 결함인가?)
• 현재는 어떠한 방법으로 결함/정상을 구분하고 있는지

2.2 해결하였을 때의 목표 확인

현업이 해당 문제가 해결되었을 때의 어떠한 모습을 그리고 있는지 파악하는 단계이다.

문제 해결의 결과에 대해서 서로가 명확히 정의하지 않으면 목표에 맞지않는 엉뚱한 모델이 나와 성공적으로 프로젝트를 마칠 수 없는 상황이 나타나기도 한다.

• 결함 유무 및 종류를 어떻게 제공해주어야하는지 (우선시해야할 결함이 있는지? 기존의 제공 방식은 어떤지?)
• 어느정도의 성능을 내야 사용 가능한지 (기존 방법의 성능은? 도메인적으로 유의미한 수치가 어느정도인지?)

2.3 데이터 파악

해당 프로젝트에서 사용가능한 데이터를 파악하는 단계이다.

설비/라인별로 상이한 스키마와 방식으로 데이터가 수집될 수 있으며,

고장이나 정기정검등으로 특정 값이 일정기간 누락되었을 수 있다.

총수집 데이터는 10년이나 중간에 측정 설비가 교체되어 데이터가 다를 수도 있다.

이외에도 다양한 조건으로 데이터가 완전치 않을 수 있기에 데이터의 구성을 충분히 파악해야한다.
(해당부분에서의 데이터 파악은 EDA가 아닌 물리적은 수집조건과 구조등을 의미한다.)

2.4 제약사항 확인

프로젝트에서 개발된 알고리즘이나 모델이 실제 적용되어 사용되기 위해서 고려해야하는 여러 제약조건을 파악하는 단계이다.

IT 기업과는 다르게 제조업에서는 이러한 제약조건이 상당수 존재하는 경우가 많으며, 문제 자체는 해결하기 어렵지 않지만 제약조건이 너무 까다로워 과제가 어려워지는 경우도 많다.

• 결함 예측 모델의 가능한 서비스 방법이 무엇인지? (해당 파트에 워크스테이션이 있는지? 네트워크를 통한 서비스 방식이 가능한지?)
• 예측 수행 주기는 어느정도인지? (제품이 1초에 한번씩 생산되는지? 생산라인이 여러군데인지?)
• 예측 결과 제공의 제약조건이 있는지? (배치로 제공해주어도 되는지? 동적으로 제공해주어야한다면 데이터 입력후 얼마 이내에 제공해주어야하는지?)
• 프로젝트에 대한 추가 조건들이 있는지? (완료 시간, 사용가능 금액 등)
• 연관부서들의 협조가 가능한지? (xx 설비 내용이 필요하다면 담당자는 협조 가능한지)

 

3. 마치며

이렇게 글을 써놓고 보니 깔끔하게 목차로 정리된 느낌보다는 생각을 두서없이 풀어놓은 글 같게 느껴진다.

앞으로 과제들을 수행하면서 위의 내용들을 좀더 체계적으로 다듬어서 글또 8기를 마칠때는 완성된 글로 느껴지게 해보려고한다.