Requirements Capture
요구사항 포착
- 다른말로, Specification이라 한다.
- Software Development Process 중, Requirement를 찾고 Documentation하는 가장 중요한 단계이다.
Point of User Requirement Capture (사용자 요구사항 포착의 요점)
- 해당 소프트웨어를 사용하는 조직이 어떻게 구동되고 있는지를 이해해야 한다.
- 기존 시스템을 분석하여 문제점을 파악해야 한다.
- 기존 시스템에 없는 기능을 파악하여 새로 개발될 시스템에 포함시켜야 한다.
Reasons for Investigating the Current System (기존 시스템을 분석하는 이유)
- 아예 새로운 시스템을 개발하는 경우보다, 기존의 시스템을 업그레이드 하는 경우가 많기 때문에
기존 시스템을 분석하는 것은 개발에 있어서 필수사항이며, 분석을 수행하는 자세한 이유는 아래와 같다.
- 기존 시스템 기능의 일부가 새로운 시스템 개발에 필요할 수 있기 때문이다.
- 기존 시스템에서 사용하던 데이터가 새로운 시스템에 필요할 수 있기 때문이다.
- DBMS Migration이 필요할 수 있다. - 기존 시스템의 Technical Document을 통해 세부적인 Processing Algorithm을 알아낼 수 있기 때문이다.
- 기존 시스템의 Defect(Bug)를 파악하여 새로운 시스템에서 이를 예방할 수 있기 때문이다.
- 기존 시스템을 분석함으로써 작업과정을 이해할 수 있기 때문이다.
- 기존 시스템의 Baseline Information을 분석하여 새로운 시스템의 Performance Target을 설정할 수 있기 때문이다.
- Baseline Information은 무엇을 결정하기 위한 기반정보를 의미한다.
Reasons Why to be Generated New Requirements (새로운 요구사항이 생성되는 이유)
- 빠르게 변하는 Business Environment에 대응해야 하기 때문이다.
- 빠르게 변하는 Technical Environment에 대응해야 하기 때문이다.
- Government와 Supra-Goverment에서 새로운 규제 및 법규를 제정하기 때문이다.
Types of Requirements (요구사항의 유형)
- 요구사항을 유형으로 나누면 아래와 같이 나눌 수 있다.
- Functional Requirement (기능적 요구사항)
- Non-Functional Requirement (비기능적 요구사항)
- Usability (사용성)
- Non-Functional Requirement에 Usability를 포함시키는 경우도 있다.
Functional Requirement (기능적 요구사항)
- "Describe what a system must do"
- 시스템이 해야하는 것을 기술한 요구사항을 의미한다.
- 시스템이 수행하는 Processing이 여기에 해당된다.
- 시스템에 입력되는 Documents, Interactions between people, Other Systems와 같은 Detail Inputs과
시스템에서 출력되는 Documents, Screen Displays와 같은 Expected Outputs이 기술되어야 한다.
- Requirement List를 작성하고 Use-Case Diagram으로 모델링된다.
Non-Functional Requirement (비기능적 요구사항)
- "Concerned with how well the system provides the functional requirements"
- 기능적 요구사항을 얼마나 잘 제공하는지에 대한 요구사항을 의미한다.
- Performance Criteria가 여기서 고려되어야 하는 사항이다.
(Response Time, Anticipated Data Volumes, Security Level 등)
- Diagram으로 표현하기 어렵고, 주로 Requirement List를 작성하여 Document로 표현된다.
Usability (사용성)
- "Concerned with matching the system to the way that people work"
- 사용자의 입장에서 사용하기 편리한지에 대한 요구사항을 의미한다.
- 사용자가 직업적으로 시스템을 사용하는지, 취미로써 사용하는지에 대한 정보를 알아야한다.
- Acceptance Criteria가 여기서 고려되어야 하는 사항이다.
(Font Size, Button Size 등)
- Diagram으로 표현하기 어렵고, 주로 Requirement List를 작성하여 Document로 표현된다.
- Usability는 사용자와 Interaction하는 UI와 관계가 깊어, Prototyping이 이루어져야 한다.
Fact Finding Techniques (Requirement Finding Techniques; 요구사항을 찾는 방법)
- 요구사항을 도출해내는 방법들에는 아래와 같은 것들이 있다.
- Background Reading (배경 조사)
- Interviewing (면담)
- Observation (관찰)
- Questionnaires (설문조사)
Background Reading (배경조사)
- 시스템을 사용하는 조직과 비즈니스 목표를 이해한다.
- Reports, Organization Charts, Policy Manuals, Job Description, Documentation of Existing Systems
등을 이용하여 조사한다.
- 해당 조직을 이해하고 다른 Fact Finding 작업을 준비하는데 도움이 된다.
(즉, 배경조사는 가장 먼저 시행하기에 좋다.)
- Document들이 Out of Date되어 있거나 실제 운영사항들을 모두 반영하고 있지 않아 배경조사가 어려울 수 있다.
Interviewing (면담)
- 시스템을 사용하는 조직의 목표와 사용자의 요구사항, 사람들의 역할에 대해 심층적으로 이해한다.
- 조직의 목표를 이해하기 위해 Manager와 면담하거나
정보를 얻고 역할들을 파악하기 위해 Staff들과 면담할 수 있다. (Customized S/W를 개발하는 경우)
- 잠재적인 사용자가 될 수 있는 Customer 혹은 Public과 면담할 수 있다. (Generic S/W를 개발하는 경우)
- 대부분의 프로젝트 유형에서 면담은 필수적인 과정이며, 기존 시스템에서 심층적인 정보를 얻어내야할 때 적합하다.
- Adaptive하게 정보를 얻어낼 수 있고, 깊이있는 정보를 얻어낼 수 있다.
- 시간과 비용이 비교적 많이 들며,
원하는 답변을 유도하여 객관적이지 못한 편향된 응답을 듣게 될 수 있으며,
Interviewee들 간의 답변이 불일치하면(Conflicting Information) 어떤 정보가 맞는지 확인하기 어렵다.
Observation (관찰)
- 실제 작업환경을 관찰하며 정보를 얻고,
새로운 시스템 개발을 위한 Baseline Information을 얻을 수 있다.
- 다른 소스로부터 얻어낸 정보를 검증하고
Conflicting Information을 검증할 수 있다.
- 기존 시스템이 어떻게 운영되는지를 직접 볼 수 있고,
직접 확인하며 다른 유형의 Fact Finding 작업들을 검증할 수 있으며,
Baseline Data를 수집할 수 있다.
- 관찰자에 의해 기존 직원들이 불편감을 느껴 평소와 달리 행동할 수 있어 얻어내는 정보에 왜곡이 있을 수 있다.
Questionnaires (설문조사)
- 많은 사람들로부터 의견을 얻어 통계를 낸다.
- Generic S/W를 개발할 때 적합하다.
- 정보를 얻어낼 사람들이 지리적으로 분산되어 있을 때 적합하다.
- 설문조사를 수행하는데 드는 Cost가 저렴하고,
많은 사람들로부터 많은 정보를 얻을 수 있으며,
지리적으로 분산되어 있는 사람들로부터 정보를 얻을 수 있는 효율적인 방법이다.
- 양질의 설문조사를 설계하기에 난이도가 높으며,
결과를 Follow-Up하거나 깊이있는 조사를 자동적으로 할 수 있는 방법이 없다.
Reference: Software Engineering 10th Edition
(Ian Sommerville 저, Pearson, 2016)
Reference: Object-Oriented Systems Analysis and Design Using UML 4th Edition
(Simon Bennett, Steve McRobb, Ray Farmer 저, McGrawHill, 2010)
