인생에서는 일상적인 일에서도 자신이 원하는 것을 설명할 수 없는 경우가 종종 있습니다. 당신의 "원하는 것"을 프로그래머에게 설명할 때, 사람은 단순히 무감각해진다.

이상적으로는 고객이 기술 사양을 작성해야 합니다. 고객만이 자신에게 필요한 것이 무엇인지 알고 있습니다. 그러나 실제로는 1C 분야에서 고객의 역량이 낮기 때문에 계약자가 이를 수행해야 하는 경우가 많습니다. 고객은 자신의 요구 사항을 구두로 표현하고 프로그래머(컨설턴트)는 이를 서면으로 작성합니다.

기술 사양이 필요한 이유는 무엇입니까?

이상적으로는 기술 사양을 동반해야 합니다. 이는 첫째, 작업, 마감일 및 구현 방법에 대한 명확한 정의입니다. 둘째, 이는 향후 논란이 되는 모든 문제를 해결하는 데 도움이 되는 문서입니다. 기술 사양을 작성할지 여부는 물론 귀하의 비즈니스이며, 개인적으로 기술 사양은 작업과 고객과의 의사 소통을 더 쉽게 만듭니다.

1C에서 267개의 비디오 강의를 무료로 받으세요:

위임사항에는 어떤 내용이 포함되어야 합니까?

저것들. 과제에는 다음이 포함되어야 합니다.

• 표적— 이 사양을 구현하여 해결할 문제;
• 설명— 향후 개선 사항 요약
• 구현 방법 — 상세 설명목표를 해결하기 위한 방법. 이 시점에서는 작업의 모든 뉘앙스를 프로그래머의 언어로 설명해야 합니다. 즉, 어떤 종류의 작업을 생성/편집하고 있는지, 인터페이스는 어떤 모습이어야 하는지 등을 설명해야 합니다. "프로그래머 언어"를 말하지 않지만 "뭔가 들어본 적이 있는" 경우에는 기술 언어로 작성하지 않는 것이 좋습니다. 꽤 재미있을 것입니다. 설명은 명확해야 하며 질문을 제기해서는 안 됩니다. 또한 다른 영역에서 유사한 솔루션을 구현하는 예가 포함될 수도 있습니다.
• 성과평가- 매우 중요한 점, 인건비에 대한 설명입니다.

기술 사양 작성에 대한 국가 표준인 GOST도 있습니다. 실제로는 거의 사용되지 않지만 고객이 고집하는 경우도 있습니다.

경험상, 작업을 맡길 때 “그때 우리가 말했잖아…” 같은 상황이 자주 발생하는데, 그게 별로 유쾌하지 않고, 전체 작업을 다시 해야 하는 경우도 많습니다. 따라서 잘 작성된 기술 사양은 양측 모두의 삶을 훨씬 쉽게 만듭니다.

1C 기술 사양의 예 및 샘플

인터넷에서 무료로 사용할 수 있는 작은 선택 항목입니다. 가장 간단하고 접근하기 쉬운 문서부터 시작해 매우 복잡한 문서까지.

우리 전문가들이 고객의 작성을 도왔습니다. 환기 시스템 현대화를 위한 기술 사양.

자세한 내용은 컷 아래에서..

기술적인 업무

실험실 건물 No. 451,452, 건물 17의 환기 시스템 기술 장비 현대화를 위해 주소 : 모스크바

1. 일반 조항

1.1. 이 기술 과제는 건물 17의 실험실 번호 451,452인 건물의 환기 장치 자동화, 제어 시스템 및 기술 장비의 현대화에 대한 작업 구현을 제공합니다.

1.2. 작업을 수행하려면 AOB, EM, XS, AHS, AK 브랜드 섹션에 대한 작업 문서를 개발해야 하며 이는 확립된 절차에 따라 합의되어야 합니다.

1.3. 규제 및 기술 문서의 요구 사항을 준수하여 작업을 수행합니다.

1.4. 작업이 완료되면 GOST 및 SNiP의 요구 사항에 따라 작성된 실제 문서를 제시하십시오.

1.5. 완성된 작업물을 고객에게 넘겨주세요.

1.6. 본 기술 사양의 특정 조항은 고객과의 합의를 통해 작업 과정에서 명확해질 수 있습니다.

2. 기술적 요구사항

2.1. 환기 장치용 열 및 냉각 제어 장치의 현대화.

2.1.1. 열 공급 제어 장치.

다음은 현대화 대상입니다.

· MIK-V 건물의 환기 장치 K1, K2, K2a, K4, 실험실 No. 452의 P2, P6, 실험실 P1의 첫 번째 난방을 위한 열 공급 제어 장치.

· MIK-V 건물 환기 장치 K1, K2, K2a의 2차 난방을 위한 열 공급 제어 장치.

기존 열공급 조절장치는 해체 대상이 되며, 상태에 해당하는 조절장치(순환펌프, 차단밸브) 일부 설비 및 기술 사양, 장착된 제어 장치에 사용됩니다.

설치된 제어 장치의 장비 구성과 사용되는 장비는 부록 1에 나와 있습니다.

수압 시험 보고서를 실행하여 환기 장치의 난방 회로 및 히터에 대한 수압 시험을 수행합니다.

배관 도장 및 단열 작업을 수행합니다.

2.1.2 환기 장치의 냉기 공급을 조절하는 장치.

MIK-V 건물의 환기 장치 K1, K2, K2a, K4, 실험실 "452"의 P2, P6, 실험실 번호 451의 P1의 냉동 장치는 현대화 대상입니다.

업무 범위:

· 냉동 제어 장치의 온도 조절 밸브 교체;

· 압축기 응축 장치 K1의 팬 분해/설치;

· 압축기 응축 장치 K1, K2의 필터 건조기 해체/설치;

· K4 환기 장치의 증발기 분해/설치;

· 불활성 가스 환경에서의 압력 테스트, 진공 청소, 프레온으로 냉동 회로 재충전;

· 파이프라인의 단열 복원.

2.1.3. 가습 회로용 공급 장치.

에어컨 K1, K2, K2a의 관개실 보충 장치에 냉수 정화 필터를 설치합니다.

2.2. 환기 장치용 제어 및 자동화 캐비닛.

환기 장치 K1, K2, K2a, K4, RU3, V1, V2, V3, V6, V7, V8, 건물 MIK-V, P2, P6, V1, V2, V3 실험실 No. 451, P1, V1 실험실용 제어 캐비닛 451호는 452호 해체대상입니다.

새로 설치된 제어판의 레이아웃:

SHUA K1 – 에어컨 K1(MIK-V)의 환기 ​​장치 및 압축기 응축 장치(KKB)용 제어 및 자동화 캐비닛;

SHUA K2 – K2 에어컨(MIK-V)용 환기 장치 및 제어 장치용 제어 및 자동화 캐비닛;

SHUA K2 – 에어컨 K2a(MIK-V)용 환기 장치 및 제어 장치용 제어 및 자동화 캐비닛;

SHUA K4 – 에어컨 K4(MIK-V)용 환기 장치 및 제어 장치용 제어 및 자동화 캐비닛;

SHUV – 배기 장치 RU3, V1, V2, V3, V6, V7, V8(MIK-V)용 제어 캐비닛;

SHUA P2, P6 – 환기 장치 및 압축기 응축 장치 P2, P6용 제어 및 자동화 캐비닛(실험실 번호 452);

SHUV – 배기 장치 V1, V2, V3용 제어 캐비닛(실험실 번호 452);

SHUA P1,V1 – 환기 장치 P1, V1용 제어 및 자동화 캐비닛(실험실 번호 451).

현대화된 제어 캐비닛은 다음을 제공해야 합니다.

· 캐비닛 전면 패널에서 환기 장치 제어 모드(수동/자동)를 선택합니다.

· 환기 장치 공정 장비의 정상 및 비상 작동 모드에 대한 조명 신호(작동/비상);

· 화재 발생 시 환기 장치를 차단합니다.

· 비상 상황 발생 시 자동으로 보호 기능을 활성화하고 장비 작동을 차단합니다.

팬과 펌프의 전기 모터를 제어하기 위한 주파수 변환기는 향후 사용될 예정입니다.

2.3. 자동화 및 파견 시스템

자동화 및 파견 시스템은 환기 장치의 작동을 관리 및 모니터링하고 들어오는 정보를 수집, 처리, 제시 및 저장하도록 설계되었습니다.

2.3.1. 자동화 시스템.

자동화 시스템은 기본적으로 유지 관리 인력의 개입이 필요하지 않고 필요한 경우 수동 제어 모드로 전환할 필요가 없는 환기 장치의 자율 작동을 보장해야 합니다. 모든 제어 옵션과 로컬 컨트롤러의 상태에 관계없이 조건이 유지되어야 합니다. 자동 종료화재시 일반 환기 시스템. 결빙 방지 회로에 대한 전원 공급을 유지하면서 각 시스템에 대해 개별적으로 분리를 수행해야 합니다.

환기 시스템의 국소 자동화에는 다음이 포함되어야 합니다.

· 환기 장치 출구의 공급 공기 온도 조절 또는 필요한 경우 서비스 실에서 배출되는 공기 온도 조절

· 공급 공기 습도 조절;

· 화재 경보가 울릴 때 팬을 멈추고 공기 밸브를 닫습니다.

· 팬이 멈추면 에어컨 가습을 끕니다.

· 팬을 시동하고 정지할 때 공기 밸브가 각각 열리고 닫힙니다.

· 겨울 모드에서 시스템을 시작하기 전에 히터를 자동으로 가열합니다.

· 공기 및 온수기의 동결 방지(팬 끄기, 공기 댐퍼 닫기, 가열 밸브 100% 열기);

· 압력 강하가 없을 때 팬 정지;

· 설치 필터의 오염 제어.

자동화된 워크스테이션을 통한 로컬 자동화에 대한 원격 영향은 다음 볼륨에서 결정됩니다.

· 온도 및 습도 컨트롤러의 설정 변경;

· 설정을 활성화/비활성화합니다.

자동화 시스템의 기존 주변 장비는 다음 순서에 따라 검증, 청소 및 추가 사용이 적용됩니다.

· 환기 장치의 온도 및 습도 센서는 검증 대상입니다.

· 차압 스위치 센서를 점검하고 청소해야 합니다.

· 환기 장치의 히터가 동결되지 않도록 보호하기 위한 온도 조절 장치를 교체해야 합니다.

· 제어 장치의 제어 밸브 드라이브는 2.1.1항에 따라 교체해야 합니다.

· 공기 밸브 드라이브는 검사를 거쳐 추가로 사용할 수 있습니다.

K1 에어컨의 재순환을 제어하려면 온-오프 공기 밸브 드라이브를 제어 신호가 0..10V인 밸브로 교체하십시오.

2.3.2. 파견 시스템.

파견 시스템에는 다음 구성 요소가 포함되어야 합니다.

· Honeywell 소프트웨어 및 하드웨어를 기반으로 한 복잡한 측정 장치, 액추에이터 및 자동화 장비.

· 다기능 케이블 시스템;

· 파견 센터를 위한 소프트웨어 및 하드웨어의 복합체.

환기 시스템을 파견하려면 다음 정보를 표시, 보관 및 기록해야 합니다.

· 온도 및 습도 센서, 부동 온도 조절기, 차압 스위치, 제어 밸브, 가습기, 공기 밸브를 갖춘 설치의 그래픽 표현;

· 설치 번호;

· 온도 및 습도 센서 판독;

· 차압 릴레이 센서 판독값;

· 제어 밸브의 위치 판독값 0..100%;

· 팬 작동/정지 모드;

· 펌프의 작동/정지 모드;

· 공기 밸브의 위치 "열림/닫힘";

· 화재 경보가 발령되면 시스템을 정지시킵니다.

· 히터가 동결될 위험이 있는 경우 시스템을 정지합니다.

· 팬 전체에 압력 강하가 없으면 설치를 중단합니다.

· 에어컨 팬이 정지하면 가습기를 끄십시오.

· 주어진 시간 일정에 따라 또는 일정 없이 시스템을 운영합니다.

· 장비 오작동 및 기술 매개변수 값이 지정된 범위를 초과하는 경우 사고 및 긴급 상황 신호.

· 메시지 로그에 사고 및 긴급 상황 등록;

· 매개변수 등록 로그온 현재 시간제어되는 매개변수의 이름, 측정 단위, 컨트롤러 번호 및 입력/출력 채널을 나타냅니다.

2.3.3. 자동화 및 파견 시스템은 주전원에서 전원을 공급받아야 합니다. 교류전압 380/220V, 주파수 50Hz(소스 사용) 무정전 전원 공급 장치~에 배터리첫 번째 카테고리의 전기 수신기에 대한 전원 공급 장치로 제공됩니다.

사람들이 종종 기술 사양의 예를 요청한다는 사실 때문에 저는 제 작업 중 일부를 커뮤니티와 공유합니다. 이 문서는 상업적인 가치는 없지만(기간 및 구성으로 인해) 샘플로 유용하게 사용할 수 있기를 바랍니다.

기술적인 업무:

자동화됨

판매 시스템.

기술적인 업무

시트에

"_" ______________ 2010

1. 일반정보

자동화 시스템의 이름

"AS 스비트"

고객

집행자

작업의 기초

시스템 생성 작업 시작 및 종료 예정일

작업 시작: 2010년 9월 1일

작업 완료: 2010년 12월 31일

시스템 구축의 목적과 목표

시스템의 목적

개발 중인 자동화 시스템은 기업의 판매 프로세스를 자동화하도록 설계되었습니다.

시스템 구축 목표

자동화된 시스템을 만드는 목표

"AS Sbyt" 개발 목표는 다음과 같습니다.

1. 3. 자동화 개체의 특성

3.1 기업 비즈니스 프로세스

3.1. 1 업무프로세스 “계약체결”

3.1.2. 비즈니스 프로세스 "지불 계산"

1. 4. 시스템 요구 사항.

4.1. 시스템 전체에 대한 요구 사항.

4.1.1. AS에서 개발된 방법과 소프트웨어 모듈시스템을 더욱 발전시킬 수 있는 기회를 포함해야 합니다.

5.1.1. 개발된 시스템은 다음과 같이 구성되어야 합니다. 자동화 시스템, 금융 및 경제 등급의 자동화 시스템을 구축하기 위해 확립된 방법론에 따라 기능 목적에 따라 할당된 하위 시스템 및 회계 모듈.

5.1.2. 개발 중인 AS는 기존 회계 시스템에 따라 각 특정 수행자를 위한 자동화된 워크스테이션(AWS)을 쉽게 설정할 수 있도록 보장해야 합니다.

5.1.3. 개발 중인 AS는 사용자 액세스 권한의 차별화를 보장해야 하며, 각 수행자의 공식적인 직무를 수행하는 데 필요하고 충분한 범위 내에서 정보에 액세스할 수 있는 기능을 제공해야 합니다.

5.1.4. 무단 액세스로부터 정보를 보호하려면 다음 메커니즘을 사용하여 구현해야 합니다.

1. 1C:Enterprise 플랫폼 수준 8.1의 액세스 권한 제한.

2. 런타임 환경 수준에서 접근 권한에 대한 추가 제한 사항.

5.1.4.1.플랫폼 수준에서는 접근 권한 제한이 우선적으로 적용되어야 합니다. 런타임 수준에서 추가 제한을 제거해도 시스템 제한이 적용되는 경우 시스템의 개체나 기능에 대한 액세스 권한이 부여되지 않습니다.

5.1.4.2 플랫폼 수준의 정보 보호

· 플랫폼 수준의 정보보호가 보장됩니다. 시스템 수단. 동시에 시스템 개체를 읽고 편집하고, 인터페이스, 시스템 기능을 사용하고, 데이터를 사용하여 일상적인 작업을 수행하는 권한이 규제됩니다. 정보 시스템.

· 모든 액세스 권한은 적절한 세트(정보 시스템 역할)로 체계화되어야 합니다.

· 정보시스템 사용자 목록은 시스템 관리자가 결정해야 한다.

· 각 사용자의 액세스 권한은 해당 사용자에게 제공되는 정보 시스템 역할 세트에 따라 결정되어야 합니다.

· 각 사용자가 사용할 수 있는 정보 시스템 역할 집합은 시스템 관리자가 결정해야 합니다.

· 시스템에서 작업을 시작할 때 사용자는 시스템에 자신의 이름과 비밀번호를 입력하여 인증 절차를 거쳐야 합니다.

5.1.4.3. 런타임 수준에서 정보 보호

시스템의 여러 디렉토리에 대해 편집 권한에 대한 추가 제한이 제공되어야 합니다.

시스템 내 편집을 금지해야 하는 디렉토리:

• 주소 약어
• 통화
• 상호결제의 종류
• 상대방의 활동 유형
• 사용자 그룹
• 신분증
• 조직 직위
• 부문
• 사용자
• 운동의 기사 돈
• 지출
• 요금

5.1.5. 사고 발생 시 정보의 안전을 보장하기 위해 매일 자동 데이터 보관이 제공되어야 합니다.

5.1.6. 인체 공학 및 기술 미학에 대한 요구 사항

5.1.6.1.디자인의 통일성을 확보하기 위해 사용자 인터페이스기본 도구 모음을 사용해야 하며 상황에 맞는 메뉴, 1C 플랫폼에서 자동으로 생성됩니다.

5.1.6.2 시스템 내 객체 및 사용자 행위를 지정하는데 사용되는 용어는 해당 주제 영역의 표준 용어에 부합해야 한다.

5.2. AS "SABYT"의 구조 및 기능에 대한 요구 사항.

5.2.1. AS "Sbyt"는 다음과 같은 자동화된 하위 시스템으로 구성되어야 합니다.

가입자에 대한 기본 정보를 입력하기 위한 하위 시스템(계약 체결)

지급 문서 생성을 위한 하위 시스템

ASKUE 시스템과의 통신 하위 시스템

결제 단말기와의 통신 하위 시스템.

5.2.2. 가입자에 대한 기본 정보를 입력(계약 체결)하기 위한 하위 시스템의 구성은 다음과 같습니다.

"가입자와의 계약"을 문서화하십시오.

5.2.3. 지급 문서 생성을 위한 하위 시스템의 구성은 다음과 같습니다.

문서 "영수증"

"벌금 발생" 문서화

문서 "소비된 에너지"

상호결제 현황 확인 모듈

5.2.4. ASKUE 시스템과 통신 하위 시스템의 구성은 다음과 같습니다.

ASKUE 시스템과의 모듈 통신.

5.2.5. 결제 단말기와 통신 하위 시스템의 구성은 다음과 같아야 합니다.

결제 단말기와의 모듈 통신.

5.3. 가입자에 대한 기본 정보를 입력하기 위한 하위 시스템 모듈 기능에 대한 요구 사항(계약 체결)

5.3.1. 가입자에 대한 기본 정보를 입력(계약 체결)하기 위한 하위 시스템은 다음 기능을 수행해야 합니다.

상대방(이하 가입자라 한다)의 설비용량에 관한 정보를 입력하고 저장하는 행위

가입자의 설치된 계량기에 관한 정보를 입력하고 저장합니다.

가입자 요금에 관한 정보 입력 및 저장

가입자에 대한 위약금 계산 조건에 관한 정보를 입력하고 저장합니다.

계약 기간에 관한 정보를 입력하고 저장합니다.

5.4. 지급 문서 생성을 위한 하위 시스템 기능에 대한 요구 사항

5.4.1. 지급 문서 생성을 위한 하위 시스템은 다음 기능을 수행해야 합니다.

가입자와의 상호 합의 상태를 결정하고 위약금 발생 조건을 결정합니다.

지불 문서(영수증 또는 송장) 생성.

5.5. ASKUE 시스템과의 통신 하위 시스템 기능에 대한 요구 사항

5.5.1. ASKUE 시스템과의 통신 하위 시스템은 다음 기능을 수행해야 합니다.

가입자와 새로 체결된 계약에 대한 데이터 전송. 통신 키는 "가입자 ID" - "가입자 계약 코드" 쌍의 고유성이어야 합니다.

가입자의 전력 소비량에 대한 데이터를 얻습니다. 통신 키는 "카운터 ID" - "카운터 코드" 쌍의 고유성이어야 합니다.

5.6. 결제 단말기와의 통신 하위 시스템 기능에 대한 요구 사항

5.6.1. ASKUE 시스템과의 통신 하위 시스템은 다음 기능을 수행해야 합니다.

결제 단말기를 통해 가입자의 전기 요금 결제에 대한 데이터를 수신합니다.

1. 6. AIS "SALES"의 제어 및 승인 절차.

6.1 고객에게 작업 결과를 제시하고 전달하기 위해 다음 절차가 확립됩니다.

6.1.1. 계약자는 테스트 예제를 사용하여 소프트웨어의 기능을 시연합니다.

6.1.2. 테스트 케이스에 대한 데이터는 고객 담당자가 준비합니다.

6.1.3. 계약자는 소프트웨어를 고객의 정보 부서로 이전하고 고객의 관리자를 교육합니다.

6.1.4. 테스트 케이스 솔루션의 결과에 따라 시험 운영을 위한 소프트웨어 양도 증명서를 준비해야 합니다.

6.1.5. 규정을 준수하지 않는 경우 기능성기술 사양의 요구 사항에 따라 계약자는 AS 개발 총 비용 내에서 의견을 제거합니다.

6.1.6. 기술 사양에 대한 추가 고객 요구 사항이 발생할 경우 수정을 위한 추가 기술 사양이 작성됩니다.

6.1.7. 유효성 추가 요구 사항고객은 시험 운영을 위한 소프트웨어 양도 증명서 서명을 거부하는 근거가 되어서는 안 됩니다.

6.1.8. 고객과 합의한 구현 일정에 따라 소프트웨어를 시험 운영으로 전환한 후 계약자는 소프트웨어 작업에 대해 고객의 직원을 간략하게 교육하고 소프트웨어 작업 지침을 각 하위 시스템에 전달합니다.

6.1.9. 소프트웨어 구현(시험 운영) 시 고객은 다음을 수행합니다.

필수 참조 데이터를 입력합니다.

실제 데이터 입력;

보고서 생성 및 작업 결과 확인.

6.1.10. 구현 과정에서 계약자는 구현 일정의 틀 내에서 고객에게 지원을 제공해야 합니다.

6.1.11. 구현을 위한 고객 직원의 준비가 부족하고 성공적인 소프트웨어 구현을 위해 계약자의 추가 지원이 필요한 경우 정보 및 컨설팅 작업 제공에 대한 계약 가격 합의를 위한 추가 프로토콜을 작성해야 합니다.

6.2.AS "SALES" 작업의 추가 지원 절차.

6.2.1. 소프트웨어가 작동된 후에는 고객과 합의한 기술 사양에 따라 고객이 원하는 추가 수정 사항을 구현할 수 있습니다.

TOR은 추가 요구 사항을 구현하기 위한 작업의 복잡성과 비용을 나타내야 합니다.

6.2.2. 계약자는 전화 " 핫라인"동반 소프트웨어.

6.2.3. 고객의 요청에 따라 계약자는 고객으로부터 직접 소프트웨어 지원을 제공할 수 있으며, 이는 소프트웨어 지원에 대한 추가 계약을 기반으로 수행되어야 합니다.

6.2.4. 소프트웨어를 작동하기 시작한 날로부터 6개월 이내에 고객이 확인한 오류는 계약자가 즉시 무료로 수정해야 합니다.

계약자가 고객의 잘못된 조치로 인해 오류가 발생했음을 발견한 경우 계약자는 이를 찾아 제거하는 데 소요된 시간을 추가로 지불해야 합니다.

6.2.5. 1C: Enterprise 구매 후 1년 이내에 고객은 다음과 같은 권리를 갖습니다. 무료 영수증 1C 프로그램 개발 및 법률 변경과 관련된 1C 회사의 모든 업데이트. 변경 설치는 고객의 자동 제어 시스템을 통해 수행되어야 합니다.

6.2.6. 계약자는 AS의 개발, 구현 또는 유지 관리 중에 고객으로부터 받은 고객 데이터베이스 내용과 기타 정보의 기밀성을 보장합니다.

기술 프로젝트:

승인했습니다. 승인을 위해 제출했습니다.

" "______________ 2010 " "_______________ 2010

"____" ________ 2010년 기술 사양에 대한 부록

자동화됨

판매 시스템.

기술 프로젝트

시트에

"__" ____________ 2010부터 유효

디렉토리. 삼

카운터. 삼

관세..3

변전소. 삼

페널티 옵션. 삼

환승. 4

요금 유형. 4

정보 레지스터. 4

관세의 의미. 4

가입자 요금. 4

미터 데이터. 5

누적 레지스터. 5

전력 소비. 5

서류..6

가입자와의 계약.. 6

에너지 소비. 6

영수증. 7

벌금 계산. 9

처리. 10

ASKUE 시스템에서 데이터를 수신합니다. 10

데이터 검색 중 결제 시스템.. 11

디렉토리

카운터

필수 조건:

요금

세부정보: 아니요

페널티 옵션

세부정보: 아니요

환승

청구 유형

값:

정보 레지스터

계약 기간

빈도: 비주기적

목적: 가입자와의 계약 유효기간을 저장하기 위해 설계되었습니다.

측정

관세의 의미

빈도: 낮

목적: 관세 및 관세가 적용되기 시작하는 날짜를 저장하도록 설계되었습니다.

측정

소품		목적
		일일 요금 비용
		야간 요금 비용(지정되지 않을 수 있음)

가입자 요금

빈도: 낮

목적: 계약에 따라 가입자에게 할당된 요금을 저장하도록 설계되었습니다.

측정

소품		목적
	디렉토리 관세	가입자 요금

미터 데이터

빈도: 낮

목적: 후속 충전을 위해 미터 판독값을 저장하도록 설계되었습니다.

측정

소품		목적
적응증일		미터 판독
표시밤		미터 판독

누적 레지스터

전력 소비

목적: 추후 청구를 위해 에너지 소비에 대한 정보를 저장하도록 설계되었습니다.

등록 유형: 협상 가능

측정

선적 서류 비치

가입자와의 계약

목적: 가입자와 계약을 체결한 사실을 반영하기 위한 목적

소품		목적
상대방	디렉토리 계약자
상대방 계약
	디렉토리 관세
설치된전원		가입자의 설치전력을 KW로 저장
시작 날짜액션		계약이 유효한 날짜
종료 날짜액션		계약 만료일
조직	조직 디렉토리
벌금 발생 옵션
명명법	디렉토리 명명법
수동 조정		문서 항목의 수동 조정 서명

테이블 부분: 카운터 및 관세

문서 게시

문서는 다음과 같이 수행됩니다.

정보 등록부 "미터 판독값"에 따르면 가입자의 미터값과 초기 미터값이 등록됩니다.

정보 등록부 "가입자 요금표"에 따르면 계약 시작일부터 가입자에 대해 설정된 요금이 기록됩니다.

계약서가 작성된 정보등록부 "계약 유효기간"에 따라 계약 개시일 및 만료일을 기재합니다.

에너지 소비

목적: 특정 날짜의 미터 판독값을 반영하도록 설계되었습니다.

문서 작성

문서는 수동으로 작성하거나 "ASKUE에서 데이터 수신" 처리를 호출하여 작성하는 두 가지 방법으로 작성할 수 있습니다.

문서 게시

문서는 다음과 같이 수행됩니다.

"미터 판독값" 정보 기록부에 따르면, 미터 판독값은 문서 날짜를 기준으로 기록됩니다.

누적 레지스터에 따르면 "다음 알고리즘에 따라 소비되는 에너지:

1. 미터 판독값은 문서 날짜 및 이전 미터 판독값을 기준으로 정보 레지스터 "카운터 판독값"에서 가져옵니다.

2. 판독 값의 차이는 누적 레지스터의 해당 리소스에 입력됩니다.

인쇄 가능한 양식

미터 판독 기록

영수증

목적 : 가입자에게 요금을 반영하도록 설계

문서 작성

문서는 수동 입력과 "지급 발생" 처리 호출의 두 가지 방법으로 작성할 수 있습니다.

표 부분: 미터 판독값

소품		목적
상대방	디렉토리 계약자
상대방 계약	상대방의 디렉토리 계약
명명법	디렉토리 명명법
	디렉토리 관세	계약에 따른 가입자 요금
	디렉토리 카운터
유형발생	발생액 이전 유형
에너지 소비		에너지 소비
관세 가치		문서 날짜 기준 관세 가격
발생		가입자에게 청구되는 금액

문서 게시

문서는 다음과 같이 수행됩니다.

세금 계정과목표에 따르면:

인쇄 가능한 양식

요금 등록

채우기 알고리즘

이 문서는 참고서 "상대방 계약"을 기반으로 작성되었습니다.

1. 디렉터리에서 정보 등록 "계약 유효 기간"에 따라 시작 날짜가 문서 날짜보다 작고 종료 날짜가 문서 날짜보다 큰 계약이 선택됩니다.
2. 이러한 계약에 해당하는 미터가 선택됩니다.
3. 계량기의 경우 에너지 소비량은 문서 날짜와 이전 문서 날짜 사이의 기간 동안 누적 레지스터 "에너지 소비"의 매출액으로 결정됩니다. 이전 문서의 날짜를 알 수 없는 경우에는 전체 매출액이 다음과 같습니다. 등록이 이루어집니다. 결과 값은 "ConsumedEnergy" 필드에 기록됩니다.
4. 관세는 문서 작성일 현재의 관세 가격과 계약에 따라 설정됩니다.
5. 적립 유형은 "미터 판독값에 따라"로 설정됩니다.
6. 발생 필드는 소비된 에너지와 관세 값을 곱하여 계산됩니다.

연산

Kt. 분석이 포함된 90.01 SubcontoKt1 - Nomenclature.NomenclatureGroup, SubcontoKt2 - Nomenclature.VAT 세율.

계정 62.02에 대변 잔액이 있는 경우 대출금은 전기로 상쇄됩니다.

Dt. 62.02 분석 포함 SubcontoDt1 - 상대방, SubcontoDt2 - 상대방 계약

거래 금액은 계정 62.02의 신용 잔액의 최소값과 "발생"변수 값입니다)

Dt. 분석이 포함된 90.03 SubcontoDt1 - Nomenclature.NomenclatureGroup, SubcontoDt2 - Nomenclature.VAT 세율

Kt. 62.01 분석 포함 SubcontoKt1 - 상대방, SubcontoKt2 - 상대방 계약

거래 금액 = "발생"*VAT 요율/(100+VAT 요율), 여기서 VAT 요율은 "명칭.VAT 요율"입니다.

벌금 계산

목적 : 과태료 누적을 가입자에게 반영하도록 설계

문서 작성

문서는 수동 입력과 "벌금 계산" 처리 호출의 두 가지 방법으로 작성할 수 있습니다.

표 부분: 미터 판독값

소품		목적
상대방	디렉토리 계약자
상대방 계약	상대방의 디렉토리 계약
벌금 발생 옵션	벌금 발생에 대한 디렉토리 옵션
발생		가입자에게 청구되는 금액

문서 게시

문서는 다음과 같이 수행됩니다.

자체 지원 계정과목표에 따르면:

세금 계정과목표에 따르면:

인쇄 가능한 양식

요금 등록

바코드가 있는 결제 영수증

바코드는 "Infograftbarcode" 글꼴을 사용하여 생성됩니다.

형성 알고리즘 라인 “0000”+가입자 계약 코드+적립됨

영수증 레이아웃은 KV_1.mxl 파일에 첨부되어 있습니다.

연산

표 섹션 "미터 판독값"의 각 줄에 대해 다음 항목을 입력해야 합니다.

Dt. 분석이 포함된 62.01 SubcontoDt1 - 상대방, SubcontoDt2 - 상대방 계약

Kt. 91.01 분석 SubcontoKt1 - 기타 소득.

거래 금액 - "Accrued" 속성의 값입니다.

트리트먼트

ASKUE 시스템에서 데이터 수신

			정확성	목적
				Sales 시스템의 미터 코드는 ASKUE 시스템의 미터_ID와 일치합니다.
				일일 미터 판독값
				야간 관세의 미터 판독 값

처리 세부정보

처리 알고리즘:

1. 데이터 전송 파일 라인에서 카운터 코드 가져오기
2. "counters" 디렉토리에서 코드로 해당 요소를 찾고, 요소를 찾을 수 없으면 "코드가 있는 카운터를 찾을 수 없습니다..."라는 메시지를 표시합니다.
3. 요소가 발견되면 값 테이블에 한 줄을 추가합니다. 여기서: "counter" - 발견된 요소, "ReadingsDay" - "Day", "ReadingsNight" - "Night"
4. 문서 “Consumed Energy” 및 라인 수에서 처리를 호출하는 경우

값 테이블의 값이 0보다 큰 경우 값 테이블의 내용을 표 부분문서를 작성하고 게시하세요.

1. 값 테이블에 행이 있고 "소비 에너지" 문서에서 처리가 호출되지 않은 경우 날짜가 다음과 같은 "소비 에너지" 문서를 생성합니다. 현재 날짜그런 다음 문서를 게시하세요.

결제 시스템에서 데이터 수신

데이터 전송 파일 형식은 DBF입니다.

데이터 전송 파일 구조:

처리 세부정보

처리 알고리즘:

1. 다음 구조로 값 테이블을 만듭니다.

1. 데이터 전송 파일 라인 선택
2. 데이터 전송 파일의 라인을 통해 루프를 시작합니다.
3. 데이터 전송 파일 라인 읽기
4. 데이터 전송 파일 라인에서 계약 코드를 가져옵니다.
5. "상대방 계약" 디렉토리에서 코드별로 해당 요소를 찾고, 해당 요소를 찾을 수 없으면 "코드와의 계약을 찾을 수 없습니다..."라는 메시지를 표시합니다.
6. 요소가 발견되면 값 표에 한 줄을 추가합니다. 여기서 "Agreement" - 발견된 요소, "Date" - "Data_plat", "Payment Number" - "Nomer_plat", "Amount" - "Summa_plat"
7. 데이터 전송 파일의 마지막 줄을 받은 후 사이클을 종료합니다.
8. 값 테이블의 각 행에 대해 "자금 수령을 위한 지불 주문" 문서를 생성합니다. 문서 생성 시 수신 문서와 동일한 날짜, 동일한 번호의 문서가 시스템에 있는지 확인하세요. 문서가 시스템에 있으면 문서가 생성되지 않습니다.
9. 문서 세부 사항 작성 규칙:

소품	값 채우기
작업 유형
	TableLineValue.Date
수신 문서 번호	테이블 라인Valuary.Payment 번호
문서 수신 날짜	TableLineValue.Date
상대방 계약	TableLineValue.Contract

'제품 요구사항 문서'를 요청해 해외 사이트를 뒤져보면 기술사양(TOR, PRD)이 죽었다는 창의적이고 설득력 있는 글을 발견할 수 있다. 우리는 이것에 부분적으로 동의해야 합니다. 제품을 처음부터 개발할 때 프로토타이핑은 때로는 매우 비전문적인 고객 메모보다 훨씬 더 흥미롭고 효과적입니다. 그러나 기본 시스템을 완성하는 것에 대해 이야기하면 상황은 완전히 다른 방향으로 나아갑니다. 우리는 수정과 맞춤 개발에 직면해 있기 때문에 셰프가 우리에게 거짓말을 하지 않는다면 기술 사양은 개먹거리가 될 것입니다. 일반적으로 오늘 우리는 구매하고 설치된 소프트웨어를 개선하기 위해 작성된 고전적인 기술 작업에 대해 이야기하고 있습니다. 요컨대, 고통스러운 것들에 관한 것입니다.

상호작용의 측면

기술 사양 작성 프로세스를 분석하기 전에 계약자와 고객이 프로젝트를 시작할 때 직면하게 되는 사각형에 대해 이야기해 보겠습니다.

요구사항- 구현하려는 고객이나 프로세스 보유자가 설명한 시스템의 원하는 동작. 일반적으로 요구 사항은 업무 경험과 프로그램의 올바른 동작에 대한 이해를 바탕으로 형성됩니다. 이는 개발자(벤더)의 핵심 정보이지만, 요구 사항을 수집하는 단계에서 충돌, 오류, 불필요한 요청 등이 가장 많이 발생합니다.

자원- 요구 사항을 구현하는 과정에서 사용해야 하는 사람, 기계, 장비, 개발 환경, 시간 및 비용. 리소스에는 기술 사양 승인 단계에서 명확한 계획과 평가가 필요합니다. 고객 측의 적절한 우선순위 지정과 공급업체 측의 노동 자원 분배를 통해 마감 기한을 놓치는 것을 방지하고 기타 위험을 최소화할 수 있습니다.

가능성- 한마디로 벤더(공연자)가 실제로 할 수 있는 일이다. RegionSoft CRM의 예를 살펴보겠습니다. 고객은 시스템을 구입하고 수정을 위한 기술 사양을 작성합니다. 웹 사이트와의 통합을 생성하고 CRM의 이벤트를 온라인 상점의 주문 번호에 연결해야 합니다. 이는 현실적인 요구 사항이며, 우리는 이를 수행할 수 있는 자원과 능력을 갖추고 있습니다. 또한 웹사이트 콘텐츠 관리 시스템인 CMS를 개발하여 CRM에 연결해야 합니다. 이론적으로 우리는 이를 수행할 수 있지만 이를 저렴하게 수행할 기회가 없으며 고객은 우리가 작업에 인적 및 시간 자원을 할당할 만큼 충분한 비용을 지불할 기회가 없습니다. 결과적으로 고객은 이 요구 사항을 거부하며 CMS가 실제로 필요하지 않으며 모든 것이 정상입니다. 그러나 나중에 TK의 "탐욕"에 대해.

제한- 기술 사양에 따른 작업 수행을 어렵거나 불가능하게 만드는 일련의 장애물: 예산, 기술 스택, 라이선스 문제, 법적 금지, 하드웨어 구성 등

따라서 네 가지 본질은 모두 밀접하게 얽혀 있으며 프로젝트 전체의 성공을 결정합니다. 각 요소를 살펴보고 기술 사양 작업 시 염두에 두어야 할 중요한 사항을 강조해 보겠습니다.

요구사항 수집 및 분석

이는 잠재적인 사용자가 프로그램에서 원하는 것이 무엇인지 명확해지는 매우 중요한 내부 기업 프로세스입니다(이하 CRM을 사용하지만 이 방법은 다른 유형의 소프트웨어에서도 작동합니다). SAP 또는 시스템 통합업체와 같은 대규모 공급업체에 연락하면 높은 확률로 비즈니스 컨설턴트(일명 개인 관리자, 일명 계정 관리자, 일명 "현재 당사의 대표")의 서비스를 사용하라는 제안을 받게 될 것입니다. 회사"). 실제로 대부분의 경우 이는 프로젝트 비용을 늘리고 사용자를 당황하게 하지 않는 두 가지 작업을 수행하는 잘 훈련된 일반 영업사원입니다.

그는 여기에 한 시간 동안 있었는데도 화이트보드에 손도 대지 않았습니다. 그는 실제 시스템 분석가가 아닙니다.

귀하와 귀하의 직원보다 귀하의 회사를 더 잘 아는 사람은 없습니다. 즉, 요구 사항을 수집하고 분석하는 것은 전적으로 귀하의 작업이며 공급업체는 이를 지원하고 안내할 수 있지만 어떤 경우에도 프로세스를 방해하지 않습니다. 개발자에게 이러한 구현에 대해 문의하고 무엇을 찾아야 할지 알아보고 시작하세요. 그건 그렇고, 좋은 조수는 전문 주제에 정통하고 소프트웨어 아키텍처에 대한 대략적인 아이디어를 가지고 있으며 개발 프로세스에 익숙한 직원이 될 수 있습니다. 그는 분석가 및 내부 전문가로 활동하여 감독할 수 있습니다. 기술 사양을 작성하고 공급업체와 통신하는 프로세스입니다.

매우 있습니다 간단한 회로요구 사항을 수집합니다.

1. CRM을 사용할 부서의 관리자와 경험이 풍부한 전문가로 구성된 실무 그룹을 만듭니다. 선택하려는 솔루션에 대해 알려주고 데모 버전에 대한 액세스를 제공하세요.
2. 회원 실무 그룹직원에게 정보를 전달하고 원하는 사항을 물어야 합니다. 새로운 프로그램완전히 자유로운 형태로. 직원 중 한 명이 그러한 소프트웨어를 접한 적이 없고 향후 사용에 대해 이야기할 준비가 되지 않은 경우 그에게 정기적인 작업을 설명하도록 요청해야 합니다. 이는 보편적인 접근 방식입니다.
3. 그런 다음 각 부서는 CRM에 없거나 측정되지 않은 내용을 식별하고 정보를 집계합니다.
4. 워킹 그룹은 수집된 요구 사항을 분석하고 교차점을 확인하고 제거합니다. 예를 들어 영업 부서와 마케팅 부서가 동일한 보고서를 주문하는 경우가 많지만 요구 사항의 데이터는 동일하더라도 필드 및 엔터티에 대한 이름이 다를 수 있습니다. 그러므로 우리는 통일된 형태로 나아가야 합니다.
5. 작업 그룹은 요구사항 목록을 작성하고 우선순위를 설정합니다. 이 단계에서는 공급업체가 리소스를 담당하므로 해당 공급업체를 참여시킬 수 있습니다. 예를 들어 RegionSoft CRM에 대한 사용자 정의 보고서 생성을 요청하거나 사이트와의 통합을 주문할 수 있습니다. 마감일이 완전히 다른 작업이므로 여기서 우선순위가 매우 중요합니다.

요구사항을 수집, 분석하고 직원 및 경영진과 합의한 후 기술 사양 작성을 시작할 수 있습니다. 공급업체에 양식을 요청하거나 직접 작성할 수 있습니다. 어떤 경우에도 몇 가지 철칙적인 규칙이 있으며 이를 준수하면 귀하와 CRM 공급업체의 골치 아픈 일을 줄일 수 있습니다.

기술 사양 분석

기술 사양을 작성하는 과정에 대해 이야기하면 여러 단계가 있습니다. 순차적인 통과를 통해 고객은 원하는 개선을 이룰 수 있습니다. 여기 있습니다.

• 식별 - 요구 사항을 정의하고 해결해야 할 문제를 찾습니다.
• 분석 - 요구 사항 분석, 주요 요구 사항 식별, 일반화.
• 적응 - CRM 기능 및 기존 비즈니스 프로세스의 맥락에서 요구 사항을 평가합니다.
• 문서화 - 요구 사항에 대한 공식적이고 자세한 설명, 기술 사양 승인.
• 공급업체(개발자)와의 커뮤니케이션 - 컴파일된 기술 사양에 따른 개선 사항과 관련하여 공급업체와의 반복적인 상호 작용입니다.
• 구현은 필요한 기능을 생성하기 위한 공급업체의 작업입니다. 공급업체가 고객과 지속적으로 접촉하는 것이 더 좋습니다. 이렇게 하면 최종 제품이 고객의 비전과 가장 밀접하게 일치하게 됩니다.
• 테스트 - 수정 및 기술 사양 준수와 변경 사항에 따른 시스템 작동성을 확인하기 위해 공급업체 직원, 고객 내부 전문가 및 최종 사용자가 기능을 확인합니다.

일반적으로 기술 사양은 여러 수준의 요구 사항을 기반으로 생성될 수 있으며, 이는 프로젝트 생성 시 교차하고 협력할 수도 있고 전혀 상호 작용하지 않을 수도 있습니다.

비즈니스 수준- 복잡하고 우선순위가 높은 작업을 해결하는 가장 글로벌한 수준입니다. 이 수준에는 비즈니스 프로세스의 통합, 개선 및 모델링, 새로운 기능 모듈 개발이 포함됩니다. 일반적으로 이는 고객과의 진지한 협의와 긴밀한 협력을 통해 자원 집약적인 개발입니다. 예를 들어 한때 RegionSoft CRM에서는 창고 회계, 금전등록기 및 생산 등의 사용자 정의 수정이 있었습니다. 점차적으로 변경 사항이 릴리스에 포함되었으며 나중에 생성이 가능해졌습니다. 새로운 제품도매업자를 위한, 소매 상점대형마트 - RegionSoft Retail.

사용자 또는 사용자 그룹 수준.이 수준에서는 기존 인터페이스를 개선하는 작업이 구현됩니다. 예를 들어, 사용자는 고객 위로 마우스를 가져갈 때 마지막 주문의 번호와 상태가 표시되는 창이나 특별한 데이터 그룹이 포함된 사용자 정의 보고서를 원할 수 있습니다. 이 수준의 개선에는 시간이 덜 걸리지만 그 중 많은 부분이 있을 수 있습니다. 예를 들어 마케팅, 물류 및 부서의 여러 요구 사항이 있습니다. 기술적 지원.

기능 수준.이전 기준과 분리하기 어려운 경우가 많으며 여기서는 공식적인 기준이 작동합니다. 개선은 인터페이스에 무언가를 표시하는 수준이 아니라 시스템 로직을 마무리하는 수준입니다. 여기에는 다양한 종류의 정렬, 채팅 통합 및 전화 통신 기능에 대한 요구 사항이 포함될 수 있습니다.

서비스 수준- 실제로 이 수준의 요구 사항은 수정 사항이 포함된 새 빌드에 가장 먼저 포함되어야 합니다. 시스템 응답 속도, 고부하 동작, 보안과 관련된 작업입니다. 이상적으로는 공급업체가 그러한 수정을 해서는 안 됩니다. 기업 소프트웨어는 속도가 느려지거나, 데이터가 손실되거나, 양식이 붕괴되거나, 동일한 수준의 액세스 권한이 배포되어서는 안 됩니다. 그러나 요구 사항이 나타나고 그것이 고객의 개인적인 편집증이나 하드웨어 측면의 문제와 관련이 없다면 이에 더 많은 관심을 기울일 가치가 있습니다.

기술 수준- 목록에서 마지막이지만 중요성과 복잡성 면에서 나머지보다 앞서 있습니다. 이는 플랫폼 관련 고객 요구 사항일 수 있습니다. 운영 체제또는 장치. 예를 들어 MacOS용 빌드 요청이 있습니다. 이러한 요구 사항이 점진적으로 릴리스로 발전하면 좋겠지만 이에 대한 수정 사항이 반드시 필요합니다. 이 수준의 고객 요청에 따라 MacOS용 RegionSoft CRM을 구축하고 추가했습니다. 원격 액세스모바일 버전에 대한 드물지만 기존 요청에 대한 임시 솔루션으로 TRM 기술을 사용합니다.

기술 사양의 해부학적 구조는 최소한 골격 형태에서는 간단합니다. 기술 사양의 필수 부분은 고객이 문제에 집중하고 작업을 올바르게 공식화하는 데 도움이 되며 계약자는 자신이 원하는 것이 무엇인지 이해할 수 있습니다. 그건 그렇고, 이해에 대해. 물론 게시물 시작 부분에서 우리는 비즈니스 컨설턴트를 클래스로 거부하면서 약간의 거짓말을했습니다. 요점은 각 공급업체가 몇 년 동안(1일 CRM에 대해 이야기하는 것이 아님), 심지어 수십 년 동안 시장에서 활동해 왔다는 것입니다. 이는 거의 모든 업계에서 일련의 사례를 보유하고 있음을 의미합니다. 따라서 엔지니어, 프로그래머 및 영업 사원은 각 회사 유형의 구현 세부 사항을 잘 알고 있습니다. 그러나 다시 한번 강조하지만, 귀하의 비즈니스에 구체적으로 집중하는 것이 중요합니다.

누구를 위해?이 섹션에서는 개선의 최종 사용자가 누구인지, 어떤 작업을 해결할 계획인지, 빈도는 어느 정도인지 설명해야 합니다.

예를 들어 보겠습니다. 한 회사는 CRM을 구현하고 있었고 상당히 많은 양의 데이터(월당 수천만 개의 레코드, 하루에 수십만 개의 레코드)를 처리해야 했습니다. 영업부서장은 이러한 기록을 "매일" 빈도로 업로드하는 것에 대한 보고서를 요청했습니다. 당연히 수백 명의 사용자가 동시에 작업하는 이러한 보고서가 시스템에 로드되었으며 프로세스를 최적화하는 솔루션이 발견되었습니다. 작업 중에 이미 영업 사원이 안전하게 플레이했으며 월말에만 보고서가 필요하다는 것이 밝혀졌으며 밤에는 일정에 따라 실행될 수 있습니다. 말할 필요도 없이 시간과 돈이 낭비되었습니다.

무엇을 위해?개선의 필요성과 비즈니스 프로세스에서의 위치에 대한 정당성. 이 점은 고객 자신에게 더 필요하지만 공급업체가 어떤 다른 프로세스가 영향을 받을지 아는 것도 유용합니다. 때로는 이것이 대체 솔루션을 찾는 데 도움이 됩니다.

무엇을 해야 합니까?가장 유익한 블록 - 시스템의 요구 사항과 기대치를 설명합니다. 그리고 여기에서 Bashorg에 보내기에 딱 맞는 진주, 기적 및 충돌이 발생하며 이는 삶을 매우 어렵게 만듭니다. 이유는 단 하나뿐입니다. 사용자는 자신이 원하는 것이 무엇인지, 무엇을 해야 하는지 모릅니다. 또 다른 작은 하위 이유가 있습니다. 사용자가 요구 사항을 공식화할 수 없다는 것입니다. 여기서 개발자(작업 그룹, 분석가(있는 경우))의 임무는 요구 사항을 올바르게 공식화하고, 적절한 요구 사항을 선택하고, 작업을 시스템 운영 맥락에 맞추도록 돕는 것입니다. 동일한 블록에서 예상 결과를 언급해야 합니다.

사양 매개변수- 마감일, 구현 단계, 모든 당사자의 책임, 필요한 연락처 등 실제로 이는 문서를 기술 사양으로 만드는 중요한 형식적 요소의 집합입니다. 개발 중 수많은 변경을 방지하려면 당사자들이 참조 조건에 동의하고 서명해야 합니다(이러한 변경은 여전히 ​​발생하지만 그 정도는 낮습니다).

이상적으로 기술 사양은 공급업체의 적극적인 참여를 통해 작성되며 그 결과는 대략 다음과 같은 구조입니다.

1. 각 메커니즘 및 각 기능의 요구 사항에 대한 설명
2. 이 기능의 구현에 대한 설명
3. 단계별 작업비 별도
4. 이 기술 사양에 대한 총 작업 비용
5. 작업 완료를 위한 시간 프레임(단계별로 분류되고 우선순위 표시)
6. 설치 조건 설명 및 수정 테스트
7. 위임사항 및 기타 조건의 포괄적 성격에 관한 유보

개발자의 눈물로 쓴 10가지 규칙

개정 의뢰사항은 개정 기술사양으로 하여야 함, 고객에게 필요한 CRM에 대한 300페이지 분량의 설명이 아닙니다. 요구 사항을 작성하기 전에 시스템 인터페이스, 해당 기능 및 문서를 주의 깊게 숙지해야 합니다. 대부분의 "원하는 사항"은 이미 기본 패키지에 포함되어 있을 가능성이 높습니다. 제가 추천하고 싶은 두 번째 단계는 내장된 수정 도구(보고서 디자이너, 구성자 등)에 주의를 기울이는 것입니다. 아마도 전업 프로그래머가 필요한 변경을 수행할 수 있을 것입니다(많은 회사에서 이를 보유하고 있습니다).

기술 사양은 욕심을 부리면 안 됩니다.종종 기업은 자신의 능력을 과대평가하거나 "모든 것을 한 번에" 얻고 싶어합니다. 이 접근 방식은 재정적 또는 비즈니스 관점에서 정당화되지 않습니다. 일반적으로 공급업체는 몇 주 동안 존재하지 않았으며(RegionSoft의 경우 15년) CRM에 누락된 내용을 실제로 이해한 후에는 해당 공급업체에 연락할 수 있습니다.

말 그대로 어제 중복성의 놀라운 예: 고객이 잘 알려진 회사에서 ERP를 구입했습니다. 러시아 회사, 회계가 작동하므로 이 공급업체의 ERP가 좋을 것이라고 생각합니다. ERP는 그 자체로 그다지 좋지 않을 뿐만 아니라 비즈니스에 매우 부적합한 것으로 나타났습니다. 그러나 RegionSoft CRM은 창고 회계 및 생산에 적합합니다. 해결책이 있습니다. ERP를 잊고 울고 1C 회계를 새로운 CRM과 통합하고 편리한 구현을 즐기십시오. 하지만 낭비되는 돈은 안타깝습니다! 그리고 클라이언트는 CRM과 ERP의 통합을 요구합니다. 우리는 그렇게 하지 않았는데 왜 이렇게 낭비적인가, 왜 상대적으로 유사한 두 시스템이 있는 걸까요?

위임사항은 현실적이고 달성 가능해야 합니다.-요구 사항과 마감일 모두. 여기에서는 공급업체의 의견을 듣는 것이 중요합니다. 공급업체는 특정 작업에 얼마나 많은 시간이 소요될지 정확히 알고 있기 때문입니다. 저를 믿으십시오. 개발자가 시간을 낭비하고 기한을 늘리는 것은 유익하지 않습니다. 가능한 한 많은 프로젝트를 완료하고 잘 수행하여 명성에 타격을 입지 않는 것이 유익합니다. 현실성에 관해서는 CRM을 충돌기 관리 시스템 수준으로 업그레이드하라는 요청을 피하기가 쉽습니다. 실제로 필요한 것을 요구 사항에 포함해야 합니다. 이 순간그리고 가까운 미래에.

예를 들어, RegionSoft CRM은 데스크톱 프로그램이므로 브라우저 클라이언트가 없습니다. 한 회사를 위한 웹 애플리케이션을 만들도록 요청하는 것은 의미가 없습니다. 이는 중요한 개발이며 현재 진행 중이며 한 회사를 위한 개발이 가능하지 않습니다. 아니요, 물론 모든 것에는 가격이 있지만 다시 말하지만 일반적인 경우 요구 사항을 충족하는 것은 불가능합니다.

이는 맞춤형 개발에 관해 이야기할 때 애플리케이션의 아이디어와 논리가 근본적으로 변경되는 상황과 혼동되어서는 안 됩니다. 실제로 "자신을 위한" 새로운 소프트웨어 생성이 후원됩니다. 그러나 그것은 또 다른 이야기입니다.

참조 조건을 자세히 설명해야 합니다.프로그램 사용 빈도부터 인터페이스에 대한 희망 사항까지 향후 프로젝트의 모든 중요한 세부 사항을 표시해야 합니다. 요구사항이 자세할수록 구현 및 테스트가 더 쉽고 빨라집니다. 특정 산업(의학, 보험, 은행)에 종사하는 경우 특히 세부 사항에 주의를 기울일 가치가 있습니다. 비즈니스와 프로그램 간의 상호 작용의 뉘앙스를 자세히 제시하면 공급업체가 작업을 이해하고 시스템을 신속하게 적응할 수 있습니다. 너의 회사.

숫자 형식, 필드 이름, 드롭다운 목록의 유무, 버튼과 힌트의 동작, 데이터 유형에 주의하세요. 고객이 CRM 운영 로직에 포함되어야 하는 자신만의 공식을 사용하는 경우( 예를 들어 딜러 보너스 계산), 이 수식은 다음과 같이 작성되어야 합니다. 전체 성적표그들의 명칭 및 계산 논리.

예, 기업 소프트웨어는 다음과 같으며 여기에는 중요한 세부 정보가 많이 포함되어 있습니다.

기술 사양은 명확하고 정확해야 합니다.모호한 공식, 구현 옵션, 불분명한 요구 사항 - 이 모든 것이 막다른 골목으로 가는 길입니다. 클라이언트는 좋은 의도로 기술 사양에 시스템 동작에 대한 몇 가지 옵션을 작성하지만 동등하지는 않습니다. 이 경우 그는 자신이 프로그래머를 돕고 있다고 확신하지만 실제로 지옥으로 가는 길은 좋은 의도로 포장되어 있으므로 개발자는 정확히 필요한 것이 무엇인지 이해해야 하며 이를 수행하는 방법을 기반으로 스스로 선택합니다. 시스템의 특성과 사용된 기술 스택에 대해 설명합니다.

올해도 또 한 가지 소원을 빌 수 있습니다. 명확한 비즈니스 요구 사항과 같이 나조차도 충족할 수 없는 것에 돈을 쓰지 마세요!

기술 사양은 인간의 언어로 작성되어야 합니다.그리고 이것은 중요합니다. 아니, 중요합니다. 언어 문제로 인해 프로젝트 구현이 지연되는 두 가지 상황을 강조하겠습니다.

1. 고객은 자신의 기술적 이해력을 입증하려고 노력하고 있으며 "창이 달력에 팝업되어야 하는 것" 대신 "통화 이벤트에 반응하는 기능과 함께 달력 본문에 힌트가 있는 창을 구현합니다..."와 같은 구성을 만듭니다. 여기서 작업을 완료로 표시할 수 있습니다.” 귀하 또는 귀하의 내부 전문가가 기술 텍스트를 작성할 기술이 없다면 Google을 사용하지 마십시오. 일반적인 단어로 작성하면 이해합니다.

   참고 사항은 불만 사항을 담은 책이 되어서는 안 됩니다.문제를 설명하는 것이 아니라 문제를 해결해야 하며, 글꼴에 주의를 기울이고 요구 사항 설명을 잊어야 합니다. 기술 사양에는 문제 자체뿐만 아니라 이해 수준의 솔루션도 포함되어야 합니다. 그러면 개발자가 코드 수준에서 문제를 해결하게 됩니다. 비교하다 “영업부서가 계획을 잘 못 세워서 숫자가 줄고 있어 우리는 1년 동안 어려움을 겪고 있습니다.”그리고 “월간 계획판매액과 실제 매출액을 제품군별로 나누어 저장하는 리포트 작성이 필요합니다”.

   참조 조건은 미래를 내다볼 수 있어야 합니다.글쎄요, 정확히는 아니지만 그 뒤에 있는 사람들입니다. 비즈니스 프로세스의 변경이 곧 발생할 것으로 알려진 경우 수정 비용을 두 번 지불하지 않도록 이를 고려해야 합니다.

   참조 조건은 관료적이어서는 안됩니다.이 문서를 작성한 적이 있다면 관료주의에 빠지고 싶은 유혹을 피하고 소개 단어와 엄격한 문구를 추가하고 각 항목을 형법 조항으로 설명하는 것이 얼마나 어려운지 느꼈을 것입니다. (바람직하게는 위반 시 모든 사람에 대한 처벌 포함) ). 관료적 공식은 기술 사양 작성 목적에 대한 불완전한 이해를 가립니다. 공급업체의 책임은 계약서에 명시되어 있으며 예산도 거기에 기록되어 있습니다. 이러한 사항을 기술 사양에 반영해서는 안 됩니다.

   참조 조건은 기술 사양이어야 합니다.역설적으로 들리지만 기술 사양 대신 편지, 불만 사항, 계약서, 새로 작성된 CRM 지침 또는 회의록을 읽는 경우가 많습니다. 물론 그러한 문서에 따라 작업하는 것은 불가능합니다. 형식과 내용을 완벽하게 파악하려면 구식 방법을 사용하십시오. 용어를 단어별로 살펴보세요. 기술적이란 수정, 기술을 지시하고 소프트웨어를 변경하여 문제를 해결하는 것을 목표로 한다는 의미입니다. 이것이 우리가 소프트웨어의 맥락에서 이야기해야 할 것입니다. 과제란 조언이나 조언이나 조언 없이 질문이나 문제를 제기하는 것을 의미합니다. 예비 견적. 문제에 대한 설명입니다.

   계명은 끝났으니 이제 책망을 받으라

   나열된 규칙 외에도 이야기할 가치가 있는 몇 가지 사항이 더 있습니다. 우리는 목표, 계획, 기대치 등 프로젝트를 성공으로 이끄는 모든 요소와 공급업체와 고객 간의 거의 우호적인 관계에 대해 이야기하고 있습니다.

   기술 사양은 빠르게 작성해야 합니다., 프로세스 자동화 작업에 직면하더라도 이동통신사아니면 대형 슈퍼마켓. 이는 기술이 엄청난 속도로 발전하고 있으며 구현 중인 시스템도 6개월 또는 1년 안에 주요 릴리스(또는 때로는 두 개)를 유지하고 새로운 기능을 받을 수 있기 때문입니다. 수정의 필요성을 재고하고 프로세스를 다시 시작해야 할 수도 있습니다.

   

   
   마침내 그는 기술 과제를 완료할 시간을 찾았습니다. 하지만 아쉽게도 이를 구현할 개발자가 남아 있지 않습니다.

   클라이언트는 스택과 기술적 한계를 인식하지 못합니다.그리고 그는 몰라서는 안됩니다. 이것은 공급 업체의 임무이며 기술 사양을 작성한 후 작업을 평가하는 사람입니다. 고객은 기술을 파헤쳐 벤더가 이런 일을 할 수 있는지, 저러는 일을 할 수 있는지 쉼표 하나하나에 물어서는 안 됩니다. 포괄적인 기술 사양을 작성하면 개발자는 적합한 아키텍처를 선택하게 됩니다. 이는 종종 생각보다 훨씬 더 나은 아키텍처입니다.

   예산을 평가하고 피하세요 불쾌한 놀라움 -거의 공동 작업 번호 1입니다. 공급 업체를 압박하고 그에게 작업에 대한 대략적인 평가를 요구해서는 안됩니다 (글쎄, 적어도 대략적으로, 눈으로, 그러나 다른 사람들과 마찬가지로 이러한 유형의 프로젝트에서는 음, 경험을 통해, 음, 오차범위). 전체 예산 평가는 위임 사항을 읽고, 분석하고, 최종 승인한 후에만 가능합니다. 개발자가 다르게 행동하는 경우 개정 비용이 최소 두 배 이상 든다는 사실에 대비하십시오.

   변화와 확장에 대한 객관적인 필요성을 바탕으로- 위에서는 개발자가 사라지지 않으며 언제든지 귀하의 요구 사항에 따라 변경 및 추가할 준비가 되어 있다고 썼습니다. 그러므로 꿈에 그리던 CRM/ERP를 즉시 만들려고 하지 말고 공급업체에 "커피를 마시는 동안 모든 것이 작동합니다" 버튼을 요구하지 마십시오. 시스템에서 작업하고 중요한 의견을 식별하고 요구 사항 수집 및 그리기를 시작하십시오. 기술 사양을 올립니다.

   기술적 과제에 대해 끝없이 글을 쓸 수 있는데, 이는 밈과 이야기뿐만 아니라 골칫거리도 만들어내는 실제 생성기입니다. 기술 사양을 비인간적으로 만드는 GOST 1989, 조금 더 나은 IEEE 표준, 이를 보완하는 프로토타입 및 기술 사양에 대해 우선 순위와 설계 규칙에 대해 이야기할 수 있습니다. 그러나 결국 나는 가장 중요한 규칙 중 하나로 제한하고 싶습니다. 기술 사양은 법의 지배도 아니고 GOST도 아니고 교리도 아니므로 개선할 수 있다면 개선하고 단순화할 수 있다면 개선하십시오. 그것을 단순화하고 우아하게 할 수 있고 모두가 좋아할 수 있다면 그렇게 하십시오. 그 이후에는 아무도 기술 사양에 코를 찌르고 거기에 쓰여 있지 않다고 말하지 않을 것이라고 확신합니다. 아니면 거의 아무도 없습니다.

   12월 내내 RegionSoft CRM 및 모든 자체 소프트웨어에 대해 할인 혜택을 제공합니다. 12월 1일부터 12월 15일까지 - 15%의 할부 및 임대 조건이 적용됩니다. 우리는 라이선스 가격을 경제적으로 정당하게 유지하고 갑작스럽게 가격을 책정하지 않기 때문에 -70%와 -90%가 없습니다.

   글쎄, CRM 시스템이 필요하다면 (수정 여부에 관계없이) 다음으로 이동하십시오. 우리 웹사이트, CRM, 그 장점 및 기타 기업 소프트웨어에 대해 많은 내용이 있습니다.

   그렇습니다. 우리는 항상 CRM 및 기타 제품을 판매하고, CRM을 수정 및 판매하고, 소프트웨어를 판매하고, 사용자를 교육할 준비가 되어 있는 파트너를 찾고 있습니다. 소득 분배는 파트너에게 공정하고 유익합니다. 우리는 당신에게 보여주고, 말하고, 가르쳐 줄 것입니다. 에 쓰기 [이메일 보호됨]

   슬라이드, 슬라이드. http://www.modernanalyst.com/ 및 Pinterest에서 가져온 만화. 더 나은 번역이 있으면 게시물에 포함시켜 드리겠습니다.