소프트웨어 공학: 소프트웨어 요구사항 - 모든 시스템 개발의 기초

 

대학 시절 배웠던 "소프트웨어 공학" 교재를 다시 한번 읽어보기로 했어요.

천천히 정리하면서 중간중간 경험적 내용을 추가하면 아주 좋은 기록이 될거 같네요.

이번 포스팅에서는 요구공학과 소프트웨어 요구사항에 대해 알아 볼게요.

 

 

이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다. 

 

 

1. 사용자 요구사항과 시스템 요구사항

소프트웨어 시스템 요구 사항은 시스템이 수행해야 하는 작업, 제공해야 하는 서비스, 그리고 운영에 대한 제약 조건을 설명합니다.

이러한 소프트웨어  시스템 요구 사항은 특정 목적을 수행하는 시스템을 원하는 고객의 요구를 반영합니다.

 

또한 요구공학(Requirements Engieering, RE)이란 이러한 서비스와 제약을 파악하고, 분석하며, 문서화하고, 검토하는 과정을 의미합니다.

 

소프트웨어 산업에서 "요구 사항(Requirements)"이라는 용어는 일관되게 사용되지 않는 경향이 있습니다. 어떤 경우에는 요구 사항이 시스템이 제공해야 하는 서비스나 시스템에 대한 제약 조건에 대한 고수준의 추상적인 진술을 의미하며, 다른 경우에는 시스템 기능에 대한 상세하고 공식적인 정의를 의미합니다.

 

Davis(1993)는 이러한 차이가 발생하는 이유를 다음과 같이 설명합니다:

“대규모 소프트웨어 개발 프로젝트를 위한 계약을 체결하려는 회사는 해결책이 미리 정의되지 않도록 요구 사항을 충분히 추상적인 방식으로 정의해야 합니다. 여러 계약자가 입찰할 수 있도록 요구 사항을 작성해야 하며, 이는 아마도 클라이언트 조직의 요구를 충족시키기 위한 다양한 방법을 제시할 것입니다. 계약이 체결되면, 계약자는 소프트웨어가 수행할 작업을 클라이언트가 이해하고 검증할 수 있도록 더 자세한 시스템 정의를 작성해야 합니다. 이 두 문서는 모두 시스템의 요구 사항 문서라고 불릴 수 있습니다.”

 

요구 사항 엔지니어링 과정에서 발생하는 문제 중 일부는 이러한 서로 다른 수준의 설명을 명확하게 구분하지 못한 결과입니다. 이를 위해, 요구 사항을 "사용자 요구 사항"과 "시스템 요구 사항"으로 구분할 수 있습니다.

 

1. 사용자 요구 사항(User Requirements): 자연어와 다이어그램을 사용하여 시스템 사용자가 시스템에 기대하는 서비스와 시스템이 운영되어야 하는 제약 조건을 설명합니다. 사용자 요구 사항은 시스템이 수행해야 할 작업을 높은 수준에서 설명하며, 주로 시스템의 외부 행동에 초점을 맞춥니다.

2. 시스템 요구 사항(System Requirements): 소프트웨어 시스템의 기능, 서비스, 그리고 운영 제약 조건에 대한 보다 상세한 설명입니다. 시스템 요구 사항 문서(때로는 기능 명세서라고도 불림)는 구현해야 할 내용을 정확하게 정의해야 하며, 시스템 구매자와 소프트웨어 개발자 간의 계약의 일부가 될 수 있습니다.

 

그림 4.1 사용자 요구사항과 시스템 요구사항

 

그림 4.1은 사용자 요구 사항과 시스템 요구 사항의 차이를 보여줍니다. 이 예시는 정신 건강 관리 환자 관리 시스템(MHC-PMS)에서 가져온 것으로, 하나의 사용자 요구 사항이 여러 시스템 요구 사항으로 확장되는 방식을 보여줍니다. 그림 4.1에서 볼 수 있듯이, 사용자 요구 사항은 일반적인 수준에서 시스템이 제공해야 할 서비스와 기능을 설명합니다. 반면, 시스템 요구 사항은 더 구체적이고 세부적인 정보를 제공하여 개발자가 실제로 구현할 내용을 명확하게 정의합니다.

 

그림 4.2 사용자 요구사항에 대한 독자, 그리고 시스템 요구사항에 대한 독자

 

그림 4.2는 사용자 요구 사항과 시스템 요구 사항의 잠재적인 독자들을 보여줍니다. 사용자 요구 사항의 독자는 주로 시스템이 어떻게 구현될지에 관심이 없는 관리자일 수 있으며, 시스템의 세부 기능보다는 전체적인 서비스와 제약에 관심을 가집니다. 반면, 시스템 요구 사항의 독자는 시스템이 비즈니스 프로세스를 어떻게 지원할지 또는 시스템 구현에 어떻게 관여할지를 더 정확히 알고자 하는 사람들입니다.

 

대규모 시스템의 경우, 시스템 구현이 시작되기 전에 요구 사항 엔지니어링 단계가 명확히 식별되는 경우가 많습니다. 이 과정의 결과로 요구 사항 문서가 생성되며, 이는 시스템 개발 계약의 일부가 될 수 있습니다. 물론, 이후 요구 사항에 대한 변경이 발생하고 사용자 요구 사항이 보다 세부적인 시스템 요구 사항으로 확장될 수 있습니다. 그러나 애자일 접근 방식에서처럼 시스템 개발이 진행되는 동안 요구 사항을 동시다발적으로 수집하는 방식은 대규모 시스템 개발에서 흔히 사용되지는 않습니다.

 

2. 기능 요구사항과 비기능 요구사항

소프트웨어 시스템 요구 사항은 기능 요구 사항과 비기능 요구 사항으로 분류됩니다:

 

1. 기능 요구 사항: 기능 요구 사항은 시스템이 제공해야 할 서비스, 특정 입력에 대한 시스템의 반응, 그리고 특정 상황에서 시스템이 어떻게 동작해야 하는지를 기술한 것입니다. 경우에 따라 기능 요구 사항은 시스템이 수행하지 말아야 할 작업도 명시할 수 있습니다.

2. 비기능 요구 사항: 비기능 요구 사항은 시스템이 제공하는 서비스나 기능에 대한 제약 조건을 의미합니다. 여기에는 타이밍 제약, 개발 프로세스에 대한 제약, 그리고 표준에 의해 부과된 제약이 포함됩니다. 비기능 요구 사항은 종종 개별 시스템 기능이나 서비스보다는 시스템 전체에 적용됩니다.

 

실제로, 서로 다른 유형의 요구 사항 간의 구분은 이 간단한 정의가 암시하는 것만큼 명확하지 않습니다. 예를 들어, 보안과 관련된 사용자 요구 사항, 즉 인증된 사용자만 접근할 수 있도록 제한하는 진술은 비기능 요구 사항으로 보일 수 있습니다. 그러나 이를 더 자세히 개발하면, 시스템에 사용자 인증 기능을 포함해야 한다는 명확한 기능 요구 사항을 생성할 수 있습니다.

 

이는 요구 사항들이 독립적이지 않으며, 하나의 요구 사항이 종종 다른 요구 사항을 생성하거나 제약한다는 것을 보여줍니다. 따라서 시스템 요구 사항은 필요한 서비스나 기능뿐만 아니라 이러한 서비스/기능이 제대로 제공되도록 하기 위한 필수적인 기능도 명시합니다.

 

2.1 기능 요구 사항

시스템의 기능 요구 사항은 시스템이 수행해야 할 작업을 설명합니다. 이러한 요구 사항은 개발 중인 소프트웨어의 유형, 예상되는 사용자, 그리고 요구 사항을 작성할 때 조직이 취하는 일반적인 접근 방식에 따라 달라집니다. 사용자 요구 사항으로 표현될 때, 기능 요구 사항은 일반적으로 시스템 사용자가 이해할 수 있는 추상적인 방식으로 설명됩니다. 그러나 더 구체적인 시스템 기능 요구 사항은 시스템 기능, 입력과 출력, 예외 처리 등을 자세히 설명합니다.

 

 

 

도메인 요구사항

도메인 요구사항(Domain requirements)은 시스템 사용자의 특정 니즈보다는 시스템에 대한 어플리케이션 도메인으로부터 유도됩니다. 그래서 도메인 요구사항 그 자체가 하나의 기능 요구사항이 될 수도 있고, 도메인 어플리케이션 내에서 구현되는 로직에 대한 설명(방법)일 수도 있습니다. 이러한 도메인 요구사항의 문제점은 소프트웨어 엔지니어가 도메인 어플리케이션에 대한 특성을 잘 알지 못할 수 있다는 점입니다. 그래서 도메인 요구사항의 누락여부, 오류여부, 상호충돌여부 등을 알 수 없을 수 있습니다.

 

기능 시스템 요구 사항은 시스템이 수행해야 할 작업에 대한 일반적인 요구 사항부터 조직의 기존 시스템이나 특정 작업 방식을 반영한 매우 구체적인 요구 사항까지 다양합니다. 예를 들어, 정신 건강 관리 시스템(MHC-PMS)의 기능 요구 사항은 다음과 같습니다:

 

1. 사용자는 모든 클리닉의 예약 목록을 검색할 수 있어야 한다.

2. 시스템은 매일 각 클리닉별로 그날 예약된 환자 목록을 생성해야 한다.

3. 시스템을 사용하는 모든 직원은 고유한 8자리 직원 번호로 식별되어야 한다.

 

이러한 기능 사용자 요구 사항은 시스템이 제공해야 할 특정 기능을 정의합니다. 이들은 사용자 요구 사항 문서에서 가져온 것으로, 기능 요구 사항이 서로 다른 수준의 세부 사항으로 작성될 수 있음을 보여줍니다(요구 사항 1과 3을 비교해보세요).

 

요구 사항 명세의 불명확성은 많은 소프트웨어 공학 문제의 원인이 됩니다. 시스템 개발자가 모호한 요구 사항을 구현하기 쉽게 해석하는 것은 자연스러운 일입니다. 그러나 이는 종종 고객이 원하는 것과 다를 수 있습니다. 새로운 요구 사항을 수립하고 시스템을 변경해야 하는 상황이 발생할 수 있습니다. 물론, 이는 시스템 제공을 지연시키고 비용을 증가시킵니다.

 

예를 들어, MHC-PMS의 첫 번째 예시 요구 사항은 사용자가 모든 클리닉의 예약 목록을 검색할 수 있어야 한다고 명시하고 있습니다. 이 요구 사항의 이유는 정신 건강 문제가 있는 환자들이 때때로 혼란스러워할 수 있기 때문입니다. 그들은 한 클리닉에서 예약이 있는데 실제로는 다른 클리닉에 갈 수 있습니다. 예약이 있다면, 그들은 클리닉에 참석한 것으로 기록될 것입니다.

 

이 요구 사항을 명시한 의료 직원은 ‘검색’이 환자 이름을 입력하면 시스템이 모든 클리닉의 모든 예약에서 해당 이름을 찾는 것을 의미한다고 기대할 수 있습니다. 그러나 이 요구 사항은 명확하게 정의되어 있지 않습니다. 시스템 개발자는 이 요구 사항을 다르게 해석하여 사용자가 클리닉을 선택한 후에 검색을 수행하도록 구현할 수 있습니다. 이는 더 많은 사용자 입력을 요구하며, 시간이 더 오래 걸릴 수 있습니다.

 

원칙적으로 시스템의 기능 요구 사항 명세는 완전하고 일관되게 작성되어야 합니다. 완전성은 사용자가 요구하는 모든 서비스가 정의되어야 함을 의미하며, 일관성은 요구 사항 간에 모순된 정의가 없어야 함을 의미합니다. 그러나 실제로는 대규모 복잡한 시스템의 경우 요구 사항의 일관성과 완전성을 달성하는 것이 거의 불가능합니다. 그 이유 중 하나는 복잡한 시스템의 명세를 작성할 때 실수와 누락이 발생하기 쉽기 때문입니다. 또 다른 이유는 대규모 시스템에는 다양한 이해관계자가 존재하기 때문입니다. 이해관계자는 시스템에 어떤 방식으로든 영향을 받는 사람이나 역할을 말합니다. 이해관계자들은 서로 다르며, 종종 일관되지 않은 요구를 가지고 있습니다. 이러한 불일치는 요구 사항이 처음 명시될 때는 명확하지 않을 수 있으며, 따라서 명세서에 모순된 요구 사항이 포함될 수 있습니다. 문제는 더 깊은 분석 후에나, 때로는 시스템이 고객에게 전달된 후에야 드러날 수 있습니다.

 

2.2 비기능 요구 사항

비기능 요구 사항은 그 이름에서 알 수 있듯이 시스템이 사용자에게 제공하는 특정 서비스와 직접적으로 관련이 없는 요구 사항입니다. 이러한 요구 사항은 신뢰성, 응답 시간, 저장 공간 점유율과 같은 발생 시스템 특성과 관련이 있을 수 있습니다. 또는 시스템 구현에 대한 제약 조건(예: I/O 장치의 기능이나 다른 시스템과의 인터페이스에서 사용되는 데이터 표현 방식)을 정의할 수 있습니다.

 

비기능 요구 사항은 성능, 보안, 가용성과 같은 시스템의 전체 특성을 지정하거나 제한합니다. 비기능 요구 사항은 종종 개별 기능 요구 사항보다 더 중요할 수 있습니다. 시스템 사용자는 자신이 원하는 방식으로 기능이 충족되지 않더라도 시스템을 사용하는 방법을 찾을 수 있지만, 비기능 요구 사항을 충족하지 못하면 시스템 전체가 사용 불가능할 수 있습니다. 예를 들어, 항공기 시스템이 신뢰성 요구 사항을 충족하지 못하면 안전 운행 인증을 받을 수 없으며, 임베디드 제어 시스템이 성능 요구 사항을 충족하지 못하면 제어 기능이 제대로 작동하지 않을 수 있습니다.

 

특정 기능 요구 사항을 구현하는 시스템 구성 요소를 식별하는 것은 종종 가능하지만(예: 보고서 요구 사항을 구현하는 서식 지정 구성 요소가 있을 수 있음), 비기능 요구 사항과 구성 요소를 연관시키는 것은 더 어렵습니다. 이러한 요구 사항의 구현은 시스템 전체에 걸쳐 분산될 수 있습니다. 그 이유는 다음과 같습니다:

 

1. 비기능 요구 사항은 개별 구성 요소보다는 시스템 전체 아키텍처에 영향을 미칠 수 있습니다. 예를 들어, 성능 요구 사항을 충족시키기 위해 구성 요소 간의 통신을 최소화하도록 시스템을 구성해야 할 수 있습니다.

2. 보안 요구 사항과 같은 단일 비기능 요구 사항은 새로운 시스템 서비스 정의와 같은 관련 기능 요구 사항을 여러 개 생성할 수 있습니다. 또한, 기존 요구 사항을 제한하는 요구 사항도 생성할 수 있습니다.

 

비기능 요구 사항은 사용자 요구, 예산 제약, 조직 정책, 다른 소프트웨어 또는 하드웨어 시스템과의 상호 운용성 필요성, 또는 안전 규정이나 개인정보 보호 법률과 같은 외부 요인으로 인해 발생할 수 있습니다. 그림 4.3은 비기능 요구 사항의 분류를 보여줍니다. 이 다이어그램에서 비기능 요구 사항은 소프트웨어의 필요한 특성(제품 요구 사항), 소프트웨어를 개발하는 조직(조직 요구 사항), 또는 외부 소스에서 올 수 있음을 알 수 있습니다:

그림 4.3 비기능 요구사항 분류(유형)

 

1. 제품 요구 사항: 이러한 요구 사항은 소프트웨어의 동작을 지정하거나 제한합니다. 예를 들어, 시스템이 얼마나 빨리 실행되어야 하는지, 얼마나 많은 메모리가 필요한지에 대한 성능 요구 사항, 허용 가능한 고장률을 설정하는 신뢰성 요구 사항, 보안 요구 사항, 사용성 요구 사항 등이 포함됩니다.

2. 조직 요구 사항: 이러한 요구 사항은 고객과 개발자의 조직에서의 정책 및 절차에서 도출된 광범위한 시스템 요구 사항입니다. 예를 들어, 시스템이 어떻게 사용될지를 정의하는 운영 프로세스 요구 사항, 사용해야 할 프로그래밍 언어, 개발 환경 또는 프로세스 표준을 지정하는 개발 프로세스 요구 사항, 시스템의 운영 환경을 명시하는 환경 요구 사항 등이 포함됩니다.

3. 외부 요구 사항: 이 범주는 시스템과 그 개발 프로세스의 외부 요인에서 도출된 모든 요구 사항을 포함합니다. 여기에는 시스템이 규제 기관에 의해 사용 승인을 받기 위해 준수해야 할 사항을 설정하는 규제 요구 사항, 시스템이 법적으로 운영되도록 하기 위해 따라야 할 법적 요구 사항, 시스템이 사용자와 일반 대중에게 수용될 수 있도록 보장하는 윤리적 요구 사항 등이 포함됩니다.

 

그림 4.4 MHC-PMS 비기능 요구사항의 예

 

그림 4.4는 사용자 요구 사항이 4.1.1절에서 소개된 MHC-PMS에서 가져온 제품, 조직, 외부 요구 사항의 예를 보여줍니다.

 

제품 요구 사항은 시스템의 가용성을 정의하며, 시스템이 가용해야 하는 시간과 허용되는 일일 다운타임을 명시합니다. 이는 MHC-PMS의 기능에 대해 아무것도 말하지 않으며, 시스템 설계자가 고려해야 할 제약 조건임을 분명히 나타냅니다.

조직 요구 사항은 사용자가 시스템에 인증하는 방법을 명시합니다. 시스템을 운영하는 보건 당국은 모든 소프트웨어에 대해 표준 인증 절차로 전환하고 있으며, 사용자 이름 대신 사용자가 신분증을 리더기에 스와이프하여 자신을 식별하도록 하고 있습니다.

외부 요구 사항은 시스템이 개인정보 보호 법률을 준수해야 할 필요성에서 도출되었습니다. 개인정보 보호는 의료 시스템에서 매우 중요한 문제이며, 이 요구 사항은 시스템이 국가 개인정보 보호 표준에 따라 개발되어야 함을 명시하고 있습니다.

 

비기능적 요구 사항과 관련된 일반적인 문제는 사용자나 고객이 이러한 요구 사항을 일반적인 목표로 제시하는 경우가 많다는 점입니다. 예를 들어, 사용의 용이성, 시스템의 고장 복구 능력, 빠른 사용자 응답과 같은 목표가 그렇습니다. 목표는 좋은 의도를 나타내지만, 시스템이 제공된 후 해석과 후속 분쟁의 여지를 남기기 때문에 시스템 개발자에게 문제를 일으킬 수 있습니다. 예를 들어, 다음 시스템 목표는 관리자가 사용성을 요구하는 전형적인 방법을 보여줍니다:

 

시스템은 의료 직원이 사용하기에 쉬워야 하며, 사용자 오류가 최소화되도록 구성되어야 한다.

 

이 목표가 ‘테스트 가능한’ 비기능적 요구 사항으로 표현될 수 있는 방법을 다시 작성해 보았습니다. 시스템 목표를 객관적으로 검증하는 것은 불가능하지만, 아래 설명에서는 시스템을 테스트할 때 사용자가 실수한 횟수를 계산하기 위해 소프트웨어 계측을 포함할 수 있습니다:

 

의료 직원은 4시간의 교육 후 시스템의 모든 기능을 사용할 수 있어야 한다. 이 교육 후, 숙련된 사용자가 시스템을 사용할 때 발생하는 평균 오류 횟수는 시간당 2회를 초과하지 않아야 한다.

 

그림 4.5 비기능 요구사항 명세를 위한 척도(측정지표)

 

가능한 경우, 비기능 요구 사항을 정량적으로 작성하여 객관적으로 테스트할 수 있도록 해야 합니다. 그림 4.5는 비기능 시스템 속성을 지정하기 위해 사용할 수 있는 측정 지표를 보여줍니다. 시스템을 테스트할 때 이러한 특성을 측정하여 시스템이 비기능 요구 사항을 충족하는지 확인할 수 있습니다.

 

실제로 고객은 자신의 목표를 측정 가능한 요구 사항으로 변환하는 데 어려움을 겪는 경우가 많습니다. 유지보수성 같은 일부 목표에는 사용할 수 있는 측정 지표가 없으며, 정량적 명세가 가능하더라도 고객은 자신의 필요를 이러한 명세와 연관시키지 못할 수 있습니다. 그들은 요구되는 신뢰성을 정의하는 숫자가 컴퓨터 시스템에 대한 일상적인 경험에서 무엇을 의미하는지 이해하지 못할 수 있습니다. 또한, 측정 가능한 비기능 요구 사항을 객관적으로 검증하는 비용이 매우 높을 수 있으며, 시스템 비용을 지불하는 고객이 이러한 비용이 정당하다고 생각하지 않을 수 있습니다.

 

비기능 요구 사항은 종종 다른 기능 또는 비기능 요구 사항과 충돌하기도 하고, 서로 상호 작용 하기도 합니다. 예를 들어, 그림 4.4의 인증 요구 사항은 시스템에 연결된 각 컴퓨터에 카드 리더기를 설치해야 함을 명확히 요구합니다. 그러나 의사나 간호사의 노트북에서 시스템에 대한 모바일 접근을 요청하는 다른 요구 사항이 있을 수 있습니다. 이러한 경우에는 카드 리더기가 장착되어 있지 않은 경우가 많으므로, 이러한 상황에서는 대체 인증 방법이 허용되어야 할 수 있습니다.

 

실제로 요구 사항 문서에서 기능 요구 사항과 비기능 요구 사항을 분리하는 것은 어렵습니다. 비기능 요구 사항이 기능 요구 사항과 별도로 명시된 경우, 그들 간의 관계를 이해하기 어려울 수 있습니다. 그러나 성능이나 신뢰성과 같은 발생 시스템 속성과 명확히 관련된 요구 사항은 명확히 강조해야 합니다. 이를 위해 요구 사항 문서의 별도 섹션에 포함시키거나, 다른 시스템 요구 사항과 구별하여 명시할 수 있습니다.

 

그 밖에 신뢰성, 안전성 및 기밀성 요구 사항과 같은 비기능 요구 사항은 중요한 시스템에 특히 중요합니다.