[소프트웨어 공학] Requirements Engineering

Requirements Engineering

요구사항 공학(Requirements Engineering)이란, 고객이 시스템에 기대하는 서비스와 그 시스템이 작동하고 개발되어야 하는 제약 조건을 규명하는 과정을 말한다. 이 과정을 통해 도출되는 결과물이 바로 시스템 요구 사항(System requirements)이며, 이는 시스템이 제공해야 할 서비스와 그 제약 조건들을 설명하는 문서다.

What is a Requirement?

요구사항은 다양한 수준에서 표현될 수 있다. 단순히 “시스템이 어떤 기능을 가져야 한다”는 추상적인 진술에서부터, 수학적으로 정의된 정밀한 기능 명세에 이르기까지 다양하다.

이러한 다양성은 요구사항이 두 가지 상반된 역할을 하기 때문이다:

• 계약 입찰의 기반 : 이 경우, 여러 업체가 참여할 수 있도록 다소 유연하게 작성되어야 한다.
• 계약 그 자체의 기반 : 이 경우에는 분쟁 없이 구현이 가능하도록 매우 명확하게 정의되어야 한다.

이러한 서로 다른 용도의 문서들이 모두 “요구사항(requirement)”이라는 이름 아래 존재할 수 있다.

요구사항의 추상화(Davis의 설명)

기업이 대형 소프트웨어 프로젝트를 외주로 주고자 할 경우, 특정한 솔루션을 미리 정하지 않도록 충분히 추상적인 수준에서 요구사항을 정의해야 한다. 여러 업체가 다양한 접근법으로 고객의 요구를 만족시킬 수 있도록 해야 하기 때문이다. 계약이 체결되면, 이후에는 고객이 시스템이 어떻게 동작할지를 이해하고 검증할 수 있도록 보다 구체적인 시스템 정의가 작성되어야 한다.

즉, 입찰 전 문서와 계약 후 시스템 정의 문서 둘 다 모두 요구사항 문서라고 불릴 수 있다.

Types of Requirements

요구사항은 두 가지 주요 형태로 구분된다.

• 사용자 요구사항(User Requirements) : 자연어(일반 문장)와 다이어그램으로 표현되며, 시스템이 어떤 서비스를 제공하고 어떤 제약 조건이 있는지를 설명한다. 고객을 대상으로 작성된다.
• 시스템 요구사항(System Requirements) : 보다 구조화된 문서로, 시스템의 기능, 서비스, 운영 제약 조건 등을 자세히 기술한다. 실제 개발의 기준이 되며, 고객과 개발자 간의 계약 문서로 사용될 수 있다.

이 두 문서는 목적과 독자층이 다르므로, 각기 다른 형식과 표현 방식을 가진다.

다양한 요구사항 독자들

요구사항 문서는 여러 이해관계자가 읽게 된다. 따라서 표현 수준의 적절한 조정이 필요하다. 예를 들어, 고객은 기술적 세부사항보다는 시스템이 제공할 기능이 비즈니스적으로 어떤 의미가 있는지에 관심이 많고, 개발자는 그 기능이 어떻게 구현될 수 있을지에 초점을 맞춘다.

시스템 이해관계자(System Stakeholders)

시스템 이해관계자란, 시스템에 어떤 식으로든 영향을 받는 사람 또는 조직을 말하며, 이들은 모두 합법적인 관심을 가질 자격이 있다.

대표적인 이해관계자의 유형은 다음과 같다:

• 최종 사용자(End Users)
• 시스템 관리자(System Managers)
• 시스템 소유자(System Owners)
• 외부 이해관계자(Externel Stakeholders)

Mentcare 시스템의 이해관계자 예시

Mentcare는 정신 건강 관리 시스템이다. 이 시스템에는 다음과 같은 다양하 이해관계자들이 존재한다.

• 환자 (환자의 정보가 시스템에 저장됨)
• 의사 (환자를 평가하고 치료함)
• 간호사 (진료 예약을 조정하고 치료 일부를 담당)
• 접수 담당자 (환자 예약을 관리함)
• IT 직원 (시스템 설치 및 유지보수 담당)
• 의료 윤리 관리자 (윤리 기준을 지키는지 점검)
• 병원 관리자 (경영 정보를 추출함)
• 의무기록 담당자 (기록의 보존과 관리 책임)

이처럼 하나의 시스템에도 매우 다양한 입장과 요구를 가진 이해관계자들이 존재하기 때문에 요구사항을 정리할 때 그들의 입장을 모두 고려해야 한다.

애자일 방법론과 요구사항

애자일 방법론은 다음과 같은 관점을 가진다.

• 상세한 시스템 요구사항을 문서화하는 것은 불필요할 수 있다. 왜냐하먄 요구사항은 항상 바뀌기 때문이다.
• 그래서 문서로 작성된 요구사항은 곧 시점이 지나면 쓸모 없어질 것이다.
• 애자일 방식에서는 요구사항을 점진적으로 도출하고, 그 요구를 “사용자 스토리(User Stories)” 형태로 표현하는 방식을 선호한다.

이러한 접근은 비즈니스 시스템에는 잘 맞지만, 사전에 명확한 분석이 필요한 시스템(예:critical system)이나 여러 팀이 병렬로 개발하는 시스템에는 적용이 어렵다.

Functional and Non-functional Requirments

요구사항 공학에서 다루는 가장 기본적인 개념 중 하나는 바로 “요구사항의 종류”에 관한 것이다. 우리는 보통 요구사항을 두 가지로 분류한다. 첫째는 기능적 요구사항(Functional Requirements), 둘째는 비기능적 요구사항(Non-functional Requirements)이며, 여기에 더해 도메인 요구사항이라는 특수한 요구사항도 함께 고려된다. 이 세 가지는 모두 시스템이 무엇을 해야 하는가와 어떤 제약 조건 속에서 동작해야 하는가를 명확하게 정의해주는 중요한 기준이 된다.

Functional Requirements(기능적 요구사항)

기능적 요구사항은 말 그대로 시스템이 수행해야 할 기능에 관한 설명이다. 어떤 입력이 들어왔을 때 시스템이 어떤 방식으로 반응해야 하는지, 특정 상황에서 어떤 행동을 취해야 하는지를 정의한다. 또한, 시스템이 해서는 안 되는 행위도 기능적 요구사항의 일부로 포함될 수 있다.

이러한 요구사항은 시스템의 사용 대상, 운영 환경, 소프트웨어의 유형 등에 따라 그 표현 방식과 세부 사항이 달라진다. 사용자 관점에서는 다소 추상적이고 포괄적으로 진술되는 반면, 개발자 관점에서는 보다 구체적이고 기술적인 수준에서 작성된다.

예를 들어, Mentcare라는 정신 건강 관리 시스템에서는 다음과 같은 기능적 요구사항이 포함될 수 있다. 사용자는 진료소별 예약 목록을 검색할 수 있어야 하며, 시스템은 매일 각 진료소별로 당일 예약 환자 목록을 자동으로 생성해야 한다. 또한, 시스템 사용자 각각은 고유한 8자리 사번으로 식별되어야 한다.

하지만 이처럼 명확하게 작성되지 않은 요구사항은 혼선을 초래할 수 있다. 예를 들어 “검색 기능이 있어야 한다”는 문장은 사용자에게는 “모든 진료소에 걸쳐 검색”으로 해석되지만, 개발자는 “선택한 진료소 내 검색”으로 받아들일 수 있다. 이처럼 모호한 표현은 요구사항 충돌과 개발 오류를 낳을 수 있기 때문에, 기능적 요구사항은 항상 가능한 한 정확하고 명료하게 진술되어야 한다.

또한, 기능적 요구사항은 완전성과 일관성을 갖추는 것이 이상적이다. 완전성은 시스템이 수행해야 할 모든 기능이 누락 없이 포함되어야 함을 의미하며, 일관성은 기능들 간에 충돌이나 모순이 없어야 함을 뜻한다. 하지만 현실적으로는 복잡한 시스템 환경과 다양한 이해관계자의 요구로 인해 완전하고 일관된 문서를 작성하기란 매우 어렵다.

Non-Functional Requirements(비기능적 요구사항)

비기능적 요구사항은 시스템이 어떤 특성을 가져야 하는지, 그리고 어떤 제약 조건 아래서 동작해야 하는지를 기술한다. 예를 들어, 시스템의 신뢰성, 응답 속도, 저장 용량, 사용성, 보안성 등이 모두 비기능적 요구사항의 예이다.

이러한 요구사항은 종종 시스템 전체에 적용되며, 하나의 비기능 요구가 여러 기능 요구로 이어지기도 한다. 예컨대 “시스템은 높은 보안을 제공해야 한다”는 비기능 요구는 사용자 인증, 접근 제한, 데이터 암호화 등의 여러 기능 요구사항을 유발할 수 있다.

비기능적 요구사항은 시스템 설계에 큰 영향을 미치며, 때로는 기능적 요구사항보다 더 중요하게 여겨지기도 한다. 예를 들어, 모든 기능이 제대로 작동한다고 하더라도, 시스템이 응답 속도가 너무 느리거나 보안에 취약하다면 실제로는 사용할 수 없는 시스템이 되어버릴 수 있기 때문이다.

이러한 비기능 요구는 세 가지 주요 유형으로 분류할 수 있다. 제품 요구사항(Product Requirements) 은 소프트웨어 자체의 성능, 신뢰성 등을 다루며, 조직 요구사항(Organizational Requirements) 은 조직의 정책이나 표준에 따른 개발 요구를 담고 있다. 마지막으로, 외부 요구사항(External Requirements) 은 법률, 규제, 외부 시스템과의 연동 같은 외부 요인에 의해 결정된다.

Mentcare 시스템을 예로 들면 다음과 같은 비기능 요구사항을 포함할 수 있다. 첫째, 시스템은 평일 오전 8시 30분부터 오후 5시 30분까지 모든 진료소에서 사용 가능해야 하며, 정상 운영 시간 중 다운타임은 하루에 5초를 초과해서는 안 된다. 둘째, 모든 사용자는 건강관리 기관의 신분 확인 카드를 통해 본인 인증을 해야 하며, 셋째, 시스템은 환자의 개인정보 보호 관련 법규를 충실히 따라야 한다.

비기능적 요구사항은 구체적으로 진술하기 어렵고, 측정 가능한 형태로 표현되지 않으면 검증이 어려운 경우가 많다. 이럴 때는 “목표(goal)”와 “검증 가능한 요구사항(verifiable requirement)”를 구분해 사용하는 것이 좋다. 예컨대, “사용하기 쉬운 시스템이어야 한다”는 것은 목표에 해당하고, “4시간의 교육 이후 시스템 기능을 숙련도 높은 수준으로 사용할 수 있어야 하며, 시간당 오류 발생이 평균 2건 이하일 것”이라는 진술은 검증 가능한 요구사항이다.

이러한 요구를 보다 명확히 표현하기 위해 우리는 종종 다음과 같은 측정 지표(metrics) 를 사용한다. 속도는 초당 처리 건수나 응답 시간으로 측정할 수 있고, 사용 편의성은 교육 시간이나 도움말 화면 수로, 신뢰성은 평균 고장 간격이나 오류 발생률로 측정할 수 있다. 견고성, 이식성 등도 마찬가지로 정의된 지표를 통해 객관적인 평가가 가능해진다.

이처럼 기능적 요구와 비기능적 요구는 시스템 요구사항의 양대 축이라 할 수 있으며, 모두가 시스템의 품질과 사용성을 결정짓는 중요한 기준이 된다.

Requirements Engineering Process

요구사항 공학(Requirements Engineering)을 실제로 수행하는 방식은 매우 다양하다. 사용되는 프로세스는 시스템이 속한 응용 분야, 참여하는 사람들의 특성, 그리고 요구사항을 개발하는 조직의 개발 문화에 따라 달라질 수 있다. 하지만 이러한 다양성에도 불구하고, 모든 요구사항 공학 과정에는 공통적으로 등장하는 기본 활동들이 있다.

요구사항 공학에서 핵심이 되는 네 가지 활동은 다음과 같다:

• 요구사항 도출(Requirements Elicitation) : 사용자의 필요와 기대를 알아내는 단계이다. 이는 단순히 질문지를 작성하거나 인터뷰를 하는 것을 넘어서, 사용자와의 긴밀한 협업을 통해 그들이 명확히 인식하지 못한 요구까지 포착해내는 과정이다.
• 요구사항 분석(Requirements Analysis) : 도출된 요구사항을 구조화하고 분류하며, 모순을 찾아내고 요구 간의 우선순위를 정하는 작업이다. 이 단계에서는 기술적 현실성과 비즈니스 가치를 함께 고려하여 요구를 정제한다.
• 요구사항 검증(Requirements Validation) : 분석된 요구사항이 정확한지, 사용자의 기대와 일치하는지를 검토하는 단계이다. 오류나 누락, 모호함이 없는지를 점검하며, 이를 위해 리뷰, 프로토타입, 테스트 케이스 등을 활용한다.
• 요구사항 관리(Requirements Management) : 프로젝트 진행 중 변경되는 요구사항을 추적하고, 변경이 시스템 전체에 미치는 영향을 평가하는 활동이다. 요구사항은 고정된 것이 아니므로, 변화에 유연하게 대응할 수 있는 관리 체계가 필수적이다.

이러한 네 가지 활동은 순차적으로만 진행되는 것이 아니라, 반복적(iterative)으로 이루어진다. 예를 들어, 요구사항을 도출한 후 분석 과정에서 누락된 내용이 발견되면 다시 도출 단계로 돌아갈 수 있다. 요구사항 공학은 하나의 순환적 사이클(spiral)을 따라 점진적으로 정교화되는 과정이 되는 것이다.

이러한 반복적 활동은 각 단계가 독립적으로 존재하지 않으며, 실질적으로는 서로 밀접하게 얽혀 있다는 점을 보여준다. 프로젝트가 커지고 복잡해질수록 이들 간의 상호 작용은 더욱 중요해지며, 유연한 프로세스 운용이 요구된다.

요구사항 도출(Requirements Elicitation)

요구사항 도출(또는 발견)은 종종 ‘요구사항 발견(Requirements Discovery)’이라고도 불리며, 시스템이 작동할 도메인 환경에 대한 이해부터 시스템이 제공해야 할 서비스, 작동 시 제한 조건까지를 파악하는 일련의 활동을 포함한다. 이 과정은 단순히 기술자와 고객 간의 인터뷰만이 아니라, 최종 사용자, 관리자, 유지보수 담당자, 도메인 전문가, 외부 규제 기관 관계자 등 다양한 이해관계자들과의 상호작용을 포함한다.

요구사항 도출은 다음의 네 가지 주요 단계를 포함하는 복합적인 과정이다.

• 요구사항 발견(Requirements discovery) : 이해관계자들과의 상호작용을 통해 명시적/암묵적 요구사항을 수집한다. 이때, 도메인에 특화된 요구사항도 함께 도출된다.
• 요구사항 분류 및 조직화(Requirements classification and organization) : 수집된 요구를 주제별로 묶고, 관련성을 기준으로 체계적으로 정리한다.
• 우선순위 지정 및 협상(Requirements prioritization and negotiation) : 상충되는 요구사항 간의 우선순위를 정하고, 이해관계자 간의 협상을 통해 해결점을 찾는다.
• 요구사항 명세화(Requirements specification) : 정리된 요구사항을 문서화하고, 다음 개발 단계로 넘긴다.

요구사항 도출 과정에는 여러 가지 어려움이 따른다. 우선, 이해관계자 스스로도 자신이 정확히 무엇을 원하는지 모를 수 있다. 또한, 요구를 각자의 언어로 표현하기 때문에 기술자들이 이를 오해하거나 잘못 해석할 가능성도 있다. 서로 다른 이해관계자들이 상충되는 요구를 제시하는 경우도 흔하며, 조직 내부의 정치적 요인이나 외부 규제도 요구사항에 영향을 줄 수 있다. 게다가, 도출 중에 새로운 이해관계자가 등장하거나, 비즈니스 환경이 바뀌면서 요구사항이 변경되기도 한다.

요구사항 도출 기법

요구사항 도출에는 다양한 기법이 활용되며, 그중 대표적인 것이 인터뷰(Interviewing)이다. 인터뷰는 형식적일 수도 있고 비형식적일 수도 있으며, 일반적으로는 미리 준비한 질문지를 기반으로 한 폐쇄형 인터뷰와, 대화 중심으로 자유롭게 요구사항을 탐색하는 개방형 인터뷰를 혼합해서 진행한다.

효과적인 인터뷰를 위해서는 선입견을 배제하고, 열린 마음으로 이해관계자의 이야기를 듣는 태도가 중요하다. 대화를 유도하기 위해 질문, 요구사항 제안, 프로토타입 기반 탐색 등이 활용된다. 다만 인터뷰는 도메인 요구사항을 깊이 이해하기엔 한계가 있다. 인터뷰 대상자가 사용하는 전문 용어가 익숙하지 않을 수 있고, 그들이 가진 암묵적 지식은 설명 없이 지나치는 경우가 많기 때문이다.

이러한 한계를 보완하기 위한 기법 중 하나가 민속지학(Ethnography)이다. 이는 사회과학자가 실제 업무 현장을 관찰하며 사람들의 작업 방식을 분석하는 방법이다. 참여자의 직접적인 설명 없이도, 사회적 조직적 요인을 자연스럽게 관찰할 수 있으며, 사람들이 실제로 어떤 방식으로 협업하고 의사소통하는지를 이해하는 데 매우 유용하다. 민속지학은 특히 현재 운영 중인 시스템의 문제점이나 개선점을 발견하는 데 효과적이지만, 새로운 기능이나 시스템의 미래 방향을 설계하는 데는 적합하지 않을 수 있다.

집중 민속지학(Focused Ethnography)은 민속지학과 프로토타입 개발을 결합한 형태로, 프로토타입을 통해 발생한 의문점들을 중심으로 관찰이 이루어진다. 이는 특히 항공 교통 제어 시스템처럼 복잡한 현장에서 효과적으로 활용된다.

사용자 이야기와 시나리오(User Stories and Scenarios)

요구사항을 실질적으로 이해하기 위한 또 다른 유용한 방법은 사용자 이야기(User Stories)와 시나리오(Scenarios)를 활용하는 것이다. 사용자 이야기는 시스템이 실제로 어떻게 사용되는지를 묘사하는 실생활 기반의 예시다. 이러한 이야기들은 이해관계자들이 자신의 상황에 빗대어 판단하고 의견을 제시할 수 있도록 돕는다.

예를 들어, 한 초등학교 교사인 Jack은 자신의 수업에서 지역 어업 산업을 주제로 프로젝트를 진행하면서, 학생들이 사진을 공유하고 논의할 수 있는 플랫폼을 필요했다. 그는 iLearn 시스템과 SCRAN 아카이브를 활용하면서도, 사진 공유 기능을 보완하기 위해 KidsTakePics라는 서비스를 별도로 연결하여 사용했다. 이 실생활 이야기를 통해 시스템의 연동성, 사용성, 인증 체계 등에 대한 요구사항을 자연스럽게 도출할 수 있다.

이와 같은 사용자 이야기로부터 도출된 시나리오는 더 구조적인 형식을 취한다. 시나리오는 다음과 같은 요소들을 포함해야 한다.

• 시작 상황의 설명
• 정상적인 이벤트 흐름
• 오류 상황에 대한 대응
• 동시적으로 발생할 수 있는 다른 활동
• 시나리오 종료 시의 시스템 상태

Jack의 예를 계속 이어보자. 사진 업로드 시나리오에서는 사용자가 사진을 선택하고 키워드를 입력한 뒤 업로드를 완료하면, 프로젝트 관리자에게 이메일이 발송되고 사용자에게는 완료 메시지가 표시된다. 그러나 만약 관리자 계정이 설정되지 않았거나 파일명이 중복된 경우, 각각 자동 알림이나 이름 자동 변경 등의 예외 처리가 이루어진다. 이러한 상세한 시나리오는 개발자가 실질적인 기능 구현에 필요한 정확한 정보를 얻는 데 큰 도움이 된다.

요구사항 명세(Requirements Specification)

요구사항 명세는 사용자의 요구와 시스템이 수행해야 할 기능을 문서화하는 과정이다. 이 단계에서는 앞서 도출되고 분석된 요구사항들을 명확하고 일관성 있게 정리하여 공식 문서로 작성하게 된다. 특히, 이 문서는 종종 개발 계약의 일부로 포함되기 때문에 가능한 완전하고 정확하게 기술되어야 한다.

사용자 요구사항(User Reuquirements)은 기술적 배경이 없는 사용자나 고객도 이해할 수 있도록 자연어와 간단한 도식으로 표현되어야 한다. 반면, 시스템 요구사항(System Requirements)은 기술자나 개발자를 위한 문서로, 보다 상세하고 기술적인 정보를 포함할 수 있다.

요구사항 명세를 작성하는 방식은 다양하다. 가장 널리 사용되는 방식은 자연어(Natural Language)를 기반으로 하는 것이며, 이 외에도 구조화된 자연어(Structed Natural language), 디자인 기술 언어(Design Description Languages), 그래픽 표현(Graphical Notation), 수학적 명세(Mathemetical Specification) 등이 있다.

예를 들어, 자연어 명세는 번호가 붙은 문장 형식으로 요구사항을 서술하며, 직관적이고 누구나 이해하기 쉬운 장점이 있다. 그러나 모호하거나 불명확해질 수 있고, 기능적/비기능저거 요구가 뒤섞이는 문제도 발생할 수 있다. 이런 한계를 줄이기 위해 구조화된 양식을 사용하거나 다이어그램, 표 형식을 병행하기도 한다.

요구사항 문서를 작성할 때는 통일된 형식, 일관된 용어 사용, 그리고 “shall”(반드시), “Should”(바람직하다)와 같은 표현 구분이 중요하다. 컴퓨터 용어는 가급적 피하고, 각 요구사항에는 이유나 배경(rationable)을 간단히 설명하는 것이 바람직하다.

예를 들어, 인슐린 펌프 시스템의 명세 중 다음과 같은 문장이 있다.

• “시스템은 10분마다 혈당을 측정하고 필요시 인슐린을 주입해야 한다.”
• “시스템은 1분마다 자가 진단 루티을 수행해야 하며, 진단 조건과 그에 따른 조치는 표1에 정의되어 있다.”

이와 같이 자연어와 함께 표나 다이어그램이 병행되면 더욱 명확하고 실용적인 명세가 된다.

구조화 명세(Structured Specification)은 요구사항 작성자의 자유도를 제한하여, 특정 양식에 따라 요구사항을 기술하는 방식이다. 특히 임베디드 시스템과 같은 제어 시스템에 적합하지만, 복잡한 비즈니스 시스템에는 너무 경직된 형식일 수 있다. 구조화 명세는 보통 기능 정의, 입력과 출력, 전제 조건과 사후 조건, 부작용 여부 등을 포함한다.

• A structured specification of a requirement for an insulin pump

또한, 표 형식(Tabular Specification)은 다양한 조건에 따른 행동 방식을 명확히 표현할 수 있어 유용하다. 인슐린 펌프 예시에서는 혈당 변화 속도에 따라 인슐린 투여량을 결정하는 알고리즘이 표로 정리되어 있으며, 각 조건에 따른 구체적 계산 방법이 기술된다.

유스케이스(Use Cases)도 요구사항 명세의 중요한 수단 중 하나이다. 유스케이스는 UML 기반 시나리오로서, 사용자(엑터)와 시스템 간의 상호작용을 정의한다. 각 유스케이스는 시스템과의 모든 가능한 상호작용을 설명하며, 일반적으로 그래픽 모델과 표 형식의 설명을 함께 포함한다. 시퀀스 다이어그램 등을 추가하면 처리 순서까지 상세히 표현할 수 있다.

요구사항 명세의 최종 산출물은 소프트웨어 요구사항 문서(Software Requirements Document)이다. 이 문서는 시스템 개발자에게 요구되는 기능과 제약을 공식적으로 정의하며, 설계 문서가 아닌, 시스템이 무엇을 해야 하는지(WHAT)를 설명하는 데 집중한다. 가능한 어떻게(HOW)에 대한 설명은 배제해야 한다.

요구사항 문서의 내용은 시스템의 종류와 개발 방식에 따라 달라진다. 예를 들어, 점진적으로 개발되는 시스템은 초기 요구사항이 상세하지 않을 수 있다. 국제 표준(예: IEEE SRS 표준)은 특히 대형 시스템에서 사용되는 요구사항 문서의 형식을 정의하고 있다.

요구사항 문서의 일반적인 구성은 다음과 같다:

• 서문(Preface) : 문서의 독자층, 버전 히스터리, 변경 요약 등을 기술한다.
• 소개(Introduction) : 시스템의 필요성, 기능 개요, 다른 시스템과의 연계, 비즈니스 목적 등을 설명한다.
• 용어 설명(Glossary) : 문서에서 사용하는 기술 용어들을 정의하여 비전문가도 이해할 수 있도록 돕는다.
• 사용자 요구사항 정의(Usre Requirements Definition) : 사용자 관점의 서비스 설명과 비기능 요구사항을 포함하며, 자연어와 도표 등을 사용한다.
• 시스템 아키텍쳐(System Architecture) : 고수준 시스템 구조를 개요로 설명하며, 재사용 컴포넌트 등을 강조한다.
• 시스템 요구사항 명세(System Requirements Specification) : 기능적/비기능적 요구사항을 기술하며, 외부 시스템과의 인터페이스도 명시한다.
• 시스템 모델(System Models) : 객체 모델, 데이터 흐름도, 의미적 데이터 모델 등 시스템 구성요소 간 관계를 시각화한다.
• 시스템 진화(System Evolution) : 하드웨어 진화, 사용자 요구 변화 등을 반영한 설계 전제와 향후 변화 가능성에 대해 설명한다.
• 부록(Appendices) : 하드웨어 사양, 데이터베이스 구조 등 관련 세부정보를 포함한다.
• 색인(Index) : 일반 색인 외에도 다이어그램, 기능 등 다양한 색인을 제공하여 문서 탐색을 용이하게 한다.

이와 같이 요구사항 명세는 소프트웨어 개발의 초석을 다지는 단계로서, 전체 개발 과정의 정확성과 효율성을 좌우하는 핵심 문서다. 체계적인 구조와 명확한 표현이 뒷받침될 때, 개발팀과 고객 모두가 만족할 수 있는 결과물을 만들어낼 수 있다.

요구사항 검증(Requirements Validation)

요구사항 검증은 요구사항이 실제로 고객이 진정으로 원하는 시스템을 정의하고 있는지를 확인하는 데 목적이 있다. 이 과정은 단순한 문서 확인을 넘어서, 오류나 누락, 불일치를 조기에 발견하여, 개발 과정에서의 비용과 리스크를 줄이는 데 결정적인 역할을 한다.

특히 소프트웨어 프로젝트에서 요구사항 오류는 고비용 오류로 분류된다. 구현 단계에서 발견된 오류보다 요구사항 단계에서 발견되지 않은 오류는 최종 제품이 사용자에게 전달된 이후 발견되는 경우가 많으며, 이때는 수정을 위해 최대 100배에 달하는 비용이 소요될 수 있다. 따라서 요구사항 검증은 매우 중요하며, 가능한 초기 단계에서 집중적으로 수행되어야 한다.

요구사항 검증에서는 다음과 같은 항목들을 중심으로 확인이 이루어진다.

• 타당성(Validity) : 시스템이 고객의 요구를 충분히 반영하고 있는가?
• 일관성(Consistency) : 요구사항 간에 충돌이나 모순은 없는가?
• 완전성(Completeness) : 고객이 요구한 기능이 모두 포함되어 있는가?
• 현실성(Realism) : 현재의 예산과 기술로 구현 가능한가?
• 검증 가능성(Verifiability) : 요구사항이 명확하게 정의되어 테스트 가능한가?

이러한 점들을 확인하기 위해 다양한 검증 기법이 사용된다. 대표적인 검증 기법은 다음과 같다.

1. 요구사항 검토(Requirements Reviews) : 시스템적이고 체계적인 방식으로 요구사항 문서를 수작업으로 분석하는 것이다. 개발자, 사용자, 고객 등이 함께 참여하여 리뷰를 수행하며, 문서가 완성된 이후뿐 아니라 작성 과정 중간중간 정기적으로 수행하는 것이 좋다.

2. 프로토타이핑(Prototyping) : 실행 가능한 모델(프로토타입)을 통해 실제 사용 흐름을 확인하면서 요구사항이 잘 반영되어 있는지를 점검한다. 이 기법은 Software Process에서 다룬 바 있으며, 요구를 시각화하고 사용자 피드백을 빠르게 받는 데 효과적이다.

3. 테스트 케이스 생성(Test-case Generation) : 요구사항에 기반한 테스트 케이스를 만들어봄으로써 요구사항이 실제로 검증 가능한지 여부를 평가한다. 테스트 가능성이 없는 요구사항은 일반적으로 모호하거나 과도하게 추상적인 경우가 많다.

요구사항 리뷰를 수행할 때는 다음과 같은 항목을 기준으로 체크하는 것이 일반적이다.

• 검증 가능성(Verifiability) : 해당 요구사항이 현실적으로 테스트 가능한가?
• 이해 가능성(Comprehensibility) : 요구사항이 명확하게 이해될 수 있는 형태로 작성되어 있는가?
• 추적 가능성(Traceability) : 해당 요구사항의 출처가 명확히 기록되어 있는가?
• 수정 가능성(Adaptability) : 이 요구사항을 변경할 경우 다른 요구사항에 미치는 영향은 제한적인가?

이러한 기준을 바탕으로 요구사항을 체계적으로 검토하고, 조기에 문제가 되는 항목들을 파악해 수정함으로써, 프로젝트 전체의 안정성과 품질을 높일 수 있다. 요구사항 검증은 단지 형식적인 절차가 아니라, 개발의 성공을 결정짓는 중요한 품질 보증 활동 중 하나로 인식되어야 한다.

요구사항 변경(Requirements Change)

소프트웨어가 완성되어 설치된 이후에도 시스템이 운영되는 비즈니스 및 기술 환경은 지속적으로 변화한다. 새로운 하드웨어가 도입되거나, 기존 시스템과의 연동이 필요해질 수도 있으며, 조직의 비즈니스 우선순위가 바뀌거나 새로운 법률과 규제가 생기면서 시스템 역시 변화에 적응해야 한다. 이로 인해 요구사항은 시스템의 생애 주기 동안 계속해서 진화하게 된다.

특히 문제는 시스템을 구매하고 비용을 지불하는 사람과 실제로 이를 사용하는 사람이 서로 다를 수 있다는 점이다. 시스템 구매자는 조직의 예산과 정책에 따라 요구사항을 정리하는 반면, 실제 사용자는 그들이 밑은 실무에 맞는 추가적인 기능을 필요로 한다. 따라서 시스템이 납품된 이후에도 사용자의 니즈를 충족시키기 위한 새로운 기능 요구가 계속해서 발생하게 된다.

대규모 시스템일수록 사용자 집단이 다양하고 광범위하다. 이들 각각은 서로 다른 요구와 우선 순위를 갖고 있으며, 요구 간 충돌이나 모순이 발생하는 경우도 많다. 이러한 요구사항은 대개 절충과 협상을 통해 타협점을 찾아야 하며, 시스템이 실제로 사용되기 시작한 이후에야 어느 부분이 더 많은 지원을 받아야 하는지가 명확해지는 경우도 있다. 이처럼 요구사항은 단발성으로 고정되는 것이 아니라, 점차적으로 진화(evolution)하고 조정(adjustment) 되어야 할 대상이다.

• Requirements Evolution

요구사항 관리(Requirements Management)

요구사항 관리란 요구사항 공학 및 시스템 개발 과정 전반에서 발생하는 요구사항 변경을 체계적으로 관리한 활동을 의미한다. 새로운 요구사항은 시스템이 개발되는 도중은 물론이고, 실제 운영 이후에도 지속적으로 발생한다. 따라서 각 요구사항을 추적할 수 있도록 식별하고, 서로 관련된 요구사항 간의 연결을 유지하며, 변경이 시스템 전체에 미치는 영향을 평가할 수 있는 체계가 필요하다.

요구사항 관리 계획(Requirements Management Planning)은 다음과 같은 사항들을 포함한다.

• 요구사항 식별 : 모든 요구사항은 고유하게 식별될 수 있어야 하며, 서로 참조 가능해야 한다.
• 변경 관리 프로세스 : 변경 요청이 들어왔을 때, 그 영향도와 비용을 분석하는 절차를 마련해야 한다. 이 절차는 후속 섹션에서 자세히 다룬다.
• 추적 정책(Traceability Policy) : 각 요구사항이 시스템의 어느 설계 요소와 연관되는지를 명시하고 기록해야 한다.
• 도구 지원 : 전용 요구사항 관리 시스템, 엑셀 스프레드시트, 간단한 데이터 베이스 등 다양한 도구를 활용할 수 있다.

요구사항 변경 관리(Requirements Change Management)

요구사항 변경을 관리하기 위해서는 변경을 받아들일지 여부를 결정하는 명확한 절차가 필요하다. 이 절차는 다음과 같은 세 가지 주요 단계로 구성된다.

• 문제 분석 및 변경 명세화
  • 먼저 변경 요청 또는 문제가 실제로 타당한지를 분석한다.
  • 분석 결과는 요청자에게 전달되며, 요청자는 이를 바탕으로 더 구체적인 요구 변경 제안을 할 수도 있고, 요청을 철회할 수도 있다.
• 변경 분석 및 비용 산정
  • 제안된 변경 사항이 전체 시스템에 미치는 영향을 평가한다. 이때 요구사항 간의 추적 정보(traceability)가 중요한 자료로 활용된다.
  • 분석이 완료되면, 변경을 수용할지 여부에 대한 결정이 이루어진다.
• 변경 구현
  • 변경이 승인되면 요구사항 문서는 물론, 필요에 따라 시스템 설계 및 구현도 수정되어야 한다.
  • 문서는 가능한 변경이 용이한 구조로 조직되어 있으야 하며, 변경 내용을 명확히 반영할 수 있어야 한다.

  

이러한 체계적인 요구사항 변경 관리는 프로젝트 진행 중 예기치 않은 요구의 변동에도 유연하게 대응할 수 있게 해주며, 전체 시스템 품질을 유지하는 데 필수적인 절차로 자리잡고 있다.

Key Points

• 소프트웨어 시스템의 요구사항은 무엇을 해야 하는지와 어떤 제약 아래서 동작해야 하는지를 명확히 규정한다.
• 기능적 요구사항(Functional Requirements)은 시스템이 제공해야 할 서비스나 수행해야 할 연산을 설명한다.
• 비기능적 요구사항(Non-Funtional Requirements)은 시스템의 제약사항이나 전반적인 성능, 신뢰성 등과 같은 출현적 속성(Emergent Properties)을 정의하며, 시스템 전체에 영향을 미치는 경우가 많다.
• 요구사항 공학은 반복적인 과정이며, 요구 도출 -> 분석 -> 명세 -> 검증 -> 변경 관리의 사이클을 따라 순환한다.
• 요구사항 도출은 인터뷰, 민속지학, 사용자 이야기 및 시나리오 등 다양한 기법을 통해 수행된다.
• 요구사항 명세는 자연어, 구조화된 형식, 표, 그래픽 모델 등을 통해 사용자와 개발자 모두가 이해할 수 있도록 정리되어야 한다.
• 요구사항 검증은 타당성, 일관성, 완전성, 현실성, 검증 가능성의 다섯가지 요소를 중심으로 검토되며, 리뷰, 프로토타입, 테스트 케이스 생성 등의 기법이 활용된다.
• 시스템이 운영되면서 비즈니스, 기술, 법칙 환경은 계속해서 바뀌므로, 요구사항 역시 지속적으로 진화하며, 이를 요구사항 관리 및 변경 관리 체계로 유연하게 다뤄야한다.