소프트웨어 요구 사항 추출

요구 사항 추출 (Requirement Elicitation)

계획 단계에서 타당성 분석이 긍정적으로 끝났다면,
프로젝트의 첫 단계는 사용자가

무엇을 원하는지 수집하는 것이다.

 

개발자는 고객/사용자와 소통하며 시스템이

제공해야 할 내용과 기능 아이디어를 끌어낸다.

---

요구 추출이 특별히 어려운 이유

요구는 “자명한 사실”이 아니다.

지금 이미 수동 업무가 굴러가고 있으면
요구를 뽑는 게 상대적으로 쉽다.

 

하지만 시스템이 아직 존재하지 않거나,
사용자도 해결책을 제대로 상상해본 적이 없으면
“함께 아이디어를 찾는 과정” 자체가 어려워진다.

 

그래서 요구 추출은
같은 질문을 여러 형태로 반복해서 던지며
“진짜 원하는 것”을 확인하는 작업이 된다.

---

요구 추출 3단계 흐름

요구 추출은 보통 아래 3단계를 밟는다.

 

1) 요구 정보 출처 파악

누가 관련자인지(이해관계자)

시스템 범위가 어디까지인지

데이터가 어디서 어디로 흐르는지(업무 흐름)

 

2) 요구 정보 취합

비즈니스 목표

현재 업무 상황(As-Is)

정책/법령/표준 같은 제약

기존 문서/규정/매뉴얼 등 조각 정보 모으기

 

3) 요구와 제한 사항 정리

모은 정보를 분석해서 우선순위를 정하고

요구와 제약(제한 사항)을 분리해 정리한다.

---

요구 정보 출처

요구 정보 출처는 “사람만”이 아니다

요구는 여러 출처에서 나온다.

역할이 다르기 때문에 구분해서 봐야 한다.

• 고객: 재정 지원 + 중요한 의사결정자
• 도메인 전문가: 해당 업무 규칙과 현실을 아는 사람
• 이해당사자: 시스템 도입으로 영향을 받는 사람(사용자 아닐 수도 있음)
• 사용자: 시스템을 직접 쓰는 사람(주 사용자/단순 운영자)
• 역공학: 레거시 시스템, 기존 문서/규정/매뉴얼도 강력한 요구 출처

※ 뷰포인트로 요구를 놓치지 않기

요구를 뽑을 때는 관점(viewpoint)이 도움이 된다.

• 상호작용 관점: 시스템을 직접 조작/교환하는 주체
• 간접 관점: 직접 조작하진 않지만 영향을 주는 주체
• 도메인 관점: 표준/제약/업무 특성 등 범위를 결정하는 요소

관점이 다르면 요구도 달라진다.
그래서 “요구가 모순처럼 보이는 순간”에 특히 유용하다.

---

요구 추출 방법

요구를 얻는 방법은 여러 가지고,
각 방법은 “얻는 정보의 범위와 효율”이 다르다.

• 고객 발표: 업무를 빠르게 이해하고 질문으로 불명확한 점을 잡는다
• 문헌/양식 조사: 실제 업무 입출력(양식/절차/규정)을 통해 흐름을 이해한다
• 인터뷰: 핵심 요구를 깊게 파는 대표 방식(정형/비정형/부분정형)
• 설문: 다수의 의견을 정량적으로 모으기 좋다(개방형/폐쇄형)
• 브레인스토밍: “토론”이 아니라 “아이디어 방출”로 신규 요구를 찾는다
• 관찰/작업 분석: 말로 안 나오는 실제 작업의 예외/요령을 발견한다
• 프로토타이핑: 일부 기능을 빠르게 보여주고 조기 피드백으로 요구를 확정한다

---

프로토타이핑의 포인트

프로토타입은 “최종 시스템 일부를 빠르게 구현한 것”이다.

 

목적은 피드백을 빨리 받아서 요구를 확정하는 것으로ㅡ

종이에 UI를 그리는 수준만으로도
아이디어 추출과 피드백에 충분히 효과가 있다.

• 장점: 결과를 눈으로 확인, 피드백을 조기에 받음
• 단점: 복잡하면 비용이 커지고, 설계/화면에 집착할 수 있음

---

정리

요구 추출은 “기능 목록 받기”가 아니다.

• 누구에게서(출처)
• 무엇을(요구)
• 어떤 조건으로(제약)

이걸 반복적으로 확인하고,
모은 정보를 우선순위로 정리해
합의 가능한 형태로 만드는 게 핵심이다.