Key Takeaway Points
- 요구사항은 시스템이 제공해야하는 기능이다.
- 소프트웨어 시스템을 구축할 때, 가장 어려운 부분은 무엇을 구축할 것인지다. 즉, 요구사항을 정확하게 결정하는 것이다.
- 소프트웨어 요구사항 도출은 시스템의 실제 요구사항을 식별하는 것을 목표로 한다.
요구사항 도출이 중요한 이유는 솔루션 공간에 대한 제약사항뿐만 아니라 시스템 기능을 정의하기 때문이다. 후속 개발 활동의 기초를 형성하기 때문에 요구사항을 잘 도출해야 한다.
1. What is Requirements Elicitation?
소프트웨어 요구사항은 시스템이 제공해야 하는 기능이다. 하나의 소프트웨어는 요구사항 충족, 예산 내 이행, 예정한 시간 내 제공, 모든 것이 만족되어야 성공할 수 있다. 그러나 이해관계자마다 비즈니스 우선 순위와 필요한 시스템 역량에 대해 다르게 인식한다.
소프트웨어 요구사항 분석은 시스템이 요구사항과 제약조건을 충족하는지 확인해야 한다. 요구사항(Requirement)과 제약조건(Constraint)의 주요 차이점은 솔루션 공간에 제약이 생기는지의 유무라고 할 수 있다. 제약조건은 설계와 구현 대안의 수를 줄인다.
예를 들면, 고객이나 정부 기관은 종종 소프트웨어 시스템에 제약을 가한다.
- 특정 제품 사용 금지
- 특정 프로그래밍 언어로 구현할 것.
이런 사항들은 정치적, 비즈니스적인 이유로 솔루션 공간을 제약한다.
2. Importance of Requirements Elicitation
세부적인 기술 요구 사항을 잘못 설정하면, 결과적으로 시스템을 마비시킨다. 추후 수정하는 것은 더욱 어렵다.
3. Challenges of Requirements Elicitation
-
개발팀은 application domain에 대해 충분히 알지 못한다.
Agile Method가 고객과의 협업, 사용자 참여를 강조하는 이유도 필요한 도메인 지식을 습득하는데 효과적이기 때문이다. -
고객과 사용자들은 소프트웨어가 무엇을 할 수 있고, 그들의 요구를 어떻게 표현해야할지 모른다.
긴밀한 협업으로 요구사항을 잘 도출해야 한다. -
공통된 배경이 부족하면 팀과 고객/사용자 간 의사소통 장벽이 형성된다.
서로의 분야에 대한 이해가 부족하다. -
소프트웨어 요구사항을 명확하게 지정할 수 없으며, 사양과 구현을 분리할 수 없다.
-
요구사항 도출의 중요성과 어려움이 종종 과소평가된다.
-
비기능적 요구사항은 식별하지 않거나 과소평가되는 경우가 많다.
비기능적 요구사항은 performance, quality, security 등 신뢰성과 관련된 영역이 포함된다. -
대상 환경에서 작동한 후에도 요구사항은 변경될 수 있다.
5. Steps For Requirements Elicitation
Ethnography는 비즈니스 조직의 외부가 아닌 내부에서 관찰하는 것을 말한다. 팀은 사용자를 이해하고 사용자처럼 생각해야 한다. 사용자가 어떻게 일하고, 어떻게 비즈니스 문제를 해결하는지 주의깊게 관찰해야 한다. 이를 위한 User Story는 요구사항 수집 방법으로 Agile method에서 널리 사용되고 있다.
- User Story는 사용자들에 의해 제작되거나 개발팀과 공동으로 제작한다.
- 각각의 User Story는 사용자 역할이 갖고 싶어하는 능력을 간략히 설명한다.
- 각각의 사용자 역할은 여러 개의 사용자 이야기를 가질 수 있다.
사용자 역할 : 의사
사용자 이야기
- 환자와의 모든 대화를 기록해야 한다.
- 특정 정보를 찾기 위해 종종 환자와의 대화를 검색해야 한다.
- 환자의 의료 검사 기록을 검색해야 한다.
6. Applying Agile Principles
Agile은 비즈니스 우선순위가 높고, 비즈니스 가치가 높은 mission-critical한 요구사항을 식별하고 검증하고 지정하는 데 초점을 맞춘다. 세부사항을 명시하지 않고, 모든 요구사항을 미리 확보하지도 않는다. 100% 정확할 필요도 없다. 요구사항이 언제든 변경될 수 있음을 인지한다. 짧은 반복 주기와 작은 증분을 갖기 때문에 변화에 더 유연하게 대응할 수 있다.
