[소프트웨어공학] 10. Requirement Capture
요구사항 분석 과정
이번 글에서는 Software Activity 글에서 정리했던 요구사항 파악 단계를 구체적으로 정리해본다.
먼저 요구사항을 파악할 때는 다음 3가지 단계를 거쳐야 한다.
1. 기존 시스템을 파악한다.
2. 기존 시스템에서 문제점을 파악한다.
3. 현재 시스템에 없는 새로운 요구사항이 있는지 파악한다.
요구사항을 파악할 때, 기존 시스템을 이해하는 것이 필요한 이유는 다음과 같다.
- 기존 시스템에 존재하는 기능이 새로운 시스템에서도 계속 필요할 수 있다.
- 기존 시스템에 존재하는 데이터를 새로운 시스템에 그대로 옮겨야 한다.
- 기존 시스템의 기술 문서는 기존 시스템의 알고리즘 흐름을 자세히 파악하는데 도움이 된다.
- 기존 시스템의 결함을 파악해서 새로운 시스템에는 같은 결함이 없도록 해야 한다.
- 사람들이 기존 시스템을 활용해서 어떻게 일을 하고 있는지 알아야 한다.
- 기존 시스템의 baseline information 은 새로운 시스템의 성능 기준을 설정하는데 도움이 된다.
(예를 들어 수강신청하는데 5천명이 동시에 오더라 라는 정보를 알고 있으면 새 시스템을 설계할 때 5천명이 동시접속해도 버틸 수 있는 시스템을 만들어야겠다는 정보를 사전에 알 수 있다.)
그리고 새로운 요구사항들은 비즈니스 환경의 변화, 기술적 환경의 변화 (스마트폰의 등장 등), 정부 정책과 법의 변화 등에 따라 계속해서 등장한다.
요구사항의 종류
Functional Requirements
시스템이 가져야 하는 '기능'과 관련된 요구사항이다.
어떤 input이 주어졌을 때, 이 데이터를 어떤 과정으로 처리하고(process), 그 결과로 어떤 output을 내보내는지를 포함하고 있다.
funtional requirements 의 경우, use case diagram 으로 모델링한다.
예를 들어 회원가입 기능에 대한 요구사항을 정리한다면
사용자가 '이름, 전화번호, 아이디, 비밀번호' 를 입력하고 '회원가입' 버튼을 클릭하면 (input)
프론트는 해당 정보를 백엔드나 데이터베이스에 보내서 회원 정보를 저장한다. (process)
그리고 회원가입에 성공하면 회원가입에 성공했다는 안내 모달창을 보여준다. (output)
Non-functional Requirements
functional requirements 를 얼마나 잘 제공하는지에 대한 요구사항이다.
즉, 기능 외적으로 시스템이 갖추어야 할 요구사항이다.
예를 들어 시스템의 응답 시간(response time), 동시 접속이 가능한 사용자 수 등이 non-functional requirement 이다.
말 그대로 사용자가 사용하려는 기능을 '얼마나 잘' 제공하는지에 대한 요구사항이다.
그 외에도 처리해야 하는 데이터의 규모, 보안이 얼마나 잘 되어 있는지도 non-functional requirement에 포함된다.
non-functional requirement는 다이어그램으로 모델링할 필요가 없기 때문에 보통 글로 나열에서 문서화한다.
Usability Requirements
이름 그대로 '사용성', 이 시스템이 사용자들이 사용하는 방식에 맞게 동작하는지와 관련된 요구사항이다.
따라서 사용자들이 하려는 작업의 특성을 고려하여 시스템의 acceptance 기준을 정해야 한다.
예를 들어 이 시스템이 '게임' 이라면, 사용자는 게임을 통해서 재미를 얻기를 원할 것이다.
그런데 시스템이 보여주는 데이터가 화면에 빼곡히 꽉 들어있다면 정보를 알아보기 힘드므로 게임과 맞지 않는다.
하지만 이 시스템이 증권 거래 시스템이라면, 화면에 증권 거래 데이터가 빼곡히 들어있는 것이 문제되지 않는다.
오히려 정보가 너무 간소화되어있으면 사용자가 불편하다고 생각할 것이다.
이 요구사항도 다이어그램보다 글로 서술하며, 프로토타입을 만들어서 이 요구사항을 만족하는지 테스트한다.
Fact Finding Technique
이런 다양한 종류의 요구사항을 파악하려면 위에 적었듯 기존 시스템 파악, 문제점 파악, 새로운 요구사항 파악을 해야한다.
이때 요구사항을 파악하는데 필요한 여러가지 요소를 찾는 방법은 다음의 4가지 방법이 있다.
Background Reading
조직과 이 조직에서 수행하는 비즈니스의 목적을 이해하는 것이다.
예를 들어 클래스넷을 개발한다고 하면, '학사 관리 시스템' 자체가 무엇이고, 이 시스템의 목적이 무엇인지 이해해야 한다.
이를 위해서 레포트, 사내 조직도, 업무 메뉴얼, 기존 시스템의 사용 메뉴얼 등을 확인할 수 있다.
소프트웨어 개발 회사의 컨설턴트들이 주로 이 단계의 작업을 수행하며, 매우 중요한 일이다.
개발자는 '구현'만 하는 직업이 아니다.
- 장점
이 단계를 통해 실제 조직의 사람들을 만나기 전에 어느 정도 사전 지식을 갖추게 되므로 대화할 때 더 쉽게 이해할 수 있고, 이 비즈니스 도메인에 대한 지식이 생기므로 다른 요구사항과 관련된 요소를 찾을 때도 도움이 된다.
- 단점
하지만 문서가 업데이트되지 않았거나, 실제 업무나 프로그램 동작과 다르게 서술되어 있다면 오히려 이해하는데 방해가 될 수도 있다.
- 적용 시기
요구사항 분석 초기에 활용하면 좋은 방법이다. (아주 당연한 말)
Interview
이 조직이 하고자 하는 일, 사용자들이 원하는 것, 조직 구성원의 역할에 대해서 더 깊게 이해하는 것을 목표로 한다.
조직의 목표를 이해할 때는 관리자(manager)를,
조직 구성원의 역할에 대해서 이해할 때는 직원(staff)을,
사용자들이 원하는 것을 파악할 땐 고객(customer)이나 잠재고객으로서 대중(public)을 인터뷰한다.
교수님이 말씀해주신 사례 중 하나는, 집에 홈 네트워크를 만들고자 하는 고객이 있었다.
엔지니어 관점에서는 속도도 빠르고 보안도 좋은 광케이블이 당연히 좋다고 생각해서 추천을 했는데, 실제 사용자는 결국 유선이므로 '선이 보인다' 라는 점 때문에 무선을 더 선호했다고 한다.
이렇게 사용자와 만나서 인터뷰를 진행하면 사용자의 진짜 요구사항을 파악할 수 있다.
- 장점
사용자에 대답에 맞춰서 질문을 바꿔가며 할 수 있으므로 요구사항과 관련된 사항을 더 깊게 이해하기 좋다.
- 단점
시간과 비용이 많이 든다.
내가 하는 질문에 따라 사람들의 대답이 유도될 수도 있기 때문에 한쪽에 편향된 대답만 들을 수도 있다.
여러 사용자들에게 물어봤는데, 그 사람들의 대답이 서로 상충할 때 어떤 것을 택하는 것이 좋을지 판단하기 힘들다.
- 적용 시기
대부분의 경우 적용하며, 기존 시스템과 사람들의 요구사항을 더 깊게 이해하고 싶을 때 활용하면 좋다.
따라서 상술한 background reading 단계가 선행되는 것이 좋다.
Observation
문서에 적혀있는 것들이 실제로 일어나는지, 인터뷰하면서 사람들이 말하지 않은 부분이 존재하는지 직접 눈으로 실제 현장을 관찰하는 것
사람들이 어떻게 일을 처리하는지 눈으로 보고, 새로운 시스템의 baseline information 을 얻는다.
예를 들어 클래스넷 시스템의 성능 기준을 잡으려고 할 때 동시에 몇명까지 접속 가능하도록 설계할 지 파악하려면 수강신청 시기에 몇 명의 수강신청 대상자들이 있고, 어떻게 접속해서 어떻게 수강신청하고 얼마나 몰리는지 직접 관찰하면 설계 기준점에 대한 정보를 얻을 수 있다.
- 장점
사람들이 어떻게 행동하는지 직접 앞단에서 경험할 수 있다.
앞서 문서와 인터뷰를 통해 얻은 정보를 검증할 수 있다.
baseline data를 얻을 수 있다.
- 단점
사람들이 자신이 관찰되는 것을 인지하면 현실과 다르게 행동할 수 있어 정보가 왜곡될 수 있다.
- 적용 상황
앞서 얻은 정보를 검증하고 싶거나, 상충되는 의견을 해결해야 할 때 관찰을 통해 정보를 얻을 수 있다.
설문조사
다수의 사람들로부터 의견을 받아 통계를 얻는 것이 목적이다.
웹이나 이메일로 설문조사를 실시하여 의견을 받을 수 있고, 이 '의견'을 기반으로 요구사항 파악에 필요한 사실을 얻을 수 있다.
- 장점
다수의 사람들로부터 정보를 얻는 가장 경제적인 방법인 동시에,
지리적 한계가 없기 때문에 효율적으로 멀리 떨어진 사람들로부터 정보를 얻을 수 있다.
- 단점
좋은 질문을 설계하기 힘들고, 설문조사 결과에 따라 더 파고들어서 질문하고 싶을 때 마음대로 하기 힘들다는 단점이 있다.
또 사람들이 설문조사를 귀찮아해서 응답 비율이 높지 않다는 문제도 있다.
- 적용 상황
다수의 사람들로부터 정보를 얻어야 할 때, 직원과 실제 고객들이 밀접하게 붙어있지 않은 경우에 사용하기 좋다.
특히 customized software 보다 generic software 에 적용하면 좋다.
지금까지 사용자의 요구사항을 파악하는 여러가지 방법, 요구사항의 종류에 대해서 정리해보았다.
배경지식을 파악하고, 인터뷰하고, 관찰하고, 설문조사를 하는 등 개발과 전혀 관련이 없어보이고, 전체 개발과정에서 20% 밖에 차지하지 않아서 사소해보이지만 요구사항 분석 역시 전체 개발 프로세스의 일부분이고 그 중에서도 제일 중요한 부분이다.
또한 요구사항은 비즈니스 환경, 기술 환경, 정부 정책 등에 영향을 받아서 계속 바뀐다.
따라서 요구사항에 대한 문서 역시 버전관리를 잘 해야한다. (git)
그래서 모든 요구사항을 다 리스트업해서 문서화를 잘 하고,
그 중에 특히 functional requriement 는 use case diagram을 통해서 시각화한다.
use case diagram을 그리고 나면 그로부터 코드를 작성할 수 있다.
이제 다음 글에서는 use case diagram 에 대해 예시와 함께 자세히 정리해본다.