소프트웨어 공학: 요구사항 문서와 명세 - "효과적인 소프트웨어 요구사항 문서화와 명확하고 일관된 시스템 명세를 위한 가이드"

 

이번 포스팅에서는 요구사항 문서화에 대해 알아 보려고 합니다.

요구사항 문서화는 자연어, 다이어그램, 그리고 수학식과 같은 다양한 방법이 사용됩니다.

결과적으로 문서화 역시 쉽지 않은 분야이며, 많은 노력이 요구되는 분야입니다.

자세한 내용을 살펴 보도록 하겠습니다.

 

 

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

 

소프트웨어 요구사항 문서 (Software Requirements Document)

소프트웨어 요구 사항 문서(종종 소프트웨어 요구 사항 명세서 또는 SRS(Software Requirements Specification)라고 불림)는 시스템 개발자가 구현해야 할 내용을 공식적으로 명시하는 문서입니다. 이 문서에는 시스템에 대한 사용자 요구 사항과 시스템 요구 사항의 상세한 명세가 모두 포함되어야 합니다. 경우에 따라 사용자 요구 사항과 시스템 요구 사항이 하나의 설명으로 통합될 수 있으며, 다른 경우에는 사용자 요구 사항이 시스템 요구 사항 명세서의 서론에 정의될 수 있습니다.

요구 사항이 많을 경우, 상세한 시스템 요구 사항이 별도의 문서로 제시될 수 있습니다.

 

요구 사항 문서는 외부 계약자가 소프트웨어 시스템을 개발할 때 필수적입니다. 그러나 애자일 개발 방법론에서는 요구 사항이 너무 빠르게 변하기 때문에 요구 사항 문서가 작성되자마자 시대에 뒤떨어지며, 이로 인해 문서 작성에 대한 노력이 대부분 낭비된다고 주장합니다.

 

공식 문서 대신 익스트림 프로그래밍(Extreme Programming, Beck, 1999)과 같은 접근 방식에서는 사용자 요구 사항을 점진적으로 수집하여 사용자 스토리로 카드에 작성합니다. 그런 다음 사용자가 시스템의 다음 단계에서 구현할 요구 사항의 우선순위를 정하게 됩니다.

요구 사항이 불안정한 비즈니스 시스템의 경우, 이러한 접근 방식이 효과적이라고 생각합니다. 그러나 시스템에 적용되는 비즈니스 요구 사항과 신뢰성 요구 사항을 정의하는 짧은 지원 문서를 작성하는 것이 여전히 유용하다고 생각합니다. 이는 다음 시스템 릴리스의 기능적 요구 사항에 집중할 때 시스템 전체에 적용되는 요구 사항을 잊어버리기 쉽기 때문입니다.

 

요구 사항 문서는 시스템 비용을 지불하는 조직의 고위 관리층부터 소프트웨어를 개발하는 엔지니어들까지 다양한 사용자 집단을 대상으로 합니다. 그림 4.6은 요구 사항 문서의 잠재적 사용자를 나타내며, 그들이 문서를 어떻게 사용하는지 보여줍니다.

그림 4.6 요구사항 문서를 이용하는 사용자

 

다양한 사용자가 있기 때문에, 요구 사항 문서는 고객에게 요구 사항을 전달하고, 개발자와 테스터에게 요구 사항을 정확하게 정의하며, 시스템의 진화 가능성에 대한 정보를 포함하는 타협이 필요합니다. 예상되는 변경 사항에 대한 정보는 시스템 설계자가 제한적인 설계 결정을 피하고, 시스템 유지보수 엔지니어가 새로운 요구 사항에 시스템을 적응시키는 데 도움이 될 수 있습니다.

 

요구 사항 문서에 포함해야 할 세부 사항의 수준은 개발되는 시스템의 유형과 사용된 개발 프로세스에 따라 다릅니다.

안전성과 보안을 상세히 분석해야 하는 중요한 시스템은 상세한 요구 사항이 필요합니다.

시스템이 외부 회사(예: 아웃소싱을 통해)에서 개발될 경우, 시스템 명세는 상세하고 정밀해야 합니다.

내부적으로 반복적인 개발 프로세스가 사용되는 경우, 요구 사항 문서는 덜 상세할 수 있으며, 시스템 개발 중에 모호함이 해결될 수 있습니다.

그림 4.7 요구사항 문서 구조

 

그림 4.7은 요구 사항 문서를 구성하는 한 가지 방법론을 보여줍니다. 이는 요구 사항 문서에 대한 IEEE 표준(IEEE, 1998)을 기반으로 한 것으로 특정 용도에 맞게 조정될 수 있는 일반적인 표준입니다. 이 경우, 시스템 진화에 대한 정보를 포함하도록 표준을 확장했습니다. 이 정보는 시스템 유지보수자들에게 도움이 되며, 설계자가 향후 시스템 기능을 지원하기 위한 기능을 포함할 수 있게 합니다.

 

물론, 요구 사항 문서에 포함되는 정보는 개발되는 소프트웨어의 유형과 사용된 개발 접근 방식에 따라 달라져야 합니다.

소프트웨어 제품에 대해 진화적 접근 방식을 채택할 경우, 요구 사항 문서는 위에서 제안된 많은 세부 장을 생략할 것입니다. 이 경우, 사용자 요구 사항과 고수준의 비기능 시스템 요구 사항 정의에 중점을 둡니다. 설계자와 프로그래머는 시스템의 개략적인 사용자 요구 사항을 충족시키기 위한 방법을 판단해야 합니다.

그러나 소프트웨어가 상호작용하는 하드웨어 및 소프트웨어 시스템을 포함하는 대규모 시스템 프로젝트의 일부일 경우, 요구 사항을 상세하게 정의하는 것이 필수적입니다. 이 경우 요구 사항 문서는 매우 길어질 가능성이 있으며, 그림 4.7에 표시된 대부분의 장을 포함해야 합니다. 긴 문서의 경우, 독자가 필요한 정보를 찾을 수 있도록 종합적인 목차와 색인을 포함하는 것이 특히 중요합니다.

 

요구사항 명세 (Requirements Specification)

요구 사항 명세는 사용자와 시스템 요구 사항을 요구 사항 문서에 기록하는 과정입니다. 이상적으로, 사용자와 시스템 요구 사항은 명확하고, 모호하지 않으며, 이해하기 쉽고, 완전하고 일관성이 있어야 합니다. 그러나 실제로는 이해관계자들이 요구 사항을 서로 다르게 해석하는 경우가 많고, 요구 사항에는 본질적으로 갈등과 모순이 있을 수 있어 이를 달성하기 어렵습니다.

 

사용자 요구 사항은 시스템 사용자가 기술 지식이 부족하더라도 이해할 수 있도록 기능적 및 비기능적 요구 사항을 설명해야 합니다. 이상적으로는 시스템의 외부 동작만을 명시해야 하며, 시스템의 아키텍처나 설계에 대한 세부 사항은 포함하지 않아야 합니다. 따라서 사용자 요구 사항을 작성할 때는 소프트웨어 용어, 구조화된 표기법, 또는 공식적인 표기법을 사용하지 않고, 자연어와 간단한 표, 양식, 직관적인 다이어그램을 사용하여 작성해야 합니다.

 

시스템 요구 사항은 시스템 설계의 시작점으로 사용되며, 사용자 요구 사항의 확장된 버전입니다. 시스템 요구 사항은 더 많은 세부 사항을 추가하고, 사용자 요구 사항이 시스템에 의해 어떻게 제공되어야 하는지를 설명합니다. 이 요구 사항은 시스템 구현 과정의 일부로 사용될 수 있으며, 따라서 전체 시스템에 대한 완전하고 상세한 명세여야 합니다.

 

이상적으로는 시스템 요구 사항도 시스템의 외부 동작과 운영 제약만을 설명해야 하며, 시스템이 어떻게 설계되거나 구현되어야 하는지에 대한 내용은 포함하지 않아야 합니다. 그러나 복잡한 소프트웨어 시스템을 완전히 명세하는 데 필요한 세부 수준에서는 모든 설계 정보를 배제하는 것이 사실상 불가능합니다. 그 이유는 다음과 같습니다:

 

1. 요구 사항 명세의 구조를 잡기 위해 시스템의 초기 아키텍처를 설계해야 할 수 있습니다. 시스템 요구 사항은 시스템을 구성하는 다양한 하위 시스템에 따라 구성됩니다.

2. 대부분의 경우, 시스템은 기존 시스템과 상호 운용해야 하며, 이는 새로운 시스템의 설계를 제약하고 요구 사항을 부과합니다.

3. 비기능 요구 사항을 충족시키기 위해 특정 아키텍처를 사용하는 것이 필요할 수 있습니다. 예를 들어, 신뢰성을 달성하기 위해 N-version 프로그래밍을 사용하는 것처럼 말입니다.

그림 4.8 시스템 요구사항 명세 작성 방법

 

사용자 요구 사항은 거의 항상 자연어로 작성되며, 요구 사항 문서에 적절한 다이어그램과 표가 첨부됩니다. 시스템 요구 사항도 자연어로 작성될 수 있지만, 양식 기반, 그래픽 시스템 모델, 또는 수학적 시스템 모델과 같은 다른 표기법도 사용할 수 있습니다.

그림 4.8은 시스템 요구 사항을 작성할 때 사용할 수 있는 가능한 표기법을 요약한 것입니다.

 

그래픽 모델은 상태 변화나 행동의 순서를 설명할 때 특히 유용합니다. UML 순서도와 상태도는 특정 메시지나 이벤트에 대한 반응으로 발생하는 행동의 순서를 보여줍니다. 안전 또는 보안이 중요한 시스템의 경우, 요구 사항을 설명하기 위해 때때로 수학적 명세가 사용되지만, 다른 상황에서는 거의 사용되지 않습니다.

 

1. 자연어 명세

자연어는 소프트웨어 공학이 시작된 이래로 소프트웨어 요구 사항을 작성하는 데 사용되어 왔습니다. 자연어는 표현력이 뛰어나고, 직관적이며, 보편적입니다. 그러나 자연어는 잠재적으로 모호하고, 독자의 배경에 따라 의미가 달라질 수 있습니다. 그 결과, 요구 사항을 작성하는 대안적인 방법에 대한 많은 제안이 있었지만, 이러한 방법들이 널리 채택된 경우는 드물며, 자연어는 여전히 시스템 및 소프트웨어 요구 사항을 명시하는 데 가장 널리 사용되는 방법입니다.

 

자연어 요구 사항을 작성할 때 오해를 최소화하기 위해 몇 가지 간단한 지침을 따를 것을 권장합니다:

1. 표준 형식을 만들어 모든 요구 사항 정의가 그 형식을 따르도록 합니다.
   형식을 표준화하면 누락 가능성이 줄어들고 요구 사항을 더 쉽게 확인할 수 있습니다. 제가 사용하는 형식은 요구 사항을 단일 문장으로 표현하며, 각 사용자 요구 사항에 대해 그 요구 사항이 제안된 이유를 설명하는 진술을 연결합니다. 이 합리적 근거는 요구 사항을 변경해야 할 경우 변경이 바람직하지 않은 이유를 결정하는 데도 도움이 될 수 있습니다.
2. 필수 요구 사항과 바람직한 요구 사항을 구분하기 위해 일관된 언어를 사용합니다.
   필수 요구 사항은 시스템이 반드시 지원해야 하는 요구 사항이며, 일반적으로 ’해야 한다(shall)’라는 표현을 사용하여 작성됩니다. 바람직한 요구 사항은 필수적이지 않으며, ’해야 한다(should)’라는 표현을 사용하여 작성됩니다.
3. 요구 사항의 핵심 부분을 강조하기 위해 텍스트 강조(굵게, 기울임, 색상)를 사용합니다.
4. 독자가 기술적인 소프트웨어 공학 용어를 이해한다고 가정하지 마십시오.
   ‘아키텍처’나 ‘모듈’과 같은 단어는 오해될 수 있으므로, 전문 용어, 약어, 두문자어의 사용을 피해야 합니다.
5. 가능한 경우, 각 사용자 요구 사항에 대해 합리적 근거를 추가하는 것이 좋습니다.
   합리적 근거는 해당 요구 사항이 포함된 이유를 설명해야 합니다.

그림 4.9 인슐린 펌프 소프트웨어 시스템의 요구사항 예

 

그림 4.9는 이러한 지침이 어떻게 사용될 수 있는지 보여줍니다. 여기에는 자동 인슐린 펌프의 임베디드 소프트웨어에 대한 두 가지 요구 사항이 포함되어 있습니다.

 

2. 구조화된 명세

구조화된 자연어는 시스템 요구 사항을 작성할 때 요구 사항 작성자의 자유를 제한하고 모든 요구 사항이 표준 방식으로 작성되도록 하는 방법입니다. 이 접근 방식은 자연어의 표현력과 이해 가능성을 대부분 유지하면서도 명세서에 일정한 일관성을 부여합니다. 구조화된 언어 표기법은 시스템 요구 사항을 명시하기 위해 템플릿을 사용합니다. 명세서에는 프로그래밍 언어 구문을 사용하여 대안과 반복을 표시할 수 있으며, 키 요소를 강조하기 위해 음영이나 다른 글꼴을 사용할 수 있습니다.

 

Robertson과 Robertson(1999)은 그들의 책에서 사용자의 요구 사항을 처음에는 각 요구 사항을 카드에 작성할 것을 권장합니다. 각 카드에는 요구 사항의 합리적 근거, 다른 요구 사항과의 종속성, 요구 사항의 출처, 지원 자료 등이 포함됩니다. 이는 그림 4.10에 표시된 구조화된 명세의 예시와 유사합니다.

그림 4.10 인슐린 펌프에 대한 요구사항의 구조화된 명세

 

구조화된 접근 방식을 사용하여 시스템 요구 사항을 명세하려면, 요구 사항에 대한 하나 이상의 표준 템플릿을 정의하고 이러한 템플릿을 구조화된 양식으로 표현해야 합니다. 명세서는 시스템이 조작하는 객체, 시스템이 수행하는 기능 또는 시스템이 처리하는 이벤트를 중심으로 구조화될 수 있습니다.

예를 들어, 그림 4.10은 혈당이 안전한 범위 내에 있을 때 전달할 인슐린 양을 계산하는 방법을 정의하는 양식 기반 명세의 예시를 보여줍니다.

 

기능적 요구 사항을 명세할 때 표준 양식을 사용하는 경우, 다음 정보를 포함해야 합니다:

 

1. 명세되는 기능 또는 엔티티에 대한 설명.

2. 입력에 대한 설명과 입력의 출처.

3. 출력에 대한 설명과 출력의 목적지.

4. 계산에 필요한 정보 또는 사용되는 시스템 내의 다른 엔티티에 대한 정보(‘필요한 부분’).

5. 수행할 작업에 대한 설명.

6. 기능적 접근 방식을 사용하는 경우, 기능 호출 전의 사전 조건과 기능 호출 후의 사후 조건 명시.

7. 작업의 부작용(있을 경우)에 대한 설명.

 

구조화된 명세서를 사용하면 자연어 명세서의 일부 문제를 해결할 수 있습니다. 명세서의 가변성이 줄어들고 요구 사항이 보다 효과적으로 정리됩니다. 그러나 여전히 명확하고 모호하지 않은 방식으로 요구 사항을 작성하는 것이 어려울 수 있으며, 특히 인슐린 용량 계산과 같은 복잡한 계산을 명세할 때 그렇습니다.

 

이 문제를 해결하기 위해 자연어 요구 사항에 추가 정보를 더할 수 있으며, 예를 들어 표나 시스템의 그래픽 모델을 사용하는 방법이 있습니다. 이를 통해 계산이 어떻게 진행되는지, 시스템 상태가 어떻게 변하는지, 사용자가 시스템과 어떻게 상호작용하는지, 그리고 작업의 순서가 어떻게 수행되는지를 시각적으로 나타낼 수 있습니다.

그림 11. 인슐린 펌프 계산에 대한 테이블 형식의 명세

 

표는 다양한 상황이 있고, 각 상황에 대해 수행할 작업을 설명해야 할 때 특히 유용합니다. 인슐린 펌프는 혈당 수치 변화율에 따라 인슐린 필요량을 계산합니다. 변화율은 현재 및 이전의 측정을 사용하여 계산됩니다. 그림 4.11은 혈당 변화율을 사용하여 전달할 인슐린 양을 계산하는 방법을 설명하는 표입니다.