프로젝트 계획(6-1) - 요구 추출(Requirement elicitation) [소프트웨어공학]

요구 분석 단계의 전반적인 측면을 알았다면

요구 추출에 대해서 알아보자

 

---

 

요구 추출이란 소프트웨어 개발에서 특별히 중요한 작업으로 사용자가 무엇은 원하는지 결정을 내리는 작업이며 여러가지 기법을 통해서 얻어진다.

 

요구 추출에는 세 가지 단계의 작업이 필요하다

 

1. 응용에 대한 정보 출처 파악
2. 응용에 대한 정보 취합
3. 요구와 제한 사항의 정의

 

 

요구 추출은 응용 분야에 대한 정보를 모으는 것부터 시작된다. 

그러한

---

요구 추출을 위한 정보를 모으는 방법 또한 여러가지다.

 

 고객의 발표
 문헌 조사
 업무 절차와 양식 조사
 관련자들 설문지
 사용자와의 인터뷰
 브레인 스토밍 회의
 사용 스토리 또는 사용사례 작성

 

위 방법을 통해서 정보를 모은다.

 

++위 방법을 통해서 얻은 요구는 우선순위로 나누면 좋다.

1. 절대적 필요

2. 필요하지만 중심은 아닌 요구

3. 충족되면 좋지만 없어도 되는 요구

 

 

---

 

요구 추출 작업에서 정보를 구해야하는데 어디서 정보를 얻어야 하느냐? 라고 말하면서

출처에 대한 말을 했다. 

 

요구 추출에 대한 출처 또한 다양하게 있다.

 

 고객

프로젝트를 유치시킨 당사자로 재정적 지원과 결정을 하는 당사자

 도메인 전문가 – 비즈니스 도메인을 지원하는 시스템을 구축하기 위하여 필요한 사람

(예를 들어 회계 시스템을 구축하기 위하여 회계사가 필요)

 

 이해당사자(stakeholder) – 시스템 운용으로 인하여 영향 받는 사람

시스템이 비즈니스 목표, 규칙에 부합하는지 살핀다.

 

 사용자 – 시스템을 직접 사용하는 사람

 

 

 역공학- 기존 레거시 시스템을 통해서 새로운 시스템을 개발하고자 할 때 얻는 정보

설계 문서를 이용해서 역으로 요구 도출

 

 

---

 

그럼 이번엔 요구 추출 방법에 대해서 자세히 알아보자

 

 

고객의 발표

 

 개발팀이 구축하는 시스템에 대하여 초기에 개념을 잡을 수 있음

 

 효과적인 가이드라인을 설명하자면

 1. 고객 업무를 잘 알고 있는 운영 책임자나 관리자가 발표 //신입사원은 적절하지 않음
 2. 발표하기 전 개발 팀원이 필요한 정보가 있는지 검토 // 정보가 있다면 추가 정보를 제공할 제 3자 요구
 3. 의심이 가는 부분을 질문하여 명확히 할 것 // 정확한 요구 파악을 위함
 4. 구현과 관련된 토의는 배제 // 구현은 지금 신경쓸 항목이 아니다
 5. 발표 내용의 복사본을 팀원과 공유
 6. 2시간 이상의 발표회는 지양

 

 

문헌 조사

 

유사한 프로젝트를 조사나  업무 문서나 양식을 조사,

산업 및 기업 표준 조사 및 관련 정부 정책/규제 조사하면

현재 개발할 시스템에 대한 통찰력을 얻을 수 있고 현재의 업무나 시스템 정보에 대해 깊은 이해가 가능하다
 

 

업무 절차 및 양식 조사

 

 업무 관련 문서, 절차, 양식, 운영 매뉴얼 조사 // 업무 절차 이해
 내부 표준 조사 // 요구나 제한사항을 찾을 수 있음
 정부, 산업, 기억의 특수 정책이나 규정 조사 // 제한

 

 

설문

 

 관리자나 사용자와 같은 이해 당사자를 대상 // 설문의 가장 큰 장점
 무기명 설문 // 무기명이라 진심이 담김 ㅋㅋ
 이해 당사자들의 관심과 내부정보, 개선 의견 도출 // 무기명이라 가능 
 감추어진 정보를 끌어내기 쉬움 // 무기명이라

 질문은 간단하고 중요한 이슈에 집중 // 복잡한 내용을 이끌어 내기엔 어려운 수단임
 적절하고 잘 기술된 질문

 

 

 

인터뷰

 

인터뷰 수행 가이드 라인
1. 가능하면 많은 당사자와 인터뷰 // 다른 시스템 사용자도 포함
2. 여유로운 인터뷰 일정 // 정보가 있다면 시간이 넘더라도 얻어야지
3. 인터뷰 약속 시간을 넘기더라도 여유롭게 //2번의 이유
4. 중요한 관련자와는 여러 차례 인터뷰 // 정확한 파악을 위함

 

 

반드시 포함해야 할 질문 또는 행동 유형

 

 최대, 최소, 예외 규칙, 예상되는 변동 등 자세한 사항
 시스템에 대한 미래의 비전 // 예상치 못한 좋은 정보 발견가능
 문제에 대한 최소한의 허용 가능한 솔루션이 무엇인지 // 소프트웨어의 문제 해결 범위를 정확히 알아냄 
 다른 정보원은 없는지 // 또 다른 인터뷰를 진행하기 위함
 인터뷰 대상자에게 다이어그램을 작성하게 함// 원활한 정보 수집을 위함

 

 

 

브레인 스토밍

 

아이디어를 낼 목적으로 여러 명으로부터 정보를 얻기 위한 회의를 말한다.

 훈련된 요원이 주재
 토론보다는 아이디어를 쏟아놓는 회의, 익명성 보장 // 그래야 원활하게 진행된다.
 서로 자극이 되어 열정을 가지고 아이디어를 창안 // 브레인 스토밍의 최고 장점
 JAD(Joint Application Development) – 집중 브레인스토밍 세션 // 기간 단축을 위함

 

브레인 스토밍의 방법을 간단히 하자면

 

1. 관련자 모두가 참여하는 회의 소집
2. 경험 많은 사람을 회의 주재자로 선정
3. 테이블에 참석자를 배석시키고 종이 준비
4. 토론을 유도할 질문을 정함
5. 질문에 대하여 답을 종이에 적되 한 장에 하나의 아이디어만 적은 후 참석자에게 돌려 봄
6. 5번 단계를 5~15분간 반복
7. 간단한 설명
8. 모든 아이디어를 칠판에 적은 후 우선순위를 정하기 위하여 투표를 할 수도 있음

 

 

프로토 타입

 

 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램 // 요구 파악
 가장 단순한 형태: paper prototype은 병행하여 만들기 적합한 형태이다 // 그림이라서 병행하여 가능
 가장 흔한 형태: 모의 사용자 인터페이스
 프로토타이핑 언어로 작성 //컴퓨팅, 데이터베이스 접근, 다른 시스템과의 상호작용은 불가능

 

 

사용자 스토리

 

애자일 방법에서 요구 취합을 위하여 많이 사용하는 방법이다.

 

 사용자와 개발 팀이 함께 작성
 사용자들이 시스템에 바라는 역량을 간단히 기술한 것
 내부 사람이 만들기 때문에 효과적

 

 

---

앞의 방법으로 얻어진 정보들을 요구를 도출한다.

 

1. 사용자 니즈 파악

사용자 스토리나 위시리스트에서 니즈를 찾는 것은 어렵지 않다. 

2. 요구 도출

니즈를 만족시키는 새로운 시스템을 위한 역량, 즉 요구를 도출한다.

개발팀은 논증을 통하여 역량을 도출하고 요구로 정의해야한다.