기술 사양은 GOST 19입니다. 프로그램 문서의 통합 시스템

GOST 19.201-78

주간 표준

통합 소프트웨어 문서화 시스템

공식 간행물

표준정보

주간 표준

프로그램 문서의 통합 시스템

기술 사양. 콘텐츠 및 디자인 요구 사항

프로그램 문서화를 위한 통합 시스템.

개발을 위한 기술 사양입니다. 보도자료의 내용 및 형식에 대한 요구사항

해결 국가위원회소련은 1978년 12월 18일 기준 No. 3351에 따라 도입일이 확정되었습니다.

이 표준프로그램 개발을 위한 기술 사양을 구성하고 완료하는 절차를 확립합니다. 소프트웨어 제품을 위한 컴퓨터, 단지 및 시스템은 목적과 범위에 관계없이.

이 표준은 ST SEV 1627-79를 완벽하게 준수합니다.

1. 일반 조항

1.1. 참조 조건은 일반적으로 시트 필드를 작성하지 않고 GOST 2.301-68에 따라 형식 11 및 12 시트의 GOST 19.106-78에 따라 작성됩니다. 시트(페이지) 번호는 텍스트 위의 시트 상단에 배치됩니다.

1.2. 승인서 및 첫 페이지 GOST 19.104-78에 따라 작성되었습니다. 정보 부분(주석 및 내용), 변경등록 시트는 허용됩니다.

문서를 포함하지 마십시오.

1.3. 변경하거나 추가하려면 참조 조건프로그램이나 소프트웨어 제품 개발의 후속 단계에서 추가 항목이 출시됩니다. 기술 사양에 대한 추가 조정 및 승인은 기술 사양에 대해 설정된 것과 동일한 방식으로 수행됩니다.

1.4. 위임사항에는 다음 섹션이 포함되어야 합니다. 소개;

개발 이유; 개발 목적;

프로그램 또는 소프트웨어 제품에 대한 요구 사항 요구 사항 프로그램 문서; 기술 및 경제 지표; 개발 단계 및 단계; 통제 및 승인 절차;

응용프로그램은 기술 사양에 포함될 수 있습니다.

프로그램이나 소프트웨어 제품의 특성에 따라 섹션의 내용을 명확하게 하거나, 새로운 섹션을 도입하거나, 개별 섹션을 결합하는 것이 가능합니다.

(변경판, 수정안 1호).

공식 출판물 ★

복제는 금지되어 있습니다

) 표준 출판사, 1978 © STANDARDINFORM, 2010

1981년 6월에 승인된 변경 번호 1이 포함된 판(2010년 1월)(IUS 9-81).

S. 2 GOST 19.201-78

2.1. "소개" 섹션에 이름을 표시하고, 간략한 설명프로그램 또는 소프트웨어 제품의 적용 범위 및 해당 프로그램 또는 소프트웨어 제품이 사용되는 대상.

2.2. “개발 기반” 섹션에는 다음 사항이 표시되어야 합니다. 개발이 수행되는 기반이 되는 문서 이 문서를 승인한 조직 및 승인 날짜 이름 그리고 (또는) 상징개발 주제.

2.1. 2.2. (변경판, 수정안 1호).

2.3. “개발 목적” 섹션에는 프로그램이나 소프트웨어 제품의 기능적, 운영적 목적이 명시되어야 합니다.

2.4. "프로그램 또는 소프트웨어 제품에 대한 요구 사항" 섹션에는 다음 하위 섹션이 포함되어야 합니다.

요구 사항 기능적 특성; 신뢰성 요구사항; 이용약관

기술적 수단의 구성 및 매개변수에 대한 요구사항; 정보 및 소프트웨어 호환성 요구 사항; 라벨링 및 포장 요구 사항; 운송 및 보관 요구 사항; 특별한 요구 사항.

(변경판, 수정안 1호).

2.4.1. 하위 섹션 "기능 특성 요구 사항"에는 수행되는 기능 구성, 입력 및 출력 데이터 구성, 타이밍 특성 등에 대한 요구 사항이 표시되어야 합니다.

2.4.2. 하위 섹션 "신뢰성 요구 사항"은 안정적인 작동을 보장하기 위한 요구 사항을 나타내야 합니다( 지속 가능한 기능, 입출력 정보 제어, 장애 후 복구 시간 등).

2.4.3. "작동 조건" 하위 섹션에는 작동 조건(주변 온도, 상대습도기타 등등 선택한 유형의 저장 매체의 경우) 지정된 특성과 서비스 유형을 제공해야 합니다. 필요한 수량및 인사 자격.

2.4.4. "기술적 수단의 구성 및 매개 변수에 대한 요구 사항"하위 섹션에는 필수 구성주요 기술적 특성을 나타내는 기술적 수단.

2.4.5. "정보 및 소프트웨어 호환성 요구 사항" 하위 섹션에는 다음 요구 사항이 표시되어야 합니다. 정보 구조입력과 출력 및 해결 방법에서 소스 코드, 프로그램에서 사용되는 프로그래밍 언어 및 소프트웨어.

필요한 경우 정보와 프로그램의 보호가 보장되어야 합니다.

(변경판, 수정안 1호).

2.4.6. "라벨링 및 포장 요구사항" 하위 섹션에서 일반적인 경우소프트웨어 제품 라벨링, 포장 옵션 및 방법에 대한 요구 사항을 나타냅니다.

2.4.7. "운송 및 보관 요구 사항" 하위 섹션에는 소프트웨어 제품에 대한 운송 조건, 보관 ​​위치, 보관 조건, 보관 ​​조건, 다양한 조건의 보관 기간이 표시되어야 합니다.

2.5a. "프로그램 문서 요구 사항" 섹션에는 프로그램 문서의 예비 구성과 필요한 경우 특별 요구 사항이 표시되어야 합니다. (추가로 도입됨, 수정안 1호).

2.5. "기술 및 경제 지표" 섹션에는 다음이 표시되어야 합니다. 경제적 효율성, 예상 연간 수요, 국내 최고 대비 개발의 경제적 이점 및 외국 샘플또는 유사품.

2.6. "개발 단계 및 단계"섹션에서는 필요한 개발 단계, 작업 단계 및 내용이 설정됩니다 (목록 프로그램 문서, 개발, 합의 및 승인이 필요함), 원칙적으로 개발 기간에 따라 수행자가 결정됩니다.

2.7. "통제 및 승인 절차" 섹션에는 테스트 유형과 일반 요구 사항일을 받아들이기 위해.

2.8. 기술 사양의 부록에는 필요한 경우 다음이 제공됩니다. 개발을 정당화하는 연구 및 기타 작업 목록;

개발 중에 사용할 수 있는 알고리즘 다이어그램, 표, 설명, 타당성, 계산 및 기타 문서 다른 개발 소스.

기술 사양.

GOST 19.201-78

소련 연방의 주 표준

1978년 12월 18일 No. 3351의 소련 국가 표준위원회 법령에 따라 도입 날짜가 설정되었습니다.

1980년 1월 1일부터

이 표준은 목적과 범위에 관계없이 컴퓨터, 컴플렉스 및 시스템용 프로그램 또는 소프트웨어 제품 개발을 위한 기술 사양을 구성하고 준비하는 절차를 설정합니다.

1. 일반 조항

정보부분(주석 및 내용), 변경등록서는 문서에 포함되지 않을 수 있습니다.

1.3. 프로그램이나 소프트웨어 제품 개발의 후속 단계에서 기술 사양을 변경하거나 추가하기 위해 추가 사항이 릴리스됩니다. 기술 사양에 대한 추가 조정 및 승인은 기술 사양에 대해 설정된 것과 동일한 방식으로 수행됩니다.

1.4. 참조 약관에는 다음 섹션이 포함되어야 합니다.

명칭 및 적용 범위;

개발 기반;

개발 목적;

기술 요구 사항프로그램이나 소프트웨어 제품;

기술 및 경제 지표;

개발 단계 및 단계;

통제 및 승인 절차;

응용 프로그램.

프로그램이나 소프트웨어 제품의 특성에 따라 섹션의 내용을 명확하게 하거나, 새로운 섹션을 도입하거나, 개별 섹션을 결합하는 것이 가능합니다.

2. 섹션 내용

2.1. "이름 및 범위" 섹션에는 이름, 프로그램 또는 소프트웨어 제품의 적용 범위에 대한 간략한 설명 및 프로그램 또는 소프트웨어 제품이 사용되는 대상이 표시됩니다.

2.2. "개발 기초" 섹션에는 다음이 표시되어야 합니다.

개발이 수행되는 기반이 되는 문서

이 문서를 승인한 조직 및 승인 날짜

개발 주제의 이름 및(또는) 기호.

2.3. “개발 목적” 섹션에는 프로그램이나 소프트웨어 제품의 기능적, 운영적 목적이 명시되어야 합니다.

2.4. "프로그램 또는 소프트웨어 제품에 대한 기술 요구 사항" 섹션에는 다음 하위 섹션이 포함되어야 합니다.

기능적 특성에 대한 요구 사항;

신뢰성 요구사항;

이용약관

기술적 수단의 구성 및 매개변수에 대한 요구사항;

정보 및 소프트웨어 호환성 요구 사항;

라벨링 및 포장 요구 사항;

운송 및 보관 요구 사항;

특별한 요구 사항.

2.4.1. 하위 섹션 "기능 특성 요구 사항"에는 수행되는 기능 구성, 입력 및 출력 데이터 구성, 타이밍 특성 등에 대한 요구 사항이 표시되어야 합니다.

2.4.2. "신뢰성 요구 사항" 하위 섹션에는 안정적인 작동을 보장하기 위한 요구 사항(안정적인 작동 보장, 입력 및 출력 정보 모니터링, 장애 후 복구 시간 등)이 표시되어야 합니다.

2.4.3. "작동 조건" 하위 섹션에는 지정된 특성이 보장되어야 하는 작동 조건(선택한 유형의 저장 매체에 대한 주변 온도, 상대 습도 등)은 물론 서비스 유형, 필요한 수 및 자격도 표시되어야 합니다. 인원.

2.4.4. "기술 수단의 구성 및 매개 변수에 대한 요구 사항"하위 섹션에는 주요 기술 특성을 나타내는 기술 수단의 필수 구성이 표시되어 있습니다.

2.4.5"정보 및 소프트웨어 호환성 요구 사항" 하위 섹션에서는 입력 및 출력의 정보 구조와 솔루션 방법, 소스 코드 및 프로그래밍 언어에 대한 요구 사항을 나타내야 합니다.

필요에 따라 정보와 프로그램을 제공해야 한다.

2.4.6. "마킹 및 포장 요구 사항"하위 섹션에는 일반적으로 소프트웨어 제품 표시 요구 사항, 포장 옵션 및 방법이 표시됩니다.

2.4.7. "운송 및 보관 요구 사항" 하위 섹션에는 소프트웨어 제품의 운송 조건, 보관 ​​위치, 보관 조건, 보관 ​​조건, 다양한 조건의 보관 기간이 표시되어야 합니다.

2.5. "기술 및 경제 지표" 섹션에는 예상 경제 효율성, 예상 연간 수요, 최고의 국내외 샘플 또는 유사품과 비교한 개발의 경제적 이점이 표시되어야 합니다.

2.6. "개발 단계 및 단계" 섹션에서는 필요한 개발 단계, 작업 단계 및 내용(개발, 합의 및 승인이 필요한 프로그램 문서 목록)과 원칙적으로 다음 사항이 설정됩니다. 개발 기간과 실행자가 결정됩니다.

2.7. "통제 및 승인 절차" 섹션에는 테스트 유형과 작업 승인을 위한 일반 요구 사항이 표시되어야 합니다.

2.8. 기술 사양의 부록에는 필요한 경우 다음이 제공됩니다.

개발을 정당화하는 연구 및 기타 작업 목록

개발 중에 사용할 수 있는 알고리즘 다이어그램, 표, 설명, 타당성, 계산 및 기타 문서

다른 개발 소스.

이 표준은 목적과 범위에 관계없이 컴퓨터, 컴플렉스 및 시스템용 프로그램 또는 소프트웨어 제품 개발을 위한 기술 사양을 구성하고 준비하는 절차를 설정합니다.

이 표준은 ST SEV 1627-79를 완벽하게 준수합니다.

디자인 규칙

참조 조건은 일반적으로 시트 필드를 작성하지 않고 GOST 2.301-68에 따라 형식 11 및 12 시트의 GOST 19.106-78에 따라 작성됩니다. 시트(페이지) 번호는 텍스트 위의 시트 상단에 배치됩니다.

승인 시트 및 표지

승인 시트와 제목 페이지는 GOST 19.104-78에 따라 작성되었습니다.

정보부분(주석 및 내용), 변경등록서는 문서에 포함되지 않을 수 있습니다.

변경 및 추가

프로그램이나 소프트웨어 제품 개발의 후속 단계에서 기술 사양을 변경하거나 추가하기 위해 추가 사항이 릴리스됩니다. 기술 사양에 대한 추가 조정 및 승인은 기술 사양에 대해 설정된 것과 동일한 방식으로 수행됩니다.

모든 세부 사항을 고려하십시오. 초기 단계개발이 불가능합니다. 실제로 지정된 접근 방식꽤 자주 사용됨. "개발 단계 및 단계" 섹션에는 기술 사양에 대한 변경 및 추가 가능성이 명확하게 표시되어야 합니다. "이 기술 사양 섹션의 내용은 고객과의 합의에 따라 변경 및 보완될 수 있습니다."

기술 사양 섹션 구성

참조 약관에는 다음 섹션이 포함되어야 합니다.

소개;

개발 이유;

개발 목적;

프로그램 또는 소프트웨어 제품에 대한 요구 사항

프로그램 문서에 대한 요구 사항;

기술 및 경제 지표;

개발 단계 및 단계;

통제 및 승인 절차;

응용프로그램은 기술 사양에 포함될 수 있습니다.

프로그램이나 소프트웨어 제품의 특성에 따라 섹션의 내용을 명확하게 하거나, 새로운 섹션을 도입하거나, 개별 섹션을 결합하는 것이 가능합니다. 엄격히 고객과 동의합니다. 기술사양서에는 고객의 동의가 반영되어야 합니다.

교육 프로그램으로서 우리는 여러 템플릿 기능(예: 간단한 텍스트 편집기)을 수행할 수 있는 기능을 제공하는 그래픽 사용자 인터페이스가 있는 실제 프로그램을 사용합니다.

소개

이 섹션에는 이름, 프로그램이나 소프트웨어 제품의 적용 범위에 대한 간략한 설명, 프로그램이나 소프트웨어 제품이 사용되는 대상이 표시됩니다.

텍스트 작업의 기본 규칙은 텍스트를 구조 단위, 하위 섹션, 단락 및 하위 단락으로 나누는 것입니다. 텍스트의 목차는 필요한 자료를 쉽게 찾을 수 있도록 명확한 구조를 갖습니다. 문서의 텍스트가 구조화되고 읽기 쉬워집니다. 하위 섹션 만들기:

프로그램 이름

이름 - "rtf 파일 작업을 위한 텍스트 편집기"

적용 분야에 대한 간략한 설명

이 프로그램은 고객 시설의 전문 부서에서 사용하도록 고안되었습니다.

콘텐츠 개별 품목항상 분명하지는 않습니다. 어려움이 있으면 공식적으로 접근해야 합니다. 수정은 고객과 기술사양에 대한 합의 단계에서 가능합니다.

개발 이유

섹션에는 다음이 표시되어야 합니다.

개발이 수행되는 기반이 되는 문서

이 문서를 승인한 조직 및 승인 날짜

개발 주제의 이름 및(또는) 기호.

하위 섹션에는 계약에 포함된 정보가 포함되어야 합니다.

개발 기반

개발의 기초는 2004년 3월 15일자 계약(서신 등) No. 666(수신 번호 이러저러함)입니다. 이 계약은 국가 단일 기업 "Spetstyazhmontazhstroyselkhozavtomatika" Ivanov Petr Ivanovich 이사와 합의되었습니다. 고객이 추가로, 승인됨 총괄이사 OJSC "Supersoft" Blyumkins Ivan Aronovich(이하 계약자라고 함), 2008년 3월 등.

개발자가 GOST 34.602-89의 "일반 정보"섹션을 사용하는 것이 편리합니다. 모든 권리귀하의 재량에 따라 기술 사양의 섹션을 보완하고 삭제하십시오. 동시에 위에 명시된 정보는 계약에 포함됩니다. 위임사항에 포함되어야 하는지 여부는 구체적인 사례에 따라 다릅니다.

이 표준은 목적과 범위에 관계없이 컴퓨터, 컴플렉스 및 시스템용 프로그램 또는 소프트웨어 제품 개발을 위한 기술 사양을 구성하고 준비하는 절차를 설정합니다.

이 표준은 ST SEV 1627-79를 완벽하게 준수합니다.

디자인 규칙

참조 조건은 일반적으로 시트 필드를 작성하지 않고 GOST 2.301-68에 따라 형식 11 및 12 시트의 GOST 19.106-78에 따라 작성됩니다. 시트(페이지) 번호는 텍스트 위의 시트 상단에 배치됩니다.

승인 시트 및 표지

승인 시트와 제목 페이지는 GOST 19.104-78에 따라 작성되었습니다.

정보부분(주석 및 내용), 변경등록서는 문서에 포함되지 않을 수 있습니다.

변경 및 추가

프로그램이나 소프트웨어 제품 개발의 후속 단계에서 기술 사양을 변경하거나 추가하기 위해 추가 사항이 릴리스됩니다. 기술 사양에 대한 추가 조정 및 승인은 기술 사양에 대해 설정된 것과 동일한 방식으로 수행됩니다.

개발 초기 단계에서는 모든 세부 사항을 고려하는 것이 불가능합니다. 실제로는 이 접근 방식이 자주 사용됩니다. "개발 단계 및 단계" 섹션에는 기술 사양에 대한 변경 및 추가 가능성이 명확하게 표시되어야 합니다. "이 기술 사양 섹션의 내용은 고객과의 합의에 따라 변경 및 보완될 수 있습니다."

기술 사양 섹션 구성

참조 약관에는 다음 섹션이 포함되어야 합니다.

소개; 개발 이유; 개발 목적; 프로그램 또는 소프트웨어 제품에 대한 요구 사항 프로그램 문서에 대한 요구 사항; 기술 및 경제 지표; 개발 단계 및 단계; 통제 및 승인 절차; 응용프로그램은 기술 사양에 포함될 수 있습니다.

프로그램이나 소프트웨어 제품의 특성에 따라 섹션의 내용을 명확하게 하거나, 새로운 섹션을 도입하거나, 개별 섹션을 결합하는 것이 가능합니다. 엄격히 고객과 동의합니다. 기술사양서에는 고객의 동의가 반영되어야 합니다.

교육 프로그램으로서 우리는 여러 템플릿 기능(예: 간단한 텍스트 편집기)을 수행할 수 있는 기능을 제공하는 그래픽 사용자 인터페이스가 있는 실제 프로그램을 사용합니다.

소개

이 섹션에는 이름, 프로그램이나 소프트웨어 제품의 적용 범위에 대한 간략한 설명, 프로그램이나 소프트웨어 제품이 사용되는 대상이 표시됩니다.

텍스트 작업의 기본 규칙은 텍스트를 구조 단위, 하위 섹션, 단락 및 하위 단락으로 나누는 것입니다. 텍스트의 목차는 필요한 자료를 쉽게 찾을 수 있도록 명확한 구조를 갖습니다. 문서의 텍스트가 구조화되고 읽기 쉬워집니다. 하위 섹션 만들기:

프로그램 이름

이름 - "rtf 파일 작업을 위한 텍스트 편집기"

적용 분야에 대한 간략한 설명

이 프로그램은 고객 시설의 전문 부서에서 사용하도록 고안되었습니다.

개별 항목의 내용이 항상 명확하지는 않습니다. 어려움이 있으면 공식적으로 접근해야 합니다. 수정은 고객과의 기술 사양 승인 단계에서 이루어질 수 있습니다.

개발 이유

섹션에는 다음이 표시되어야 합니다.

개발 수행의 기반이 되는 문서 이 문서를 승인한 조직 및 승인 날짜 개발 주제의 이름 및(또는) 기호.

하위 섹션에는 계약에 포함된 정보가 포함되어야 합니다.

개발 기반

개발의 기초는 2001년 1월 1일자 계약(서신 등) No. 000(수신 번호 이러저러함)입니다. 이 계약은 국가 단일 기업 "Spetstyazhmontazhstroyselkhozavtomatika" Ivanov Petr Ivanovich 이사(이하 고객이라고 함)와 합의되었으며 Blyumkins Ivan Aronovich 총책임자(이하 계약자라고 함)의 승인을 받아 2008년 3월에 체결되었습니다. .

"라는 부분을 이용하시면 편리합니다. 일반 정보» GOST 34.602-89, 개발자는 자신의 재량에 따라 기술 사양의 섹션을 추가하고 삭제할 수 있는 모든 권리를 갖습니다. 동시에 위에 명시된 정보는 계약에 포함됩니다. 위임사항에 포함되어야 하는지 여부는 구체적인 사례에 따라 다릅니다.

개발 주제의 명칭 및 기호

개발 주제명은 “Development”입니다. 텍스트 편집기 rtf 파일 작업을 위한 것입니다."

개발 주제(토픽 코드) 지정은 “RTF-007”입니다.

개발 목적

섹션에는 프로그램이나 소프트웨어 제품의 기능적, 운영적 목적이 명시되어야 합니다.

기능적 목적

프로그램의 기능적 목적은 사용자에게 작업할 수 있는 기회를 제공하는 것입니다. 텍스트 문서 RTF 형식으로.

하위 섹션에는 '확대됨'이 표시되어야 합니다. 기능적 목적프로그램. 세부사항(기능 목록 등)은 아래 관련 섹션에 제공됩니다.

운영 목적은 상당히 광범위하게 해석될 수 있습니다. 어디서, 어떻게, 누구에 의해, 어떤 프로그램을 사용해야 합니까?

동일한 크기의 타이어는 Zhiguli 및 Volga 차량에서 성공적으로 사용할 수 있지만 KamAZ에서는 사용할 수 없습니다. 그리고 그 반대도 마찬가지입니다. 그러나 각 고무 크기에 따라 작동 목적이 결정될 수 있습니다.

공식적인 접근 방식을 사용해 보겠습니다.

운영 목적

이 프로그램은 고객 시설의 전문 부서에서 사용해야 합니다.

프로그램의 최종 사용자는 고객 시설의 전문 부서 직원이어야 합니다.

프로그램 또는 소프트웨어 제품에 대한 요구 사항

섹션에는 다음 하위 섹션이 포함되어야 합니다.

기능적 특성에 대한 요구 사항 신뢰성 요구사항; 이용약관 기술적 수단의 구성 및 매개변수에 대한 요구사항; 정보 및 소프트웨어 호환성 요구 사항; 라벨링 및 포장 요구 사항; 운송 및 보관 요구 사항; 특별한 요구 사항.

프로그램, 시스템 또는 제품에 대한 일반적인(기술적) 요구 사항을 포함하는 표준이 있는 경우(예: “GOST. 자동화된 정보 및 측정 시스템. 일반(기술) 요구사항'에 따라 기술 사양 개발이 크게 단순화됩니다. 최대지정된 표준의 내용은 단순히 기술 사양으로 다시 작성됩니다.

기능적 요구 사항

하위 섹션에는 수행되는 기능의 구성, 입력 및 출력 데이터의 구성, 타이밍 특성 등에 대한 요구 사항이 표시되어야 합니다.

수행되는 기능의 구성에 대한 요구 사항

프로그램은 다음 기능을 수행할 수 있는 기능을 제공해야 합니다.

1. 새(빈) 파일을 생성하는 기능입니다.

2. 기존 파일 열기(로드) 기능.

4. 클립보드를 이용하여 현재 파일을 편집하는 기능 운영 체제.

5. 파일을 원래 이름으로 저장하는 기능.

6. 원본과 다른 이름으로 파일을 저장하는 기능.

7. 현재 파일의 내용을 전송하는 기능 이메일로외부 클라이언트 메일 프로그램을 사용합니다.

8. 온라인 정보를 문자열 형식으로 표시하는 기능(팁).

9. 온라인 도움말 시스템의 기능.

10. 프로그램 이름, 프로그램 버전, 저작권 및 개발자 의견을 표시하는 기능.

"실행 가능성을 제공한다"는 진부한 표현은 그래픽 사용자 인터페이스를 사용하여 개발된 최신 소프트웨어에 적용됩니다. 이러한 소프트웨어 도구는 대부분 "유휴" 상태로 운영자의 작업을 기다리고 있습니다.

입력 데이터 구성 요구 사항

프로그램의 입력 데이터는 다음 형식으로 구성되어야 합니다. 별도의 파일사양에 해당하는 rtf 형식입니다.

지정된 형식의 파일은 운영 체제 요구 사항에 따라 포맷된 로컬 또는 이동식 미디어에 배치(저장)되어야 합니다.

형식이 다르지만 확장자가 rtf인 파일은 열어서는 안 됩니다.

파일 http:///file. rtf 또는 ftp:///file. rtf를 열면 안 됩니다. 파일 시스템이 FAT32로 포맷된 경우, 예를 들어 ext3 형식으로 포맷된 로컬 또는 이동식 미디어의 파일을 열어서는 안 됩니다.

출력 데이터 구성을 위한 요구 사항

입력 데이터 구성을 위한 요구 사항을 참조하세요.

요구사항은 출력 데이터 구성과 동일합니다. 이는 기술 사양의 두 가지 사항을 결합해야 하는 경우입니다.

타이밍 요구 사항

프로그램의 타이밍 특성에 대한 요구 사항은 없습니다.

고객이 프로그램 속도에 대한 요구 사항을 갖고 있는지 명확히 해야 합니다(예: 프로그램이 특정 크기의 파일을 시작하고 열고 닫는 데 걸리는 시간). 고객이 지정하는 경우 특정 숫자, 안전하게 플레이해야 하며 기술 장비의 구성 및 매개변수에 대한 요구 사항에 2,500달러 이상의 슈퍼컴퓨터를 포함해야 합니다. 사실, 그러한 금액은 정당화되어야 합니다. 고객에게 시간 특성이 중요하지 않은 경우 시간 특성에 대한 요구 사항 포기에 대해 작성해야 합니다(위 문구 참조).

신뢰성 요구 사항

하위 섹션에는 안정적인 작동을 보장하기 위한 요구 사항(안정적인 작동 보장, 입력 및 출력 정보 모니터링, 장애 후 복구 시간 등)을 표시해야 합니다.

신뢰성은 섬세하고 매우 위험한 것입니다. 그러나 1.3.2 절에 따른 기능 및 실패 모드 목록. GOST 24.701-86은 고객이 작성하고 계약자와 동의해야 합니다. 대부분의 경우 고객이 이해할 수 있는 내용을 기대하는 것은 불가능합니다. 프로그램의 안정적인 작동은 계약자에 달려 있는 것이 아니라 하드웨어 및 운영 체제의 신뢰성에 달려 있으며 또한 고객에게 신뢰성과 안정성을 높이기 위한 여러 가지 엄격한 조치를 제공한다는 점을 고객에게 설명할 가치가 있습니다. 프로그램의.

프로그램의 안정적인(안정적인) 작동을 보장하기 위한 요구 사항

프로그램의 안정적인(지속 가능한) 운영은 고객이 일련의 조직적, 기술적 조치를 구현함으로써 보장되어야 하며 그 목록은 아래와 같습니다.

기술 장비의 무정전 전원 공급 장치 구성 라이센스가 부여된 소프트웨어 사용 01.01.01 결의안에 명시된 러시아 연방 노동 사회 개발부의 권장 사항을 정기적으로 이행합니다. "부문 간 승인에 따라 표준 표준 PC 및 사무 장비 서비스 및 소프트웨어 유지 관리 작업 시간”; GOST 요구 사항을 정기적으로 준수합니다. 정보 보호. 컴퓨터 바이러스의 존재 여부를 테스트하는 소프트웨어입니다.

목록에 12개를 더 추가할 수 있습니다. 규제 문서. 기술 사양을 처음 승인하는 동안 고객은 타협하는 경향을 보이기 시작할 가능성이 높습니다.

보다 인도적인 접근이 가능합니다. 그러나 동일한 GOST에 따른 시스템의 신뢰성은 특정 시간 간격 동안 특정 i 번째 기능의 오류 없는 성능으로 간주될 수 있습니다. 우리는 고객이 프로그램의 안정적인 작동을 위한 기준을 고려할 것을 제안합니다. 다음 지표: 고객이 한 시간 내에 파일을 100번 열고 닫았습니다. 프로그램이 지정된 시간 간격 내에 실패하지 않으면 신뢰성 요구 사항이 충족된 것으로 간주됩니다.

고객이 최종적으로 신뢰성은 계약자에 달려 있는 것이 아니라 기술 장비 및 운영 체제의 신뢰성에 달려 있다고 확신하고 포기하는 경우 해당 섹션에 다음 문구를 작성해야 합니다.

프로그램의 안정적인(안정적인) 작동을 보장하기 위한 요구 사항은 없습니다.

장애 후 복구 시간

기술 장비의 정전으로 인한 고장 후 복구 시간(기타 외부 요인)는 운영 체제의 치명적인 오류(충돌 아님)가 아니라 하드웨어 및 소프트웨어의 작동 조건을 준수하는 경우 너무 많은 시간을 초과해서는 안 됩니다.

하드웨어 오작동이나 운영 체제의 치명적인 오류(충돌)로 인한 오류 발생 후 복구 시간은 하드웨어 오작동을 제거하고 소프트웨어를 다시 설치하는 데 필요한 시간을 초과해서는 안 됩니다.

스크롤 비상 상황또한 고객이 작성하고 계약자와 합의했습니다. 실제로 오류가 치명적이지 않거나 운영 체제 충돌이나 하드웨어 오류로 인한 것이 아닌 경우 운영 체제를 재부팅해야 할 때입니다.

잘못된 운영자 조치로 인한 실패

운영 체제와 상호 작용할 때 운영자(사용자)의 잘못된 작업으로 인해 프로그램 오류가 발생할 수 있습니다. 위 이유로 인한 프로그램 오류를 방지하려면 최종 사용자에게 관리 권한을 부여하지 않고도 작업할 수 있는지 확인해야 합니다.

이용약관

하위 섹션에는 지정된 특성이 보장되어야 하는 작동 조건(선택한 유형의 저장 매체에 대한 주변 온도, 상대 습도 등)은 물론 서비스 유형, 필요한 직원 수 및 자격도 표시되어야 합니다.

기후적 작동 조건

기후 조건특정 특성이 보장되어야 하는 동안 작동은 다음에 대한 요구 사항을 충족해야 합니다. 기술적 수단작동 조건 측면에서.

이 프로그램은 상대습도 90%, 대기압 462mm에서 +5°C부터 +35°C까지 완벽하게 작동합니다. rt. Art., 이러한 조건은 대략 현대 컴퓨터의 작동 조건과 일치하기 때문입니다. 비산업실행. 그러나 사양이 구체적이고 작업이 승인되자마자 고객은 계약업체가 기후 테스트를 수행하도록 강요할 수 있는 좋은 기회를 얻습니다. 완전히계약자의 비용으로.

서비스 유형에 대한 요구 사항

프로그램의 안정적인(안정적인) 작동을 보장하기 위한 요구 사항을 참조하세요.

이 프로그램에는 어떤 유형의 유지 관리도 필요하지 않습니다.

유지 관리 유형은 "신뢰할 수 있는(지속 가능한) 작동을 보장하기 위한 요구 사항" 하위 섹션에서 차용해야 합니다.

고객이 기술 사양을 승인하는 동안 리소스가 부족하거나 모든 유형의 유지 관리를 수행하려는 욕구를 언급하는 경우 우리 스스로, 약간의 비용으로 소프트웨어 지원을 위한 기술 사양 개발을 제공하는 것이 합리적입니다. 별도의 계약. 거부하는 경우 해당 프로그램은 지원되지 않는 것으로 간주됩니다.

직원 수 및 자격 요건

프로그램 운영에 필요한 최소 인원은 시스템 관리자와 정규직 2명 이상이어야 합니다. 최종 사용자프로그램 - 운영자.

시스템 관리자는 고등 교육 학위를 가지고 있어야 합니다 전문교육운영 체제 제조업체의 인증서. 수행된 작업 목록 시스템 관리자, 다음을 포함해야 합니다:

기술적 수단의 기능을 유지하는 업무 설치(설치) 및 시스템 소프트웨어 기능 유지(운영 체제) 작업 프로그램을 설치하는 작업입니다.

프로그램의 최종 사용자(운영자)는 운영 체제의 그래픽 사용자 인터페이스를 사용하는 데 실용적인 기술을 가지고 있어야 합니다.

직원은 전기 안전(사무기기 작업용) 분야의 자격 그룹 II 인증을 받아야 합니다.

승인된 기술 사양에 가장 핵심적인(굵게) 문구가 없는 경우, 고객은 운영자가 "대응할 수 없다"는 사실을 언급하여 계약자에게 운영 체제의 그래픽 사용자 인터페이스를 운영하기 위한 매뉴얼을 개발하도록 요청할 권리가 있습니다. ” 프로그램과 함께.

II가 없는 인원 자격 그룹전기 안전에 따라 개인용 컴퓨터 및 사무용품에 접근할 권리도 없습니다.

기술적 수단의 구성 및 매개 변수에 대한 요구 사항

하위 섹션은 주요 기술적 특성을 나타내는 기술적 수단의 필수 구성을 나타냅니다.

개발할 장비보다 나쁘지 않은 장비를 선택해야 합니다. 늦어도 고객에게 장비를 제공하도록 요청하는 것이 논리적입니다. 특정 기간. 그것은 약, 물론 컴퓨터에 관한 것입니다.

하드웨어에는 IBM 호환이 포함되어야 합니다. 개인용 컴퓨터(PC)에는 다음이 포함됩니다.

클록 주파수가 GHz - 10 이상인 Pentium-1000 프로세서; 마더보드 FSB, GHz - 5 이상; 숫양부피, Tb - 10, 그 이상; 등…

정보 및 소프트웨어 호환성 요구 사항

하위 섹션에는 프로그램에서 사용하는 입력 및 출력 정보 구조와 솔루션 방법, 소스 코드, 프로그래밍 언어 및 소프트웨어에 대한 요구 사항이 표시되어야 합니다.

필요한 경우 정보와 프로그램의 보호가 보장되어야 합니다.

정보 구조 및 해결 방법에 대한 요구 사항

파일의 정보 구조에는 rtf 형식 사양에서 요구하는 마크업이 포함된 텍스트가 포함되어야 합니다.

입력 및 출력의 정보 구조(파일)는 물론 솔루션 방법에 대한 요구 사항도 없습니다.

소스 코드 및 프로그래밍 언어 요구 사항

프로그램의 소스 코드는 C++로 구현되어야 합니다. Borland C++ Buider 환경은 통합 프로그램 개발 환경으로 사용해야 합니다.

프로그램에서 사용되는 소프트웨어 요구 사항

프로그램에서 사용하는 시스템 소프트웨어는 라이센스가 부여된 운영 체제의 현지화된 버전이어야 합니다. 이러한 서비스 팩을 사용할 수 있습니다.

정보 및 프로그램 보호 요구 사항

정보 및 프로그램 보호에 대한 요구 사항은 없습니다.

그러한 요구는 피해야 합니다. 정보와 프로그램에 대해 일정 수준의 보호를 보장하는 것은 가능하지만 보안을 보장하는 것은 불가능합니다. 고객은 이를 깨닫고 지속하지 않을 가능성이 높습니다.

라벨링 및 포장 요구 사항

프로그램은 배포(외부 광) 매체(CD)의 소프트웨어 제품으로 제공됩니다.

우리는 소프트웨어 제품인 배포 매체의 라벨링 및 포장에 대해 이야기하고 있습니다(GOST 19.004-80 참조).

라벨링 요건

소프트웨어 제품에는 개발사의 상표, 유형(이름), 버전 번호, 일련번호, 제조 날짜 및 러시아 Gosstandart 적합성 인증서 번호(있는 경우).

표시는 GOST 9181-74의 요구 사항을 고려하여 인쇄하여 만든 스티커 형태로 소프트웨어 제품에 적용되어야 합니다.

마킹의 품질은 가장 정교한 방법을 사용하여 확인됩니다. 먼저 물로 마킹을 씻어낸 다음 휘발유 및 기타 유기 용제로 씻어냅니다. 품질이 좋지 않은 표시에 대해서는 인쇄 회사에 책임을 지게 하십시오. 계약자의 임무는 적합성 인증서 뒤에 숨는 것입니다(프린터에게 인증서 요청).

포장 요구 사항

소프트웨어 제품은 제조업체의 포장 용기에 포장되어야 합니다.

바로 제조사입니다. 계약자는 컨테이너 제조업체보다 더 큰 책임을 질 수도 없고 져서도 안 됩니다.

포장조건

소프트웨어 제품의 포장은 환경에 공격적인 불순물이 없는 상태에서 +15 ~ +40°C의 온도와 80% 이하의 상대 습도에서 폐쇄되고 통풍이 잘되는 장소에서 수행되어야 합니다.

고객은 올바른 모습의 소프트웨어 제품을 받게 됩니다. 소프트웨어 제품이 부적절한 상태(스크래치, 균열 및 기타 결함)로 반품된 경우 계약자는 고객의 포장 조건 위반에 대해 클레임을 제기하고 소프트웨어 제품을 수락하지 않을 수 있습니다.

포장 절차

포장용으로 준비된 소프트웨어 제품은 포장 제조업체의 도면에 따라 골판지(GOST 7376-89 또는 GOST 79)로 만든 상자인 컨테이너에 넣습니다.

소프트웨어 제품은 방수 필름으로 만들어진 커버를 사용하여 포장되어 있습니다. 필수 출석화학적으로 공격적이지 않은 건조제(실리카겔).

작성하려면 여유 공간골판지 또는 발포 플라스틱으로 만든 개스킷은 포장 용기에 넣습니다.

운영 문서는 다음 위치에 있어야 합니다. 소비자 포장소프트웨어 제품과 함께.

배송 서류는 쿠션재의 최상층에 위치합니다. 포장 목록그리고 포장 목록.

소비자 포장은 GOST에 따라 접착 테이프 6-70으로 덮어야 합니다.

소비자용 포장으로 포장된 소프트웨어 제품은 반드시 팔레트에 올려 놓고 화물 형태의 변형을 방지하기 위해 테이프로 묶어야 하며, 습기로부터 보호하기 위해 폴리에틸렌 필름 M 0.2로 포장해야 합니다.

팔레트 상자에는 GOST에 따른 포장 목록을 포함한 배송 문서가 포함되어 있어야 합니다.

화물 공간의 크기는 1250 x 820 x 1180mm를 초과할 수 없습니다.

순 중량 - 200kg 이하.

총 중량 - 220kg 이하.

하위 섹션에서는 일부 기술 장비에 대해 이전에 개발된 문서의 패키징 절차를 보여줍니다. 소프트웨어 제품의 맥락에서는 다소 이례적으로 보입니다. 간단한 러시아어로-완전한 농담.

운송 및 보관 요구 사항

하위 섹션에는 소프트웨어 제품의 운송 조건, 보관 ​​위치, 보관 조건, 보관 ​​조건, 다양한 조건에서의 보관 기간을 표시해야 합니다.

하위 섹션에서는 일부 기술 장비에 대해 이전에 개발된 문서의 운송 및 보관 조건을 제공합니다. 이는 포장 요구 사항에도 적용됩니다. 소프트웨어 제품의 맥락에서는 다소 이례적으로 보입니다.

고객은 운송 및 보관 조건을 위반할 권리가 없습니다. 계약자는 다음과 같은 이유로 소프트웨어 제품을 고객에게 반환하는 것을 거부할 수 있습니다. 모습소프트웨어 제품은 운송 및 보관 조건을 준수하지 않은 결과입니다.

운송 및 보관 조건

모든 유형의 운송(거리 제한이 없는 항공기의 가열된 밀봉 구획 포함)을 통해 운송 컨테이너에 담긴 소프트웨어 제품을 운송하는 것이 허용됩니다. 철도 차량으로 운송되는 경우, 운송 유형은 소형, 저톤수입니다.

소프트웨어 제품을 운반하고 보관할 때 먼지와 강수로부터 보호해야 합니다. 소프트웨어 제품을 기울이는 것은 허용되지 않습니다. 운송을 위한 기후 조건은 다음과 같습니다.

주변 공기 온도, °C - 플러스 5에서 플러스 50까지; 대기압, kPa 등; 25°C의 상대 습도는 이러합니다.

특별 요구 사항

프로그램은 운영 체제 제조업체의 권장 사항에 따라 개발된 그래픽 사용자 인터페이스를 통해 사용자(운영자)와의 상호 작용을 제공해야 합니다.

이 표준의 개발자는 미래를 내다봤습니다. 그 당시에는 그래픽 사용자 인터페이스를 갖춘 프로그램이 없었습니다.

소프트웨어 문서 요구 사항

이 섹션에는 프로그램 문서의 예비 구성과 필요한 경우 특별 요구 사항이 표시되어야 합니다.

프로그램 문서의 구성은 GOST 19.101-77에 의해 제공됩니다.

프로그램 문서의 예비 구성

프로그램 문서의 구성에는 다음이 포함되어야 합니다.

기술 사양 테스트 프로그램 및 방법; 시스템 프로그래머 가이드; 운영자 매뉴얼; 운영 문서 목록.

프로그램 및 테스트 방법은 계약자가 개발한 프로그램이 합의 및 승인된 기술 사양의 요구 사항을 충족한다는 것을 고객에게 보여야 합니다. 공동(인수) 테스트를 수행한 후 고객과 계약자는 작업 인수(인도) 증명서에 서명합니다. 따라서 작업이 종료되고 계약 조건이 이행됩니다.

조항 2.6에 따르면. GOST 19.101-77 “결합이 허용됩니다 개별 종운영 문서(운영 문서 목록 및 양식 제외) 이러한 문서를 결합해야 할 필요성은 기술 사양에 명시되어 있습니다. 병합된 문서에는 병합된 문서 중 하나의 이름과 명칭이 할당됩니다.”

다음에 포함된 소프트웨어 문서 예비 목록, GOST 19.106-78의 요구 사항에 따라 발행되어야 합니다.

기술 및 경제 지표

예상 경제성은 계산되지 않습니다.

연간 프로그램 사용 추정 횟수는 한 워크스테이션에서 365회의 작업 세션입니다.

이 섹션에는 예상 경제 효율성, 예상 연간 수요, 최고의 국내외 샘플 또는 유사 제품과 비교하여 개발의 경제적 이점이 표시되어야 합니다.

고객이 12개의 워크스테이션에 프로그램을 설치했다고 가정해 보겠습니다. 계약자는 개발 비용으로 1000달러를 요구했습니다. 고객은 워크스테이션에 설치할 수 있습니다. 소프트웨어 제품배포당 $500, 워크스테이션당 라이센스당 $100입니다.

개발의 경제적 이점

최고의 국내 및 외국 유사품과 비교하여 개발의 경제적 이점은 다음과 같습니다.

일자리 수

개발

경제적 이익

개발 단계 및 단계

이 섹션에서는 개발에 필요한 단계, 작업 단계 및 내용(개발, 합의 및 승인이 필요한 프로그램 문서 목록)은 물론 일반적으로 개발 기간을 설정하고 수행자를 결정합니다.

개발 단계 및 단계는 GOST 19.102-77에 의해 규제됩니다. GOST 19.102-77은 개별 작업 단계 및 조합의 배제를 방지하지 않습니다. 개별 단계공장

개발 단계

개발은 세 단계로 진행되어야 합니다.

기술 사양 개발 상세한 디자인; 구현.

개발 단계

기술 사양 개발 단계에서는 본 기술 사양의 개발, 조정 및 승인 단계가 완료되어야 합니다.

세부 설계 단계에서는 다음 작업 단계를 완료해야 합니다.

프로그램 개발; 프로그램 문서 개발; 프로그램을 테스트 중입니다.

구현 단계에서는 프로그램 준비 및 이전이라는 개발 단계가 완료되어야 합니다.

기술 사양 개발 단계에서는 다음 작업을 수행해야 합니다.

문제 설명; 기술적 수단에 대한 요구사항의 결정 및 설명; 프로그램 요구 사항 결정; 프로그램 및 문서 개발의 단계, 단계 및 시기를 결정합니다. 프로그래밍 언어 선택; 기술 사양의 조정 및 승인.

프로그램 개발 단계에서는 프로그램을 프로그래밍(코딩)하고 디버깅하는 작업을 해야 합니다.

프로그램 문서 개발 단계에서 프로그램 문서 개발은 이 기술 사양의 프로그램 문서의 예비 구성 조항의 요구 사항과 함께 GOST 19.101-77의 요구 사항에 따라 수행되어야 합니다.

프로그램의 테스트 단계에서는 다음 유형의 작업을 수행해야 합니다.

프로그램 개발, 조정 및 승인(GOST에는 "순서"라는 오타가 있는 것 같습니다) 및 테스트 방법 승인 테스트 수행; 테스트 결과에 따라 프로그램 및 프로그램 문서를 조정합니다.

프로그램 준비 및 이전 단계에서는 고객의 시설에서 운영할 프로그램 및 프로그램 문서를 준비하고 이전하는 작업을 완료해야 합니다.

통제 및 승인 절차

이 섹션에는 테스트 유형과 작업 승인을 위한 일반 요구 사항이 표시되어야 합니다.

테스트 유형

승인 테스트는 정해진 기간 내에 고객 현장에서 수행되어야 합니다.

프로그램 승인 테스트는 계약자가 개발하고 고객이 동의한 프로그램 및 테스트 방법(최소 특정 기간 이전)에 따라 수행되어야 합니다.

고객과 계약자는 테스트 보고서에 승인 테스트 진행 상황을 문서화합니다.

작업 수락을 위한 일반 요구 사항

테스트 프로토콜에 따라 계약자는 고객과 함께 프로그램 승인 및 시운전 인증서에 서명합니다.

응용

기술 사양의 부록에는 필요한 경우 다음이 제공됩니다.

개발을 정당화하는 연구 및 기타 작업 목록 개발 중에 사용할 수 있는 알고리즘 다이어그램, 표, 설명, 타당성, 계산 및 기타 문서 다른 개발 소스.

있다면 가져오시면 어떨까요? 그리고 개발을 수행해야 하는 기반이 되는 GOST 목록을 게시하십시오. 예를 들어:

GOST 19.201-78. 기술 사양, 콘텐츠 및 디자인 요구 사항 등...