이전 글에서 요구공학이 무엇인지, 왜 중요한지를 짤막하게 정리해보았다.
이번 글에서는 요구공학에서 다루는 프로세스들에 대해서 짤막하게 얘기해보고자 한다.
요구공학의 프로세스 (Requirements Process)
요구공학의 공통 프로세스는 다음의 5가지이다.
시험을 치거나 할 것은 아니니, 달달 외울 필요는 없을것 같고 …
어차피 이 업을 계속 한다면, 자연스럽게 진행하게 될 프로세스이니 가볍게 읽어보면 좋을 것 같다.
1. 요구사항 도출하기(Requirements Elicitation) :
말 그대로 요구사항을 도출한다. 고객이 진정 원하는 소프트웨어가 무엇인지를 알기 위해, 무엇을 물어봐야할지를 생각해보는 단계이다.
문제 영역의 경계(Boundary)를 정의하고, 문제의 맥락을 이해한다. 문제와 관련된 이해관계자(Stakeholders)가 누구인지, 이해관계자들은 어떤 것을 원하고 어떤 것을 원하지 않는지. 목표는 무엇인지. 발생할 수 있는 시나리오와 제약사항. 타당성과 리스크를 확인한다.
한마디로, 요구사항에 필요한 모든 것을 끌어내고 수집하는 단계이다.
각 문제의 이해관계자들은 서로 모순되거나 상충되는 요구사항이나 서로 제로섬, 트레이드오프 관계의 요구사항을 요청하기도 한다.
예를 들면, “앱을 실행하자마자 번개처럼 UI를 매우 빠르게 띄울 수 있도록 해달라.”, “그런데 VE(원가절감 ^^)를 해야하니, 디바이스의 메모리와 CPU 성능은 쓰레기에요. 하지만 번개처럼 UI를 매우 빠르게 띄워주세요.” 같은 요구사항을 들 수 있겠다.
이 단계에서는 요구사항에 대한 재료를 도출하기 시작하며, 아래와 같은 초기 산출물 초안이 나온다.
- Use case
- Project Background
- Stakeholder List
- Business Goal List
- System Context Diagram
- System Feature List
- Assumptions
- Raw-QAS
2. 요구사항 분석하기(Requirements Analysis) :
요구사항들을 분석하여 분류하고 정리, 우선순위를 세운다.
수많은 요구사항들을 하나하나 분석하여 기능적 요구사항(FR)인지 비 기능적 요구사항(NFR)인지 구별하고, 어떤 요구사항이 핵심인지, 어떤 요구사항이 더 중요하고 덜 중요한지, 요구사항 간 연관관계는 무엇인지, 요구사항이 중복되거나 모순되는 지점이 있는지 등을 정리하는 단계이다.
기능적 요구사항(FR)쪽에서는 Use case를 정제하고, 경계들을 다듬는다.
비 기능적 요구사항(NFR)쪽에서는 QAW(Quality Attributes Workshop), 또는 간소화 버전인 mini-QAW 활동을 통해 Raw-QAS를 정제하고, 중요도와 난이도 바탕으로 우선순위를 정한다.
이 단계에서는 보통 아래와 같은 산출물들이 나온다고 볼 수 있겠다.
- 정제된 Use case
- Basic flow
- Alternative flow
- Include / Extend relationship
- QAS (Raw-QAS의 정제된 버전)
- Quality Attribute Tree / Utility Tree
3. 요구사항 구체화 (Requirements Specification) :
정리한 요구사항들을 문서화하는 단계이다.
이 단계부턴 다른 사람이나 외주업체가 보더라도, 해당 산출물들을 통해 실제로 개발과 검증이 가능한 설계가 나올 수 있는 수준이 되어야 한다. (OOAD 단계에서 구체적인 설계 산출물이 나온다.)
Elicitation, Analysis 단계를 거치며 나온 요구사항들을 문장이나 표, 다이어그램 등으로 정리하여 문서를 작성한다.
즉, 이 단계의 산출물은 앞 단계에서 도출하고 정리한 요구사항 재료들을, 다른 사람이 읽어도 바로 개발과 검증이 가능하도록 문서와 다이어그램 형태로 고정한 것들이다.
- 시스템의 범위와 맥락을 정리하는 산출물
- Project Background
- Stakeholder List
- Business Goal List
- System Context Diagram
- System Feature List
- Assumptions
- FR을 명세하는 산출물
- Use Case Diagram
- Use Case Scenarios
- System Sequence Diagram
- NFR을 명세하는 산출물
- QA Scenario List
- QAS (Quality Attribute Scenario)
4. 요구사항 검증하기 (Requirements Validation) :
작성한 요구사항을 점검하는 단계이다.
단순 오탈자 점검을 넘어서서, 각 요구사항들이 빠지거나 모순점 없이 작성이 잘 되었는지? 를 확인한다.
주로 확인하는 내용은 아래와 같다.
한마디로, “적은 문서가 말이 되는지 ?” 를 리뷰하는 단계다.
- 빠진 요구사항은 없는지 ?
- 서로 충돌하거나 모순되는 요구사항은 없는지 ?
- 문장이 모호하지 않은지 ?
- 정량화가 필요한 요구사항은 수치가 명확하게 기술되었는지 ?
- 실제로 구현이 가능한지 ?
- 테스트가 가능한지 ?
- Actor / Use cases / QA / Feature 간 연결이 부자연스러운 곳은 없는지 ?
5. 요구사항 관리하기 (Requirements Management) :
요구사항을 관리하는 단계이다.
요구사항이 한 번 확정된 이후에는 변경되지 않으면 좋겠지만, 현실에서는 자주 바뀐다.
그렇기 때문에, 요구사항이 변하더라도 유연하게 대처해야 하는데, 주로 이런 항목들이 해당 단계에서 포함된다.
- 요구사항 변경 이력 관리
- 버전 관리
- 추적성 (Traceability)
- 영향도 분석
- 요구사항 우선순위 관리
- 산출물 간 연결 유지
찬찬히 살펴보면 당연한 내용들이 많은데..
막상 실전에서 적용해보려고 하면 번거롭고, 작성해야하는 문서들이 적지 않은 편이다.
책상머리에선 모든 것을 할 수 있는 것처럼 느껴지지만, 늘 시간은 모자라고 요구사항은 넘쳐난다.
그럼에도 결국 가장 중요한 것은, 고객의 요구사항을 정확하게 파악하는 일이라 생각한다.
요구공학을 형식주의로 내려치기하는 것도, 종교처럼 맹신하는 태도도 경계해야 하지 않을까 싶다.
산출물들에 대한 설명을 적자니, 글이 지나치게 길어질 것 같아 공부하면서 큰 꼭지만 작성하였다.
기회가 된다면 요구공학의 각 프로세스에서 다루는 산출물들을 좀 더 자세히 들여다보고 싶다.