고객의 사양은 무엇입니까? GOST에 따른 기술 사양

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

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

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

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

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

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

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

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

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

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

예:

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

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

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

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

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

시스템 구축의 목적과 목표

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

예:

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

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

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

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

시스템을 구축하면 부서의 효율성이 높아져 운영 비용이 절감될 것입니다.”

시스템 요구사항

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

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

예:

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

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

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

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

4.1.1 시스템에 교육기관 등록

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

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

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

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

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

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

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

담보 유형에 대한 요구 사항

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

문서 요구 사항

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

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

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

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

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

개발 단계 및 단계

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

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

시스템 제어 및 승인 절차

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

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

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

위임 조건 - 지정된 조치를 수행하거나 필요한 작업(서비스)을 수행하라는 상대방의 서면 명령입니다. 이와 별도로 이러한 문서는 일반적으로 사용되지 않습니다.

그러나 어떤 경우에는 그러한 작업이 권리와 의무의 출현에 대한 유일한 서면 확인입니다.

그러한 임무에 적용되는 규칙

해당 규칙(규칙)은 공개적으로 접근 가능한 장소에 게시되며 해당 조건을 수락하는 사람은 서비스 제공 및 기타 다양한 거래 옵션에 대해 공개 계약을 체결한 당사자로 간주됩니다.

다양한 문서는 고객이 계약자의 조건을 수락했다는 증거가 될 수 있습니다. 이는 현금 영수증, 계약자의 서비스에 대한 고객의 지불을 나타내는 지불 주문 및 기술 사양을 포함한 기타 서면 문서일 수 있습니다.

동시에 과제는 작업 생산에 대한 기본 규칙의 위치를 ​​명확하게 나타내야 하며, 그렇지 않으면 전체 내용을 명시할 수 있습니다.

이 법안은 기술 사양을 원격으로 결론짓는 것을 허용합니다. 이러한 가능성은 작업 실행(서비스 제공) 규칙에 자세히 명시되어야 합니다. 다양한 통신수단(이메일, 팩스 등)을 통해 대응이 가능합니다.

어떤 경우에도 당사자는 거래 체결의 결과와 특정 권리 및 의무의 출현을 명확하게 이해하고 인식해야 합니다. 당사자들의 계약(합의) 체결을 확인하기 위해 전자 디지털 서명 및 팩스 사용이 허용됩니다(거래 조건에 명시적으로 명시된 경우).

그러한 문서를 사용하는 다른 형태

일반적인 비즈니스에서 기술 사양은 주 계약의 필수 부속서이며 기술 사양이 없으면 유효하지 않습니다. 인터넷에는 기술 사양의 다양한 예가 있습니다.

어떤 옵션을 선택할지 명확하지 않기 때문에 그들의 다양성은 종종 잔인한 농담을 합니다. 우리는 이 문서를 작성하거나 샘플 기술 사양을 분석할 때 충족해야 하는 필수 조건을 고려하려고 노력할 것입니다. 인터넷에서 다운로드:

문서는 서면으로 작성되고 당사자 또는 권한을 부여받은 대리인이 서명합니다. 법인이 당사자인 경우 문서에 조직의 인장이 있어야 합니다. 과제에 서명하는 사람의 적절한 자격 증명에 주의를 기울여야 합니다. 대리인은 일반적으로 위임장을 가지고 있습니다. 법인은 간단한 서면 형식, 개인 - 공증 형식으로 위임장을 작성합니다. 위임장은 발행한 사람이 언제든지 취소할 수 있다는 점을 고려하여, 문서에 서명하기 전에 그 유효성을 확인해야 합니다.

과제에는 수행할 작업(서비스)에 대한 기술적 요구 사항이 자세히 명시되어 있습니다. 계약자의 지침은 주 계약 조건을 위반하지 않고 그 구현이 부정적인 결과를 초래하지 않는 한 고객에게 구속력을 갖습니다.

문서에는 준비 날짜와 작업 완료 기한이 표시됩니다. 작업 단계와 결과 수락 기한이 표시될 수 있습니다. 필요한 경우 실행 책임자가 문서에 명시되어 있습니다. 이 작업에는 당사자의 세부 정보도 포함될 수 있습니다.

필요한 경우 기술사양에 원본 및 사본 등 다양한 문서를 첨부할 수 있습니다. 준공 문서는 기술 사양의 사본 수와 동일한 수의 사본으로 생성됩니다. 거래의 각 당사자는 모든 첨부 파일과 함께 원본 기술 사양을 가질 권리가 있습니다.

아래는 기술 사양 중 하나입니다. 당사 웹사이트의 "문서 샘플" 섹션에서 다른 기술 사양 샘플을 찾을 수 있습니다. 사이트의 "질문과 답변" 섹션에서 이 주제에 대한 법률 문서를 읽어보세요. 새로운 권리와 의무를 적절하게 등록하는 것은 거래에 관련된 모든 당사자가 이를 이행하는 데 핵심입니다.

작업에 대한 참조 조건

저자로부터: 작성 방법 웹사이트 개발을 위한 참고 사항? 주제는 매우 광범위하며 (가능하다면) 하나의 기사 프레임워크 내에서 100% 분석하기가 어렵습니다. 그러나 이 기사에서는 일반 조항, 고려해야 할 사항, 기술 사양을 작성할 때 주의해야 할 사항에 대해 간략하게 설명하려고 노력할 것입니다.

그래서, TK

사이트 개발자를 위한 참조 조건이 준비되어 있습니다. 고객과 계약자 간의 계약을 체결할 때 기술 사양을 참조해야 합니다. 기술 사양의 사항 및 조건을 이행하지 않거나 부정확하게 이행하는 경우 양측 모두 책임을 명시해야 합니다. 하지만 (제 생각에는) 기술 사양이 작성되는 가장 중요한 것은 웹 사이트 개발 프로세스 속도 향상.

이 예를 분석해 보겠습니다.

웹 사이트 어딘가에 달력이 필요하다고 가정해 보겠습니다. 그것은 작은 일처럼 보였습니다.

하지만 이 달력의 기능을 자세히 설명할수록 결과를 더 빨리 얻을 수 있습니다.

여기서 조금 설명하겠습니다. 달력은 달력과 다릅니다. 이번 달의 요일별 숫자를 간단하게 보여주는 달력이 있습니다. 달을 넘겨볼 수 있는 달력이 있습니다. 월과 연도를 넘겨볼 수 있는 달력이 있습니다.

우리는 무엇을 가지고 있습니까? 계약자는 기술 요구 사항을 충족했지만 완전히 다른 달력을 원했습니다. 모든 것이 기술 사양에 부합하는 것 같습니다. 누구도 비난할 수 없으며 갈등도 없지만 가장 중요한 것이 손실되었습니다. 시간과 돈.

이것은 평범한 달력의 예입니다.

달력의 경우처럼 더 심각한 작업을 다시 실행해야 하고 처리하는 데 반나절 이상이 소요된다면 어떻게 될까요? 그리고 당신은 웹사이트가 없고 고객이 당신의 프로젝트를 완료하고 새로운 프로젝트를 시작할 수 있음에도 불구하고 당신과 장난을 치고 있습니다.

그러므로 보다 자세한 내용각 사이트 모듈의 기능을 설명할수록 결과를 더 빨리 얻을 수 있습니다. 양측 모두 이에 관심을 가져야 합니다.

기술 사양은 일반적으로 어떤 항목으로 구성됩니까?

당신이 회사 또는 회사의 소유자라고 상상해 봅시다. 귀하의 회사는 모든 제품의 생산 및 판매에 참여하고 있습니다. 구매자가 있습니다. 판매자(상점 및 온라인 상점), 서비스 센터, 제품 소비자와 협력합니다. 아니면 그런 회사의 웹사이트를 만들고 있는데 기술 사양을 작성해야 합니다.

어떤 역할을 수행하든 관계없이 가장 먼저 해야 할 일은 조직의 구조, 수행하는 작업, 명명법, 특성 및 일반적으로 제품 및 회사와 관련된 모든 것을 연구하는 것입니다.

사이트에서 일어날 일은 고객이 기업에서 일어나는 일의 본질을 얼마나 깊이 이해하는지에 달려 있습니다. 따라서 여기서의 임무는 상호적입니다. 고객은 기업에 대해 가능한 한 자세히 설명해야 하며 계약자는 현재 일어나고 있는 일의 본질을 철저히 이해해야 합니다.

웹사이트를 만들 회사의 기술 사양을 직접 작성하는 경우에도 종이 한 장에 모든 내용을 파악하는 것이 좋습니다.

한 점씩 살펴보겠습니다.

사이트 설명

여기에서 회사와 회사가 하는 일에 대해 몇 문장으로 작성할 수 있습니다.:

• 소개 같은 것을 하세요.
• 누구를 위한 것인가 - 사이트의 타겟 고객
• 잠재적 구매자
• 제품 판매자(상점, 온라인 상점)
• 서비스 센터

파트너(기업):

• 제품 소비자(이미 구매한 사람)
• 웹사이트가 왜 필요한가요?
• 회사의 이미지를 향상시키기 위해

매출 증대를 위해:

• 고객의 편의를 위해
• 사이트 유형
• 기업

웹사이트 – 명함:

• 온라인 상점
• 언어 버전

영어

러시아인

사이트는 몇 가지 문제를 해결해야 합니다. 따라서 우리는 사이트의 목표와 목적을 더욱 발전시킵니다.

사이트의 목표와 목적.

기술 사양의 이 섹션에서는 전체 대상 고객을 살펴보고 사이트가 그들을 위해 해결해야 하는 작업 범위를 설명합니다.잠재적인 제품 구매자

문제를 해결해야합니다:

제품, 부가 서비스, 보증, 서비스 및 선택 방법에 대한 고품질의 포괄적인 정보를 제공합니다.

• 전시실 정보 제공
• 소매 네트워크에 대한 정보 제공

제품 선택 및 구매 문제에 대해 회사 전문가가 잠재 구매자의 온라인 상담을 구성하여 질문할 수 있는 기회를 제공합니다.

따라서 우리는 전체 대상 고객을 살펴 봅니다. 저희 홈페이지를 팔로우하시면 제품판매자(매장, 온라인스토어), 서비스센터, 파트너(기업), 제품소비자에 대한 목표와 목적을 설명하고 있습니다. 즉, 사이트가 각 사이트에 대해 구체적으로 수행해야 하는 작업입니다.

이제 사이트 모듈을 나열합니다.

사이트 기능

사이트의 기능을 나열하려면 필요한 사항을 결정해야 합니다.

• 사이트에 대한 뉴스가 필요합니까?
• 광고 블록이 필요합니까?
• 등록이 필요합니까?
• 사이트의 폐쇄된 섹션이 필요한가요?(등록된 사용자에게만 해당)
• 피드백 양식이 필요합니까?
• 메일링 스크립트가 필요합니까?
• 등. 등.

이 모든 것을 설명하고 나면 가장 중요하고 흥미로운 사실에 도달하게 됩니다. 물론 위에서 행한 모든 작업은 매우 중요하지만 지금은 더욱 더 뜨거워지고 있습니다.

사이트 기능 설명

현재 우리는 사이트가 누구를 위한 것인지, 어떤 목표와 목표를 달성해야 하는지, 그리고 추가 기능을 알고 있습니다.

수집된 모든 정보를 시스템으로 가져와 웹사이트에 아름답게 담아야 할 때가 왔습니다. 작업을 더 쉽게 만들고 수레바퀴를 재발명하지 않으려면 유사한 주제에 대한 사이트를 살펴보세요. 그들로부터 무엇인가 배우고, 그 기능을 살펴보고 시험해 보고, 귀하의 웹사이트에서 불편해 보이는 부분을 개선하려고 노력하십시오. 원칙적으로 기술 사양 작성 초기부터 유사한 주제에 대한 사이트를 볼 수 있습니다(경험이 없으면 경험이 필요함).

메뉴 항목부터 시작하는 것이 좋습니다. 사이트의 기본 페이지를 표시하고 각 방문자가 스스로 정보를 빠르게 찾을 수 있도록 해야 합니다. 그리고 방문자는 우리의 타겟 고객입니다.

메뉴에는 많은 항목이 포함되므로 드롭다운 목록 형식으로 표시됩니다.

먼저 회사에 대해 알려주셔야 합니다. 회사, 회사 연혁, 연락처, 리뷰에 대한 페이지가 있을 수 있습니다.

당연히 "제품" 메뉴 항목과 "제품 카탈로그", "릴리스", "제품 리뷰" 하위 항목이 있어야 합니다.

일반적으로 설명하는 방법이 명확하기를 바랍니다. 우리 웹사이트에 가능한 메뉴의 최종 버전을 제시하겠습니다.

• 회사 소개
• 회사 연혁
• 콘택트 렌즈

리뷰

• 이벤트
• 재고
• 사이트의 새로운

제품

• 제품 카탈로그
• 릴리스
• 제품 리뷰

서비스

• 서비스 부서
• 보증 서비스
• 보증 후 서비스

소비자에게

• 구매 및 배송
• 사용
• 서비스에 대해

상점 및 온라인 상점

• 제품 사진
• 자주 묻는 질문

서비스 센터

• 서비스센터가 되는 방법
• 자주 묻는 질문

파트너용

• 협력에의 초대
• 자주 묻는 질문

메뉴를 정리한 것 같습니다. 이제 각 페이지에 무엇이 포함될지, 그리고 그것이 어떻게 작동하는지 설명해야 합니다. 또한 사이트의 대략적인 레이아웃을 제공합니다. 연필로 종이에 그려서 스캔하여 작업 명세서에 첨부할 수 있습니다. 제가 말씀드릴 유일한 것은 디자이너의 상상력을 제한하지 말고 가장 일반적인 형태로 스케치하라는 것입니다.

이 부분은 페이지 모양을 원하는 방식에 따라 변경됩니다. 상단에 너무 많은 배너가 필요하지 않을 수도 있고, "사이트 맵", "집", "연락처" 아이콘 형식으로 상단에 연락처(주소, 전화, 팩스)를 표시해야 할 수도 있습니다. 왼쪽에는 뉴스가 필요하지 않지만 왼쪽에는 "프로모션 및 릴리스"가 표시될 수도 있습니다.

이제 가장 중요한 것은 작업의 논리를 설명하는 것입니다.

작동 논리

위 사진을 기준으로 설명하겠습니다.

사이트 상단은 사이트의 모든 페이지에서 동일하게 유지됩니다. 뉴스피드는 메인 페이지에만 표시됩니다. 왼쪽의 보조 페이지에는 현재 있는 항목의 메뉴 하위 항목이 표시됩니다. 예를 들어 "고객 서비스" 페이지에 있는 경우 "보증 서비스", "보증 후 서비스"에 대한 링크가 표시됩니다. "). 따라서 이러한 링크를 클릭하면 해당 페이지로 연결됩니다. 여기서 왼쪽 하위 항목 아래에는 온라인 컨설턴트(Skype, ICQ)에게 연락하기 위한 데이터가 표시됩니다. 프로모션 및 릴리스 블록은 각 페이지에 남아 있습니다. 사이트 바닥글은 모든 페이지에 동일하게 표시됩니다.

이것은 대략적인 작업 논리가 설명되는 방식입니다.

이제 각 블록에 대해 자세히 설명하겠습니다. 예를 들어 '뉴스피드'입니다.

최신 10개 뉴스의 "뉴스피드"입니다. 각 뉴스는 뉴스 제목, 발행일, 뉴스의 간략한 시작 부분(4~5줄) 및 "전체 읽기" 링크로 구성되어야 합니다. "전체 읽기" 링크를 클릭하면 뉴스 페이지로 이동됩니다. 귀하가 접한 뉴스가 주요 콘텐츠 대신 표시됩니다. 또한 뉴스 제목과 발행 날짜도 포함됩니다. 뉴스피드도 왼쪽에 표시됩니다.

지난 몇 달, 몇 년 동안의 뉴스가 보관됩니다. 즉, 당월 뉴스 아래에 "(해당 월 또는 연도)에 대한 아카이브"가 표시됩니다. "(해당 월 또는 연도)에 대한 보관" 링크를 클릭하면 해당 월/연도에 대한 뉴스 목록이 드롭다운됩니다.이것이 각 블록의 동작을 설명하는 방법입니다. 달력 사건을 잊지 말자.

그리고 가장 중요한 것은 제품 카탈로그의 작업을 설명해야 한다는 것입니다.

여기서 내가 당신에게 임무를 하나 주겠다.

: 디렉터리가 어떻게 작동할지 곰곰이 생각해 보고 설명해보세요. 옵션을 이메일로 보내주세요. 우리는 최고의 것을 출판할 것입니다.

또 무엇이 있어야 합니까? 호환성을 나타내는 것이 좋을 것입니다.

호환성

이 시점에서 우리는 어떤 운영 체제와 어떤 브라우저에서 사이트가 똑같이 좋아 보여야 하는지를 나타냅니다. 어떤 버전으로, 어떤 언어로 작성해야 할까요? 어떤 CMS가 사용됩니까? 당신이 실제로 무슨 말을 하는지 알고 있다면 이 점을 지적할 가치가 있습니다.

이러한 질문을 모르는 경우 사이트가 올바르게 표시되어야 하는 브라우저를 표시하십시오. 나머지는 공연자의 양심에 의지하세요.

결론

• 그리고 그 일을 잊지 마세요!

기민한

그들이 말했듯이 - "천 단어 대신", 이 주제에 대해 Skype에서 4-5시간 동안 복음을 전할 때마다 이미 지루해지고 있으며 "기술 사양"의 정의에 노골적으로 말도 안 되는 말을 집어넣는 세계적인 경향이 점점 더 심해지고 있기 때문입니다. 수년에 걸쳐.

문제

사실은 용어에 대한 명확하고 이해하기 쉬운 정의뿐만 아니라 특정 형식이 있을 때 모든 조작 및 대체가 자신의 브리핑, 프로토타입, 즉석에서 발명된 설문지, 설명 및 단순히 들어오는 응용 프로그램으로 보인다는 것입니다. 적어도 비전문적입니다. 따라서 우리는 개념에 대한 과학적 정의부터 시작합니다.

참조 조건 - 기술 개체(제품) 설계에 대한 원본 문서입니다. 기술 사양은 개발 중인 객체의 주요 목적, 기술적 특성, 품질 지표 및 기술 및 경제적 요구 사항, 문서 작성(디자인, 기술, 소프트웨어 등)에 필요한 단계를 완료하기 위한 지침 및 구성을 설정합니다. 특별한 요구 사항으로. 기술 사양은 법적 문서입니다. 응용 프로그램은 설계 작업을 위한 고객과 계약자 간의 계약에 포함되어 있으며 그 기반이 됩니다. 이는 목적, 목표, 원칙, 예상 결과 및 마감일을 포함하여 작업 절차 및 조건을 결정합니다. . 즉, 특정 작업 항목이 완료되었는지 여부를 판단할 수 있는 객관적인 기준이 있어야 합니다. 기술 사양 문구의 모든 변경, 추가 및 설명은 고객과 합의하고 승인을 받아야 합니다. 이는 설계 문제를 해결하는 과정에서 초기 데이터의 부정확성이나 오류가 발견될 경우 개발에 참여한 각 당사자의 유죄 정도와 이와 관련하여 발생한 손실의 분배를 판단하는 것이 필요하기 때문에 필요합니다. 이것으로. 위임사항은 정보 기술 분야의 용어로서 수행자가 소프트웨어 제품, 정보 시스템, 웹 사이트, 포털 또는 기타 IT 서비스를 개발, 구현 또는 통합하는 작업을 설정하는 데 필요한 포괄적인 정보를 포함하는 법적으로 중요한 문서입니다.

이해할 수 있는 언어로 번역

1) 기술과제 - 과제를 설정합니다. 이는 프로토타입, 스케치, 테스트, 디자인 프로젝트보다 먼저 와야 한다는 것을 의미합니다. 마인드맵, 데이터 흐름 다이어그램, 아키텍처는 이미 특정 작업의 완료이기 때문에 이것이 질문에 대한 답입니다. 그리고 질문 자체가 아직 모든 당사자에 의해 요청, 공식화 및 서명되지 않은 경우 모든 답변은 선험적으로 부정확할 것입니다. 그렇죠? 따라서 모든 프로젝트에 대한 작업의 시작은 문제를 공식화하는 것이며 문제 해결을 위한 12가지 옵션의 스케치를 열광적으로 검색하는 것이 아닙니다.

2) 실제로 새로운 내용은 논리적으로 첫 번째 지점부터 이어집니다. TK 자체의 텍스트는 "목표 및 목표" 장으로 시작해야 합니다. 이 장에서는 세계의 엔트로피를 높이려는 최근 시도가 추구하는 비즈니스 목표가 무엇인지 명확하게 설명합니다. . 어떤 문제도 해결하지 못하고, 아무것도 달성하지 못하며 "심심해서" 수행하는 목적 없는 작업은 공식적으로 기술 작업으로 간주되지 않으며 이제부터는 "보통 종이 조각"의 상태에 있습니다.

3) 제안된 디자인 컨셉이나 인터랙티브 프로토타입, 심지어 즉시 사용 가능한 웹사이트가 위의 비즈니스 문제를 해결하는지 어떻게 이해합니까? 더 이상 할 일이 없습니다. 다시 정의로 돌아가야 합니다. “결정합니다... 예상 결과와 기한을 결정합니다. 즉, 이 작업 또는 저 작업 항목이 완료되었는지 여부를 판단할 수 있는 객관적인 기준이 있어야 합니다.” 즉, 기술 사양은 루블, 초, 톤 킬로미터 또는 섭씨 온도로 명확하게 측정 가능한 지표 없이는 존재할 수 없습니다. 간략한 내용이나 프로토타입, 기타 터무니없는 종이일 수도 있지만 기술 과제는 아닙니다.

여기에서 우리는 이 TOR에 동일한 지표를 취하고 측정하고 당사자가 악수를 하거나 재작업을 위해 프로젝트를 보내는 "수락 및 평가 절차" 장이 있어야 한다는 결론을 내립니다.

4) 기술 과제는 반드시 고객의 전반적인 사업 계획, 사업 개발 전략 및 시장 부문 분석과 일치해야 합니다. 이 모든 것을 통해 올바른 목표를 설정하고 정확한 측정 기준을 도출할 수 있으며, 이는 완성된 정보 제품을 적절하게 수용하는 데 사용됩니다. 고객의 사업 계획이 없으면 기술 사양의 비전문적인 구현이 자동으로 보장됩니다.

아웃소싱 스튜디오가 비즈니스 목표와 측정 가능한 비즈니스 지표를 소유자보다 더 잘 알고 있습니까? 분명히 그렇지 않습니다. 이는 올바른 기술 사양을 계약업체의 고용 직원이 아닌 고객의 대표가 작성해야 함을 의미합니다. 수행자가 스스로 작업을 설정하고 이를 평가하는 방법을 생각해낸 다음, 결국 완료된 작업에 대해 스스로 최종 점수를 매기는 것은 터무니없는 일입니다. 이상적으로는 이러한 "아마추어 활동"이 존재해서는 안 되지만 실제로는 모든 곳에서 발생하는 일이므로 기술 과제는 프로젝트에 필요한 지원을 제공하지 않으며 본질적으로 허구의 문서인 경우가 너무 많습니다. 그러지 마세요.

5) 완성된 기술 사양을 수정할 때마다 비용이 발생합니다. 당사자 중 한 사람이 마음을 바꾸거나, 잠을 충분히 자지 못하거나, 갑자기 돈을 절약하기로 결정했다는 이유로 "프로젝트 구성"을 자유롭게 끝없이 편집할 수는 없습니다. 기술 사양의 각 변경에 대한 가격도 관련 장에 미리 명확하게 명시되어야 합니다.

그런데 이론적으로 페이지나 기능 목록에 대한 모든 디자인 편집이나 변경에는 명확한 가격이 있어야 하며, 이 비용은 변경하기 전에 미리 지불해야 합니다. 개인적으로 저는 승인된 기술 사양의 편집 비용을 전체 프로젝트 예산의 30%로 추정해야 한다고 제안하지만 그렇지 않은 경우도 있습니다.

참조 조건에는 개발을 위한 시기와 총 예산은 물론 기존의 모든 자원과 제한 사항 목록을 미리 표시해야 한다는 점을 언급할 가치가 있습니까? - 아니, 너무 뻔할 것 같아.

그래서: 우리는 무엇을 하고 있나요? 무엇을 위해? 우리가 한 일을 어떻게 이해할 수 있습니까? 각 피벗 비용은 얼마입니까? - 종이에 적힌 이 모든 질문에 대한 답은 가장 실패한 프로젝트도 끌어낼 수 있는 “만약의 총알”입니다.

보안 질문

1) 그렇다면 기술 사양 작성을 위한 공식 GOST도 있을 수 있을까요? - 네, 심지어 여러 개죠.

2) 기술 사양에는 필요한 페이지에 대한 설명, 버튼 수, 사용된 라이브러리, 지침 등에 대한 설명이 포함되어 있지 않습니까? - TOR 자체에는 없지만 이 모든 것을 부록에 넣을 수 있습니다. 물론 위에서 설명한 목표, 제한 사항 및 달성된 결과를 추가로 평가하는 방법으로 이 모든 것을 조정할 수 있습니다. 일반적인 캐릭터에 대한 설명까지 포함하여 최소한 모든 향후 콘텐츠를 게시하십시오. 그러나 작업에 대한 명확한 설명이 아니라 그 이후에 게시하십시오.

3) 그럼 그런 게 필요하지 않을까요? - 아마도 세상에 수천 명의 사람들이 태어날 때부터 눈이 멀고 잘 사는 것처럼 오늘날에는 수천 개의 사이트가 전혀 기술적 사양 없이 만들어지고 있을지도 모릅니다. 그러나 어디로 향하고 있는지 확인하고 의식적으로 결정을 내리고 얻은 결과를 독립적으로 평가하려면 기술 사양 없이는 할 수 없습니다.

4) 따라서 귀하와 Wikipedia는 기술 사양이 고객에 의해 작성되었다고 작성합니다. 그런데 어떻게 해야 할지 모르겠어요/시간이 없어요/그냥 혼자서 하고 싶지 않아요. 어떻게 이런 일이 있을 수 있나요? - 기술 사양 개발을 귀하의 비즈니스, 작업, 대상 고객 및 요구 사항에 완전히 익숙하고 동시에 웹 개발의 모든 단계에 대해 철저하게 지식을 갖춘 제3자에게 아웃소싱합니다. 이 제3자는 일종의 "웹 공증인"이 될 것입니다. 즉, 계약자가 필요한 지표를 과소평가하지 않거나 마감 기한을 지연하지 않을 것이며 고객이 달성 가능한 지표를 설정하고 최종 승인 시 그렇지 않을 것이라는 보증인이 될 것입니다. 생성된 제품을 주관적으로 평가하고 이전에 기록된 요구 사항을 즉석에서 변경합니다.

5) 그리고 기술 사양이 법적 문서인 경우 아웃소싱 업체에게 비용을 지불하지 않고 소송을 제기하여 모든 것을 10번째로 다시 실행하도록 강요할 수 있습니까? - 문서가 올바르게 작성되면 성취도를 평가하기 위한 목표와 방법론이 표시됩니다. 문서에 당사자가 서명하고 계약에 언급된 경우(위탁 약관 자체는 계약이 아님) 물론 가능합니다. 그러나 일반적인 개요, 프로토타입, 예술 창작 레이아웃, FL의 안전한 거래로는 더 이상 그렇지 않습니다.

6) 작업이 일종의 스크럼이나 애자일을 사용하여 수행될 것이라고 말합니다. 이는 더 이상 구식 기술 사양이 필요하지 않음을 의미합니다. 그렇습니까? - 스스로 판단하십시오. 그들은 당신을 명확하게 가리는 이해할 수 없는 단어라고 부르고 이제 익숙하지 않은 용어를 기반으로 목표와 지표로 가득 찬 법적으로 유능한 문서를 포기하겠다고 제안합니다. Agile 자체에서는 "연말까지 최소 10,000 방문 달성", "한 달 안에 사이트에서 25건 이상의 주문 달성"과 같은 목표를 세울 수 없습니다. 부주의한 직원들로 구성된 새로운 조직. 여러 번 생각해보세요: "그들이 당신의 눈에 먼지를 던지고 있지 않습니까?" 실제로 전문적인 기술 사양은 새로운 스크럼에 해를 끼칠 수는 없지만 확실히 도움이 됩니다.

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

이 섹션에서는 기술 사양 개발(이하 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의 내용에는 항상 특정 요구 사항의 만족과 연결되는 특정 요구 사항을 구현하는 기능의 목표 및 성능에 관한 정보가 포함되어야 합니다.

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

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

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

다음은 다양한 소스의 기술 사양 구조에 대한 예입니다.

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

기술 사양의 주제;

수행되는 작업의 목표;

보고 요구 사항;

작업 조직 절차;

위 GOST 19.201-78의 예입니다.

소개;

개발 이유;

개발 목적;

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

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

기술 및 경제 지표;

개발 단계 및 단계;

통제 및 승인 절차;

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

일반 조항;

업무 목적;

후보자의 자격 요건.

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

연구 수행의 기초

출연자와 공동 출연자

1. 연구 과제

   소스 데이터

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

   연구 일정

   연구결과의 활용 목적

   연구결과 전달 및 승인 절차

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

작업의 기초

집행자

작업 타이밍

작업의 목적

연구개발 성과

개발 중인 제품

기술 요구 사항

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

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

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

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

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

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

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

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

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

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

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

인증 요구 사항

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

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

문서 요구 사항

작업 수락 절차.

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

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

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

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

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

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

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

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

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

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

1. 프로젝트 설명

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

3. 타이밍 매개변수

4. 기술적인 매개변수

5.생산 매개변수

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

9. 표준 및 규정

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

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

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

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

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

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

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

본질적으로 기술 사양과 이벤트 계획은 혁신적인 프로젝트 개발의 기초입니다.