[Software Engineering] SDLC Analysis 단계 핵심: Requirements Determination

 

 

Requirements Determination이 중요한 이유

우리가 SDLC(Systems Development Life Cycle)를 따라 개발을 진행할 때, 제일 먼저 하는 단계가 Planning이고 그 다음이 Analysis이다. Requirements Determination(요구사항 도출)은 Analysis 단계의 핵심이다.

 

왜 이게 그렇게 중요할까?  시스템 실패의 50% 이상이 요구사항 문제에서 비롯된다. 이 단계는 가장 적은 비용으로 변경이 가능한 단계이고 , 여기서 방향을 잘 잡아야 프로젝트가 문제없이 완성될 수 있다.

 

 

 

Requirements Determination

 

우리가 요구사항 도출(Requirements Determination)을 하는 궁극적인 목적은 Planning에서 넘어온 High-level의 비즈니스 요구사항(System Request)들을 상세한 요구사항으로 바꿔주는 것이다. 그렇게 되면 이걸 바탕으로 모델링을 시작한다.

 

Requirement(요구사항)이 뭘까?

요구사항은 쉽게 말해 "시스템이 반드시 해야 하는 일" 또는 "시스템이 갖춰야 할 특성"을 정의한 문장이다. 처음에는 비즈니스나 사용자 관점(business or user perspectives)에서 시작하지만 , Analysis 단계를 거치면서 최종적으로는 시스템이 어떻게 구현될지에 대한 기술적인 설명으로 발전하게 된다.

 

요구사항 정의에서 나오는 최종 산출물(deliverables)이 바로 Design 단계로 넘어가는 첫걸음이 된다.

 

요구사항은 크게 두 가지로 나뉜다.

1. Functional: 시스템의 서비스와 행동에 대한 정의. (무엇을 할 것인가?)
2. Non-functional: 시스템의 제약 조건과 품질 특성에 대한 정의. (어떻게 잘 할 것인가?)

 

 

요구사항 도출에서의 문제점

요구사항 도출 단계에서 발생하는 대표적인 문제들:

• 진짜 사용자 찾기 어려움 (Analyst may not have access to the correct users): Analyst가 실제로 시스템을 사용할 핵심 사용자(Correct Users)에게 접근하지 못하는 경우가 많다.
• 모호한 명세 (Requirements specifications may be inadequate, e.g., ambiguous): 정의된 요구사항 자체가 모호(Ambiguous)해서 문제가 있다.
• 처음부터 다 알 수 없음 (Some requirements may not be known in the beginning): 프로젝트 초반에는 모든 요구사항을 다 파악하기 어렵다는 현실적인 문제도 있다.

 

결국, 요구사항 정의는 명확하고, 구체적이며, 검증 가능한 문장을 만드는 게 핵심이다. 이 어려움을 극복하기 위해 Analysis Approaches가 필요하다.

 

 

 

Requirements Analysis Approaches

이런 문제들을 해결하고 더 나은 요구사항을 도출하기 위해, 우리가 어떤 방식으로 분석에 접근해야 할까? 

 

1. 문제 분석 (Problem Analysis)

가장 흔하게 사용되는 접근법이다.

• 사용자나 매니저에게 기존 시스템(as-is system)의 문제점을 파악해달라고 요청 , 새로운 시스템(to-be system)에서 어떻게 해결하고 싶은지를 듣는 방식이다.

 

2. 근본 원인 분석 (Root Cause Analysis)

Problem Analysis에서 더 나아간 방법이 바로 Root Cause Analysis이다.

• 단순히 "증상(Symptoms)"만 보는 게 아니라, 그 문제 뒤에 숨어있는 Root Causes(근본 원인)에 초점을 맞추는 것이다.
• 접근 방식은 현재 시스템의 문제점을 나열하고, 그 문제 하나하나에 대해 가능한 모든 근본적인 원인을 찾아보는 것이다.

 

 

 

 

보통 Fishbone Diagram을 통해 근본원인을 파악한다. 위 예시를 분석하면 다음과 같다.

• 재주문 레벨/수량 부정확 (Incorrect Reorder Level and Quantities):
  • 재주문 시점(Reorder Point)이 너무 낮게 설정됨.
  • 재주문 수량(Reorder Quantity)이 너무 적게 설정됨.
• 주문 처리 지연 (Delays in Order Processing):
  • 주문 승인(Order Approval)이 늦어짐.
  • 업체 확인(Identifying Vendor)이 늦어짐.

 

---

 

Requirements Gathering Techniques (요구사항 수집 기법)

나중에 발견되는 요구사항일수록 반영하기가 훨씬 어렵고 비용이 많이 들기 때문에 우리의 목표는 모든 요구사항을 발견하는 것이다.

 

 

기법들은 다음과 같다.

• 인터뷰 (Interviews)
• JAD (Joint Application Development)
• 설문지 (Questionnaires)
• 문서 분석 (Document analysis)
• 관찰 (Observation)

 

 

인터뷰

가장 흔하게 사용되는 기법이다.

 

질문 유형:

• 폐쇄형 질문 (Closed-ended questions): "하루에 전화 주문이 몇 건 접수되나요?"처럼 구체적인 답변을 유도한다. 주로 답이 정해져있는 질문이므로 가장 어려운 질문에 속한다.
• 개방형 질문 (Open-ended questions): "일상적으로 겪는 어려움이 무엇인가요?"처럼 넓은 범위의 의견을 모을 때 사용한다.
• 탐색 질문 (Probing questions): "예를 들어 주실 수 있나요?"처럼 앞선 답변을 깊이 파고들 때 사용하며 꼬리질문이다.
  
   

인터뷰 절차: 인터뷰 대상을 선정하고, 질문을 디자인하고, 인터뷰를 준비한 다음, 실제로 인터뷰를 진행하고, 마지막에는 후속 조치(Post-interview Follow-up)로 정리된 노트(Notes)를 인터뷰이에게 보내 Verification받는 과정이 필수이다.

 

 

 

JAD (Joint Application Development)

JAD는 퍼실리테이터(Facilitator) 주도 하에 여러 사용자(10~20명)와 분석가들이 한자리에 모여 요구사항을 논의하는 공동 회의 방식이다.

• 강점: 사용자 참여도(User Involvement)가 매우 높고 , 정보를 통합(Integration)하기 좋기 때문에 요구사항을 종합적으로 빠르게 도출할 수 있다. 특히 프로젝트 범위가 점점 확장되는 Scope Creep 현상을 방지하는 데 효과적이다.
  
  
• 진행: 인터뷰처럼 Top-down 방식의 질문을 사용하고 , 성공적인 세션을 위해선 사전 계획(Careful planning)과 규칙(Ground rules) 설정이 중요하다.

 

Questionnaires (설문조사)

인터뷰나 JAD처럼 깊이 있는 정보를 얻기는 어렵지만, 광범위한 정보를 효율적으로 얻을 수 있다는 엄청난 장점이 있다.

주요 활용 시점:

1. 조사 대상이 많을 때 (Large numbers of people):
2. 정보와 의견 모두 필요할 때 (Need both information and opinions):
3. 외부 사용자 대상일 때 (Designing for use outside the organization):

 

다만, 설문지의 단점은 응답률(Typical response rates)이 종이 설문지는 50% 미만, 웹 기반 설문지는 30% 미만으로 낮다,

 

 

 

 

---

 

 

 

Document Analysis & Observation

우리가 인터뷰나 설문지로 사람들이 생각하는 요구사항을 모았다면, 이제는 사람들이 실제로 하는 일을 통해 요구사항을 검증하고 숨겨진 요구사항을 찾아내야한다. 

 

 

Document Analysis

Document Analysis는 현재 시스템(as-is system)에 대한 정보를 파악하는 데 가장 기본이 된다.

• 양식(Forms)
• 보고서(Reports)
• 정책 매뉴얼(Policy manuals) 

하지만 이 문서들이 설명하는 formal system을 완전히 믿을 수 있을까?

 

A formal system과 a real informal system사이에는 괴리가 존재한다. 따라서 사용되지 않는 요소를 찾고 추가적인 폼을 찾는 것이 필요하다.

 

 

Observation

Observation은 사용자들이 실제로 일하는 모습을 보면서 정보를 수집하는 기법이다.

• 검증의 도구: 사용자들이 인터뷰에서 말한 내용의 validity을 확인하는 데 도움이 된다. 
• 관찰의 딜레마: 하지만 사람이 관찰당하면 행동이 바뀔 수 있다는 문제(Behaviors may change when people are watched)가 있기에 사용자가 관측된다고 느끼면 안된다.
• 요령: 그래서 분석가는 최대한 티 내지 않고(Keep a low profile), 그들의 일에 방해되거나 영향을 주지 않도록 노력해야한다.
• 주기적 활동: 주간, 월간, 연간처럼 주기적으로 발생하는 활동(periodic activities)을 놓치지 않도록 주의해야한다. 

 

결론적으로, 우리가 관찰하는 것이 실제로 존재하는 것과 다를 수 있다는 점을 항상 염두 해야한다. "스티브 잡스는 ‘사람들은 직접 보여주기 전까지 자신이 무엇을 원하는지 모른다’고 말했듯이, 단순히 고객의 말만 듣는 것으로는 충분하지 않다."

 

 

 

 

 

 

이 단계에서 모든 요구사항을 모으고 다음 단계인 Text analysis에서 modeling basis를 추출한다.

 

 

 

---

 

 

 

Text Analysis

요구사항 수집 기법의 결과로 나온 텍스트들을 그냥 두는 게 아니라, 분석해서 시스템을 구성할 핵심 객체(Object)와 그들의 관계(Relationship)를 파악하는 작업이다.

 

1. 문장 분석 (Sentence Diagram)

문장 분석은 문장을 시각적으로 도식화해서 시스템의 주요 관심 객체(primary objects of interest)를 식별하는 데 도움을 준다.

2. 의미적 관계 식별 (Identifying Semantic Relations)

도메인 분석을 위해 텍스트에서 보편적인 의미적 관계(universal semantic relationships)를 파악해야한다.

3. 분류 분석 (Taxonomic analysis)

분류 분석은 이 의미적 관계들을 사용해서 문제 도메인(problem domain) 내의 서로 다른 관심 객체들을 연결하는 것이다. 이걸 통해 객체 지향 모델링의 기반이 되는 계층 구조나 연관 관계를 시각화할 수 있다.

 

 

 

---

 

 

 

 

 

Requirement Definition(요구사항 정의)

텍스트 분석으로 객체와 관계까지 파악했다면, 이제 이 모든 정보를 정리해서 Requirement Definition 단계이다.

• 작성 형태: 기능적/비기능적 요구사항을 outline format으로 나열
• 협업: 사용자(User)와 분석가(Analyst)가 긴밀하게 협력해서 사용자가 실제로 필요로 하는 것이 무엇인지 정의.

가장 중요한 목적: 이 문서가 바로 시스템의 범위(System Scope)를 정의한다.

• 무엇을 할지(what to do), 그리고 무엇을 하지 않을지(what not to do)를 명확히 한다. 이 범위 설정이 제대로 안 되면 프로젝트는 Scope Creep에 빠진다

 

기능 요구사항 vs. 비기능 요구사항 (Functional vs Non-functional)

이 둘을 명확히 구분해야한다.

• Functional requirements(기능 요구사항): 시스템이 제공해야 할 서비스, 특정 입력에 대한 반응, 특정 상황에서의 행동을 정의한다. (예: 환자는 예약을 변경할 수 있어야 한다)

 

 

• Non-functional requirements(비기능 요구사항): 시스템의 기능/서비스에 대한 제약 사항(Constraints)이다. 시스템 전체에 적용되는 경우가 많고, 개발 프로세스나 표준에 대한 제약도 포함된다. (예: 시스템은 윈도우 환경에서 작동해야 한다(Operational) , 새로운 약속은 2초 이내에 저장되어야 한다(Performance))

 

 

 

---

 

 

User Stories

Agile 개발 방식에서는 공식적인 요구사항 정의를 대신하거나 보조하기 위해 User stories를 사용한다.

• 표준 형식: As a <role>, I want to <list of functions> so that <list of objectives>.
• 예시: "As a secretary, I want to be able to schedule appointments for our patients so that we can meet our patients' needs".

사용자의 역할과 원하는 기능, 그리고 그 목적을 한 문장으로 명확하게 전달하기 때문에, 개발팀이 사용자 관점에서 기능을 이해하는 데 효과적이다.

 

 

---

 

The System Proposal (시스템 제안서)

Analysis 단계의 마지막 문서가 바로 The System Proposal이다. 이 문서는 Planning 단계와 Analysis 단계에서 만들어진 모든 핵심 자료를 통합하는 종합 보고서이다.

 

 

주요 구성 요소:

1. Executive Summary (경영진 요약): 바쁜 경영진이 빠르게 훑어보고 어떤 부분을 자세히 읽을지 결정할 수 있도록 모든 핵심 정보를 요약한다.
2. System Request, Workplan, Feasibility Analysis: Planning 단계의 문서들을 Analysis 결과를 바탕으로 업데이트한 내용이다.
3. Requirements Definition: 최종 확정된 Functional/Non-functional 요구사항 목록이다.
4. Functional/Structural/Behavioral Models: 요구사항을 바탕으로 도출된 시스템의 초기 모델들이다.

 

 

---

 

 

결론적으로,

요구사항 도출(Requirement Determination)은 소프트웨어 개발에서 가장 중요한 작업(most important work)이고 , 이 과정을 통해 시스템의 비전이 개발되고(vision of the system can be developed) , 모든 자료가 시스템 제안서로 통합되어 다음 단계로 나아갈 수 있다.

 

 

 

 

출처: 경북대학교 손정주 교수님, “소프트웨어설계” 강의 자료