"모든 기능을 문제없이 동작하게 해 주세요!!"
언뜻 보면 완벽한 요구사항입니다.
모든 기능을 구현해야 하고, 구현하는 모든 기능에 문제가 없어야 합니다.
이만큼 완벽한 요구사항이 있을까요? ㅎㅎ
안타깝지만, 이게 최근까지도 현실에서 심심찮게 볼 수 있는 농담같은 진담이었습니다.
이번 포스팅에서는 요구사항 작성시 발생하는 일관성과 모호성을 예방하기 위한 방안으로
Easy Approach to Requirements Syntax (EARS)에 대해 살펴 보고자 합니다.
관련글 보기
- ISO/PAS 8800: AI 안전 요구사항 도출 (Derivation of AI Safety Requirements)
- 명확한 요구사항 작성 (모호성 제거) - 시각적 요구사항 정의, 모델기반 요구사항 명세서 (Model-Based Requirements Specification, MBRS)
- 소프트웨어 공학: 소프트웨어 문서화의 중요성과 적절한 작성 시점
- 소프트웨어 기능 요구사항 상세화 수준
- 소프트웨어 공학: 요구공학과 요구사항 분석 (SMART)
1. 요구사항 작성 시 발생하는 주요 이슈
1-1. 요구사항이 모호하게 작성됨
요구사항이 모호하게 작성되면 프로젝트 전반에 걸쳐 혼란과 비효율이 발생할 수 있습니다. 요구사항이 명확하지 않으면 개발자는 이를 각기 다르게 해석할 가능성이 높아지고, 결과적으로 예상과 다른 기능이 구현될 위험이 커지기 때문입니다.
모호한 요구사항의 대표적인 예는 주관적인 표현 사용입니다. “시스템은 빠르게 응답해야 한다”와 같은 문장은 ‘빠르게’의 기준이 사람마다 다르게 해석될 수 있어 구체적인 요구사항으로서의 역할을 하지 못합니다. 또한, 조건과 범위가 명확하지 않은 경우에도 문제가 발생합니다. 예를 들어, “데이터를 자동으로 백업해야 한다”라는 요구사항에서 ‘자동’, ‘백업 주기’, ‘백업 대상’ 등이 구체적으로 정의되지 않으면 개발자마다 다른 방식으로 구현할 가능성이 높습니다.
이러한 모호성은 개발 및 테스트 단계에서 혼란을 초래하기도 합니다. 개발자는 요구사항을 해석하는 과정에서 불필요한 의사결정을 해야 하며, 테스트 팀은 기준이 불분명한 상태에서 검증을 진행해야 하므로 테스트의 신뢰성이 떨어질 수 있습니다. 결과적으로 프로젝트 일정이 지연되고 추가 비용이 발생할 가능성이 커질 수 있습니다.
1-2. 요구사항 작성에 일관성이 부족함
요구사항 작성에서 일관성이 부족하면 프로젝트 진행 과정에서 혼란을 초래하고, 개발자와 이해관계자 간의 의사소통 오류를 유발할 수 있습니다. 일관성이 부족한 대표적인 사례는 표현 방식이 일관되지 않는 경우입니다. 같은 개념이 문서 내에서 다른 용어로 표현되면, 개발자가 이를 동일한 요구사항으로 인식하지 못할 수 있습니다. 예를 들어, 한 부분에서는 “로그인 세션 유지 시간”을 정의하면서 다른 부분에서는 “자동 로그아웃 시간”이라는 표현을 사용하면, 두 개의 요구사항이 서로 다른 의미로 해석될 수 있습니다.
또한, 요구사항 간의 충돌도 문제를 일으킬 수 있습니다. 하나의 요구사항에서 특정 기능이 반드시 포함되어야 한다고 명시하면서, 다른 요구사항에서는 해당 기능이 선택 사항으로 기술되는 경우가 이에 해당합니다. 이런 충돌이 발생하면 개발자는 어느 요구사항을 우선해야 할지 판단하기 어려워지고, 결국 요구사항 변경이 반복되어 일정 지연과 비용 증가로 이어질 수 있습니다.
이밖에도 요구사항 작성시 발생하는 이슈로는 중요 요구사항이 누락된다거나, 이해관계자간 소통이 부족하다거나, 요구사항이 자주 변경된다거나 등의 이슈들이 있지만, 이번 포스팅에서는 요구사항 작성 시 야기될 수 있는 모호성(Ambiguity)과 일관성(Consistency)에 대한 이슈에 대해 좀 더 자세히 알아 보도록 하겠습니다.
2. 요구사항 컨텍스트(Context) 구조화 전략
2-1. 요구사항 컨텍스트(Context)란?
요구사항 컨텍스트(Requirements Context)는 요구사항이 적용되는 환경, 조건, 이해관계자, 시스템의 제약사항 등을 포함한 배경 정보를 의미합니다. 단순히 기능적인 요구사항을 나열하는 것이 아니라, 해당 요구사항이 왜 필요한지, 어디에서 적용되는지, 어떤 영향을 미치는지를 정의하는 것은 요구사항의 일관성을 유지하고, 모호성을 개선하는데 중요한 역할을 합니다.
요구사항 컨텍스트(Requirements Context)
요구사항이 적용되는 환경, 조건, 이해관계자, 시스템 제약사항 등을 포함한 배경정보를 의미합니다.
2-2. 요구사항 컨텍스트의 중요성
먼저 요구사항이 일관성을 유지한다는 것은 요구사항들이 서로 충돌하지 않고, 논리적으로 연결되며, 개발자가 해석할 때 동일한 결과를 도출할 수 있어야 한다는 것입니다. 따라서 요구사항 컨텍스트를 명확하게 설정하면 요구사항의 목적을 명확히 이해할 수 있어, 개발 방향을 일관되게 유지할 수 있습니다. 또한 여러 요구사항이 서로 어떤 관계를 가지는지 정의하면, 일관성을 유지하기 쉬워질 뿐만 아니라, 특정 요구사항이 변경되었을 때, 관련된 시스템이나 기능에 미치는 영향을 쉽게 파악할 수 있습니다.
요구사항은 단순한 문서나 명세서로 존재하는 것이 아니라, 프로젝트의 환경과 맥락 속에서 의미를 가집니다. 같은 기능이라도 산업별, 비즈니스 모델별로 다른게 정의될 수 있기 떄문입니다. 예를 들어 차량 제어 소프트웨어에서의 데이터 응답시간과 모바일 앱에서의 데이터 응답시간을 고려해 보면, 차량 주행 안정성과 관련된 응답시간과 모바일 앱의 사용자 경험 중심의 응답시간은 상대적 성능 기준이 달라질 수 밖에 없기 때문에, 같은 "응답시간" 요구사항이라도 자동차 소프트웨어와 모바일 앱에서는 컨텍스트에 따라 다르게 해석되어야 하며, 이들이 고려되어야 일관성이 유지될 수 있습니다.
또한 요구사항이 모호하다는 것은 동일한 요구사항을 두고도 여러 해석이 가능하거나 구체적인 조건이 명확하지 않은 경우를 의미합니다. 이러한 모호성의 원인은 컨텍스트 부족에서 기인하기도 합니다. 요구사항을 명확하게(모호하지 않게) 정의하려면 도메인 지식과 비즈니스 목표, 사용자 기대치 등 다양한 사항들을 고려해야 합니다. 서두에 언급한 것처럼, 모든 기능이 문제 없이 동작할것과 같은 요구사항은 요구사항의 컨텍스트에 대한 정보가 아무것도 없는 상황에서 단순히 요구사항이라는 형태로 정의된 무책임하고 모호한 요구사항의 대표적 사례라 할 수 있을것입니다.
2-3. 요구사항 컨텍스트 구조화 전략
소프트웨어 개발에서 요구사항은 단순한 문서 이상의 의미를 갖습니다. 프로젝트의 방향을 결정짓고, 이해관계자 간의 기대를 조율하며, 최종 제품이 성공적으로 완성될 수 있도록 하는 기반이 되기 때문입니다. 하지만 요구사항이 제시된다고 해서 그 자체로 충분한 것은 아닙니다. 요구사항이 의미를 갖기 위해서는 그것이 속한 맥락, 즉 요구사항 컨텍스트(Context) 가 명확하게 정의되고 구조화되어야 합니다. 그렇지 않으면 요구사항의 일관성(Consistency)이 깨지고, 모호성(Ambiguity)이 증가하며, 소프트웨어 개발에 혼선을 야기할 수 있으며, 소프트웨어 변경 관리가 어려워지는 문제에 직면할 수 있습니다.
1) 이해관계자 분석 및 요구사항 소스 정의
요구사항 컨텍스트를 효과적으로 구조화하려면 먼저 이해관계자(Stakeholder)를 정의하고, 그들이 요구사항을 도출하는 소스를 파악해야 합니다. 이때 이해관계자는 프로젝트에 참여하는 모든 구성원을 의미하며, 요구사항이 누구에 의해 도출되었는지 그리고 어떤 출처에서 유래했는지를 명확히 하기 위함입니다.
2) 주요 용어 정의(Glossary & Terminology Standardization)
요구사항을 정확하게 정의하기 위해서는 사용되는 용어에 대한 공통된 이해가 필요합니다. 같은 용어라도 이해관계자마다 다르게 해석될 수 있기 때문에, 이를 명확하게 정의해야 합니다.
요구사항 정의를 위해 사용될 수 있는 용어는 주로 일반 용어(General Terminology), 도메인 용어(Domain-Specific Terminology), 기능 용어(Functional Terminology), 비기능 용어(Non-Functional Terminology), 법적 및 규제 용어 (Legal & Regulatory Terminology)로 구성될 수 있습니다.
이처럼 주요 용어를 문서화하여 프로젝트 팀 전체가 동일한 의미로 해석하도록 하면, 개발 과정에서 불필요한 혼선을 줄일 수 있습니다.
주요 용어 정의 시 주의사항
주요 용어에 대한 정의는 문서의 일관성과 모호성을 해결하는 중요 요소입니다. 그런데 실제 프로젝트에서는 문서 앞부분에 나와있는 약어 정리 수준의 용어 정의로 활용하고 있는게 대부분의 현실이라 생각합니다. 이는 문서화 과정에서 그만큼 용어 정의에 대한 중요성을 간과하고 있음을 반증하는 사례라고 생각합니다.
따라서 주요 용어에 대한 체계적인 분류와 이것이 하나의 데이터베이스 형태로 개발/관리되어 조직내 누구나 접근가능한 수준으로 공개되고 활용되며, 지속적으로 업데이트되어야 할 것입니다.
3) 제약 조건 및 기술적 고려 사항(Constraints & Technical Considerations)
요구사항을 구현할 때 반드시 고려해야 하는 제약 조건을 정의해야 합니다. 이러한 제약 조건을 명확히 하지 않으면, 요구사항이 기술적으로 구현 가능하지 않거나 예상보다 많은 리소스가 필요할 수 있습니다. 주요 제약 조건으로는 성능, 보안, 그리고 하드웨어 제약들이 있으며, 기술적 고려사항으로는 도메인 상황에 맞는 다양한 기술적 고려사항들이 존재할 것입니다.
4) 요구사항 변경 관리 및 추적성(Requirements Traceability & Change Management)
소프트웨어 개발 과정에서 요구사항이 변경될 가능성이 높습니다. 따라서 요구사항이 변경될 때 기존 요구사항과의 연관성을 분석하고, 변경 이력을 체계적으로 관리하는 것이 필요합니다. 요구사항 변경이 기존 시스템에 미치는 영향을 분석하고, 버전 관리 시스템을 활용해 변경 이력을 추적하면, 요구사항 변경으로 인한 혼란을 최소화할 수 있습니다.
지금까지 살펴본 요구사항 컨텍스트를 체계적으로 구조화하면, 요구사항의 명확성과 품질을 보장할 수 있습니다. 이를 위해 EARS(Easy Approach to Requirements Syntax)를 활용하여 효과적인 요구사항 작성 방안에 대해 살펴 보고자 합니다. EARS는 요구사항을 좀 더 명확하고 일관되게 표현할 수 있는 방법론으로, 이를 통해 보다 정확하고 일관성있는 요구사항을 정리하는 방법에 대해 알아 보겠습니다.
3. EARS (Easy Approach to Requirements Syntax) 배경
소프트웨어 및 시스템 엔지니어링에서 요구사항(Requirements) 은 개발 프로세스의 근본적인 요소입니다. 요구사항이 명확하고 일관되게 작성되지 않으면, 프로젝트 진행 중 혼란이 발생하고 품질이 저하될 가능성이 높아집니다. 하지만 전통적인 요구사항 작성 방식은 모호성(Ambiguity), 일관성 부족(Inconsistency), 검증 불가능성(Non-verifiability) 등의 문제를 야기하는 경우가 많았습니다.
EARS는 2009년 영국의 Rolls-Royce PLC에서 Alistair Mavin(“Mav”)과 그의 팀에 의해 개발되었습니다. 당시 Rolls-Royce는 항공기 엔진 제어 시스템의 감항인증(CS-E: Certification Specification for Engines) 규정을 분석하면서 심각한 문제에 직면했습니다. 해당 규정에는 50개 이상의 요구사항이 포함되어 있었으나, 자연어 기반의 문서가 모호하고 일관성이 부족하여, 엔지니어들이 요구사항을 해석하고 시스템을 설계하는 데 큰 어려움을 겪었습니다. 또한 요구사항간 종속성과 상충 관계를 파악하기 어려웠고, 요구사항 충족 여부를 검증하기 위한 테스트 케이스 도출이 어려운 상황이었습니다.
이러한 문제를 해결하기 위해, Alistair Mavin과 그의 팀은 요구사항을 자연어(Natural Language) 기반이면서도, 구조화된 문법으로 작성할 수 있는 방법을 개발했습니다. 그것이 바로 EARS(Easy Approach to Requirements Syntax)입니다. EARS는 자연어를 사용하되, ‘조건(Condition) → 동작(Action)’의 형태를 포함한 명확한 문법적 틀을 제공했습니다. 또한, EARS는 단순하면서도 유연한 형식을 제공하여, 요구사항 작성자와 이해관계자들이 쉽게 이해할 수 있도록 설계되었습니다.
EARS (Easy Approach to Requirements Syntax)
자연어(Natural Language)를 기반으로 하면서도 구조적 패턴을 적용하여, 보다 명확하고 이해하기 쉬운 요구사항을 작성할 수 있도록 돕는 방법론입니다.
4. EARS의 핵심: 6가지 패턴을 통한 요구사항 구조화
- Ubiquitous Requirements (항상 적용되는 요구사항)
- Event-Driven Requirements (이벤트 기반 요구사항)
- State-Driven Requirements (상태 기반 요구사항)
- Optional Requirements (선택적 요구사항)
- Complex Requirements (복합 요구사항)
- Unwanted Behaviour Requirements (원하지 않는 동작 요구사항)
4-1. Ubiquitous Requirements (항상 적용되는 요구사항)
Ubiquitous Requirements는 특정 조건이나 사건 없이 언제나 적용되는 요구사항을 의미합니다. “Ubiquitous” 라는 용어는 ‘언제나 어디서나 적용되는’ 이라는 의미를 가지며, 시스템이 항상 수행해야 하는 기본적인 규칙이나 동작(Always-on behavior)을 정의할 때 사용됩니다. 따라서 Ubiquitous Requirements 패턴을 적용하면 특정 이벤트나 상태에 구애받지 않고, 시스템이 ‘기본적으로 항상 지켜야 하는 규칙’을 명확하게 표현할 수 있습니다.
■ EARS 형식
The system shall always [action].
시스템은 항상 [action] 해야 한다.
- “shall”: 요구사항의 필수적 의무(Mandatory) 를 명시함.
- “always”: 특정 조건 없이 언제나(Always-on) 요구사항이 적용됨을 명확히 함.
- [action]: 시스템이 수행해야 하는 구체적인 동작(Behavior) 을 정의함.
■ 예시:
- 시스템은 항상 저장된 사용자 데이터를 암호화해야 한다.
- 엔진이 켜져 있을 때 차량은 항상 대시보드를 밝게 표시해야 한다.
■ Ubiquitous Requirements 특징
- 항상 적용(Always-on): 특정 이벤트, 상태, 조건 없이 지속적으로 적용되는 요구사항
- 명확성(Clarity): 모호성이 없고, 항상 수행해야 하는 행동을 구체적이고 단순하게 표현
- 일관성(Consistency): 프로젝트 전체에서 일관된 시스템 동작 규칙을 유지
- 검증 용이성(Testability): ‘항상(Always)’이라는 절대적 기준 덕분에 테스트가 용이함
■ Ubiquitous Requirements 작성 시 주의사항
- 정확하고 구체적으로 작성하기: 애매한 표현(“빠르게”, “안전하게”) 대신 정량적인 수치(예: 2초 이내, 99.9%의 가용성) 를 명시해야 합니다.
- 필요할 때만 사용하기: 항상 적용(Always-on) 요구사항은 시스템 자원에 큰 부하를 줄 수 있으므로 필요성이 명확한 경우에만 사용해야 합니다.
- 테스트 가능성 확보: 요구사항은 명확히 검증 가능(Testable) 해야 합니다. (예, “항상 50ms 이내에 응답” → 성능 테스트 수행 가능)
4-2. Event-Driven Requirements (이벤트 기반 요구사항)
Event-Driven Requirements(이벤트 기반 요구사항)는 특정 이벤트(Event)가 발생했을 때 시스템이 수행해야 하는 행동을 정의하는 패턴입니다. “Event-Driven”이라는 용어는 사건 기반’ 또는 ‘이벤트 기반’을 의미하며, 트리거(trigger)에 의해 시스템이 반응하는 조건-행동(Trigger-Action) 형태의 요구사항을 명확히 표현합니다. 일반적으로 이벤트가 발생했을 때(When) 시스템이 반드시 해야 하는 동작을 나타내며, 주로 알람, 보안, 오류 처리, 사용자 인터랙션 등의 시나리오에서 사용됩니다.
■ EARS 형식
When [event], the system shall [action].
[event]가 발생하면, 시스템은 [action] 해야 한다.
- “When”: 요구사항의 트리거(Trigger, 사건) 를 명확히 정의합니다.
- “the system shall”: 필수적 행동(Mandatory Action)임을 명시합니다.
- ”[action]”: 시스템이 수행해야 하는 구체적인 동작(Behavior)을 명확히 설명합니다.
■ 예시:
- 사용자가 비밀번호를 3회 잘못 입력하면, 시스템은 계정을 잠가야 한다.
- 비상 버튼이 눌리면, 시스템은 즉시 관제 센터에 알림을 전송해야 한다.
■ Event-Driven Requirements의 특징
- 조건-행동 명확성(Trigger-Action Clarity): ‘When’ 구문을 사용해 트리거(Trigger)와 시스템 행동(Action)을 명확히 구분함
- 실시간 반응성(Real-Time Responsiveness): 이벤트 발생 시 즉각적인 시스템 반응을 명시함
- 비즈니스 규칙 표현(Business Rules): 보안, 알람, 인증 등 비즈니스 로직을 직관적으로 설명
- 테스트 용이성(Testability): 특정 이벤트에 대한 시나리오 기반 테스트가 가능함
■ Event-Driven Requirements 작성 시 주의사항
- 명확한 트리거(Trigger) 정의: ‘When’ 구문으로 이벤트(사건)를 정확하고 구체적으로 표현해야 합니다.
(예, “When the battery level is below 10%” (모호함 없이 구체적 수치 사용)) - 구체적이고 테스트 가능한 행동(Action) 명시: 테스트가 가능하도록 구체적인 행동을 포함해야 합니다. (예, “Send an email notification” (테스트 케이스가 명확))
- 응답 시간(Response Time) 명시: 이벤트 발생 시 시스템 반응의 속도(Speed of Response) 를 명확히 포함하는 것이 중요합니다. (예, “Within 1 second”, “Immediately” 등 반응 시점을 명시함.)
- 중복 이벤트(Repeated Events) 처리 고려: 같은 이벤트가 반복해서 발생할 경우 중복 처리 방지(Throttle, Debounce) 로직을 요구사항에 포함할 수 있습니다. (예, “When a temperature alarm occurs, suppress additional alerts for 5 minutes.”)
4-3. State-Driven Requirements (상태 기반 요구사항)
State-Driven Requirements(상태 기반 요구사항)은 시스템이 특정 상태(State)에 있을 때만 유효한 요구사항을 정의합니다. “State-Driven”은 ‘상태 기반’을 의미하며, 시스템이 특정 상태(조건)가 유지되는 동안 반드시 수행해야 하는 동작을 명확히 표현합니다. 상태 기반 요구사항은 주로 모드(Mode), 세션(Session), 연결 상태(Connection Status), 배터리 상태(Battery Level), 주행 상태(Driving State) 등의 시나리오에서 사용됩니다.
■ EARS 형식:
While [state], the system shall [action].
[state] 상태에서 시스템은 [action] 해야 한다.
- “While”: 시스템이 특정 상태(State)에 있을 때만 적용됨을 명시합니다.
- “the system shall”: 시스템이 반드시 수행해야 하는 필수 동작(Mandatory Action)임을 명시합니다.
- ”[action]”: 시스템이 수행해야 하는 구체적인 행동(Behavior)을 정의합니다.
■ 예시:
- 차량이 주행 중일 때, 시스템은 비디오 재생 기능을 비활성화해야 한다.
- 배터리 잔량이 20% 미만일 때, 시스템은 백그라운드 프로세스를 제한해야 한다.
■ State-Driven Requirements의 특징
- 상태 기반(Condition-Based): 특정 상태(State)가 유지되는 동안에만 요구사항이 적용됨
- 상태 전이(State Transitions)와 명확성: 시스템 모드(Mode), 연결 상태(Status), 배터리 상태(Level) 등과 연관됨
- 실시간 반응성(Real-Time Responsiveness): 상태가 변하면 즉각적인 상태 기반 동작(State-Driven Action) 수행
- 모호성 제거 및 명확성 확보: ‘While’ 구문으로 상태와 행동을 명확히 구분
- 상태 기반 테스트(State-Based Testing) 용이성: 특정 상태에서만 실행되는 시나리오 테스트(Scenario Testing)가 가능함
■ State-Driven Requirements 작성 시 주의사항
- 상태(State)의 정의를 명확히 할 것: ‘While’ 구문에서 상태는 명확하고 측정 가능(Quantifiable and Measurable) 해야 합니다.
예) 모호한 상태: “While the system is busy” → 명확한 상태: “While the CPU usage exceeds 90%” - 상태 전이(Transition)를 고려할 것: 상태가 시작될 때(Entry)와 종료될 때(Exit)의 동작을 명확히 정의해야 합니다.
예) “While the device is in sleep mode, disable the display. When the sleep mode ends, re-enable the display.” - 상태 지속 시간 및 타이밍(Timing) 명시: 특정 상태가 유지되는 동안의 행동 주기(Periodicity) 를 명확히 합니다.
예) “While the server is in maintenance mode, log system health every 5 seconds.” - 테스트 가능성(Testability) 확보: 상태 기반 요구사항은 상태 기반 테스트(State-Based Testing) 를 통해 상태 전이와 요구사항 충족 여부를 검증할 수 있어야 합니다.
4-4. Optional Requirements (선택적 요구사항)
Optional Requirements(선택적 요구사항)은 특정 조건이 충족되었을 때 시스템이 선택적으로 수행할 수 있는 동작을 정의합니다. “Optional”은 ‘선택적’ 또는 ‘조건부 수행 가능’을 의미합니다.
필수적으로 수행해야 하는 Mandatory Requirements와 달리, 조건이 충족되면 시스템이 ‘할 수도 있다(May)’는 유연성을 포함합니다. 주로 사용자 선호 기능, 부가 서비스, 성능 최적화 기능, 또는 선택적 보안 기능 등에 사용됩니다.
■ EARS 형식
Where [condition], the system may [action].
[condition]인 경우 시스템은 [action]을 수행 할 수 있다.
- “Where”: 특정 조건(Condition) 이 충족되었을 때만 동작함을 명시합니다.
- “the system may”: 시스템이 해당 동작을 선택적으로 수행할 수 있음(May) 을 의미합니다.
- ”[action]”: 시스템이 수행할 구체적인 선택적 행동(Behavior) 을 정의합니다.
■ 예시:
- 사용자가 다크 모드를 활성화한 경우, 시스템은 다크 테마 인터페이스를 표시할 수 있다.
- 네트워크 신호가 약한 경우, 시스템은 저대역폭 모드로 전환할 수 있다.
■ Optional Requirements의 특징
- 조건부 선택성(Conditional Optionality): 특정 조건에서만 ‘선택적 동작’ 수행 가능
- 유연성(Flexibility): ‘May’ 구문을 사용하여 필수가 아닌 선택적 요구사항임을 명시
- 사용자 중심(User-Centric): 사용자 선호, 설정, 모드 등에 따라 맞춤형 동작(User Preferences) 제공
- 비즈니스 가치를 높임(Business Value): 광고, 프리미엄 기능, 부가 서비스 등 선택적 기능으로 수익성을 향상
- 모호성 제거(Clarity): ‘Where’ 구문으로 조건을 명확히 정의하여 혼동 방지
■ Optional Requirements 작성 시 주의사항
- 조건(Where)의 명확성 확보: ‘Where’ 구문을 사용해 조건(Condition)을 구체적이고 명확하게 정의해야 합니다.
예) 모호한 조건: “Where performance is high” → 명확한 조건: “Where CPU usage is below 50%” - 선택적 동작(May)의 테스트 가능성(Testability): 선택적 동작(May) 도 테스트 케이스(Test Cases) 가 가능해야 합니다.
예) “Where Dark Mode is enabled, the background should change to black.” → UI 테스트 시 Dark Mode ON/OFF 시나리오 포함 - 선택성과 필수성 구분: ‘May’는 ‘Shall’(필수 요구사항) 과 명확히 구분되어야 합니다.
• 필수(Mandatory): “When battery is below 5%, the system shall shut down.”
• 선택(Optional): “Where battery is below 20%, the system may reduce brightness.” - 비즈니스 로직 반영: 사용자 선호(User Preferences), 프리미엄 서비스(Premium Features), 광고 및 수익 모델(Ad Revenue) 등 비즈니스 가치를 반영한 선택적 요구사항을 포함할 수 있습니다.
4-5. Complex Requirements (복합 요구사항)
Complex Requirements(복합 요구사항)은 하나 이상의 조건(Conditions)이나 시나리오(Scenarios)가 조합되어 다양한 행동(Action)을 요구하는 경우를 정의합니다. “Complex”는 ‘복합적인’, ‘다중 조건을 포함한’이라는 의미를 가지며, 조건문(If-Else) 및 다중 경로 처리(Multiple Outcomes)를 포함하는 다중 조건 기반 요구사항(Multiple Condition-Based Requirements)을 명확하게 표현할 때 사용됩니다.
주로 안전 시스템(Safety Systems), 보안 프로토콜(Security Protocols), 비즈니스 로직(Business Rules), 오류 처리(Error Handling) 등에서 활용됩니다.
■ EARS 형식:
If [condition], then the system shall [action]. Otherwise, the system shall [alternative action].
[condition]인 경우, 시스템은 [action] 해야한다. 만약 그렇지 않으면 시스템은 [alternative action]을 해야 한다.
- “If”: 요구사항의 주요 조건(Main Condition)을 정의합니다.
- “then”: 조건이 충족되었을 때 시스템이 수행할 주요 행동(Mandatory Primary Action)을 명시합니다.
- “Otherwise”: 조건이 충족되지 않았을 때의 대체 행동(Alternative Action)을 정의합니다.
- “the system shall”: 필수 동작(Mandatory Action)임을 명확히 표현합니다.
■ 예시:
- 사용자가 올바른 OTP를 입력하면, 시스템은 접근을 허용해야 한다. 그렇지 않으면, 접근을 거부해야 한다.
- 온도가 100°C를 초과하면, 시스템은 냉각 팬을 작동시켜야 한다. 그렇지 않으면, 대기 모드를 유지해야 한다.
■ Complex Requirements의 특징
- 다중 조건 처리(Multiple Condition Handling): If-Then-Else 문법을 사용해 조건별 다중 시나리오를 명확히 정의
- 복합 시나리오 모델링(Scenario Modeling): 조건부 결과(Conditional Outcomes)를 체계적으로 명시
- 논리적 명확성(Logic Clarity): 조건과 결과 간 관계(If-Else Relationship)를 명확하게 구분
- 상태 기반 테스트(State-Based Testing): 용이성 다양한 시나리오 기반 테스트(Test Cases) 설계에 용이
- 비즈니스 규칙 반영(Business Rules Integration): 실제 비즈니스 프로세스(Real-World Business Logic)를 명확히 표현
■ Complex Requirements 작성 시 주의사항
- 명확한 조건(If)의 정의: ‘If’ 구문에서 조건은 측정 가능(Quantifiable)하고 구체적(Specific)이어야 합니다.
예) 모호한 조건: “If performance is high” → 명확한 조건: “If server response time is below 100 ms” - 명확한 행동(Then/Otherwise)의 정의: ‘Then’ 및 ‘Otherwise’ 구문은 검증 가능(Testable) 하고 명확한 결과(Observable Outcome)를 포함해야 합니다.
예) “Then send an email” 대신 “Then send an email with the subject ‘Alert: High CPU Usage’” - 다중 조건(Complex Scenarios) 분해: 복잡한 다중 조건(Multiple Conditions)은 여러 개의 Simple 또는 State-Driven 요구사항으로 분해하여 관리하는 것이 좋습니다.
예)
• If CPU > 90%, activate cooling.
• If CPU > 95%, trigger shutdown. - 예외 처리(Exception Handling) 명시: 모든 조건에는 반드시 ‘Otherwise’ 구문으로 대체 시나리오(Alternative Scenarios) 를 명확히 해야 합니다.
예) “If the sensor fails, then alert the operator. Otherwise, log the failure.”
4-6. Unwanted Behaviour Requirements (원하지 않는 동작 요구사항)
Unwanted Behaviour Requirements(원하지 않는 동작 요구사항)은 특정 조건에서 시스템이 수행하지 말아야 하는 동작을 명시하는 요구사항입니다. “Unwanted Behaviour”는 ‘원치 않는 동작’, 즉 시스템이 특정 상황에서 반드시 피해야 할 행동을 의미합니다.
이 요구사항은 보안(Security), 안전성(Safety), 데이터 보호(Data Protection) 및 장애 처리(Fault Handling) 등에서 위험 요소를 예방하는 데 매우 중요합니다. 특히, 안전성이 중요한 산업(Automotive, Aerospace, Medical, Industrial Systems) 에서 자주 사용됩니다.
■ EARS 형식:
The system shall not [action] when [condition].
대상 시스템은 [condition] 인 경우에는 [action]을 수행하지 않아야 한다.
- “The system shall not”: 시스템이 절대 수행하지 말아야 할 금지 동작(Prohibited Action)을 명시합니다.
- “when”: 금지 동작이 적용되는 조건(Condition) 을 명확히 정의합니다.
- ”[action]”: 시스템이 수행하지 말아야 할 행동(Forbidden Behaviour)을 구체적으로 설명합니다.
■ 예시:
- 사용자 세션이 만료되었을 때, 시스템은 어떠한 거래도 처리하지 않아야 한다.
- 안전벨트가 착용되지 않았을 때, 차량은 시동이 걸리지 않아야 한다.
■ Unwanted Behaviour Requirements의 특징
- 금지 동작 명확성(Prohibited Action Clarity): 시스템이 수행하지 말아야 할 동작을 명확히 정의
- 조건 기반 금지(Conditional Prohibition): 특정 조건 하에서만 금지 동작을 정확히 지정(When Clause)
- 안전성 및 신뢰성 확보(Safety & Reliability): 안전 요구사항(Safety Requirements) 및 보안 요구사항(Security Requirements) 반영
- 규정 및 법률 준수(Compliance): 산업 표준(ISO, IEC, GDPR, FDA) 등과 규정 준수(Compliance) 보장
- 테스트 용이성(Testability): 금지 조건 및 동작이 명확하여 시나리오 기반 테스트(Scenario Testing) 설계가 용이
■ Unwanted Behaviour Requirements 작성 시 주의사항
- 금지 조건(When)의 명확성 확보: ‘When’ 구문에서 조건은 명확하고 측정 가능(Quantifiable and Measurable) 해야 합니다.
예) 모호한 조건: “When security is weak” → 명확한 조건: “When two-factor authentication is not verified” - 금지 동작(Shall not)의 구체성: ‘Shall not’ 구문은 시스템의 금지 행동(Prohibited Action)을 구체적이고 명확하게 명시해야 합니다.
예) 모호한 금지 동작: “Shall not store data insecurely” → 명확한 금지 동작: “Shall not store passwords in plain text” - 안전성과 규정 준수 확인: 산업 표준(ISO, IEC, GDPR, HIPAA) 및 법적 규제(Regulations)와 일치하는지 반드시 검토합니다.
- 예외 처리(Exception Handling) 포함: 금지 조건에 대한 예외 상황(Exceptions)이 존재하는 경우, 이를 명시해야 합니다.
예) “The system shall not process any transactions unless a manual override is performed by an administrator.” - 테스트 및 검증(Testability) 확보: ‘Unwanted Behaviour’ 시나리오 기반 테스트(Scenario-Based Testing)가 반드시 가능해야 합니다.
예) “When session expires, test that no transactions are processed.”
5. EARS를 위한 어휘사전(Glossary) 활용
EARS(Easy Approach to Requirements Syntax)는 명확하고 일관성 있는 요구사항 작성에 효과적인 방법론입니다. 그러나 EARS만으로는 용어의 통일성과 재사용성을 충분히 보장하기 어렵습니다. 이를 해결하기 위해 EARS의 구성 요소(Action, Condition, State 등)에 대해 요구사항 분석 단계에서 어휘사전(Glossary)을 구축하고, 이를 기반으로 요구사항을 작성하는 방안을 정리 해 봅니다.
먼저 EARS 문법에서 어휘사전을 구성하기 위한 구성요소로는 Action(행동), Condition(조건), State(상태), Event(이벤트), 그리고 Actor(행위자)가 있습니다. 여기서 Action은 시스템이 수행하는 구체적인 동작을 의미하며, Condition은 요구사항이 적용되는 특정 상황, State는 시스템이 유지하는 특정 상태, Event는 시스템 동작을 유발하는 사건, 그리고 Actor는 시스템과 상호작용하는 주체를 나타냅니다. 요구사항 작성 시, 발생하는 문제점 중 하나가 내용의 구체화가 있는데, 즉 어떤 요구사항은 매우 상세하게 작성되는 반면, 어떤 요구사항은 매우 추상적으로 정의된다는 점입니다. 이는 요구사항 일관성과도 연결되어 요구사항으로 인한 여러 문제를 야기하는 원인이기도 합니다. 그런데 이와 같이 어휘사전을 구성하고 그 구성요소에 대한 수준을 일관성 있게 정의 함으로써 이러한 문제들을 해결할 수 있다고 생각합니다. 그밖에도 이해관계자간 오해를 최소화하고, 공통 용어 재사용으로 문서 작성 효율을 향상 시킬 수 있을 뿐만 아니라, 명확한 용어 덕분에 테스트케이스 설계도 용이해 진다는 장점을 추가로 얻을 수 있게 됩니다.
EARS 어휘사전 구축 방법
1) 핵심 용어 수집:
- 요구사항 분석 단계에서 Action, Condition, State, Event, Actor 관련 핵심 용어 수집
- 이해관계자와 협력해 도메인 특화 용어 포함
2) 용어 정의 및 속성 명시: 용어 유형정의(Definition)예시(Example)규칙(Rules)
| Action | 시스템 동작 | ‘Send alert’ | 동사 형태 사용 |
| Condition | 특정 상황 | ‘battery < 20%’ | 수치 포함 |
| State | 시스템 상태 | ‘Sleep mode’ | 명사형 사용 |
| Event | 동작 유발 사건 | ‘Button pressed’ | 명확한 트리거 지정 |
| Actor | 시스템 주체 | ‘User’, ‘Sensor’ | 고유 명칭 부여 |
3) 표준 구문 및 템플릿 정의:
| EARS 유형 | 구문 템플릿(Template) |
| Ubiquitous | The system shall always [Action]. |
| Event-Driven | When [Event], the system shall [Action]. |
| State-Driven | While [State], the system shall [Action]. |
| Optional | Where [Condition], the system may [Action]. |
| Complex | If [Condition], then [Action]. Otherwise, [Alternative]. |
| Unwanted | The system shall not [Action] when [Condition]. |
마치며...
요구사항 명세는 프로젝트의 성공을 좌우하는 핵심 요소로, 특히 일관성(Consistency)과 모호성(Ambiguity)의 개선이 요구사항 품질 확보의 핵심입니다. 모호하거나 일관되지 않은 요구사항은 이해관계자 간의 혼란을 초래하며, 개발 및 테스트 단계에서 비용과 시간이 불필요하게 낭비될 수 있습니다.
이러한 문제를 해결하기 위해, 2009년 EARS(Easy Approach to Requirements Syntax)가 제안되었고, 이는 명확성과 일관성을 갖춘 요구사항 작성 방법론을 제공합니다. EARS는 Ubiquitous, Event-Driven, State-Driven, Optional, Complex, Unwanted Behaviour Requirements 등 다양한 패턴을 통해 요구사항의 구조를 표준화함으로써 모호성을 제거하고, 요구사항 간의 충돌을 방지할 수 있습니다.
그러나 EARS의 효과를 극대화하기 위해서는 어휘사전(Glossary)의 활용이 필수적입니다. EARS 기반 어휘사전을 통해 Action, Condition, State, Event, Actor 등 요구사항 구성 요소를 명확하게 정의하고, 모든 이해관계자가 동일한 용어를 동일한 의미로 해석할 수 있도록 합니다. 이를 통해 요구사항의 일관성을 유지할 수 있으며, 요구사항 변경 및 테스트 시 추적성(Traceability)을 확보할 수 있습니다.
관련글 보기
'Software Engineering' 카테고리의 다른 글
| 프로세스(Process) vs. 프로젝트(Project) 용어.. 잘 알고 계시죠? (0) | 2025.02.10 |
|---|---|
| Umbrella Organization (우산 조직)을 아시나요? (0) | 2025.02.02 |
| 대한민국에서 차량 제어분야 고연차 소프트웨어 엔지니어로서의 도전과 성장 (1) | 2025.02.01 |
| 소프트웨어 개발과 다품종 소량생산: 변경점 관리의 도전과 가치 (0) | 2025.01.21 |
| MECE 원칙을 활용한 소프트웨어 Fault Tolerance 중복성 설계: 신뢰성과 효율성을 극대화하는 접근법 (0) | 2025.01.04 |