기술 사양 내용에 대한 요구 사항. 기술 사양을 직접 작성하는 방법

프로젝트 범위 정의, 기술 사양 개발

이 섹션에서는 기술 사양 개발(이하 TK) 문제에 대해 간략하게 설명합니다. 먼저, 기술명세의 정의를 제시하고, 기술명세가 고객과 계약자 모두에게 주는 이점을 설명하며, 기술명세의 주요 기능을 나열한다. 다음으로 TK의 본질이 무엇인지 고찰하고, TK의 구조와 내용을 밝히고, TK의 구조 예를 제시한다. 결론적으로 혁신적인 프로젝트의 기술 사양의 특징이 주목됩니다.

고유한 특성을 지닌 혁신적인 프로젝트를 위한 기술 사양을 개발하는 작업은 원칙적으로 기술 사양을 개발할 때와 동일하게 유지되므로 전체 기술 사양을 개발하는 문제가 먼저 고려됩니다.

정의

현재로서는 혁신적인 프로젝트의 기술 사양(TOR)에 대한 표준화된 정의가 없다는 점에 유의해야 합니다. 현재 국가 표준 데이터베이스에는 TK와 관련된 세 가지 표준이 있습니다. 이들 모두는 정보 기술 분야와 관련이 있습니다.

GOST 19.201-78. 프로그램 문서의 통합 시스템. 기술 사양. 콘텐츠 및 디자인 요구 사항.

GOST 25123-82. 컴퓨팅 기계 및 데이터 처리 시스템. 기술 사양. 건설, 프리젠 테이션 및 디자인 순서.

GOST 34.602-89. 정보 기술.

자동화 시스템에 대한 일련의 표준입니다. 자동화된 시스템 생성을 위한 참조 조건.

예를 들어, "GOST 19.201-78. 프로그램 문서의 통합 시스템. 기술 사양. 내용 및 디자인에 대한 요구 사항" 기술 사양에 대한 정의는 다음과 같습니다. "자동화 시스템에 대한 기술 사양 - 자동화 시스템 개발에 필요한 목표, 요구 사항 및 기본 초기 데이터를 정의하는 확립된 방식으로 승인된 문서입니다. 경제적 효율성에 대한 예비 평가가 포함되어 있습니다."

기술 사양에 따르면 다음이 허용됩니다.

수행자 - 작업의 본질을 이해하고 고객에게 미래 제품, 소프트웨어 제품 또는 자동화 시스템의 "기술적 외관"을 보여줍니다.

고객-정확히 필요한 것이 무엇인지 이해합니다.

양 당사자 - 완제품을 발표합니다.

계약자 - 프로젝트 구현을 계획하고 계획에 따라 작업합니다.

계약자 - 기술 사양에 명시되지 않은 작업 수행을 거부합니다.

고객과 계약자 - 완제품에 대한 단계별 점검을 수행합니다(인수 테스트 - 수행 테스트);

요구 사항 변경과 관련된 오류 방지(생성 단계 및 단계에서 다음을 제외) 테스트).

따라서 기술 사양은 일련의 요구 사항을 포함하고 개발자와 고객 모두가 최종 제품을 제시하고 이후 요구 사항 준수 여부를 확인할 수 있는 문서입니다.

기술 사양이 상세할수록 승인 테스트 중에 고객과 개발자 사이에 논란이 되는 상황이 줄어들 것입니다.

TK는 네 가지 주요 기능을 수행합니다.

합법적인. 기술 사양은 법적 문서이며 고객과 계약자 간의 계약서에 부록으로 포함되어 있습니다.

조직적.

기술 사양의 도움으로 추가 작업을 간소화하고 작업 대기열(구성표)로 전환하며 불필요한 작업에 노력을 낭비하지 않을 수 있습니다.

정보 제공.

잘 작성된 기술 사양은 프로젝트를 완료하는 데 필요한 좋은 정보 소스가 될 수 있습니다. TK의 구조화된 특성을 통해 가장 쉽게 인식할 수 있는 형식과 작업을 완료하는 데 필요한 양으로 정말 흥미로운 정보를 얻을 수 있습니다.

의사소통.

상세한 기술 사양은 계약자가 고객의 요구 사항을 더 잘 이해하고 모든 취향에 맞는 작업을 수행하는 데 도움이 됩니다.

기술 사양의 핵심은 할당된 작업을 성공적으로 완료하는 것입니다. 기술 사양이 더 좋고 더 잘 작성될수록 작업이 더 효과적으로 완료됩니다. 또한 이는 규모에 의존하지 않습니다. 기술 사양을 잘못 준비하면 결과를 예측할 수 없거나 고객이 필요로 하는 대로 작업이 완료되지 않거나 전혀 완료되지 않는 등의 결과가 발생할 수 있습니다. 작업 고객은 자신이 원하는 것을받지 못하며 완료된 작업에 대해 비용을 지불하지 않을 권리가 있습니다.

많은 데이터가 아직 알려지지 않았기 때문에 기술 사양 작업은 어렵고 중요한 단계입니다. 전문가에 따르면 프로젝트의 성공은 기술 사양 개발 단계의 적격한 구현에 50-70% 달려 있습니다.

원칙적으로 기술 사양 개발 단계는 주제 영역 연구, 계산 및 모델링이 선행됩니다.

기술 사양에 대한 책임 있는 작업을 통해 개발자는 작업 완료를 위한 시나리오를 볼 수 있습니다. 당신의 강점과 약점, 작업을 완료하는 과정을 살아가는 방법을 명확하게 이해하십시오. 기준을 결정하고 지표, 특성, 금액을 설정하고 자원을 평가합니다.

기술 사양은 고객과 합의하거나 공동으로 개발합니다.

그 중요성에도 불구하고 기술 사양의 내용과 구조는 사실상 규제 문서에 의해 규제되지 않습니다.

일반적으로 고객은 목표(자신이 이해하는 대로)와 자원 제한(시간, 돈)을 설정합니다. 수행자의 임무는 우선 요구 사항을 주제 영역의 언어로 번역하고, 문제를 최대한 완전하고 유능하게 공식화하고, 솔루션의 필요성을 정당화하고, 초기 데이터를 이해하고 명확하게 하는 것입니다. TOR의 내용에는 항상 특정 요구 사항의 만족과 연결되는 특정 요구 사항을 구현하는 기능의 목표 및 성능에 관한 정보가 포함되어야 합니다.

요구 사항에 대한 작업은 관리 대상입니다. 정의되지 않은 요구사항은 요구사항에 대한 다양한 해석을 허용하고 개발 중인 제품의 품질에 대한 객관적인 평가를 허용하지 않기 때문에 작업의 모든 참가자에게 불확실성을 야기합니다.

요구 사항 시스템을 구성할 때 고객과 ​​개발자가 사용할 수 있는 리소스의 가용성(재무, 생산, 인적, 시간)을 분석하고 감독 및 라이센스 기관의 요구 사항을 고려하는 것이 필요합니다. 기술 단지(생산)를 설계할 때.

가장 자주 통제하는 기관은 Rostekhnadzor, Rosstandart, Rospotrebnadzor, Rosprirodnadzor 등의 지역 기관입니다.

예를 들어 작업 명세서에는 다음 섹션이 포함될 수 있습니다.

기술 사양의 주제;

수행되는 작업의 목표;

보고 요구 사항;

작업 조직 절차;

위 GOST 19.201-78의 예입니다.

소개;

개발 이유;

개발 목적;

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

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

기술 및 경제 지표;

개발 단계 및 단계;

통제 및 승인 절차;

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

컨설팅 서비스 제공에 대한 참조 조건의 다음 예

일반 조항;

업무 목적;

후보자의 자격 요건.

“페름 기술혁신파크 조성을 위한 개념개발, 개발전략 및 타당성 조사”(이하 R&D) 연구 수행을 위한 참고사항의 예

연구 수행의 기초

출연자와 공동 출연자

1. 연구 과제

   소스 데이터

   연구 수행을 위한 기본 요구 사항

   연구 일정

   연구결과의 활용 목적

   연구결과 전달 및 승인 절차

R&D용 TOR 템플릿 구조의 예

작업의 기초

집행자

작업 타이밍

작업의 목적

연구개발 성과

개발 중인 제품

기술 요구 사항

작업의 결과로 달성해야 하는 주요 매개변수는 다음과 같습니다.

기본 설계 요구 사항(해당하는 경우)

담보 유형별 요건(해당되는 경우)

표준화, 통일, 관련 객체와의 호환성 및 상호 호환성에 대한 요구 사항입니다.

인간의 생명과 건강을 위한 안전과 환경보호를 위한 요구사항

신뢰성 요구사항(해당하는 경우)

신뢰성과 내구성에 대한 요구 사항.

인체공학 및 기술적 미학에 대한 요구사항(해당되는 경우)

작동 요구 사항, 유지 관리 용이성 및 유지 관리 가능성(해당되는 경우)

저항 요구 사항(해당하는 경우)

성능 요구 사항(해당하는 경우)

인증 요구 사항

산업별 기타 요구사항 및 특별 요구사항

특허 순도 및 특허성에 대한 요구 사항

문서 요구 사항

작업 수락 절차.

따라서 주어진 예의 구조를 분석하면 기술 과제의 구조와 내용이 수행해야 하는 작업에 따라 결정된다는 점을 알 수 있습니다.

혁신적인 프로젝트를 위한 기술 사양 개발의 특징

혁신 프로젝트는 과학적, 기술적 아이디어를 새롭거나 개선된 제품으로, 실제 활동에 사용되는 새롭거나 개선된 기술 프로세스로, 또는 사회 서비스에 대한 새로운 접근 방식으로 변환하는 것과 관련되어 있기 때문에 독특한 이벤트입니다. 한 번도 해본 적 없는 일을 해야 하는 상황. 그리고 과거 경험은 기대할 수 있는 사항에 대해 제한적인 지침만 제공할 수 있습니다. 따라서 혁신적인 프로젝트는 높은 수준의 불확실성과 위험을 안고 있으며 이것이 그 특징입니다.

혁신적인 프로젝트의 개발은 프로젝트의 의도된 최종 아이디어를 얻기 위한 솔루션을 찾고 이 혁신적인 프로젝트를 구현하기 위해 시간, 자원 및 수행자를 연결하는 일련의 작업 및 활동을 생성하는 것을 목표로 합니다. 구현하는 동안 모든 혁신적인 프로젝트는 아이디어 개발 단계부터 아이디어가 관련성이 없는 단계까지 특정 경로를 거칩니다. 기술 사양 개발 단계는 혁신 프로젝트의 초기 단계를 의미합니다.

혁신적인 프로젝트에서 완전히 창조할 때 신제품모든 매개변수를 미리 계획하는 것은 어렵기 때문에 본질적으로 주로 설명적인 동적 확장 기술 사양을 사용하는 것이 제안됩니다.

신제품 아이디어가 나온 후 첫 번째 단계는 고객 요구 사항, 신제품에 대한 시장 세분화, 규범, 표준, 일반 목표(시장 점유율, 비용), 출시 시간 등을 포함할 수 있는 요구 사항 카탈로그를 만드는 것입니다. 시장, 수명 주기 기간, 일반 위험 평가.

요구사항 카탈로그에 설명된 지표는 확장 기술 사양이라는 문서에 지정되어 있습니다.

요구사항 카탈로그가 "클라이언트 언어"로 작성되면 확장 기술 사양도 "기업 언어"로 작성됩니다. 확장된 기술 사양에는 전통적인 사항(작업 범위, 보고, 초기 데이터, 매개변수 요구 사항 등)과 프로젝트 사업 계획의 일부 요소(제안된 가격 책정 정책, 계획된 시장 점유율, 계획된 매출액 등)가 포함되어야 합니다. , 등.) .

요구사항 카탈로그는 고객의 관점에서 작성되므로 요구사항 카탈로그 작성을 위한 언어도 (특정 기술 세부사항 없이) 고객이 이해할 수 있도록 선택됩니다. 요구 사항 카탈로그에는 고객 요구에 대한 기업의 제안이 반영됩니다.

확장된 기술 사양에는 다음이 포함될 수 있습니다.

1. 프로젝트 설명

2. 프로젝트의 시장 및 경제적 목표

3. 타이밍 매개변수

4. 기술적인 매개변수

5.생산 매개변수

8. 디자인 및 인체공학적 요구사항

9. 표준 및 규정

따라서 확장된 기술 사양을 작성하는 주요 작업은 개발 중인 제품에 대한 가장 완전한 정보를 수집하여 계획의 기초로 사용하는 것입니다.

확장된 TOR의 정보는 프로젝트 결과를 구성할 모든 구성 요소의 목록인 제품 구조 측면에서 추가로 지정됩니다. 프로젝트 결과 구조 계획에는 생성되는 제품의 모든 구성 요소, 블록 및 노드가 포함됩니다.

기술 사양의 가장 중요한 요소는 작업 목적, 결과 적용 범위, 작업 내용, 구현 프로그램, 기술, 경제 및 기타 지표, 작업 요구 사항, 수준입니다. 구현 방법, 작업 결과, 예상 결과의 과학적, 기술적 및 실제적 가치; 결과의 의도된 용도와 보고 자료의 표현 유형 및 형식.

구조에서 기술 사양의 위치를 ​​고려해 봅시다. 조직의 혁신 프로세스(조직의 혁신 도입)에 따르면.

처음에는 혁신 개념이 개발되었습니다. 연구 단계(조직 조사, 향후 혁신 활동에 대한 성과 지표 선택, 혁신 구현에 필요한 활동 목록 정당화)가 선행됩니다.

형성된 개발자 팀에 의한 혁신 개념은 후속 설계에 필요한 모든 정당성, 초기 설정 및 매개변수를 포함해야 하는 혁신적인 프로젝트 개발을 위한 작업(TOR)으로 개발됩니다.

혁신적인 프로젝트 개발 과제를 기반으로 개별 작업의 개발 및 솔루션은 물론 구현 모니터링(마감일 이정표, 제어 매개변수 목록, 제어 기준 등)을 위한 세부 실행 계획이 작성됩니다. ).

본질적으로 말하면, 참조 조건과 이벤트 계획은 혁신적인 프로젝트 개발의 기초입니다.

프로젝트의 내용은 계획된 활동에 대한 설명 및 규정, 자원의 최적 사용 계산, 예상되는 구현 결과 평가를 정량적 가치로 표현한 것입니다. 혁신적인 프로젝트의 기본은 조직적, 재정적 부분입니다.

"소프트웨어 수명주기 모델"주제에 대한 강의 자료를 숙지하십시오. GOST 19.102-77에 따른 수명주기 단계. 학문분야 “소프트웨어와 IT의 개발 및 표준화”의 문제점 진술”.

1. 출판물에서 관련 섹션을 연구하십시오.

이론적인 부분. 기술 사양 개발

참조 조건소프트웨어 제품의 주요 개발 목표, 요구 사항을 공식화하고 개발 시기와 단계를 정의하며 승인 테스트 프로세스를 규제하는 문서입니다. 고객 대표와 계약자 대표 모두 기술 사양 개발에 참여합니다. 본 문서는 고객의 초기 요구 사항, 첨단 기술 성과 분석, 연구 작업 결과, 사전 설계 연구, 과학적 예측 등을 기반으로 작성되었습니다.

기술 사양 개발 절차

기술 사양의 개발은 다음 순서로 수행됩니다. 먼저, 수행할 기능의 집합과 초기 데이터의 목록 및 특성이 설정됩니다. 그런 다음 결과 목록, 특성 및 표시 방법이 결정됩니다.

다음으로, 소프트웨어의 운영 환경이 지정됩니다. 즉, 하드웨어의 특정 구성 및 매개변수, 사용된 운영 체제 버전, 향후 소프트웨어 제품이 상호 작용할 설치된 다른 소프트웨어의 버전 및 매개변수 등이 지정됩니다.

개발 중인 소프트웨어가 일부 정보를 수집 및 저장하거나 기술 프로세스의 제어에 포함되는 경우 장비 및 전원 공급 장치에 장애가 발생할 경우 프로그램의 조치를 명확하게 규제할 필요가 있습니다.

1. 일반 조항

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

1.2. 승인 시트와 제목 페이지는 GOST 19.104-78에 따라 작성되었습니다. 정보부분(주석 및 내용), 변경등록서는 문서에 포함되지 않을 수 있습니다.

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

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

소개;

적용 범위 및 명칭

개발의 기초

개발 목적

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

기술 및 경제 지표

개발 단계 및 단계

통제 및 승인 절차

응용 프로그램.

프로그램이나 소프트웨어 제품의 기능에 따라 섹션의 내용을 명확하게 하거나 새로운 섹션을 도입하거나 개별 섹션을 결합하는 것이 가능합니다. 필요한 경우 기술 사양에 응용 프로그램을 포함하는 것이 허용됩니다.

2.1.서론에는 프로그램이나 소프트웨어 제품의 적용 범위와 그것이 사용되는 대상(예: 시스템)에 대한 간략한 설명이 포함되어야 합니다. 소개의 주요 목적은 이 개발의 관련성을 보여주고 이 개발이 유사한 개발 중에서 어떤 위치를 차지하는지 보여주는 것입니다.

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

2.3. “개발 기반” 섹션에는 다음이 표시되어야 합니다.

개발이 수행되는 기반이 되는 문서입니다. 그러한 문서는 계획, 주문, 계약 등이 될 수 있습니다.

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

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

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

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

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

신뢰성 요구사항

이용약관

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

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

라벨링 및 포장 요구 사항

운송 및 보관 요구 사항

특별 요구 사항.

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

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

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

2.5.4 하위 섹션 "기술 수단의 구성 및 매개변수에 대한 요구 사항"에서는 기술적 특성을 표시하여 필요한 기술 수단 구성을 나타냅니다.

2.5.5. 하위 섹션 "정보 및 소프트웨어 호환성 요구 사항"에서는 입력 및 출력의 정보 구조와 솔루션 방법, 소스 코드 및 프로그래밍 언어에 대한 요구 사항을 지정해야 합니다. 필요한 경우 정보와 프로그램의 보호가 보장되어야 합니다.

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

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

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

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

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

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

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

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

기타 개발 소스.

고객이 기술사양에서 규정한 요구사항을 제시하지 않은 경우 해당 위치에 “요구사항 없음”을 표시하여야 합니다.

기술 사양 개발의 예는 부록 B와 C에 나와 있습니다.

보안 질문

1. 소프트웨어 수명주기 모델의 개념을 제시합니다.

2. 소프트웨어 개발 단계를 알려주세요.

3. 문제 진술과 프로젝트 전 조사에는 무엇이 포함됩니까?

4. 소프트웨어 제품의 기능적, 운영적 요구사항을 나열하십시오.

5. 기술 사양 개발 규칙을 나열하십시오.

6. 기술 사양의 주요 섹션 이름을 지정합니다.

부록 A

작업 옵션

동일한 옵션에 대해 실험실 작업 번호 1-5가 수행됩니다.

1. "학생 진도 계산" 소프트웨어 모듈을 개발합니다. 소프트웨어 모듈은 학장, 부학장 및 학장실 직원이 세션 동안 학생의 진행 상황을 기록하도록 설계되었습니다. 학생의 학업 성취도에 대한 정보는 전체 학업 기간 동안 보관되어야 하며 수강한 과목의 증명서와 졸업장 보충 자료를 준비하는 데 사용되어야 합니다.

2. "학생의 개인 파일" 소프트웨어 모듈을 개발합니다. 소프트웨어 모듈은 학장실, 노동조합위원회, 인사부 직원이 학생에 대한 정보를 얻도록 설계되었습니다. 정보는 학생의 전체 학습 기간 동안 저장되어야 하며 증명서 및 보고서 준비에 사용되어야 합니다.

3. "조합 최적화 문제 해결" 소프트웨어 모듈을 개발합니다. 모듈에는 최소 길이의 주기(여행하는 판매원 문제) 찾기, 최단 경로 찾기 및 최소 스패닝 트리 찾기를 위한 알고리즘이 포함되어야 합니다.

4. 소프트웨어 모듈 "매트릭스 프로세싱"을 개발합니다. 모듈에는 행과 열을 기준으로 행렬 요소의 합과 곱을 검색하고 행렬의 평균, 최소 및 최대 값을 계산하는 알고리즘이 포함되어 있어야 합니다.

5. Windows 애플리케이션 “Organizer”를 개발합니다. 이 응용 프로그램은 개인 및 조직의 주소와 전화 번호는 물론 일정, 회의 등을 기록, 저장 및 검색하기 위한 것입니다. 이 응용 프로그램은 모든 컴퓨터 사용자를 대상으로 합니다.

6. Windows 애플리케이션 "계산기"를 개발합니다. 이 애플리케이션은 모든 사용자를 대상으로 하며 모든 산술 연산(우선순위 관련)을 포함해야 하며 바람직하게는(반드시 그런 것은 아니지만) 여러 가지 수학 함수를 포함해야 합니다.

7. 부서 직원에 대한 정보(성명, 직위, 학위, 학문 분야, 업무량, 지역 사회 봉사, 시간제 근무 등)가 포함된 소프트웨어 모듈 "부서"를 개발합니다. 이 모듈은 HR 부서 직원과 학장실 직원이 사용하도록 고안되었습니다.

8. 실험실 직원에 대한 정보(성명, 성별, 나이, 결혼 여부, 자녀 유무, 직위, 학업 학위)가 포함된 "실험실" 소프트웨어 모듈을 개발합니다. 이 모듈은 노동조합 위원회 및 인사부 직원이 사용하도록 고안되었습니다.

9. "드라이클리닝" 소프트웨어 모듈을 개발하십시오. 서비스 등록시 소유자 이름, 제품 설명, 서비스 유형, 주문 접수 날짜 및 서비스 비용을 나타내는 신청서가 작성됩니다. 작업이 완료되면 영수증이 인쇄됩니다.

10. "교통 위반 회계" 소프트웨어 모듈을 개발하십시오. 각 자동차(및 소유자)에 대한 위반 목록이 데이터베이스에 저장됩니다. 각 위반에 대해 날짜, 시간, 위반 유형 및 벌금 금액이 기록됩니다. 벌금을 모두 납부하면 해당 차량은 데이터베이스에서 삭제됩니다.

11. 대리점 직원이 사용할 수 있는 소프트웨어 모듈 "자동차 매장 카드 색인"을 개발합니다. 데이터베이스에는 자동차에 대한 정보(제조사, 엔진 크기, 생산 날짜 등)가 포함되어 있습니다. 구매 요청이 접수되면 적합한 옵션을 검색합니다. 해당 옵션이 없으면 클라이언트는 클라이언트 데이터베이스에 입력되고 해당 옵션이 나타날 때 알림을 받습니다.

12. 소프트웨어 모듈 "PBX 가입자 지수"를 개발합니다. 카드 색인에는 휴대폰과 휴대폰 소유자에 대한 정보가 포함되어 있습니다. 지불 연체를 기록합니다(구독 및 시간 기준). 시내전화 시간제 결제는 이미 도입된 것으로 알려졌다.

13. 버스 노선의 무료 좌석 가용성에 대한 정보가 포함된 소프트웨어 모듈 "Avtokassa"를 개발합니다. 데이터베이스에는 항공편 번호, 경로, 운전자, 버스 유형, 출발 날짜 및 시간, 티켓 가격에 대한 정보가 포함되어야 합니다. 항공권 신청이 접수되면 프로그램은 적합한 항공편을 검색합니다.

14. 책에 대한 정보(저자, 제목, 출판사, 출판 연도, 가격)가 포함된 "서점" 소프트웨어 모듈을 개발합니다. 구매자는 필요한 책에 대한 요청을 작성합니다. 책이 없으면 데이터베이스에 입력되고 필요한 책이 상점에 도착하면 알림을 받습니다.

15. 소프트웨어 모듈 “Car Parking”을 개발합니다. 이 프로그램에는 자동차 제조사, 소유자, 진입 날짜 및 시간, 주차 비용, 할인, 미결제 금액 등에 대한 정보가 포함되어 있습니다.

참조 조건은 정보 시스템이나 기타 제품을 만들기 위한 소스 자료입니다. 따라서 기술 사양(TK로 약칭)에는 우선 제품에 대한 기본 기술 요구 사항이 포함되어야 하며 이 시스템이 수행해야 하는 작업, 작동 방법 및 조건에 대한 질문에 답해야 합니다.

일반적으로 기술 사양 작성 단계에 앞서 주제 영역에 대한 조사를 실시하고 분석 보고서를 작성하는 것으로 끝납니다. 위임사항 문서의 기초를 형성하는 것은 분석 보고서(또는 분석 메모)입니다.

보고서가 고객의 요구 사항을 일반적인 용어로 제시하고 이를 UML 다이어그램으로 설명할 수 있다면 기술 사양에는 시스템의 모든 기능 및 사용자 요구 사항을 자세히 설명해야 합니다. 기술 사양이 상세할수록 승인 테스트 중에 고객과 개발자 사이에 논란이 되는 상황이 줄어들 것입니다.

따라서 기술 사양은 개발자와 고객 모두가 최종 제품을 제시하고 이후 요구 사항 준수 여부를 확인할 수 있는 문서입니다.

기술 사양 작성을 위한 지침 표준은 GOST 34.602.89 "자동화 시스템 생성을 위한 기술 사양" 및 GOST 19.201-78 "기술 사양"입니다. 콘텐츠와 디자인에 대한 요구사항입니다." 첫 번째 표준은 자동화 시스템 개발자를 위한 것이고, 두 번째 표준은 소프트웨어를 위한 것입니다(“GOST란 무엇입니까” 기사에서 이 시리즈 간의 차이점을 논의했습니다).

따라서 아래에는 GOST에 따라 기술 사양에 포함되어야 하는 섹션의 목록과 설명이 나와 있습니다.

따라서 기술 사양 문서는 실제로 자동화 개체에 대한 분석 연구 단계에서 식별된 설계된 제품에 대한 모든 요구 사항을 반영해야 합니다.

위 표를 바탕으로 기술 사양의 주요 섹션을 강조할 수 있습니다.

• 시스템(프로그램)에 관한 일반 정보
• 시스템(프로그램)의 목적, 목표 및 목표
• 시스템 요구 사항(기능 요구 사항, 사용자 요구 사항, 시스템 전체 요구 사항 등)
• 보안 유형에 대한 요구 사항
• 문서 요구 사항
• 개발 단계 및 단계
• 시스템(프로그램)의 제어 및 승인 절차.

일반 정보
기술 사양 문서의 이 섹션에는 시스템의 전체 이름과 문서 개발에 사용될 모든 약어가 포함되어야 합니다.

예:

“이 문서에서 생성되는 정보 시스템은 "교육 자원 액세스를 위한 단일 창"(EO로 약칭)이라고 합니다.
교육 자원 접근을 위한 단일 창구 시스템은 이 문서의 뒷부분에서 단일 창구 또는 시스템으로 지칭될 수 있습니다.

또한 여기에는 개발에 관련된 조직(고객 및 계약자)의 세부 정보를 제공하는 하위 섹션을 포함해야 합니다.

기술 사양 문서의 "개발 기반" 하위 섹션에는 이 작업을 수행하는 데 기초가 되는 주요 문서가 나열되어 있습니다. 예를 들어, 한 국가의 정부나 다른 정부 기관이 위임한 시스템의 경우 정부의 법률, 법령 및 규정이 지정되어야 합니다.

기술 사양 문서의 필수 부분에는 용어 및 약어 목록도 포함되어야 합니다. "용어"와 "전체 형식"이라는 두 개의 열이 있는 표 형식으로 용어와 약어를 표시하는 것이 좋습니다.

용어 및 약어는 알파벳순으로 정렬됩니다. 우선, 러시아어 용어와 약어를 해독한 다음 영어 용어를 해독하는 것이 일반적입니다.

시스템 구축의 목적과 목표

기술 사양 문서의 이 섹션에는 시스템 생성의 목적과 목표가 포함되어야 합니다.

예:

"정보 시스템 "교육 자원에 대한 단일 액세스 창"은 사용자에게 러시아 연방 교육 시스템 및 교육 기관 기능을 수행하는 조직에 관한 완전하고 신속하며 편리한 정보를 제공하도록 설계되었습니다.

시스템의 주요 목표는 통합된 정보 환경을 구축하고 러시아 연방 교육 기관의 비즈니스 프로세스를 자동화하는 것입니다.

단일 창 정보 시스템의 생성은 다음을 보장해야 합니다.

• 사용자에게 광범위한 정보 자원을 제공합니다.
• 정보 보안 수준 향상;
• 다양한 비즈니스 프로세스를 최적화하여 교육 기관 및 부서의 효율성을 높입니다.
• 부서 내 정보 시스템과 서비스 간의 상호 작용 프로세스의 효율성을 높입니다.

시스템 구축으로 부서 효율성이 향상되어 운영 비용이 절감될 것입니다.”

시스템 요구사항

기술 사양 문서의 이 섹션은 시스템의 기본 기능 요구 사항을 설명하기 위한 것입니다. 이는 기술 사양에서 가장 중요한 부분입니다. 시스템을 가동하는 과정에서 고객과의 분쟁에서 주요 논거가 되기 때문입니다. 그러므로 글쓰기에 매우 신중하게 접근할 필요가 있다.

참조 약관 문서에는 자동화 개체 분석 단계에서 식별된 모든 요구 사항이 포함되어야 합니다. 기능 요구사항 설명을 통해 공개해야 하는 주요 비즈니스 프로세스를 강조하는 것이 가장 좋습니다.

예:

“4.1 비즈니스 프로세스”러시아 연방 교육 기관에 대한 정보 제공

이 비즈니스 프로세스에서 다음 참가자가 식별됩니다.

중재자 – 제공된 데이터의 정확성을 담당하는 시스템 유지 관리 직원의 일부인 부서 직원

사용자는 러시아 연방 교육 기관의 업무에 대한 정보를 받아야 하는 시민입니다.

4.1.1 시스템에 교육기관 등록

러시아 연방 교육 기관의 등록은 해당 기관의 담당 직원이 수행합니다(“정부 법령 ...”).

교육 기관을 등록하는 과정은 다음 단계로 구성됩니다.

• 작성자는 조직에 대한 기록을 작성합니다.
• 작성자는 조직의 데이터를 입력합니다.
• 시스템은 특정 조직의 라이선스를 확인합니다.

• 라이센스가 데이터베이스에 존재하는 경우 시스템은 성공적인 등록에 대한 메시지를 작성자에게 보냅니다.
• 데이터베이스에서 라이선스를 찾을 수 없으면 시스템은 이 조직에 대한 라이선스가 없다는 메시지를 작성자에게 보냅니다.

시간이 허락한다면 이 섹션에 제공된 정보는 참조 약관 문서의 부록에 더 자세히 공개되어야 합니다. 기술 사양의 부록에서는 화면 형식을 제공할 수 있으며 아래에서는 화면에 나타나는 모든 이벤트(생성, 보기, 편집, 삭제 등)를 설명합니다.

시스템 전체에 대한 요구 사항에는 모든 하위 시스템에 대한 설명과 함께 아키텍처 공개가 포함됩니다. 참조 약관의 이 부분에서는 시스템을 다른 제품(있는 경우)과 통합하기 위한 요구 사항을 설명해야 합니다. 또한, 참조 조건에는 다음이 포함되어야 합니다.

• 시스템 작동 모드 요구 사항
• 목적지 표시기
• 신뢰성 요구 사항
• 안전 요구 사항
• 직원의 수와 자격 및 작업 일정에 대한 요구 사항
• 정보 보호 요구 사항
• 사고 발생 시 정보의 안전을 위한 요구사항
• 특허 허가 요건
• 표준화와 통일을 위한 요구사항
• 등.

담보 유형에 대한 요구 사항

기술 사양 문서의 이 섹션에는 수학, 정보, 언어, 소프트웨어, 기술 및 기타 유형의 지원(있는 경우)에 대한 요구 사항이 포함되어야 합니다.

문서 요구 사항

기술 사양의 "문서 요구 사항" 섹션에는 고객에게 제공해야 하는 설계 및 운영 문서 목록이 포함되어 있습니다.

기술 사양의 이 섹션은 기능 요구 사항에 대한 설명만큼 중요하므로 "고객에게 GOST 34에 따라 모든 문서를 제공해야 합니다."라는 문구로 제한해서는 안 됩니다. 이는 “양식”, “여권” 등을 포함한 전체 서류 패키지를 제공해야 함을 의미합니다. GOST 34.201-89에 지정된 목록의 문서 대부분은 귀하나 고객 모두에게 필요하지 않으므로 기술 사양 문서 개발 단계에서 목록에 즉시 동의하는 것이 좋습니다.

최소 문서 패키지에는 일반적으로 다음이 포함됩니다.

• 기술 사양
• 예비(기술) 설계 명세서
• 기술 설계에 대한 설명
• 정보 기반의 조직에 대한 설명
• 사용자 가이드;
• 관리자 안내서;
• 테스트 프로그램 및 방법론
• 승인 테스트 보고서;
• 완료된 작업 증명서

기술 사양의 문서 목록을 문서 이름과 문서가 개발되어야 하는 표준을 나타내는 표 형식으로 제시하는 것이 좋습니다.

개발 단계 및 단계

위임 문서의 이 섹션은 수행해야 하는 모든 작업 단계에 대한 정보를 제공해야 합니다.

단계 설명에는 이름, 시기, 작업 설명 및 최종 결과가 포함되어야 합니다.

시스템 제어 및 승인 절차

기술 사양 문서의 이 섹션에서는 승인 테스트를 수행하는 기준이 되는 문서를 표시해야 합니다.

필요한 경우 기술 사양을 다른 섹션으로 보완하거나 부적절한 항목을 제거하여 줄일 수 있습니다.

기술 사양의 구조를 변경할 경우 충돌 상황을 피하기 위해 문서를 개발하기 전에 고객과 합의해야 합니다.

설계를 시작하기 전에 설계된 장치의 목적과 범위는 프로젝트 고객과 개발자 사이에서 결정되어야 하며 모든 기술적(전술적, 기술적) 특성이 완전히 합의되어야 합니다. 이를 위해 특별 문서가 개발 중입니다. 참조 조건이 장치 또는 시스템의 설계를 위해.

앞으로 개발자에게 기술 사양은 프로젝트 개발의 모든 단계를 안내하는 기본적이고 기본적인 문서입니다.

위임사항 개발은 매우 중요하고 책임감 있는 과정입니다. 이 개발 단계에서 발생한 실수는 매우 심각한 결과를 초래할 수 있습니다.

원칙적으로 기술 사양 개발은 고객 대표와 설계자가 공동으로 수행합니다. 기술 사양에는 개발자의 많은 박식과 경험이 필요합니다. 따라서 참조 조건은 이 분야에서 상당한 경험을 가진 최고의 자격을 갖춘 전문가가 작성합니다.

참조 조건은 개발의 주요 방향, 즉 미래 제품(장치, 시스템)의 설계 및 작동 원리를 결정합니다.

기술 사양은 작업의 초기 단계이며 신제품을 만드는 데 필요한 모든 개발 및 작업 유형을 위해 작성됩니다. 위임사항에는 섹션 중 하나로서 다음을 수행하는 것도 포함될 수 있습니다.

연구 작품,

개발작업,

자동화 장비, 개별 부품 및 시스템, 기술, 측정 장비, 제어 장비, 안전 장비 등의 개발

고객의 책임은 개발자에게 제품 개발을 위한 신뢰할 수 있는 초기 데이터를 제공하는 것입니다. 고객은 신제품 및 초기 데이터에 대한 요구 사항에 대한 책임이 있으며 제공된 정보의 정확성에 대한 전적인 책임을 집니다.

참조 조건에는 세 가지 주요 섹션이 포함되어야 합니다.

1. 소비자 속성과 사용 효율성을 결정하는 제품에 대한 기술 및 경제적 요구 사항,

2. 고객과 개발자의 공동 검토가 필요한 문서 목록,

3. 개발 결과 전달 및 승인 절차.

필요한 경우 기술 사양에는 생산 준비 및 개발에 대한 요구 사항도 포함될 수 있습니다.

기술 사양의 구체적인 내용은 고객과 개발자가 결정하며, 사전 개발의 경우 개발자가 결정합니다.

고객이 표준 요구 사항과 다르지만 개발 중인 제품에 대한 개별 요구 사항이 있지만 지정된 조건에서 제품 사용의 효율성을 저하시키지 않는 경우 러시아 연방 국가 표준의 의견을 얻어야 합니다. 이러한 제품을 개발하고 제조할 가능성이 있습니다.

안전, 건강 및 환경 보호를 감독하는 기관의 표준 및 규제 문서 요구 사항과 모순되는 참조 요구 사항을 포함하는 것은 허용되지 않습니다.

참조 사항에는 디자이너의 작업을 용이하게 하고 개발 시간을 단축하기 위해 가능한 한 많은 정보가 포함되어야 합니다.

위임사항의 품질은 개발에 필요한 자료 수집의 양과 완전성에 의해 보장됩니다. 개발에는 다음 재료가 사용됩니다.

과학기술정보,

특허정보,

판매시장의 특징,

제품이 제조될 생산 특성(기술 장비, 인력 자격, 노동 조직 수준 등).

위임사항은 원칙적으로 개발 중인 제품에 대해 다음과 같은 지표를 설정합니다.

기술 수준 및 품질에 대한 예측 지표,

주요 목적

판매시장의 특징,

기술 및 성능 특성,

표준화 및 통일 수준,

기술 및 경제 지표

특허 법적 지표,

제품 등에 대한 특별 요구사항

참조 조건은 고객과 개발자가 설정한 방식으로 개발되고 승인됩니다.

기술 사양의 개발 및 승인을 위한 일반적인 절차는 러시아 국가 표준 GOST 15.001-88에 의해 확립되었습니다.

위임 조건에는 개발 단계와 각 단계 완료 기한 및 전체 개발을 규정합니다.

기술 사양은 국가 표준 GOST 2.105-95에 따라 텍스트 디자인 문서의 일반 요구 사항에 따라 작성되었습니다.

표 1