소프트웨어 기능 요구사항 상세화 수준

출처: https://re-magazine.ireb.org/

 

소프트웨어 요구사항을 분석하거나 요구사항 명세서를 작성하는 관점에서 볼 때, 실무에서 가장 많이 고민하는 질문은 "요구사항을 어느정도로 상세하게 작성해야 하는가?" 일 것입니다. 이에 대한 정확한 답을 내기에는 프로젝트마다 달라질 것이며, 프로젝트의 진행 정도에 따라서도 달라질 것이며, 프로젝트 실무자 즉, 이해관계자들에 따라서도 달라질 수 있는 문제라고 생각합니다.
그렇다면 객관적으로 소프트웨어 요구사항 상세화는 어떻게 접근하는 것이 올바른 방향일까를 고민하기 위해 다음 글을 작성해 봅니다.

먼저 소프트웨어 기능 요구사항의 상세화는 소프트웨어 동작에 대한 세부 묘사의 많고 적음에 따라 달라진다고 보아야 할 것입니다. 즉, 소프트웨어 기능의 설명이 얼마나 자세하거나 일반적인지에 따라 상세화 수준이 결정된다고 할 수 있습니다. 따라서 프로젝트의 다양한 단계에서는 기능 요구사항의 설명에 대해 서로 다른 세부 수준을 요구합니다: 초기 프로젝트 단계에서는 광범위한 범위의 비전이 필요하고, 후반 단계에서는 더 깊이 있는 내용 설명 및 요구사항이 작성되어야 합니다.

1. 들어가며

소프트웨어 요구사항은 기능 요구사항(FR, Functional Requirements)과 비기능 요구사항(Non-Functional Requirements)으로 구분됩니다. "기능 요구사항은 소프트웨어 기능이 제공해야 할 동작과 동작의 결과에 관한 요구사항입니다." 이러한 기능 요구사항(FR)은 소프트웨어가 사용자에게 제공할 작업과 서비스 측면에서 소프트웨어가 무엇을 해야 하는지를 명시하며, 데이터 전송, 데이터 변환, 데이터 저장 및 데이터 검색을 포함할 수 있습니다. 이러한 유형의 요구사항은 소프트웨어가 사용자에게 무엇을 해야 하는지를 의미하며, 외부 사건에 반응하거나 외부 사건을 발생시키는 소프트웨어의 의도된 동작을 나타냅니다. 그리고 비기능 요구사항(NFR)은 소프트웨어 기능이 사용자에게 전달되는 방식과 관련이 있으며, 품질, 기술적, 환경적 및 조직적 제약이 주로 비기능 요구사항으로 작성될 수 있습니다.
예를 들어 ATM 기기에 대한 FR/NFR이 다음과 같을 때, 기능 요구사항은 소프트웨어 특정 부분의 동작을 찾을 수 있다면, 비기능 요구사항은 소프트웨어 전체에 적용되는 경우가 많습니다.

• FR: 시스템은 현재 계좌 잔액을 조회해야 한다 (무엇)
• NFR: 시스템은 모든 거래를 최대 30초 이내에 완료해야 한다 (어떻게)

요구사항 엔지니어링에서는 두 가지 유형 모두 중요합니다. 둘 다 도출되고, 분석되며, 명세화되고, 모델링되고, 관리되어야 합니다. 그러나 요구사항 세분화에 대한 주제는 주로 기능 요구사항(FR)에 한정하여 작성하고자 합니다.

---

2. 요구사항 세분화 수준

ATM 시스템의 예를 계속하면, 요구사항 명세서에는 다음과 같은 요구사항이 존재할 수 있습니다.

• 시스템은 현재 계좌에서 거래를 수행해야 한다.
• 시스템은 하나의 현재 계좌에서 다른 현재 계좌로 금액을 이체해야 한다.
• 시스템은 고객의 카드와 비밀번호를 확인해야 한다.
• 시스템은 하루 동안 고객 거래의 총 금액이 $5000을 초과하지 않도록 해야 한다.

이 네 가지 예는 모두 유효한 기능 요구사항이지만, 각 요구사항별로 세분화 수준이 모두 다릅니다. 먼저 첫번째 요구사항은 정확하지 않은 묵시적인 내용이 포함되어 있습니다. 예를 들어 현재 계좌에 액세스되는 거래의 수가 몇개인지, 거래의 종류가 인출인지, 입금인지 등의 정보가 정확히 표기되지 않았습니다. 다만, 시스템을 사용하는 사용자는 "현재 계좌"에서만 거래가 이루어져야 한다는 기능만을 포함하고 있습니다. 반면 두 번째 요구사항은 현재 계좌가 하나임을 명시적으로 표현하고 있으며, 거래의 유형도 명확하게 "이체"라는 행위로 한정하고 있습니다. 그리고  세 번째 및 네 번째 예는 사용자가 요구하는 특정 기능을 명시 한다기 보다, 앞서 정의된 기능들을 처리 하기 위한 부가적인 제약사항들을 기술하고 있습니다. 즉, 첫번째와 두번째 예는 기능 요구사항의 세분화 수준을 표현하고 있지만, 세번째와 네번째는 기능에 대한 비기능 요구사항을 표현한 예라고 볼 수 있습니다.

세분화 수준은 기능 요구사항에서 소프트웨어의 기능을 설명하는 정보의 양이 많고 적음을 나타냅니다. 이는 요구사항을 통해 정의하고자 하는 요구사항 목표의 유형과 관련이 있으며, 이러한 요구사항 목표를 몇가지 기준에 따라 분류하는 방법론이 이미 제안되었으며 요구사항 엔지니어가 세분화 수준에 주목하여 요구사항 도출/정의를 보다 효과적으로 수행하고 더 높은 품질의 사양을 개발하는데 도움을 줍니다.

2.1 RAM(Requirements Abstraction Model)

RAM은 요구사항을 체계적으로 분류하고 관리하기 위한 모델입니다. RAM은 요구사항을 네 가지 수준으로 나누어 소프트웨어 개발의 각 단계에서 요구사항을 명확히 하고, 요구사항 간의 관계를 이해하며, 요구사항 관리의 효율성을 높이는 데 도움을 줍니다. RAM은 특히 복잡한 시스템의 요구사항을 명확히 하고, 이해 관계자 간의 의사소통을 개선하는 데 효과적입니다.
RAM 모델은 다음과 같은 네 가지 수준으로 요구사항을 분류합니다:

2.1.1. 제품 수준 (Product Level)

제품 수준은 조직의 전략과 목표에 맞추어 제품이 달성해야 할 주요 비즈니스 목표를 정의합니다. 이 수준에서는 전체 제품의 목표와 방향을 설정하고, 제품이 달성해야 할 주요 비즈니스 목표를 명확히 합니다.

• 예시:
  • “제품은 시장 점유율을 10% 증가시켜야 한다.”
  • “제품은 연간 매출을 20% 증가시켜야 한다.”
  • “제품은 고객 만족도를 85% 이상 유지해야 한다.”
• 특징:
  • 조직의 전략적 목표와 직접적으로 연관됩니다.
  • 경영진과 고위 관리자에 의해 설정됩니다.
  • 전체 프로젝트의 방향성을 결정합니다.

2.1.2. 기능 수준 (Feature Level)

기능 수준은 제품이 제공할 주요 기능을 정의합니다. 이 수준의 요구사항은 사용자가 제품을 사용할 때 기대하는 주요 기능과 특징을 설명하며, 제품의 가치와 사용자 경험을 향상시키는 데 중점을 둡니다.

• 예시:
  • “제품은 사용자 로그인 기능을 제공해야 한다.”
  • “제품은 사용자 프로필 편집 기능을 제공해야 한다.”
  • “제품은 상품 검색 기능을 제공해야 한다.”
• 특징:
  • 제품이 제공할 주요 기능과 특징을 설명합니다.
  • 제품 관리자와 기획자가 작성합니다.
  • 사용자 경험을 개선하고 제품의 가치를 높이는 데 중점을 둡니다.

2.1.3. 기능 수준 (Function Level)

기능 수준은 사용자가 소프트웨어를 통해 수행할 수 있는 특정 작업과 이 작업이 어떻게 수행되는지를 상세히 설명합니다. 이 수준의 요구사항은 소프트웨어가 수행해야 할 구체적인 기능을 명확히 합니다.

• 예시:
  • “시스템은 사용자가 자신의 계좌 잔액을 확인할 수 있도록 해야 한다.”
  • “시스템은 사용자가 계좌 이체를 할 수 있도록 해야 한다.”
  • “시스템은 사용자가 상품을 장바구니에 추가할 수 있도록 해야 한다.”
• 특징:
  • 사용자가 소프트웨어를 통해 수행할 수 있는 구체적인 작업을 설명합니다.
  • 시스템 분석가와 개발자가 작성합니다.
  • 소프트웨어가 제공할 기능을 명확히 정의합니다.

2.1.4. 구성 요소 수준 (Component Level)

구성 요소 수준은 소프트웨어의 특정 구성 요소와 이 구성 요소가 어떻게 구현될지를 상세히 설명합니다. 이 수준의 요구사항은 소프트웨어의 기술적 구현 방법과 관련된 세부 사항을 다룹니다.

• 예시:
  • “시스템은 데이터베이스에 사용자 계좌 정보를 저장해야 한다.”
  • “시스템은 암호화된 비밀번호를 사용하여 사용자 인증을 수행해야 한다.”
  • “시스템은 REST API를 통해 외부 시스템과 통신해야 한다.”
• 특징:
  • 소프트웨어의 특정 기술적 구현 방법을 설명합니다.
  • 개발자와 설계자가 작성합니다.
  • 구현 세부 사항과 관련된 요구사항을 다룹니다.

2.2 CREWS(Cooperative Requirements Engineering With Scenarios) RE 프로세스

CREWS RE 프로세스는 요구사항 엔지니어링을 체계적으로 수행하기 위한 시나리오 기반 접근법입니다. 이 프로세스는 요구사항을 도출, 분석, 명세화, 검증 및 관리하는 데 도움을 주며, 복잡한 시스템의 요구사항을 명확히 하고 이해 관계자 간의 의사소통을 개선하는 데 효과적입니다. CREWS RE 프로세스는 요구사항을 세 가지 주요 추상화 수준에서 정의합니다:

2.2.1. 맥락적 수준 (Contextual Level)

맥락적 수준에서는 시스템이 제공해야 할 서비스와 그 합리성을 식별합니다. 이 수준에서는 시스템이 조직의 목표와 어떻게 일치하는지, 어떤 비즈니스 프로세스를 지원하는지, 이해 관계자의 요구사항과 기대를 반영합니다.

• 목적: 시스템의 전체적인 목적과 비즈니스 환경을 이해하는 것
• 내용: 시스템의 목표, 비즈니스 프로세스, 이해 관계자의 요구사항
• 활동: 비즈니스 목표와 요구사항을 도출하고 문서화
• 예시:
  • “은행 시스템은 고객이 온라인으로 계좌를 개설할 수 있도록 해야 한다.”
  • “병원 관리 시스템은 환자의 예약 일정을 관리할 수 있어야 한다.”

2.2.2. 기능적 수준 (Functional Level)

기능적 수준에서는 시스템과 사용자 간의 상호 작용을 중점적으로 다룹니다. 이 수준에서는 시스템이 제공해야 할 구체적인 기능과 서비스를 정의합니다.

• 목적: 사용자와 시스템 간의 상호 작용을 명확히 정의
• 내용: 사용자 시나리오, 유스케이스, 구체적인 기능 요구사항
• 활동: 유스케이스 및 시나리오 작성, 기능 요구사항 명세화
• 예시:
  • “사용자는 로그인 페이지를 통해 시스템에 접근할 수 있어야 한다.”
  • “사용자는 계좌 잔액을 조회할 수 있어야 한다.”

2.2.3. 물리적 수준 (Physical Level)

물리적 수준에서는 시스템의 실제 성능과 상호 작용을 다룹니다. 이 수준에서는 시스템이 어떻게 구현될지에 대한 기술적인 세부 사항을 정의합니다.

• 목적: 시스템의 물리적 구현을 정의
• 내용: 시스템 아키텍처, 데이터베이스 설계, 기술적 요구사항
• 활동: 기술적 요구사항 명세화, 시스템 설계 문서 작성
• 예시:
  • “시스템은 SSL을 사용하여 모든 데이터 전송을 암호화해야 한다.”
  • “데이터베이스는 사용자의 로그인 정보를 안전하게 저장해야 한다.

2.3 User Stories applied for Agile Software Development

User Stories Applied for Agile Software Development에서는 사용자 스토리를 체계적으로 관리하고 이해하기 위해 다양한 분류 체계를 사용합니다. 이러한 분류 체계는 사용자 스토리를 더 작은 단위로 나누고, 우선순위를 설정하며, 전체 시스템의 기능을 더 잘 이해하는 데 도움이 됩니다. 주요 분류 체계는 다음과 같습니다:

2.3.1. 에픽 (Epic)

에픽(Epic)은 크고 광범위한 사용자 스토리로, 구현하는 데 여러 스프린트가 필요할 수 있습니다. 에픽은 나중에 더 작은 사용자 스토리로 분할될 수 있습니다.

• 특징:
  • 매우 큰 사용자 스토리.
  • 여러 스프린트에 걸쳐 구현될 수 있음.
  • 세분화되지 않은 상태로 유지되어 있다가 필요에 따라 분할됨.
• 예시:
  • “As a user, I want to manage my account so that I can keep my information up-to-date.”
  • 이는 다양한 작은 스토리(예: 프로필 편집, 비밀번호 변경 등)로 나눌 수 있습니다.

2.3.2. 테마 (Theme)

테마(Theme)는 관련된 여러 사용자 스토리의 집합으로, 특정 기능이나 목표를 달성하기 위해 그룹화된 스토리입니다. 테마는 프로젝트의 특정 영역이나 모듈을 나타낼 수 있습니다.

• 특징:
  • 공통된 목표를 가진 여러 사용자 스토리의 그룹.
  • 프로젝트의 특정 영역을 포괄함.
  • 관련된 스토리들을 한데 모아 관리함.
• 예시:
  • “결제 처리” 테마는 다음과 같은 사용자 스토리를 포함할 수 있습니다:
  • “As a user, I want to add items to my cart so that I can purchase them later.”
  • “As a user, I want to apply discount codes so that I can get a discount on my purchase.”
  • “As a user, I want to complete the payment process so that I can finalize my purchase.”

2.3.3. 사용자 스토리 (User Story)

사용자 스토리(User Story)는 단일 기능이나 작업을 설명하는 간단한 요구사항입니다. 사용자 스토리는 사용자 관점에서 기능을 설명하며, “누가”, “무엇을”, “왜”의 세 가지 요소로 구성됩니다.

• 특징:
  • 특정 사용자 기능을 설명하는 간단한 요구사항.
  • 하나의 스프린트에서 구현할 수 있을 만큼 작음.
  • 수용 기준과 함께 작성되어 명확한 완료 조건을 제공함.
• 예시:
  • “As a user, I want to log in to the system so that I can access my personal dashboard.”
  • “As a customer, I want to search for products so that I can find items I want to purchase.”

2.3.4. 작업 (Task)

작업(Task)은 사용자 스토리를 구현하기 위한 구체적인 개발 작업입니다. 작업은 개발자가 사용자 스토리를 완성하기 위해 수행해야 하는 세부 활동을 설명합니다.

• 특징:
  • 사용자 스토리를 구현하기 위한 구체적인 개발 활동.
  • 개발자가 수행해야 하는 작은 단위의 작업.
  • 사용자 스토리를 완료하는 데 필요한 모든 작업을 포함함.
• 예시:
  • “데이터베이스에 사용자 테이블 생성”
  • “로그인 페이지 디자인”
  • “사용자 인증 API 구현”

---

3. 요구사항 추상화

요구사항 추상화는 여러 요구사항들을 다양한 기준에 따라 그룹화 한 것으로 볼 수 있으며, 소프트웨어 개발에서 요구사항을 다양한 수준으로 나누어 이해하고 관리하는 것을 의미합니다. 이를 통해 요구사항 상세화 단계가 계층화되어 정리되며, 요구사항의 복잡성을 줄이고 명확한 이해와 효율적인 관리를 가능하게 합니다. 따라서 요구사항 추상화 수준이 높을수록 요구사항이 일반적이기 때문에, 고수준의 추상화된 요구사항을 달성하기 위해서는 추상화 그룹 내 하위 수준의 요구사항을 먼저 달성해야 하며, 각 하위 수준의 요구사항은 상위 수준 요구사항의 목표 범위 내에서 상세화가 이루어져야 합니다.

이때 중요한 사항은 요구사항의 "범위"인데, 요구사항이 상세화가 된다는 의미는 앞에서 언급한 바와 같이 보다 많은 정보가 추가적으로 기술된다는 의미이므로, 상위 요구사항의 목표를 벗어나는지를 잘 확인해야 합니다. 가령 앞의 예에서처럼 ATM 요구사항 중  "한 계좌에서만 거래가 이루어져야 한다."는 상위 요구사항이 있을때, 이 상위 요구사항의 목표는 첫째, 여러개의 계좌가 아니라 하나의 계좌에서만 거래가 이루어져야 한다는 점과, 두번째 거래라는 "행위" 자체가 구체화되어야 한다는 점입니다. 예를 들어 거래의 종류가 "입금"인지, "출금"인지, "이체"인지에 대한 상세화에 중점을 두어야지, 거래 자체를 위한 제약사항 즉, "인증서 확인" 이라든지, "거래 처리 제한시간" 과 같은 추가 상세화 항목은 요구사항을 상세화 함에 있어 혼란만 가중시킨다는 점을 이해해야 합니다.

참고로 행위에 추가적인 정보는 각 기능의 "비기능 요구사항(NFR)"으로 간주되어 정의하는 것은 당연히 필요한 사항입니다.

---

4. 기능 vs. 비기능 요구사항 식별

기본적으로 기능 요구사항은 소프트웨어에서 구현되어야 할 요구사항 목표를 의미하며, 비기능 요구사항은 이러한 기능에 대한 단계, 규칙, 제약사항등과 관계가 있다고 볼 수 있습니다.  예를 들어 아래 요구사항들을 살펴 보겠습니다.

• 카드가 유효한지 확인합니다.
• 선택한 거래가 카드 유형과 호환되는지 확인합니다.
• 제공된 비밀번호가 올바른지 확인합니다.
• 제공된 비밀번호가 잘못된 경우 비밀번호 오류 횟수를 증가시킵니다.
• 제공된 비밀번호가 올바른 경우 비밀번호 오류 횟수를 0으로 재설정합니다.

먼저 고객의 카드와 비밀번호를 확인하는 것은 고객이 ATM을 사용할 때의 목표가 아닙니다. 그러나 이는 목표를 달성하기 위해 필요한 중간 단계입니다: 예를 들어, ATM을 사용하는 기본 목표는 "인출을 수행"하는 것이지, 카드의 유효성 자체를 확인하는 것은 아닙니다. 이는 기능 수행을 위한 단계, 규칙, 제약사항등을 표현한 것으로 비기능 요구사항에 가깝다고 볼 수 있습니다. (나머지도 마찬가지)

이러한 비기능 요구사항은 일반적으로 비즈니스 정책과 관련이 있으며, 비즈니스 프로세스를 보완하는 방식으로 설명합니다. 이는 또한 비즈니스 규칙으로 알려져 있으며, 예를 들어 기업 정책, 정부 규제 또는 소프트웨어가 준수해야 하는 산업 표준을 설명할 수 있습니다.

예, “시스템은 하루 동안 고객 거래의 총 금액이 $5000을 초과하지 않도록 해야 한다”의 경우입니다. 비즈니스 규칙은 여러 FR 또는 조직의 다양한 소프트웨어 제품 간에 공유되는 경우가 많습니다.

---

5. 왜 기능 요구사항의 세분화 수준에 주의해야 하는가?

간단히 말해, 더 낮은 세분화 수준으로 지정하면 더 많은 노력과 시간이 필요합니다. 그리고 필요 이상으로 요구사항을 상세히 기술하는 것은 노력의 낭비입니다. 반면, 실제로 더 많은 세부 사항이 필요한 경우 더 높은 세분화 수준으로 지정하면 범위에 대한 적절한 결정을 내릴 수 없습니다. 따라서 소프트웨어 개발에서 기능 요구사항을 적절히 세분화 하면 소프트웨어 설계, 개발, 테스트, 유지보수 등 모든 단계에서 명확성화 효율성을 높일 수 있습니다.

그러나 기능 요구사항의 세분화는 여러 이해관계자들의 협업과 이해가 수반되어야 하며, 세분화를 위한 많은 정보를 추가로 도출하고 문서화 해야 하며, 그에 따른 기술적 성숙도가 완성되어 있어야 원활한 세분화가 가능해 지기 떄문에, 이러항 사항들은 기능 요구사항에 대한 세분화를 어렵게 만드는 요인이 되기도 합니다.

5.1 이해관계자의 협업과 이해

기능 요구사항은 요구사항 분석가와 설계 및 개발자, 그리고 테스터를 비롯한 다양한 이해관계자들이 달성해야 할 목표입니다. 따라서 이들간의 적절한 협업을 통해 필요한 요구사항 도출이 이루어져야 하기 떄문에, 충분한 협의와 검토가 이루어져야 합니다. 이 과정에서 각 이해관계자들의 명확한 용어의 사용과 기능 항목 범위에 대한 합의 등이 전제되어야 합니다. 이를 위해 요구사항에 대한 합의된 템플릿 기반의 요구사항 세분화는 이해관계자간 협업 및 이해에 도움을 줄수 있습니다.

5.2 기능 요구사항 정보 상세화

기능 요구사항은 목표와 행위에 대한 상세함을 표현함에 있어 상위 수준의 요구사항보다 많은 정보들을 표현해야 합니다. 앞의 예에서 "은행 거래"라는 행위를 상세화 한다는 측면에서 보면 먼저 "거래"의 행위에는 "입금", "출금", 그리고 "이체"의 행위로 상세화 할 수 있습니다. 그리고 "입금" 행위도, "현금 입금", "카드 입금", "통장 입금", "무통장 입금", 그리고 최근에는 휴대폰을 활용한 "온라인 입금"으로도 상세화 할 수 있습니다. 그러나 여기서 휴대폰을 활용한 온라인 입금에 대한 행위에서 휴대폰에서 입력되는 데이터 처리 기술이나, 인프라, 보안, 통신과 관련된 기술적 이해를 수반하는 것은 기능 요구사항 정보를 상세화의 어려움을 야기시키는 요인중 하나라고 볼 수 있습니다. 따라서 크로스 팀 구성이나, 도메인 전문가의 참여, 그리고 점진적 세분화를 통해 어려움을 감소 시킬 수도 있습니다.

---

6. 요구사항 상세화와 테스트 레벨

요구사항 상세화에서 고려해야 할 또하나의 사항으로 "기능 요구사항의 상세화는 어느수준까지 이루어져야 하는가?" 라는 질문일 것입니다. 요구사항 상세화는 그 자체가 많은 시간과 자원을 필요로하는 활동이기 때문에 어떤 기준이 제시되지 않으면, 매우 소모적이고 고통스런 반복 작업의 연속일 것입니다. 따라서 요구사항 상세화는 테스트 레벨과 연계하여 명확한 기준을 수립하는 것이 필요합니다.

6.1 단위 테스트 (Unit Testing)

단위 테스트의 목적은 개별 모듈이나 함수의 동작을 화이트박스 형태로 검증하는 것입니다. 따라서 단위 테스트를 위한 요구사항 상세화는 개별 모듈 수준에서의 정보가 제공되어야 하므로, 각 모듈의 입력, 출력 처리 기준, 예상 출력값까지 정의될 수 있어야 합니다. 다음의 사항을 살펴 보겠습니다. 다음 사항은 테스트 완료를 판단하기 위한 기준으로서의 요구사항과 테스트 케이스 작성을 위한 상세 설계 사항을 예로 정리한 사항입니다.

6.1.2 단위 테스트를 위한 요구사항

• 기능 요구사항 (Functional Requirements)
  • 시스템이 제공해야 할 구체적인 기능을 설명합니다.
  • 예: “로그인 함수는 올바른 이메일과 비밀번호를 입력받아야 한다.”
• 비기능 요구사항 (Non-Functional Requirements)
  • 시스템이 어떻게 동작해야 하는지를 설명합니다. 성능, 보안, 사용자 경험 등이 포함됩니다.
  • 예: “로그인 함수는 입력된 비밀번호를 암호화하여 처리해야 한다.”
• 단위 테스트를 위한 입출력 정의
  • 함수나 모듈의 입력 값과 예상 출력 값을 명확히 정의합니다.
  • 예: “로그인 함수는 문자열 형식의 이메일과 비밀번호를 입력받고, Boolean 형식의 성공 여부를 반환해야 한다.”

6.1.3 단위 테스트를 위한 상세 설계 항목

• 기능 요구사항에 대한 구현을 목적으로 하는 설계 내용 
  • 각 모듈이나 함수의 내부 로직과 동작을 구체적으로 설명합니다.
  • 예: “로그인 함수는 입력된 이메일과 비밀번호를 데이터베이스에 저장된 값과 비교한다.”
• 기능 요구사항에 대한 인터페이스 정의 (Interface Definition)
  • 모듈 간의 상호작용을 정의하고, 입력 및 출력 인터페이스를 명확히 합니다.
  • 예: “로그인 함수는 인증 모듈을 호출하여 사용자 자격 증명을 확인한다.”
• 기능 요구사항에 대한 데이터 흐름
  • 함수나 모듈 내에서 데이터가 어떻게 처리되고 흐르는지를 설명합니다.
  • 예: “로그인 함수는 비밀번호를 해시하고, 데이터베이스 쿼리를 통해 사용자 정보를 조회한다.”
• 기능 요구사항에 대한 에러 처리 및 예외 상황
  • 함수나 모듈에서 발생할 수 있는 예외 상황과 이를 처리하는 방법을 정의합니다.
  • 예: “로그인 함수는 잘못된 자격 증명 입력 시 ‘인증 실패’ 메시지를 반환한다.”

6.2 통합 테스트 (Integration Testing)

통합 테스트의 목적은 소프트웨어를 구성하는 여러 모듈의 결합이 제대로 작동하는지를 검증하는 것입니다. 따라서 통합 테스트를 위한 요구사항 상세화 수준은 소프트웨어 모듈간 인터페이스와 데이터 교환이 명확하게 정의되는 수준까지를 의미합니다. 예를 들어, "로그인 모듈이 소프트웨어 통합을 위한 상세화 수준은 별도의 인증 모듈, 또는 외부 인증 모듈과 적절한 통합이 수행되는지를 확인할 수 있는 수준"까지 일 것입니다. 따라서 통합 테스트를 위한 상세화에서는 어떤 별도 인증모듈인지, 또는 외부 인증 모듈인지를 구체화 하고, 이들 인증 모듈들간의 인터페이스가 적절히 도출되었는지까지를 상세화 수준의 기준으로 볼 수 있을 것입니다.

6.3 시스템 테스트 (System Testing)

시스템 테스트의 목적은 전체 시스템이 요구사항에 맞게 동작하는지를 검증해야 하기 때문에, 요구사항에는 기능 요구사항 외에도 추가적으로 비기능 요구사항들이 필요하게 됩니다. 따라서 시스템 테스트를 위한 상세화 수준의 기준은 비기능 요구사항의 정의 유무와 적절성이 될 수 있습니다. 

---

7. 마치며..

기능적 요구사항의 세분화 수준 개념은 매우 간단하지만, 실제로 많은 요구사항 엔지니어가 명세를 작성할 때 이를 고려하지 않는 경우가 많습니다. 세분화 수준을 고려하면 요구사항 도출 및 분석 작업에 적절한 노력을 기울이고 더 높은 품질의 요구사항 명세를 달성할 수 있습니다.

IEEE 830 표준은 요구사항 명세의 품질을 평가하는 기준으로 다음을 제시합니다: 정확성, 모호성 없음, 완전성, 일관성, 수정 가능성, 우선순위 지정, 검증 가능성, 추적 가능성.

범위를 제공하는 명세의 목표일 때, FR의 세분화 수준에 주의를 기울이면 다음을 할 수 있습니다:

• 요약 FR이 존재할 때 명세가 완료되지 않았는지, 하위 기능 FR이 더 높은 세분화 수준의 FR과 관련이 없는지 식별할 수 있습니다.
• 사용자 목표에 맞춰 FR을 집중할 때 소프트웨어가 제공할 작업에 대한 모호성이 없는 범위를 표현할 수 있습니다.
• 하위 기능 목표로 적절한 FR을 지정함으로써 유지보수가 용이하고 일관성이 더 높은 요구사항 문서를 생성할 수 있습니다.

 

 

 

이 글은 https://re-magazine.ireb.org/articles/functional-requirements-and-their-levels-of-granularity을 기반으로 작성하였습니다.