IEEE 830-1998 Recommended Practice for Software Requirement Specification

1 작성자의 동의 없이 본 자료의 일부 또는 전부를 무단 전재, 복제 및 배포를 금합니다.
IEEE 830-1998 Recommended Practice for
Software Requirement Specification
Korea Testing Laboratory
이홍석

1. Definition, abbreviation
Baseline:
A specification or system that has been formally reviewed
and agreed upon, that thereafter serves as the basis for
further development and can be changed only through
formal change control procedures.
(IEEE Std 610.12-1990)
System Requirements Specification (SyRS):
A structured collection of information that embodies the
requirements of the system.

Testability:
The degree to which a requirement is stated in terms that
permit establishment of test criteria and performance of
tests to determine whether those criteria have been met.
(IEEE Std 610.12-1990)
Traceability:
The degree to which a relationship can be established
between two or more products of the development process,
especially products having a predecessor-successor or
master-subordinate relationship to one another; e.g., the
degree to which the requirements and design of a given
system element match.
(IEEE Std 610.12-1990)

Validation:
The process of evaluating a system or component during or
at the end of the development process to determine
whether a system or component satisfies specified
requirements. (IEEE Std 610.12-1990)
Verification:
The process of evaluating a system or component to
determine whether the system of a given development
phase satisfies the conditions imposed at the start of that
phase. (IEEE Std 610.12-1990)

2. 목표
본 강의를 통해 아래와 같은 것들을 도움을 받을 수 있다.
a) 소프트웨어 고객들이 얻고자 하는 것을 정확하게 기술하게
된다.
b) 소프트웨어 제공자가 고객이 원하는 것이 무엇인지를 정확
하게 이해한다.
c) 소프트웨어 개발사는 다음의 목표를 달성할 수 있다.
• SRS표준의 outline을 조직에 맞게 개발할 수 있다.
• SRS의 format과 contents를 정의할 수 있다.
• SRS의 품질 checklist나 SRS 작성자의 handbook과 같
은 부가적인 사내 지원 아이템을 개발할 수 있다.
참고문헌: IEEE Std 830-1998, IEEE Recommended Practice
for Software Requirements Specifications

3. 좋은 SRS의 장점
1. 고객과 공급자간에 소프트웨어의 기능에 대한 기본적인 합
의를 이끌어낼 수 있다. (Customer, Supplier)
2. 개발에 들어가는 노력을 줄일 수 있다. (Developer)
3. 비용과 스케줄을 예측하기 위한 기초를 제공한다. (PM)
4. 확인(Validation)및 검증(Verification)에 대한 베이스라인을
제공한다. (QA Engineer)
5. 제품 향상을 위한 기반을 제공한다.

1. 고객과 공급자간에 소프트웨어의 기능에 대한 기본적인 합
의를 이끌어낼 수 있다.
• SRS에서 소프트웨어가 수행할 기능에 대해서 완벽하게 기술되어있다면
SRS문서는 잠재적 고객이 그 소프트웨어가 그들의 요구를 만족할 것인지
혹은 그들의 요구를 만족시키기 위해서 어떻게 수정이 되어야 하는지를 도
울 수 있다.
2. 개발에 들어가는 노력을 줄일 수 있다.
• 주의 깊게 SRS를 검토함으로써 개발 사이클의 앞 부분에서 누락, 잘못된
이해, 불일치 등과 같은 것들을 발견하게 된다.
• 개발 사이클의 앞부분에서는 문제점을 고치기 용이하며 수정에 들어가는
비용이 상대적으로 적다.
3. 비용과 스케줄을 예측하기 위한 기초 정보를 제공한다.
• SRS에서 개발되어야 할 제품을 명시한다면 프로젝트 비용을 예측하고 입
찰 혹은 가격 예측에 대한 승인을 얻어내는데 사용될 수 있다.

4. 확인(Validation)및 검증(Verification)에 대한 베이스라인을
제공한다.
• 조직은 V&V계획을 좋은 SRS로부터 더 생산적으로 개발할 수 있다.
• 개발 계약의 일부로서 SRS는 어떤 부분에서 평가가 되어야 하는지에 대한
베이스라인을 제공한다.
5. 제품 향상을 위한 기반을 제공한다.
• SRS는 제품을 개발하는 프로젝트에 대해서 논의하는 것이 아니라 제품에
대해서 논의하는 것이기 때문에 SRS는 개발이 완료된 제품에 대한 향후 개
선의 기초를 제공해 줄 수 있다.
• SRS가 변경될 필요가 있을 수는 있지만 근본적인 제품 평가에 대한 정보는
여전히 활용될 수 있다.

4. 좋은 SRS를 만들기 위한 고려사항 8가지
1. Nature of the SRS
2. Environment of the SRS
3. Characteristics of a good SRS
4. Joint preparation of the SRS
5. SRS evolution
6. Prototyping
7. Embedding design in the SRS
8. Embedding project requirement in the SRS

4.1 Nature of the SRS
SRS는 특정 환경에서 어떤 기능을 수행하는 소프트웨어 제품,
프로그램, 또는 프로그램들의 집합을 기술한 것이다.
SRS의 작성 주체는 누구인가?
• 제품 제공자 측에 속해 있는 사람들
• 제품 구매자 측에 속해 있는 사람들
• 제품 제공자와 구매자 측에 속한 사람들
Customer가 요구사항을 informal하게 작성해서
supplier에게 보내면
Supplier가 그 내용을 정리해서 Customer와 합의
하여 Requirement를 완성한다.

4.1 Nature of the SRS
SRS 작성자는 다음의 기본적인 사항들을 SRS에서 다루어야
한다.
a. Functionality
• 소프트웨어는 어떤 일을 수행해야 하는가?
b. External interface
• 소프트웨어는 사람, 시스템의 하드웨어, 다른 하드웨어, 혹은 다른 소프트
웨어와 어떻게 상호작용을 할 것인가?
c. Performance
• 속도, 가용성, 반응 시간, 다양한 소프트웨어 기능의 복구시간 등
d. Attribute
• 이식성, 정확성, 유지보수성, 보안성 및 그 외 고려사항
e. Design constraints imposed on an implementation
• 구현해야 하는 언어, 데이터베이스 무결성을 위한 정책, 리소스 제약사항,
운영체제 등등
SRS를 작성할 때에는 Design이나 Project요구사항을 명시하지 않도록 한다.

4.2 Environment of the SRS
• SRS의 일부가 전체 project plan에서 중요한 역할을 한다
• 소프트웨어는 (1) 프로젝트 내의 모든 기능들을 포함하거나
아니면 (2) 다른 더 큰 시스템의 일부가 될 수 있다.
• 만약 Software가 다른 더 큰 시스템의 일부인 경우……
 SRS는 시스템과 소프트웨어 부분과의 인터페이스를 명시해야 한다.
 소프트웨어 부분에 대한 성능과 기능적 요구사항에 대해서 기술해
야 한다.
SRS가 소프트웨어 개발 프로세스에서 중요한 역할을 담당하
기 때문에 SRS작성자는 주어진 임무의 범위를 벗어나서는 안
된다.

4.2 Environment of the SRS
SRS는 다음의 조건을 만족해야 한다.
1. 모든 소프트웨어 요구사항을 정확하게 정의해야 한다. 소
프트웨어 요구사항은 해결되어야 하는 작업의 특성으로 인
해 생겨날 수 있거나 프로젝트의 특수한 특성으로 인해 생
겨날 수 있다.
2. 디자인 혹은 구현에 대한 상세한 내용을 기술해서는 안 된
다. 이와 같은 내용은 디자인 단계에서 기술되어야 한다.
3. 소프트웨어에 대한 추가적인 제약사항을 부과해서는 안 된
다. 이런 속성은 소프트웨어 품질보증 계획(SQAP)과 같은
문서에서 명세 되어야 한다.
SRS에서 다루어야 하는 영역을 명확히 규정하여
다른 문서와 내용이 겹치지 않도록 한다!!!

4.3 Characteristics of a good SRS
SRS는 다음의 속성을 가져야 한다.
1. Correct
2. Unambiguous
3. Complete
4. Consistent
5. Ranked for importance and/or stability
6. Verifiable
7. Modifiable
8. Traceable

SRS가 가져야 하는 속성 - 4.3.1 Correct
SRS에 명시된 모든 요구사항들이 소프트웨어가 만족시켜야
하는 것이면 SRS는 correct하다.
정확성을 보증하는 도구나 절차는 존재하지 않는다. SRS는 다
른 적용 가능한 상위 사양서(SyRS와 같은)와 비교하거나 다른
project documentation 혹은 다른 적용 가능한 표준과 비교하
여 그것이 정확하다는 것을 보여야 한다.
차선책으로 고객이나 사용자가 SRS가 실제 needs를 반영했는
지를 판단할 수도 있다. 추적성은 이런 절차를 더 쉽고 오류가
덜 발생시키도록 한다.

SRS가 가져야 하는 속성 - 4.3.2 Unambiguous
SRS에 명시된 모든 요구사항들이 오직 한가지 방식으로 해석
이 된다면 SRS는 unambiguous하다
최소한 최종 제품의 각각의 특성이 한가지의 의미를 갖는 용
어로 기술되어야 함을 의미한다.
만약 특별한 의미로 사용되는 용어가 다양한 의미를 가질 수
있다면, 그 용어는 glossary에 포함되어 의미를 더 상세히 만
들어야 한다.
SRS는 software life cycle의 요구사항 프로세스에서 중요한 부
분을 담당하고 있으며 디자인, 구현, 프로젝트 모니터링, V&V,
및 교육에서 사용된다.

SRS는 그것을 작성하는 사람과 사용하는 사람을 위해서 모호
하지 않아야 한다. 하지만 …..
• 고객들은 같은 배경지식을 갖고 있지 않아서 소프트웨어 요구사항을 같
은 방식으로 기술하기 쉽지 않다.
• 개발자를 위한 요구사항 작성을 개선시키려는 표현방법은 비생산적일
수 있는데, 이는 그런 방식이 고객이 이해하지 못하게 하기 때문이며 그
반대도 그렇다.
모호함을 회피하도록 하기 위한 방법
1. 자연 언어의 위험을 인지하고 회피하기
2. 요구사항 명세 언어
3. 표현 도구

• 요구사항은 종종 자연어로 표현된다.
• 자연어는 선천적으로 모호하다.
• 자연어 SRS는 독립적인 부서에서 모호한 언어 사용이 있는지 검토
되어야 하며 그런 사항들은 수정되어야 한다.
3. 표현 도구

3. 표현 도구
자연어의 선천적인 모호함을 회피하는 한가지 방법은 SRS를
특정 요구사항 명세 언어로 표현하는 것이다.
명세 언어의 사용의 단점
1) 그것을 배우는데 소요되는 시간
2) 비 기술적 사용자들은 그런 언어를 이해하지 못함
명세 언어의 장점
1) 특정 타입의 요구사항을 표현하고 특정 타입의 시스템의
요구상을 표현하는데 더 좋을 수 있음
2) 자동으로 구문적, 문법적, 의미적 오류를 탐지

3. 표현 도구
모호함을 회피하도록 하기 위해 표현 도구를 사용할 수 있는
데 일반적으로, 요구사항을 기술하는 방법은 세 종류(Object,
process, behavioral)의 일반적인 카테고리로 나눌 수 있다.
1. Object oriented 접근법 – 요구사항을 현실세계의 object,
attribute, object에 의해 수행되는 service등으로 구성함
2. Process based 접근법 – 요구사항을 data flow를 통해 통
신하는 함수들의 계층으로 구성함
3. Behavioral approach접근법 – 시스템의 external behavior
를 약간의 추상화된 형태로 표현하는 방법(predicate
calculus, mathematical functions, 또는 state machines)

SRS가 가져야 하는 속성 - 4.3.3 Complete
SRS가 다음의 항목을 다루고 있다면, SRS는 complete하다.
a. 기능, 성능, 디자인 제약사항, 속성, 외부 인터페이스와 관
련된 모든 중요한 요구사항들. 특별히 시스템 명세서에 의
해 부과된 외적 요구사항 역시 요구사항으로 인정되고 고
려되어야 한다.
b. 소프트웨어의 모든 입력 및 환경 상황들에 대한 반응이 정
의되어야 한다. (모든 현실적인 상황을 구분화하여 입력 데
이터의 모든 현실적인 등급에 대한 소프트웨어의 반응이
정의되어야 한다.)
c. SRS에 있는 모든 수치, 표, 그림에 대한 식별 및 참고 문헌
과 측정할 수 있는 모든 용어 및 단위에 대한 정의

4.3.3.1 Use of TBD
TBD(to be determined)를 사용하는 어떤 SRS도 완벽하다고
할 수 없다. 하지만 TBD는 때때로 필요하며 다음을 수반해야
한다.
a. TBD를 사용하게 된 이유에 대한 설명(왜 명세할 수 없는가)
을 하여 추후 그 문제가 해결될 수 있도록 한다.
b. TBD를 제거하기 위해 어떤 것들이 수행되어야 하는지를
설명하고, TBD가 언제 제거되어야 하는지를 설명

SRS가 가져야 하는 속성 - 4.3.4 Consistent
Consistency는 내부적 일치성에 대한 것이다. 만약 SRS가 몇
몇의 system 요구사항과 같은 상위 수준의 문서와 부합하지
않는다면 그 SRS는 잘못된 것이다.
만약 SRS 내에 기술된 개개의 요구사항의 어떤 부분집합도 충
돌하지 않는다면 SRS는 내부적으로 consistent하다

SRS가 가져야 하는 속성 - 4.3.4 Consistent
SRS에서 충돌이 발생하는 3가지 타입은 다음과 같다.
a. 현실 세계의 object에 명세한 특성의 충돌이 일어날 수 있음.
1. 출력 보고서의 포맷에 대해 한 요구사항에서는 테이블 포맷으로 표현
하라고 하였는데, 다른 요구사항에서는 텍스트로 표현하라고 함
2. 하나의 요구사항에서는 모든 불빛의 상태가 초록이 되어야 한다고 표
현했는데, 다른 요구사항에서는 모든 불빛의 상태가 파란색이 되어야
한다고 표현한 경우
b. 두 개의 기술된 행동 사이에 논리적 혹은 시간적 충돌이 일어
날 수 있음
1. 하나의 요구사항은 프로그램이 두 개의 입력을 더하라고 하였으나 다
른 요구사항에서는 프로그램이 두 개의 입력을 곱하라고 한 경우
2. 하나의 요구사항이 “A”는 “B”를 항상 뒤따라야 한다고 하였으나 다른
요구사항에서는 “A”와 “B”는 동시에 발생되어야 한다고 한 경우
c. 두 개 혹은 그 이상의 요구사항은 같은 실 세계의 object를 기
술할 수 있지만 다른 용어로 표현할 수 있음.
1. user input에 대한 program의 request를 한 요구사항에서는 “prompt”
로 표현, 다른 요구사항에서는 이를 “cue”라고 표현

SRS가 가져야 하는 속성 - 4.3.5 Ranked for importance
and/or stability
SRS는 중요도나 안정성에 따라 등급이 매겨질 수 있다. 일반적으
로 모든 요구사항이 중요한 것은 아니다. 어떤 요구사항은 매우
중요할 수 있고, 어떤 요구사항은 부차적인 것일 수도 있다.
SRS의 각각의 요구사항은 이런 것들의 차이를 명확하고 명시적
으로 구분되어야 한다. 요구사항의 등급 식별은 다음의 방식에서
도움이 된다.
a. 고객에게 각각의 요구사항에 대해 좀 더 주의 깊도록 함으로
써 그들이 가지고 있을 수 있는 숨겨진 가정을 명확하게 할 수
있다.
b. 개발자가 정확한 디자인 결정을 하도록 하고 소프트웨어 제품
의 다른 부분들에 대한 적절한 수준의 노력을 할 수 있도록 한
다.

4.3.5.1 안정성의 정도
요구사항을 인식하는 한가지 방법은 안정성 수준을 이용하는 것
이다.
안정성은 소프트웨어 시스템에 의해 지원되는 구성, 기능 및 사
람에게 영향을 미치는 곧 있을 사건의 경험 및 지식을 기반으로
하는 어떤 요구사항에 대한 기대되는 변화의 개수의 관점에서 표
현될 수 있다.

4.3.5.2 필요성의 정도
요구사항의 등급을 매기는 또 다른 방법은 필수적인(essential),
조건적으로 필요한(conditional), 선택적인(optional)으로 나누는
것이다.
a. Essential – 이 요구사항이 합의된 방식으로 제공되지 않는다
면 소프트웨어를 받아들일 수 없음
b. Conditional – 이 요구사항은 소프트웨어 제품을 개선시킬 것
이지만, 그것이 없다고 해서 소프트웨어를 받아들이지 않겠다
는 것은 아님
c. optional – 이 요구사항은 유용하거나 혹은 유용하지 않을 수
도 있다. 이 요구사항은 supplier가 SRS에서 요구하지 않은 무
엇인가를 추가적으로 제공해주는 것을 의미한다.

4.3.5.2 필요성의 정도
Degree of
requirement
고객의
요구사항
Supplier의
제공사항
요구사항이 불만족할 경우 고객이 제품
을 acceptable하는지의 여부
Essential O X X
Conditional O X O
Optional X O O

4.3.5.2 필요성의 정도 – 다른 표준의 예
MISRA C-2004의 경우 Required, Advisory등급의 두 단계로 나누어서 기
술함
NO
MISRA
RULE
Classification MISRA RULE Information
1 1.1 Required
All code shall conform to ISO 9899:1990 “Programming la
nguages – C”, amended and corrected by ISO/IEC 9899/C
OR1:1995, ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/C
OR2:1996
2 1.2 Required
No reliance shall be placed on undefined or unspecified
behavior.
3 1.3 Required
Multiple compilers and/or languages shall only be used if
there is a common defined interface standard for object
code to which the languages/compilers/assemblers
conform
4 1.4 Required
The compiler/linker shall be checked to ensure that 31
character significance and case sensitivity are supported f
or external identifiers
5 1.5 Advisory
Floating-point implementations should comply with
a defined floating-point standard

SRS가 가져야 하는 속성 - 4.3.6 Verifiable
SRS에 기술된 모든 요구사항에 대해 각각이 verifiable하면 SRS는
verifiable하다.
소프트웨어 제품이 요구사항을 만족시킬 수 있는 확인 방법이 사
람이나 도구에 의한 유한적으로 비용 효율이 높은 절차가 있다면
요구사항은 verifiable하다
일반적으로 ambiguous한 요구사항은 verifiable하지 않다.
verifiable하지 않은 요구사항의 문구의 예
1) “works well”
2) “good human interface”
3) “shall usually happen”
4) 그 외에 이론적으로 시험이 불가능한 방법
(예를 들면, 그 프로그램은 절대로 무한 루프에 진입하지 않아야 한다)

SRS가 가져야 하는 속성 - 4.3.7 Modifiable
SRS의 구조와 스타일이 요구사항의 구조와 스타일을 유지시키는
동안 쉽게 완벽하게, 일관성 있게 어떤 변경도 가능하다면 SRS는
modifiable하다.
Modifiability는 SRS가 다음의 속성을 만족해야만 한다.
a) 목차, index, 명시적 cross-referencing과 함께 구성이 사용하
기 쉽고 일관성이 있고 논리 정연해야 한다.
b) 중복적이지 않아야 한다.(같은 요구사항이 한 SRS내에서 하나
이상이 존재해서는 안 된다)
c) 요구사항들을 섞어서 표현하지 않고, 각각의 요구사항을 분리
하여 기술하여야 한다.

SRS가 가져야 하는 속성 - 4.3.7 Modifiable
Redundancy자체는 에러가 아니지만 에러를 유발할 수 있다. 중
복성은 때때로 SRS를 더 읽기 편하게 할 수는 있다.
하지만 문서가 업데이트가 될 때 문제가 발생할 수 있다.
예를 들어 요구사항의 내용이 한 부분에서만 변경될 수 있고 나
머지 부분은 변경되지 않을 수 있다. 그 때 SRS는 inconsistent하
게 된다.
중복성이 필요할 때마다 SRS는 명시적으로 cross-reference를 포
함하여 modifiable할 수 있도록 해야 한다.

3.8 Traceable
각각의 요구사항이 traceable하고 SRS가 향후 개발 혹은 문서의
개선에서의 각각의 요구사항의 참조를 가능하게 한다면, SRS는
traceable하다. 아래의 두 타입의 traceability를 권장한다.
a) backward traceability(즉 개발 이전 stage에서의). 이것은 각
각의 요구사항이 이전 문서에서의 source를 명시적으로
reference하는지에 따라 달려있다.
b) forward traceability(즉 SRS에 의해 야기된 모든 문서들). 이것
은 SRS의 각 요구사항이 unique한 이름을 갖거나 참조번호를
갖느냐에 따라 달려있다.
소프트웨어 제품이 생산 및 유지 단계에 진입해 있을 때, SRS의
forward traceability는 특별히 중요하다. code와 design문서가 변
경되면 그 변경에 의해 영향을 받는 모든 요구사항들을 알아낼
수 있는 것이 중요하다.

ISO26262-6에서의 Traceability
요구사항 작성 단계에서부터 소프트웨어 안전 요구사항 검증 단계까지,
모든 단계에 대해 추적이 가능해야 한다.

4.4 SRS의 joint preparation
소프트웨어 개발 프로세스는 공급자와 고객이 완성된 소프트웨
어가 무엇을 해야 하는지를 합의하는 것에서부터 시작해야 한다.
이것은 고객이나 공급자가 홀로 SRS를 쓰는 것은 좋은 SRS로 인
정받을 수 없기 때문에 중요하다.
a) 고객은 일반적으로 충분히 유용하게 사용할 수 있는 SRS를 쓰
는 것만큼 소프트웨어 디자인과 개발 프로세스를 이해하지 못
한다.
b) 공급자는 훌륭한 시스템을 위해 요구사항을 충분히 잘 명세한
것 만큼 고객의 문제와 전문분야를 잘 이해하지 못한다.
그렇기 때문에 잘 쓰여지고 완벽하게 이해될 수 있는 SRS를 쓰기
위해서는 공급자와 고객이 같이 작업해야 한다.

4.4 SRS의 joint preparation
소프트웨어와 시스템이 동시에 정의되어야 하는 특수한 상황이
있을 수 있다. 그렇다면 소프트웨어의 functionality, interface,
performance, other attribute, constraint가 사전에 정의되어있지
않기 때문에 공동으로 정의하기 보다는 협상하여 변경하기 쉽다.
Joint preparation은 SRS작성을 어렵게 할 수 있지만, 좋은 SRS의
특성을 만족시키는 것(4.3 좋은 SRS의 조건) 못지 않게 중요하다.

4.5 SRS evolution
소프트웨어 제품이 발전함에 따라 SRS가 진화할 필요가 있을 수
있다.
프로젝트가 시작한 시점에 몇몇의 상세 내용을 작성하는 것은 불
가능한 일일 수 있다.(예를 들어 요구사항 단계에서 interactive 프
로그램에 대한 스크린 포맷의 모든 것을 정의하는 것은 불가능할
지 모른다.)
SRS에서 결핍, 부족, 부정확한 것이 발견됨에 따라 추가적인 변경
이 반드시 필요할 수 있다.

4.5 SRS evolution
이 단계에서 두 가지 중요한 고려사항은 다음과 같다.
a) 비록 진화적 개정이 불가피하게 예상된다고 하더라도 요구사
항은 그 당시에 알려진 만큼 완벽하고 철저하게 명세 되어야
한다. 요구사항이 완벽하지 않다는 사실은 반드시 표기되어야
한다.
b) 예상된 변경을 확인, 제어, 추적, 보고하기 위해 공식적인 변경
절차가 시작되어야 한다. 요구사항에서의 승인된 변경은 다음
의 내용을 포함하여야 한다.
1. 변경의 심사 절차를 정확하고 완벽하게 제공하여야 한다.
2. SRS의 현재 및 대체된 부분의 검토를 제공하여야 한다.

ISO26262에서 SRS evolution의 사례
Overview of product development at the software level(일부)
소프트웨어 아키텍처 디자인 단계에서도
Software 안전 요구사항을 갱신한다.

ISO26262에서 SRS evolution의 사례
개발 단계 Software Safety Requirement 작성 관련 표준
6 소프트웨
어 안전 요
구사항의
명세서
6.4.1 소프트웨어 안전 요구사항은 고장이 소프트웨어에 할당된 기술
적 안전 요구사항의 위반을 야기할 수 있는 모든 소프트웨어 기반의
기능을 다루어야 한다.
7 소프트웨
어 아키텍
처 설계
7.4.9 소프트웨어 안전 요구사항은 소프트웨어 컴포넌트에 할당되어
야 한다. 결과적으로 각 소프트웨어 컴포넌트는 컴포넌트에 할당된
요구사항의 최고 ASIL을 준수하여 개발되어야 한다.
비고 이 할당에 따라 소프트웨어 안전 요구사항의 향후 갱신이 필요
할 수 있다.

4.6 Prototyping
prototyping은 프로젝트의 요구사항 동안 빈번히 사용된다. 많은
도구들이 prototyping이 시스템의 일부 특성들을 보여주면서 매
우 빠르고 쉽게 생성되도록 한다.
prototyping은 다음의 이유로 유용하다
a) customer는 SRS를 일고 그것에 반응하는 것보다 prototype을
보고 그것에 대해서 반응하는 것을 더 좋아할 것이다.
prototype은 매우 빠른 피드백을 준다.
b) prototype은 시스템의 행동의 예상하지 못한 측면을 보여준
다 그래서 그것은 대답을 제공할 뿐만 아니라 새로운 질문을
제공한다. 이것은 SRS를 좀 더 가까이 다가갈 수 있도록 한다.
c) prototype을 기반으로 하는 SRS는 개발 기간 동안 덜 변경되
는 경향이 있어서 개발 시간이 짧아진다.

4.7 SRS에서 디자인을 포함시키기
요구사항은 시스템의 함수나 속성을 외부에서 알아볼 수 있도록
명세 한다. 디자인은 시스템의 특별한 서브 컴포넌트 및 그것의
다른 컴포넌트간의 인터페이스를 기술한다.
SRS 작성자는 요구되는 디자인 제약사항을 식별하는 일과 특정
디자인을 예상하는 일 사이에서 명확하게 구별해야 한다.
SRS에서의 모든 요구사항은 대체 가능한 디자인을 제약시킴에
유의한다.
이것은 모든 요구사항이 디자인을 의미하는 것은 아니다.

4.7 SRS에서 디자인을 포함시키기
SRS는 다음의 사항들을 명세해야 한다.
(1) 어떤 기능이 수행되어야 하는지
(2) 어떤 데이터가 생성되어야 하는지
(3) 누구를 위해 어떤 위치에서 어떤 결과가 생성되어야 하는지
SRS는 수행되어야 하는 서비스에 집중해야 한다.
SRS는 다음과 같은 디자인 아이템에 대해 보통은 명시하지 않아
야 한다.
a) software를 module로 분해하는 것
b) functions을 module에 할당하는 것
c) information의 흐름이나 모듈간의 control을 기술하는 것
d) data structure를 선택하는 것
요구사항을 작성하는 활동이 아니라, 소프트웨어 설계를 하는 활동의 범주에 해당함

4.7.1 필요한 디자인 요구사항
특별한 경우에 어떤 요구사항은 심각하게 디자인을 제약할 수 있
다. 예를 들어서 보안이나 안전 요구사항은 아래와 같은 필요에
의해서 디자인에 직접적으로 영향을 미칠 수 있다.
a) 어떤 함수를 분리된 모듈에 있도록 한다.
b) 프로그램의 어떤 부분 사이에서 제한된 통신만을 허락한다.
c) 대단히 중요한 변수에 대한 데이터 무결성을 체크한다.
유효한 디자인 제약사항의 예는 물리적 요구사항, 성능적 요구사
항, 소프트웨어 개발 표준, 소프트웨어 품질 보증 표준 등이 있다.
그러므로 요구사항은 순수하게 외부의 관점에서 기술되어야 한
다. 요구사항을 기술하는 모델을 사용하고자 할 때, 모델은 단순
히 외부 행동을 표시하고 디자인은 기술하지 않는다는 것을 기억
하여야 한다.

4.7.1 필요한 디자인 요구사항
그러므로 요구사항은 순수하게 외부의 관점에서 기술되어야 한
다. 요구사항을 기술하는 모델을 사용하고자 할 때, 모델은 단순
히 외부 행동을 표시하고 디자인은 기술하지 않는다는 것을 기억
하여야 한다.
위 두 그림 중에 어느 것이 요구사항에 적합할까?

4.8 SRS에서의 프로젝트 요구사항을 포함시키기
SRS는 소프트웨어 제품을 생산하는 프로세스가 아니라 소프트웨
어 제품에 대해서 기술해야 한다.
프로젝트 요구사항은 고객과 공급자 사이에 소프트웨어 생산에
적용되는 계약 문제사이의 이해를 표현한다. 이런 것들은 일반적
으로 다음과 같은 항목들을 포함한다.
a. cost
b. delivery schedule
c. reporting procedures
d. 소프트웨어 개발 방법
e. quality assurance
f. validation and verification criteria
g. acceptance procedures
프로젝트 요구사항은 다른 문서에 기술된다. 일반적으로는 소프
트웨어 개발 계획, 소프트웨어 품질 보증 계획, 혹은 작업 기술서
에 기술된다.

SRS와 SyRS의 유사성 (Normalized원칙)
SyRS는 다음의 속성을 가져야 한다.
a) Unique set.
b) Normalized.
Requirements should not overlap (i.e, they shall not refer
to other requirements or the capabilities of other
requirements).
c) Linked set.
d) Complete.
e) Consistent.
f) Bounded.
g) Modifiable.
h) Configurable.
i) Granular.
SRS에 디자인 설계 내용, 프로젝트 요구사
항을 넣지 않는 것은 Normalized 속성을 가
져야 하는 SyRS의 원칙과 유사하다.

5. SRS개요의 prototype
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms, and abbreviations
1.4 references
1.5 Overview
2. Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
3. Specific requirements
Appendix
Index

5.1 Introduction
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.4 references
1.5 Overview
2.4 Constraints
Appendix
Index

5.1 Introduction
Table of Contents
1. Introduction
1.1 Purpose
• SRS의 목적을 기술한다
• SRS을 읽을 대상이 누구인지를 기술한다
1.2 Scope
• 생산되는 소프트웨어 제품의 이름을 기술한다.
• 소프트웨어 제품이 무엇을 하는지, 필요하다면 무엇을 하지 않는지
를 기술한다.
• 관련된 장점, 목적, 목표를 포함하여 기술되고 있는 소프트웨어의
적용을 기술한다.
• 만약 상위 요구사항이 존재한다면, 상위 수준의 명세에서 유사한
표현과 일치성을 갖도록 한다.
1.4 references
1.5 Overview

5.1 Introduction
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
• SRS을 원활하게 이해하기 위해 필요한 모든 용어, 머리글자, 약어
의 정의를 기술한다. 이런 정보는 1개 이상의 appendix에서나 다른
문서의 참고를 통해 제공할 수 있다.
1.4 references
• SRS의 외부에서 참고한 모든 문서의 리스트를 작성한다.
• 문서 제목, 보고서 번호(가능하다면), 날짜, 출판 회사 등을 식별한
다.
• 참고문헌을 얻을 수 있는 source를 기술한다.
1.5 Overview
• SRS의 나머지가 무엇을 포함하고 있는지를 기술한다.
• SRS가 어떻게 구성되고 있는지를 기술한다.

5.2 Overall description
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.4 references
1.5 Overview
2.4 Constraints
Appendix
Index

Table of Contents
• 제품을 다른 관련 제품과의 관점 속에 넣어야 한다. 만약 그 제품이
독립적으로 동작한다면 여기에 그렇게 기술되어야 한다.
• 만약 SRS가 더 큰 시스템의 컴포넌트로 제품을 정의한다면, 이 부
분에서는 소프트웨어의 기능에 대한 더 큰 시스템의 요구사항과의
관계를 기술해야 하고 시스템과 소프트웨어간의 인터페이스를 식
별해야만 한다.
• 더 큰 시스템의 주요 컴포넌트, 상호 연결관계, 외부 인터페이스를
보여주는 블록 다이어그램은 도움이 된다.

Table of Contents
• 이 부분에서는 어떻게 소프트웨어가 내부의 다양한 제약사항속에
서 동작하는지를 기술하여야 한다. 예를 들어 제약사항들은 다음과
같은 것들이 있다.
a. System interface
b. User interface
c. Hardware interface
d. Software interface
e. Communication interface
f. Memory
g. Operations
h. Site adaptation requirement

2.1.1 System interfaces
각각의 시스템 인터페이스를 나열하고 시스템 요구사항을 달성
하기 위해 소프트웨어의 기능을 식별하여야 하고, 그 시스템에
일치하는 인터페이스를 설명하여야 한다.

2.1.2 User interfaces
다음의 사항을 기술하여야 한다.
a. 소프트웨어 제품과 그 사용자 사이의 각각의 인터페이스의 논
리적 특징. 이것은 소프트웨어 요구사항을 달성하기 위해 필
요한 설정 특징(필요한 화면 포맷, 페이지 또는 윈도우 레이아
웃, 보고서 및 메뉴의 내용, 프로그램 가능한 기능 키의 가용
성)을 포함해야 한다.
b. 그 시스템을 사용해야만 하는 사람과의 최적화된 인터페이스
의 모든 측면. 이것은 그 시스템이 사용자에게 어떻게 나타나
야 하는지에 대한 하는 것들과 하지 않는 것들의 리스트의 조
합일 수 있다. 하나의 예로 길거나 짧은 오류 메시지의 옵션에
대한 요구사항이 있을 수 있다. 다른 것들과 마찬가지로, 이런
요구사항들은 검증 가능해야 한다. 예를 들어 “타이핑 점원은
기능 X를 할 수 있다” 보다 “4등급의 타이핑 점원은 교육 1시
간 후 Z분 이내에 기능 X를 할 수 있다”

2.1.3 Hardware interfaces
소프트웨어 제품과 시스템의 하드웨어 컴포넌트간의 각각의 인
터페이스의 논리적 특징들을 기술해야 한다. 여기에는 설정 특징
(포트의 개수, 명령 셋 등)을 포함한다.
하드웨어 인터페이스는 또한 어떤 디바이스가 지원되어야 하는
지, 어떻게 디바이스가 지원되는지, 프로토콜은 어떠한지 등과 같
은 문제들을 포함한다.
예를 들어 터미널 서포트는 line-by-line 서포트와 반대로 full-
screen 서포트를 명세해야 할 수도 있다.

2.1.4 Software interfaces
이 부분에서는 그 외에 요구되는 소프트웨어 제품(예를 들어, 데
이터 관리 시스템, 운영 체제, 수학 패키지)과 다른 어플리케이션
과의 인터페이스(예를 들어 수신 시스템과 일반적 ledger시스템
의 account사이의 연결)의 사용을 기술한다. 각각의 요구되는 소
프트웨어 제품에 대해 다음의 것들이 기술되어야 한다.
• Name
• Mnemonic
• Specification number
• Version number
• Source
각각의 인터페이스에 대해 다음의 것이 제공되어야 한다.
• 소프트웨어와 인터페이스 하는 목적
• 메시지 내용과 형식의 관점에서 인터페이스의 정의

2.1.5 Communication interfaces
이 부분은 local network protocol등과 같은 다양한 통신 인터페
이스를 명시하여야 한다.
2.1.6 Memory constraints
이 부분은 primary 및 secondary memory의 해당되는 특징과 제
약사항에 대해서 기술하여야 한다.

2.1.7 Operations
이 부분은 다음과 같은 유저에게 필요한 일반적이고 특별한 동
작을 기술하여야 한다.
a) 사용자 측면에서의 동작에서의 다양한 모드(예를 들면 사용자
가 초기화시키는 동작들)
b) Operator와 상호작용을 하는 동작의 주기와 operator가 없는
동작의 주기
c) 데이터 처리 지원 기능
d) 백업 및 복구 동작
Note. 이 부분은 때때로 User interface section의 일부로 기술되
기도 함.

2.1.8 Site adaptation requirements
이 부분은 다음을 고려하여야 한다.
a) 해당 site, mission, 또는 동작 모드(e.g. grid value, safety
limits, etc) 에 특화된 어떤 데이터나 초기화 순서에 대한 요구
사항을 정의하여야 한다.
b) 소프트웨어를 특정한 설치에 맞추도록 하기 위해서 site 혹은
mission관련된 특징들이 수정될 수 있도록 site 혹은 mission
관련된 특징을 기술하여야 한다.

이 부분은 소프트웨어가 수행할 주요 기능들에 대해 요약하여 기
술하여야 한다. 예를 들어서 회계 프로그램의 SRS인 경우 이 부
분을 고객이 account maintenance, customer statement, invoice
preparation등과 같은 것을 각각의 기능이 요구하는 자세한 설명
없이 간단하게 기술해야 한다.
때때로 이 부분에서 필요한 기능의 요약은 상위 수준의 명세서
(만약 존재한다면)로부터 직접적으로 가져올 수도 있다.

아래의 사항을 준수하여야 한다.
a) 고객이나 다른 사람이 이 문서를 처음 봤을 때 기능 리스트를
보고 이해가 가능한 수준으로 기능들에 대해 잘 조직화하여
구성하여 설명하여야 한다.
b) 텍스트 혹은 그림으로 표현하는 방법을 사용하여 함수들과 그
들 사이의 관계를 설명하는데 사용한다. 여기에서 표현된 그
림들은 설계에서 사용하려고 하는 목적이 아니라 고객으로 하
여금 논리적인 관계를 단순하게 이해시키기 위함이다.

• 이 부분은 교육 수준, 경험, 기술적 전문 수준을 포함하여 기대
하는 사용자의 일반적인 특징을 기술한다.
• 세부적인 요구사항을 기술하는데 사용되지 않아야 하고 SRS의
특별한 요구사항(3장에서 기술)을 기술하려고 하기 위한 이유
를 설명하여야 한다.

2.4 Constraints
이 부분은 개발자가 개발하는데 고려하여야 할 제약사항을 기술
한다. 포함되어야 할 내용은 다음과 같다.
a. Regulatory policies
b. Hardware limitations(e.g. signal timing requirements)
c. 다른 어플리케이션과의 인터페이스
d. Parallel operations
e. Audit functions
f. 제어 기능
g. 상위 언어 요구사항
h. Signal handshake protocols(e.g. XON-XOFF, ACK-NACK)
i. Reliability 요구사항
j. 어플리케이션의 criticality
k. 안전 및 보안 고려사항

이 부분은 SRS에서 언급한 요구사항에 영향을 미치는 각각의 요
소들을 나열해야 한다. 이런 요소들은 소프트웨어의 디자인 제약
사항이 아니고 SRS의 변경에 의해 영향을 미칠 수 있는 요소이다.
예를 들어 특정 OS가 소프트웨어 제품의 지정된 하드웨어에 가
능하다고 가정했을 때, 만약 OS가 사용 가능하지 않는다고 한다
면 SRS는 즉시 변경되어야 한다.
2.6 Apportioning of requirements
이 부분은 현재 버전에서 개발되지 않고 향후 버전에서 개발될
요구사항을 나열한다.

5.3 Specific requirements
이 부분은 아래의 사항을 만족하여야 한다.
1) 설계자가 요구사항을 만족시키기 위한 설계가 가능하도록 요
구사항을 상세하게 설명하여야 한다.
2) 시험자가 요구사항을 만족시키는 시험 수행이 가능하도록 소
프트웨어 요구사항을 모두 포함하여야 한다.
• 사용자, operator, 다른 외부 시스템에 의해 외부적으로 모든
요구사항이 인식 가능할 수 있어야 한다.
• 입력을 시스템에 주었을 때, 시스템에서 수행하는 기능 및 그
에 따른 반응이 기술되어 있어야 한다.

상세 요구사항을 작성하기 위한 원칙
1. 상세 요구사항은 4.3에 기술한 모든 특징들과 부합하도록 기
술되어야 한다.(4.3 Characteristics of a good SRS)
2. 상세 요구사항은 연관이 있는 이전 문서들과 상호 참조 되어
야 한다.
3. 모든 요구사항은 고유하게 식별 가능해야 한다.
4. 가독성을 최대화시키기 위해 요구사항을 주의 깊게 구성해야
한다.

5.3.1 외부 인터페이스
이 부분에서는 소프트웨어 시스템의 모든 입력과 출력에 대해서
상세하게 기술하여야 한다.
5.2에 기술한 interface부분과 상호 보완적인 성격을 가져야 하며,
5.2에 있는 내용이 반복되어서는 안 된다.

5.3.1 외부 인터페이스
내용 및 형식은 다음과 같다.
a. 아이템의 이름
b. 목적
c. 입출력 정보
d. 유효 범위, 정확도, 허용오차
e. 측정 단위
f. 타이밍
g. 다른 입출력과의 관계
h. 화면 형식 및 구성
i. 데이터 형식
j. 명령어 형식
k. 종료 메시지

5.3.2 기능
• 기능적 요구사항은 소프트웨어의 입력을 받아 소프트웨어가
처리하여 출력을 생성하는 기본적인 행동을 정의해야 한다.
• 여기에는 다음을 포함한다.
a. 입력의 유효성 체크
b. 동작의 정확한 순서
c. 비정상적 조건에서의 반응, 다음을 포함하여
 Overflow
 Communication facilities
 Error handling and recovery
d. 파라미터 효과
e. 입력에 대한 출력의 관계, 다음을 포함하여
 입력/출력 순서
 입력을 출력으로 변환시키는 공식

5.3.2 기능
기능적 요구사항을 서브함수나 서브 프로세스로 나누는 것도 괜
찮다. 하지만 소프트웨어 설계 시에 이런 방식으로 나누어야 한
다는 의미는 아니다.
5.3.3 성능적 요구사항
이 부분은 소프트웨어 상 혹은 소프트웨어와 사람이 상호 작용할
때의 정적, 동적으로 수치화된 요구사항을 명시한다.
수치화된 정적 요구사항은 다음을 포함한다.
a. 지원되어야 하는 terminal의 개수
b. 지원되어야 하는 동시 접속 사용자의 수
c. 처리되어야 하는 정보의 양과 타입
정적인 요구사항은 Capacity라는 제목의 절에서 기술할 수도 있
다.

5.3.3 성능적 요구사항
수치화된 동적 요구사항은 예를 들면 다음의 내용을 포함한다.
1) 트랜잭션의 수
2) 정상적인 경우 및 최고로 workload인 경우에서 일정 기간 내
에 처리되어야 하는 작업 및 데이터의 양
측정할 수 있는 용어로 모든 요구사항을 기술해야 한다.
예를 들면,
95%의 트랜잭션은 1초 이내에 처리되어야 한다. (Good)
Operator가 트랜잭션이 끝나는 것을 기다리도록 하게 해서는 안
된다. (No good)

5.3.4 논리적 데이터베이스 요구사항
이 부분은 데이터베이스에 들어가야 하는 정보에 대한 논리적 요
구사항을 기술한다. 논리적 요구사항은 다음과 같다.
a) 다양한 기능들이 사용하는 정보들의 타입
b) 사용빈도
c) 접근 능력(또는 역량, capability)
d) 데이터 entitiy와 그들간의 관계
e) 무결성 제약
f) 데이터를 유지하는 요구사항

5.3.5 디자인 제약사항
이 부분은 다른 표준, 하드웨어 제한 등에 의해 부과되는 디자인
의 제약사항을 기술한다.
5.3.5.1 표준 부합
이 부분은 표준이나 법규에 의한 요구사항을 기술한다. 요구사항
들은 다음을 포함할 수 있다
a. 보고서 양식
b. 데이터 작명
c. 회계 절차
d. 평가 추적

5.3.5.1 표준 부합
예를 들어서 이것은 활동을 추적하기 위한 소프트웨어를 위한 요
구사항을 기술하는 것일 수 있다. 그런 추적들은 몇몇의 어플리
케이션이 최소한의 규제를 만족시키거나 재무 표준을 만족시키
기 위해 필요할 수 있다.
심사 추적 요구사항을 예: 인건비 데이터베이스의 변경은 이전
값 및 이후 값으로 추적 파일로 저장되어야 한다.

5.3.6 소프트웨어 시스템 속성
소프트웨어 속성으로서의 요구사항은 여러 개가 있다. 요구되는
속성을 명시함으로써 속성들이 만족했는지의 여부를 객관적으로
검증할 수 있도록 해야 한다. 5.3.6.1~5.3.6.5는 일부 예를 제공한
다.
5.3.6.1 Reliability
5.3.6.2 Availability
5.3.6.3 Security
5.3.6.4 Maintainability
5.3.6.5 Portability

5.3.6.1 Reliability
Delivery할 시점에 소프트웨어 시스템의 요구되는 reliability를 수
립하기 위해 요구되는 요소들을 기술한다.
5.3.6.2 Availability
전체 시스템에 대해 정의된 availability 수준을 보장하기 위해 요
구되는 요소들을 기술한다. 예를 들면 체크 포인트, 복구, 재 시
작 등과 같은 것들이 있다.

5.3.6.3 Security
잘못된 혹은 악의적 접근, 사용, 변경, 파괴, 폐쇄로부터 소프트웨
어를 보호하기 위한 요소를 기술한다. 이 부분에서의 특별한 요
구사항은 다음을 포함한다.
a) 특정 암호화 기술을 사용한다
b) 로그나 히스토리 데이터 세트를 유지한다
c) 어떤 기능을 다른 모듈에 할당한다.
d) 프로그램의 일부 영역들간의 통신을 제한한다
e) 중요 변수에 대한 데이터 무결성을 체크한다.

5.3.6.4 Maintainability
소프트웨어 자체에 대해 쉽게 유지 보수할 수 있는 것과 관련된
속성들을 기술한다. 모듈화, 인터페이스, 복잡성 등과 같은 것들
이 될 수 있다.
5.3.6.5 Portability
소프트웨어가 다른 host machine이나 운영체제에 쉽게 포팅할
수 있는 것과 관련된 속성들을 기술한다. 다음과 같은 것들을 포
함할 수 있다.
a) host-dependent code가 있는 component의 백분율
b) Host dependent code의 백분율
c) 증명된 Portable language의 사용
d) 특정 컴파일러나 language subset의 사용
e) 특정 OS의 사용

5.3.7 특정 요구사항을 조직화하기
5.3.7.1 System mode
5.3.7.2 User class
5.3.7.3 Objects
5.3.7.4 Feature
5.3.7.5 Stimulus
5.3.7.6 Response
5.3.7.7 Functional hierarchy
5.3.7.8 Additional comments

IEEE 830-1998 Recommended Practice for Software Requirement Specification

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (12)

Semelhante a IEEE 830-1998 Recommended Practice for Software Requirement Specification

Semelhante a IEEE 830-1998 Recommended Practice for Software Requirement Specification (20)

IEEE 830-1998 Recommended Practice for Software Requirement Specification