다양한 요구사항 분석 기법 및 활용법Various Requirements Analysis Techniques and Their Applications
📅
🚀
들어가기 전에 🔗
지난 시간에는 성공적인 프로젝트의 첫 단추인 소프트웨어 요구사항 명세서(SRS) 작성법에 대해 알아보았습니다.
하지만 훌륭한 SRS 문서를 만들기 위해서는 그보다 먼저 사용자와 이해관계자들이
정말로 원하는 것
이 무엇인지 정확하게 파악하는 과정, 즉 요구사항 분석
단계가 선행되어야 합니다.오늘은 이렇게 중요한 요구사항을 효과적으로 도출하고 분석하기 위한 다양한 기법들에 대해 함께 살펴보겠습니다.
🚀
요구사항 분석이란 무엇이며 왜 중요할까요? 🔗
요구사항 분석은 소프트웨어 개발 생명주기(SDLC)의 초기 단계로, 개발하고자 하는 시스템에 대해 사용자와 이해관계자들의 필요와 기대를 이해하고, 이를 구체적이고 명확한 요구사항으로 변환하는 일련의 과정입니다.
이 과정은 단순히 사용자의 말을 받아 적는 것을 넘어, 불분명하거나 암묵적인 요구, 상충하는 요구 등을 식별하고 해결하는 복잡한 활동을 포함합니다.
사용자의 진짜 속마음 읽기
요구사항 분석이 중요한 이유
- 프로젝트 성공의 기반잘못되거나 누락된 요구사항은 프로젝트 실패의 가장 큰 원인 중 하나입니다. 초기에 정확한 요구사항을 파악하는 것이 성공의 지름길입니다.
- 비용 절감개발 후반 단계에서 요구사항 변경이나 오류를 수정하는 것은 초기에 비해 훨씬 많은 비용과 시간을 소모합니다.
- 이해관계자 만족도 향상사용자의 실제 필요를 충족하는 시스템을 개발하여 만족도를 높일 수 있습니다.
- 명확한 개발 방향 제시개발팀에게 무엇을 만들어야 하는지 명확한 가이드라인을 제공하여 혼란을 줄이고 효율성을 높입니다.
요구사항 분석은 단순히 기술적인 작업이 아니라, 사람들과의 소통, 문제 해결 능력, 분석적 사고가 모두 요구되는 중요한 과정입니다.
🚀
정형 분석 vs 비정형 분석 🔗
요구사항 분석 기법은 크게
정형 분석(Formal Analysis)
과 비정형 분석(Informal Analysis)
으로 나눌 수 있습니다.✅
정형 분석 기법 (Formal Analysis Techniques) 🔗
정형 분석은 수학적 원리나 정형화된 표기법(Formal Notation)을 사용하여 요구사항을 명확하고 모호함 없이 기술하고 검증하는 방법입니다.
주로 안전성이 매우 중요한 시스템(Safety-critical systems, 예: 항공 관제, 원자력 발전소 제어)이나 복잡한 시스템의 일관성과 완전성을 보장하기 위해 사용됩니다.
➡️
특징 🔗
- 엄격하고 수학적인 표현 사용 (예: 유한 상태 기계, 페트리넷, Z 표기법 등)
- 요구사항의 모호성 제거 및 일관성 검증에 효과적
- 자동화된 분석 도구 활용 가능
➡️
장점 🔗
- 요구사항의 정확성과 완전성을 높일 수 있습니다.
- 오류를 조기에 발견하여 시스템의 신뢰성을 향상시킵니다.
➡️
단점 🔗
- 전문적인 지식과 많은 노력이 필요하여 비용과 시간이 많이 소요됩니다.
- 이해관계자들이 정형화된 표현을 이해하기 어려울 수 있어 의사소통에 장벽이 될 수 있습니다.
➡️
예시 🔗
상태 전이 다이어그램(State Transition Diagram), 결정 테이블(Decision Table), 명세 언어(Z, VDM 등) 사용.
👨💻
일반적인 상용 소프트웨어 개발에서는 정형 분석 전체를 적용하기보다는, 특정 복잡한 로직이나 상태 변화를 명확히 하기 위해 부분적으로 상태 전이 다이어그램 등을 활용하는 경우가 많습니다.✅
비정형 분석 기법 (Informal Analysis Techniques) 🔗
비정형 분석은 자연어나 그림, 다이어그램 등 비교적 덜 엄격하고 이해하기 쉬운 방법을 사용하여 요구사항을 도출하고 분석하는 방법입니다.
대부분의 소프트웨어 개발 프로젝트에서 널리 사용되며, 이해관계자와의 원활한 의사소통에 중점을 둡니다.
➡️
특징 🔗
- 자연어, 그림, 간단한 다이어그램 사용 (예: 유스케이스 다이어그램, 사용자 스토리)
- 이해관계자와의 소통 및 참여 용이
- 유연하고 다양한 상황에 적용 가능
➡️
장점 🔗
- 비교적 배우고 적용하기 쉽습니다.
- 다양한 이해관계자들이 쉽게 참여하고 이해할 수 있습니다.
➡️
단점 🔗
- 자연어의 모호성으로 인해 요구사항 해석에 오해가 발생할 수 있습니다.
- 요구사항의 완전성이나 일관성을 보장하기 어려울 수 있습니다.
➡️
예시 🔗
인터뷰, 설문조사, 워크숍, 브레인스토밍, 스토리텔링, 프로토타이핑, 유스케이스 모델링 등.
👨💻
실제 프로젝트에서는 정형 분석과 비정형 분석 기법을 상황에 맞게 조합하여 사용하는 경우가 많습니다.🚀
주요 비정형 요구사항 도출 및 분석 기법 🔗
이제 실제 프로젝트에서 자주 사용되는 주요 비정형 요구사항 도출 및 분석 기법들을 자세히 살펴보겠습니다.
✅
1. 인터뷰 (Interviews) 🔗
인터뷰는 분석가가 이해관계자(사용자, 고객, 관리자 등)와 직접 만나 대화를 통해 요구사항을 수집하는 가장 기본적인 방법입니다.
➡️
종류 🔗
- 구조적 인터뷰 (Structured Interview): 미리 준비된 질문 목록에 따라 체계적으로 진행합니다.
- 비구조적 인터뷰 (Unstructured Interview): 특정 주제에 대해 자유롭게 대화하며 정보를 얻습니다.
- 반구조적 인터뷰 (Semi-structured Interview): 주요 질문은 준비하되, 상황에 따라 유연하게 추가 질문을 하거나 대화의 흐름을 조절합니다. (가장 일반적)
➡️
장점 🔗
- 심층적인 정보와 사용자의 암묵적인 지식까지 얻을 수 있습니다.
- 질문을 통해 모호한 부분을 즉시 명확히 할 수 있습니다.
- 이해관계자와의 신뢰 관계 구축에 도움이 됩니다.
➡️
단점 🔗
- 시간과 비용이 많이 소요될 수 있습니다. (특히 다수의 이해관계자 인터뷰 시)
- 인터뷰 진행자의 숙련도에 따라 결과의 질이 달라질 수 있습니다.
- 인터뷰 대상자의 주관적인 의견이나 편향된 정보가 포함될 수 있습니다.
✅
2. 설문조사 (Surveys / Questionnaires) 🔗
설문조사는 다수의 사람으로부터 정량적 또는 정성적인 데이터를 수집하기 위해 미리 작성된 질문지를 사용하는 방법입니다.
➡️
장점 🔗
- 짧은 시간에 많은 사람으로부터 정보를 수집할 수 있어 비용 효율적입니다.
- 익명성을 보장하여 솔직한 답변을 유도할 수 있습니다.
- 수집된 데이터를 통계적으로 분석하기 용이합니다.
➡️
단점 🔗
- 질문지를 잘못 설계하면 원하는 정보를 얻기 어렵거나 응답률이 낮을 수 있습니다.
- 심층적인 정보나 복잡한 의견을 파악하는 데는 한계가 있습니다.
- 응답자의 상황이나 문맥을 이해하기 어렵습니다.
✅
3. 워크숍 (Workshops / Focus Groups) 🔗
워크숍은 다양한 이해관계자들이 한자리에 모여 특정 주제에 대해 집중적으로 논의하고 아이디어를 교환하며 요구사항을 도출하고 합의하는 방법입니다. (포커스 그룹 인터뷰(FGI)도 유사한 형태입니다.)
➡️
장점 🔗
- 다양한 관점의 의견을 한 번에 수렴하고 상충하는 요구사항을 조기에 해결할 수 있습니다.
- 참여자 간의 시너지 효과를 통해 창의적인 아이디어나 해결책을 도출할 수 있습니다.
- 요구사항에 대한 이해관계자들의 공동 소유 의식과 합의 수준을 높일 수 있습니다.
➡️
단점 🔗
- 참여자들의 적극적인 참여와 숙련된 진행자(Facilitator)가 필수적입니다.
- 소수의 목소리가 큰 사람에 의해 논의가 편중될 수 있습니다.
- 참여자들의 일정을 조율하고 준비하는 데 시간과 노력이 필요합니다.
✅
4. 관찰법 (Observation / Shadowing) 🔗
관찰법은 분석가가 사용자의 실제 업무 환경을 직접 방문하여 사용자가 시스템을 사용하거나 업무를 수행하는 과정을 관찰하고 기록하는 방법입니다. '섀도잉(Shadowing)'은 사용자를 그림자처럼 따라다니며 관찰한다는 의미입니다.
➡️
장점 🔗
- 사용자가 말로 표현하지 못하는 암묵적인 요구사항이나 실제 업무 절차상의 문제점을 발견할 수 있습니다.
- 문서화되지 않은 실제 업무 흐름이나 작업 환경에 대한 깊이 있는 이해를 얻을 수 있습니다.
- 인터뷰나 설문에서 얻기 어려운 현실적인 데이터를 수집할 수 있습니다.
➡️
단점 🔗
- 관찰자의 존재가 사용자의 평소 행동에 영향을 미칠 수 있습니다. (호손 효과)
- 시간이 많이 소요될 수 있으며, 특정 시점에만 발생하는 작업은 관찰하기 어려울 수 있습니다.
- 관찰 결과를 해석하는 데 분석가의 주관이 개입될 수 있습니다.
✅
5. 문서 분석 (Document Analysis / Review) 🔗
기존 시스템 문서, 업무 매뉴얼, 경쟁사 제품 분석 자료, 관련 법규 및 규제, 기술 표준 문서 등 이미 존재하는 다양한 문서를 검토하여 요구사항을 도출하는 방법입니다.
➡️
장점 🔗
- 비교적 적은 비용과 시간으로 시스템 배경 지식과 현재 상황에 대한 정보를 얻을 수 있습니다.
- 새로운 시스템이 기존 시스템과 어떻게 통합되어야 하는지, 어떤 제약 조건을 따라야 하는지 파악하는 데 유용합니다.
➡️
단점 🔗
- 기존 문서가 최신 정보가 아니거나 부정확할 수 있습니다.
- 문서만으로는 사용자의 실제 필요나 암묵적인 요구를 파악하기 어려울 수 있습니다.
✅
기타 기법들 🔗
위에서 언급된 기법 외에도 다음과 같은 다양한 기법들이 활용될 수 있습니다.
- 프로토타이핑 (Prototyping)시스템의 일부 기능을 미리 만들어 사용자에게 보여주고 피드백을 받아 요구사항을 구체화하고 검증하는 방법. (매우 효과적)
- 유스케이스 모델링 (Use Case Modeling)사용자와 시스템 간의 상호작용을 유스케이스 단위로 정의하고 각 유스케이스 시나리오를 기술하여 기능 요구사항을 도출하는 방법.
- 사용자 스토리 (User Stories)"사용자로서 나는 ~을 할 수 있기를 원한다. 그래서 ~한 가치를 얻을 수 있다" 형식으로 간결하게 요구사항을 표현하는 애자일 방법론에서 주로 사용.
- 브레인스토밍 (Brainstorming)여러 사람이 자유롭게 아이디어를 제시하고 토론하여 다양한 요구사항을 발굴하는 기법.
각 기법은 고유한 장단점을 가지고 있으므로, 프로젝트의 성격, 이해관계자의 특성, 가용 시간 및 자원 등을 고려하여 가장 적합한 기법들을 조합하여 사용하는 것이 중요합니다.
🚀
요구사항 추적성 매트릭스 (Requirements Traceability Matrix, RTM) 🔗
요구사항 분석 과정에서 도출된 요구사항들은 프로젝트 생명주기 동안 지속적으로 관리되어야 합니다.
요구사항 추적성 매트릭스(RTM)
는 이러한 요구사항들이 설계, 개발, 테스트, 최종 인수 단계까지 어떻게 반영되고 검증되는지를 추적하고 관리하기 위한 문서 또는 도구입니다.
요구사항 추적성 매트릭스
✅
RTM의 역할 및 중요성 🔗
- 변경 영향 분석특정 요구사항이 변경될 경우, 이와 관련된 설계, 코드, 테스트 케이스 등에 어떤 영향을 미치는지 쉽게 파악할 수 있습니다.
- 요구사항 누락 방지모든 요구사항이 설계, 구현, 테스트 단계에서 빠짐없이 다루어졌는지 확인할 수 있습니다.
- 테스트 커버리지 확인각 요구사항에 대해 테스트 케이스가 적절히 작성되었는지 검토할 수 있습니다.
- 프로젝트 진행 상황 모니터링요구사항별 개발 및 테스트 진행 상태를 추적할 수 있습니다.
- 이해관계자와의 의사소통요구사항의 현재 상태와 변경 이력을 명확하게 공유할 수 있습니다.
RTM은 간단한 스프레드시트 형태로 만들 수도 있고, 전문적인 요구사항 관리 도구(예: JIRA, Confluence, IBM DOORS)를 사용할 수도 있습니다.
요구사항 분석 단계에서부터 RTM 구축을 계획하고 꾸준히 업데이트하는 것이 중요합니다.
🚀
결론 🔗
오늘은 소프트웨어 개발의 성패를 좌우하는 중요한 단계인 요구사항 분석을 위한 다양한 기법들에 대해 알아보았습니다.
정형 분석과 비정형 분석의 차이점을 이해하고, 인터뷰, 설문, 워크숍, 관찰법 등 실제 프로젝트에서 유용하게 사용될 수 있는 비정형 분석 기법들의 특징과 장단점을 살펴보았습니다.
또한, 도출된 요구사항을 효과적으로 관리하기 위한 요구사항 추적성 매트릭스(RTM)의 중요성에 대해서도 언급했습니다.
다음 시간에는 사용자의 관점에서 시스템의 기능을 효과적으로 정의하고 분석하는 데 널리 사용되는유스케이스 기반 요구사항 분석방법에 대해 자세히 알아보겠습니다.
✅
참고 🔗
- Software requirements analysis - Wikipedia↗ (영문, 요구사항 분석 위키피디아)
- Requirements Traceability Matrix (RTM) - Guru99↗ (영문, RTM 상세 설명 및 예제)