Jak napisać specyfikację techniczną zgodnie z GOST. Jak napisać specyfikację techniczną zgodnie ze specyfikacją techniczną GOST 19.201 78

GOST 19.201-78

Grupa T55

STANDARD MIĘDZYPAŃSTWOWY

jeden system dokumentacja programu

ZADANIE TECHNICZNE. WYMOGI DOTYCZĄCE TREŚCI I PROJEKTU

Ujednolicony system dokumentacji programu. Specyfikacja techniczna dla rozwoju. Wymagania dotyczące treści i formy prezentacji

MKS 35.080

Data wprowadzenia 1980-01-01

Dekretem Państwowego Komitetu ds. Standardów ZSRR z dnia 18 grudnia 1978 r. N 3351 datę wdrożenia ustalono na 01.01.80

WYDANIE (styczeń 2010) z poprawką nr 1, zatwierdzoną w czerwcu 1981 (IUS 9-81).


Niniejsza norma ustanawia procedurę konstruowania i przygotowywania specyfikacji technicznych dotyczących tworzenia programu lub oprogramowania dla komputerów, kompleksów i systemów, niezależnie od ich przeznaczenia i zakresu.

Norma jest w pełni zgodna z ST SEV 1627-79*.
________________
* Dostęp do wymienionych tutaj dokumentów międzynarodowych i zagranicznych można uzyskać, klikając link do strony internetowej http://shop.cntd.ru. - Uwaga producenta bazy danych.

1. POSTANOWIENIA OGÓLNE

1. POSTANOWIENIA OGÓLNE

1.1. Zakres obowiązków jest sporządzany zgodnie z GOST 19.106-78 na arkuszach formatu 11 i 12 zgodnie z GOST 2.301-68, z reguły bez wypełniania pól arkusza. Numery arkuszy (stron) umieszczane są w górnej części arkusza, nad tekstem.

1.2. Arkusz aprobaty i strona tytułowa są sporządzone zgodnie z GOST 19.104-78.

Część informacyjna (adnotacja i treść) oraz karta rejestracji zmiany nie mogą być zawarte w dokumencie.

1.3. Aby wprowadzić zmiany lub uzupełnienia zadanie techniczne na kolejnych etapach rozwoju programu lub oprogramowania wydawany jest dodatek do niego. Koordynacja i zatwierdzanie uzupełnień do specyfikacji technicznych odbywa się w taki sam sposób, jak określono dla specyfikacji technicznych.

1.4. Regulamin musi zawierać następujące sekcje:

wstęp;

powody rozwoju;

cel rozwoju;

wymagania dotyczące programu lub oprogramowania;

wymagania dotyczące dokumentacji programu;

wskaźniki techniczne i ekonomiczne;

etapy i etapy rozwoju;

procedura kontroli i akceptacji;

Wnioski mogą być zawarte w specyfikacjach technicznych.

W zależności od funkcji programu lub oprogramowania możliwe jest wyjaśnienie treści sekcji, wprowadzenie nowych sekcji lub połączenie poszczególnych sekcji.

(Wydanie zmienione, zmiana nr 1).

2.1. W sekcji „Wprowadzenie” należy podać nazwę, krótki opis zakresu zastosowania programu lub oprogramowania oraz przedmiot, w jakim program lub produkt jest używany.

2.2. Sekcja „Podstawa rozwoju” powinna wskazywać:

dokument(-y), na podstawie którego przeprowadzane jest opracowywanie;

organizacja, która zatwierdziła ten dokument i data jego zatwierdzenia;

imię i (lub) symbol tematy rozwojowe.

2.1, 2.2 (Wydanie zmienione, zmiana nr 1).

2.3. Sekcja „Cel rozwoju” musi wskazywać funkcjonalny i operacyjny cel programu lub oprogramowania.

2.4. Sekcja „Wymagania dotyczące programu lub oprogramowania” powinna zawierać następujące podsekcje:

wymagania dotyczące cech funkcjonalnych;

wymagania dotyczące niezawodności;

Warunki korzystania;

wymagania dotyczące składu i parametrów środki techniczne;

wymagania dotyczące kompatybilności informacji i oprogramowania;

wymagania dotyczące etykietowania i pakowania;

wymagania dotyczące transportu i przechowywania;

specjalne wymagania.

(Wydanie zmienione, zmiana nr 1).

2.4.1. Podsekcja „Wymagania dotyczące cech funkcjonalnych” musi wskazywać wymagania dotyczące składu wykonywanych funkcji, organizacji danych wejściowych i wyjściowych, charakterystyk czasowych itp.

2.4.2. W podrozdziale „Wymagania dotyczące niezawodności” należy wskazać wymagania dotyczące zapewnienia niezawodnego działania (zapewnienie stabilnej pracy, monitorowanie informacji wejściowych i wyjściowych, czas odzyskiwania po awarii itp.).

2.4.3. W podrozdziale „Warunki pracy” należy wskazać warunki pracy (temperatura otoczenia, wilgotność względna itp. dla wybranych rodzajów nośników danych), w jakich muszą być zapewnione określone charakterystyki, a także rodzaj usługi, wymaganą liczbę i kwalifikacje personel.

2.4.4. W podrozdziale „Wymagania dotyczące składu i parametrów środków technicznych” wskazano wymagany skład środków technicznych, wskazując ich główne cechy techniczne.

2.4.5 W podsekcji „Wymagania dotyczące kompatybilności informacji i oprogramowania” należy wskazać wymagania dotyczące struktury informacyjne na wejściach i wyjściach oraz metodach rozwiązań, kody źródłowe, języków programowania i oprogramowania wykorzystywanego przez program.

Tam, gdzie jest to konieczne, należy zapewnić ochronę informacji i programów.

(Wydanie zmienione, zmiana nr 1).

2.4.6. W podrozdziale „Wymagania dotyczące znakowania i pakowania” ogólnie wskazano wymagania dotyczące oznaczania oprogramowania, możliwości i metod pakowania.

2.4.7. W podsekcji „Wymagania dotyczące transportu i przechowywania” należy wskazać dla oprogramowania warunki transportu, miejsca przechowywania, warunki przechowywania, warunki przechowywania, okresy przechowywania w różnych warunkach.

2,5a. Sekcja „Wymagania dotyczące dokumentacji programu” powinna wskazywać wstępny skład dokumentacji programu i, jeśli to konieczne, specjalne wymagania dla niej.

(Wprowadzono dodatkowo zmianę nr 1).

2.5. Sekcja „Wskaźniki techniczne i ekonomiczne” powinna wskazywać: szacowaną efektywność ekonomiczną, szacowany roczny popyt, korzyści ekonomiczne rozwoju w porównaniu z najlepszymi próbkami lub analogami krajowymi i zagranicznymi.

2.6. W części „Etapy i etapy rozwoju” określone są niezbędne etapy rozwoju, etapy i treść pracy (lista dokumentów programowych, które należy opracować, uzgodnić i zatwierdzić), a także z reguły Określono ramy czasowe rozwoju i wykonawców.

2.7. Sekcja „Procedura kontroli i odbioru” musi wskazywać rodzaje testów i ogólne wymagania dotyczące odbioru pracy.

2.8. W załącznikach do specyfikacji technicznych, jeśli to konieczne, podaje się:

wykaz badań i innych prac uzasadniających rozwój;

diagramy algorytmów, tabele, opisy, uzasadnienia, obliczenia i inne dokumenty, które można wykorzystać podczas opracowywania;

inne źródła rozwoju.



Tekst dokumentu elektronicznego
przygotowane przez Kodeks JSC i zweryfikowane względem:
oficjalna publikacja
Ujednolicony system dokumentacji programu:
Zbiór norm krajowych. -
M.: Standartinform, 2010

Nazwa:

Ujednolicony system dokumentacji programu.

Ważny

Data wprowadzenia:

Data anulowania:

Zastąpione przez:

Tekst GOST 19.201-78 Ujednolicony system dokumentacji programu. Zadanie techniczne. Wymagania dotyczące treści i projektu

GOST 19.201-78

STANDARD MIĘDZYPAŃSTWOWY

UJEMNIONY SYSTEM DOKUMENTACJI OPROGRAMOWANIA

ZADANIE TECHNICZNE. WYMOGI DOTYCZĄCE TREŚCI I PROJEKTU

Oficjalna publikacja

Standardinform

STANDARD MIĘDZYPAŃSTWOWY

Ujednolicony system dokumentacji programu

ZADANIE TECHNICZNE. WYMOGI DOTYCZĄCE TREŚCI I PROJEKTU

Ujednolicony system dokumentacji programu.

Specyfikacja techniczna dla rozwoju. Wymagania dotyczące treści i formy prezentacji

Dekretem Państwowego Komitetu ds. Standardów ZSRR z dnia 18 grudnia 1978 r. nr 3351 ustalono datę wprowadzenia

Niniejsza norma ustanawia procedurę konstruowania i przygotowywania specyfikacji technicznych dotyczących tworzenia programu lub oprogramowania dla komputerów, kompleksów i systemów, niezależnie od ich przeznaczenia i zakresu.

Norma jest w pełni zgodna z ST SEV 1627-79.

1. POSTANOWIENIA OGÓLNE

1.1. Zakres obowiązków jest sporządzany zgodnie z GOST 19.106-78 na arkuszach formatu 11 i 12 zgodnie z GOST 2.301-68, z reguły bez wypełniania pól arkusza. Numery arkuszy (stron) umieszczane są w górnej części arkusza, nad tekstem.

1.2. Arkusz aprobaty i strona tytułowa są sporządzone zgodnie z GOST 19.104-78. Dozwolona jest część informacyjna (adnotacja i treść), w której znajduje się arkusz rejestracji zmian

nie dołączaj dokumentu.

1.3. Aby dokonać zmian lub uzupełnień w specyfikacjach technicznych na kolejnych etapach rozwoju programu lub oprogramowania, wydawany jest dodatek do nich. Koordynacja i zatwierdzanie uzupełnień do specyfikacji technicznych odbywa się w taki sam sposób, jak określono w przypadku specyfikacji technicznych.

1.4. Zakres obowiązków musi zawierać następujące sekcje: wprowadzenie;

przyczyny rozwoju; cel rozwoju;

wymagania dotyczące programu lub oprogramowania; wymagania dotyczące dokumentacji programu; wskaźniki techniczne i ekonomiczne; etapy i etapy rozwoju; procedura kontroli i akceptacji;

Wnioski mogą być zawarte w specyfikacjach technicznych.

W zależności od funkcji programu lub oprogramowania możliwe jest wyjaśnienie treści sekcji, wprowadzenie nowych sekcji lub połączenie poszczególnych sekcji.

(Wydanie zmienione, zmiana nr 1).

Oficjalna publikacja ★

Powielanie jest zabronione

) Wydawnictwo Standardy, 1978 © STANDARDINFORM, 2010

Wydanie (styczeń 2010) z poprawką nr 1, zatwierdzoną w czerwcu 1981 (IUS 9-81).

S. 2 GOST 19.201-78

2.1. W sekcji „Wprowadzenie” należy podać nazwę, krótki opis zakresu zastosowania programu lub oprogramowania oraz przedmiot, w jakim program lub produkt jest używany.

2.2. W sekcji „Podstawy opracowania” należy wskazać: dokument(y), na podstawie którego prowadzone jest opracowywanie; organizacja, która zatwierdziła ten dokument i data jego zatwierdzenia; nazwa i (lub) symbol tematu opracowania.

2.1. 2.2. (Wydanie zmienione, zmiana nr 1).

2.3. Sekcja „Cel rozwoju” musi wskazywać funkcjonalny i operacyjny cel programu lub oprogramowania.

2.4. Sekcja „Wymagania dotyczące programu lub oprogramowania” powinna zawierać następujące podsekcje:

wymagania dotyczące cech funkcjonalnych; wymagania dotyczące niezawodności; Warunki korzystania;

wymagania dotyczące składu i parametrów środków technicznych; wymagania dotyczące kompatybilności informacji i oprogramowania; wymagania dotyczące etykietowania i pakowania; wymagania dotyczące transportu i przechowywania; specjalne wymagania.

(Wydanie zmienione, zmiana nr 1).

2.4.1. Podsekcja „Wymagania dotyczące cech funkcjonalnych” powinna wskazywać wymagania dotyczące składu wykonywanych funkcji, organizacji danych wejściowych i wyjściowych, charakterystyk czasowych itp.

2.4.2. W podrozdziale „Wymagania dotyczące niezawodności” należy wskazać wymagania dotyczące zapewnienia niezawodnego działania (zapewnienie stabilnej pracy, monitorowanie informacji wejściowych i wyjściowych, czas odzyskiwania po awarii itp.).

2.4.3. W podrozdziale „Warunki pracy” należy wskazać warunki pracy (temperatura otoczenia, wilgotność względna itp. dla wybranych rodzajów nośników danych), w jakich muszą być zapewnione określone charakterystyki, a także rodzaj usługi, wymaganą liczbę i kwalifikacje personel.

2.4.4. W podrozdziale „Wymagania dotyczące składu i parametrów środków technicznych” wskazano wymagany skład środków technicznych, wskazując ich główne cechy techniczne.

2.4.5. W podsekcji „Wymagania dotyczące kompatybilności informacji i oprogramowania” należy wskazać wymagania dotyczące struktur informacyjnych na wejściu i wyjściu oraz metod rozwiązywania, kodów źródłowych, języków programowania i oprogramowania używanego przez program.

Tam, gdzie jest to konieczne, należy zapewnić ochronę informacji i programów.

(Wydanie zmienione, zmiana nr 1).

2.4.6. W podrozdziale „Wymagania dotyczące znakowania i pakowania” ogólnie wskazano wymagania dotyczące oznaczania oprogramowania, możliwości i metod pakowania.

2.4.7. Podrozdział „Wymagania dotyczące transportu i przechowywania” musi wskazywać dla oprogramowania warunki transportu, miejsca przechowywania, warunki przechowywania, warunki przechowywania, okresy przechowywania w różnych warunkach.

2,5a. Sekcja „Wymagania dotyczące dokumentacji programu” powinna wskazywać wstępny skład dokumentacji programu i, jeśli to konieczne, specjalne wymagania dla niej. (Wprowadzono dodatkowo zmianę nr 1).

2.5. Sekcja „Wskaźniki techniczne i ekonomiczne” powinna wskazywać: szacowaną efektywność ekonomiczną, szacowany roczny popyt, korzyści ekonomiczne rozwoju w porównaniu z najlepszymi próbkami lub analogami krajowymi i zagranicznymi.

2.6. W części „Etapy i fazy rozwoju” ustalone są niezbędne etapy rozwoju, etapy i treść pracy (lista dokumentów programowych, które należy opracować, uzgodnić i zatwierdzić), a także z reguły rozwój ramy czasowe i wykonawcy są ustalani.

2.7. Sekcja „Procedura kontroli i odbioru” powinna wskazywać rodzaje badań i ogólne wymagania dotyczące odbioru pracy.

2.8. W załącznikach do specyfikacji technicznych, jeżeli jest to konieczne, podaje się: wykaz badań i innych prac uzasadniających rozwój;

diagramy algorytmów, tabele, opisy, uzasadnienia, obliczenia i inne dokumenty, które można wykorzystać podczas opracowywania; inne źródła rozwoju.

• GOST 19.001-77 Ujednolicony system dokumentacji programu. Postanowienia ogólne
• GOST 19.005-85 Ujednolicony system dokumentacji programu. P-schematy algorytmów i programów. Konwencjonalne oznaczenia graficzne i zasady wykonania
• GOST 19.101-77 Ujednolicony system dokumentacji programu. Rodzaje programów i dokumenty programowe
• GOST 19.102-77 Ujednolicony system dokumentacji programu. Etapy rozwoju
• GOST 19.103-77 Ujednolicony system dokumentacji programu. Oznaczenia programów i dokumentów programowych
• GOST 19.104-78 Ujednolicony system dokumentacji programu. Podstawowe napisy
• GOST 19.105-78 Ujednolicony system dokumentacji programu. Ogólne wymagania dotyczące dokumentów programowych
• GOST 19.106-78 Ujednolicony system dokumentacji programu. Wymagania dotyczące drukowanych dokumentów programowych
• GOST 19.201-78 Ujednolicony system dokumentacji programu. Zadanie techniczne. Wymagania dotyczące treści i projektu
• GOST 19.202-78 Ujednolicony system dokumentacji programu. Specyfikacja. Wymagania dotyczące treści i projektu
• GOST 19.301-79 Ujednolicony system dokumentacji programu. Program i metodologia testów. Wymagania dotyczące treści i projektu
• GOST 19.401-78 Ujednolicony system dokumentacji programu. Tekst programu. Wymagania dotyczące treści i projektu
• GOST 19.402-78 Ujednolicony system dokumentacji programu. Opis programu
• GOST 19.403-79 Ujednolicony system dokumentacji programu. Lista oryginalnych posiadaczy
• GOST 19.404-79 Ujednolicony system dokumentacji programu. Notatka wyjaśniająca. Wymagania dotyczące treści i projektu
• GOST 19.501-78 Ujednolicony system dokumentacji programu. Formularz. Wymagania dotyczące treści i projektu
• GOST 19.502-78 Ujednolicony system dokumentacji programu. Opis aplikacji. Wymagania dotyczące treści i projektu
• GOST 19.503-79 Ujednolicony system dokumentacji programu. Przewodnik programisty systemu. Wymagania dotyczące treści i projektu
• GOST 19.504-79 Ujednolicony system dokumentacji programu. Przewodnik programisty. Wymagania dotyczące treści i projektu
• GOST 19.505-79 Ujednolicony system dokumentacji programu. Instrukcja obsługi. Wymagania dotyczące treści i projektu
• GOST 19.506-79 Ujednolicony system dokumentacji programu. Opis języka. Wymagania dotyczące treści i projektu
• GOST 19.507-79 Ujednolicony system dokumentacji programu. Lista dokumentów operacyjnych
• GOST 19.508-79 Ujednolicony system dokumentacji programu. Instrukcja konserwacji. Wymagania dotyczące treści i projektu
• GOST 19.601-78 Ujednolicony system dokumentacji programu. Ogólne zasady powielania, rozliczania i przechowywania
• GOST 19.602-78 Ujednolicony system dokumentacji programu. Zasady powielania, rozliczania i przechowywania drukowanych dokumentów programowych
• GOST 19.603-78 Ujednolicony system dokumentacji programu. Ogólne zasady dokonywania zmian
• GOST 19.604-78 Ujednolicony system dokumentacji programu. Zasady dokonywania zmian w drukowanych dokumentach programowych
• GOST 28195-89 Ocena jakości oprogramowania. Postanowienia ogólne
• GOST 34.601-90 Technologia informacyjna. Zbiór standardów dla systemów zautomatyzowanych. Zautomatyzowane systemy. Etapy tworzenia
• GOST 34.602-89 Technologia informacyjna. Zbiór standardów dla systemów zautomatyzowanych. Regulamin tworzenia zautomatyzowanego systemu
• GOST R 56447-2015 Gaz, kondensat gazowy, ropa naftowa i gaz oraz złoża ropy i kondensatu gazowego. Oprogramowanie do przetwarzania i interpretacji danych sejsmicznych. Podstawowe wymagania funkcjonalne i techniczne
• GOST R 56448-2015 Pola gazu, kondensatu gazowego, ropy i gazu oraz pól naftowo-gazowych. Oprogramowanie do modelowania geologicznego złóż. Podstawowe wymagania funkcjonalne i techniczne
• GOST R 56450-2015 Gaz, kondensat gazowy, ropa naftowa i gaz oraz złoża ropy i kondensatu gazowego. Oprogramowanie do modelowania hydrodynamicznego systemów gromadzenia i oczyszczania węglowodorów. Podstawowe wymagania funkcjonalne i techniczne
• GOST R 55711-2013 Zespół środków technicznych zautomatyzowanej adaptacyjnej komunikacji radiowej HF (HF) dupleks. Algorytmy pracy
• GOST R 56566-2015 Technologie informacyjne. Ocena procesu. Część 9. Docelowe profile procesów
• GOST R 55692-2013 Moduły elektroniczne. Metody kompilacji i debugowania programów testowych do automatycznego sterowania
• GOST R 56449-2015 Gaz, kondensat gazowy, ropa naftowa i gaz oraz złoża ropy i kondensatu gazowego. Oprogramowanie do modelowania hydrodynamicznego pól. Podstawowe wymagania funkcjonalne i techniczne
• GOST R 56413-2015 Technologie informacyjne. Europejskie profile stanowisk pracy w ICT
• GOST R ISO/IEC 15026-1-2016 Inżynieria systemów i oprogramowania. Gwarancja na systemy i oprogramowanie. Część 1. Pojęcia i słownictwo
• GOST R ISO/IEC 15026-4-2016 Inżynieria systemów i oprogramowania. Gwarancja na systemy i oprogramowanie. Część 4. Gwarancje cyklu życia
• GOST R 56920-2016 Inżynieria systemów i oprogramowania. Testowanie oprogramowania. Część 1. Pojęcia i definicje
• GOST R 56921-2016 Inżynieria systemów i oprogramowania. Testowanie oprogramowania. Część 2: Procesy testowe
• GOST R ISO/IEC 26555-2016 Inżynieria systemów i oprogramowania. Narzędzia i techniki zarządzania technicznego linii produktów
• GOST R ISO/IEC 29155-1-2016 Inżynieria systemów i oprogramowania. Struktura analizy porównawczej efektywności projektów informatycznych. Część 1. Pojęcia i definicje
• GOST R 54360-2011 Laboratoryjne systemy zarządzania informacją (LIMS). Standardowy przewodnik dotyczący walidacji LIMS
• GOST R 54593-2011 Technologie informacyjne. Darmowe oprogramowanie. Postanowienia ogólne
• GOST R ISO/IEC 12207-2010 Technologia informacyjna. Inżynieria systemów i oprogramowania. Procesy cyklu życia oprogramowania
• GOST R 53798-2010 Standardowy przewodnik dotyczący laboratoryjnych systemów zarządzania informacjami (LIMS)
• GOST R ISO/IEC 15504-1-2009 Technologie informacyjne. Ocena procesu. Część 1: Pojęcie i słownictwo
• GOST R ISO/IEC 15504-2-2009 Technologia informacyjna. Ocena procesu. Część 2: Przeprowadzenie oceny
• GOST R ISO/IEC 15504-3-2009 Technologia informacyjna. Ocena procesu. Część 3: Przewodnik po ocenie
• GOST R 57098-2016 Inżynieria systemów i oprogramowania. Zarządzanie cyklem życia. Przewodnik po opisie procesu
• GOST R 57100-2016 Inżynieria systemów i oprogramowania. Opis architektury
• GOST R 57101-2016 Inżynieria systemów i oprogramowania. Procesy cyklu życia. Zarządzanie projektami
• GOST R 57102-2016 Technologie informacyjne. Inżynieria systemów i oprogramowania. Zarządzanie cyklem życia. Część 2: Wytyczne dotyczące stosowania normy ISO/IEC 15288
• GOST R 57122-2016 Gaz, kondensat gazowy, ropa naftowa i gaz oraz złoża ropy i kondensatu gazowego. Cóż, oprogramowanie do projektowania konstrukcji. Podstawowe wymagania funkcjonalne i techniczne
• GOST R 57193-2016 Inżynieria systemów i oprogramowania. Procesy cyklu życia systemów
• GOST R ISO/IEC 15504-5-2016 Technologie informacyjne. Ocena procesu. Część 5: Przykładowy model oceny procesu cyklu życia oprogramowania
• GOST 34009-2016 Środki i systemy sterowania taborem trakcji kolejowej. Wymagania Systemowe
• GOST R 57318-2016 Systemy automatyki przemysłowej i integracja. Zastosowanie i zarządzanie procesami inżynierii systemów
• GOST R ISO/IEC 25001-2017 Technologia informacyjna. Inżynieria systemów i oprogramowania. Wymagania i ocena jakości systemów i oprogramowania (SQuaRE). Planowanie i zarządzanie
• GOST R ISO/IEC 33004-2017 Technologie informacyjne. Ocena procesu. Wymagania dotyczące modeli referencyjnych procesów, modeli oceny procesów i modeli dojrzałości
• GOST R ISO/IEC 15414-2017 Technologie informacyjne. Otwarte przetwarzanie rozproszone. Model referencyjny. Język opisu przedsiębiorstwa
• GOST IEC 60848-2016 Język specyfikacji GRAFCET dla sekwencyjnych diagramów funkcji
• GOST R ISO/IEC 25051-2017 Technologie informacyjne. Inżynieria systemów i oprogramowania. Wymagania i ocena jakości systemów i oprogramowania (SQuaRE). Wymagania jakościowe i instrukcje testowania gotowego do użycia oprogramowania (RUSP).
• GOST R ISO/IEC 33001-2017 Technologia informatyczna. Ocena procesu. Pojęcia i terminologia
• GOST R ISO/IEC 33002-2017 Technologie informacyjne. Ocena procesu. Wymagania dotyczące przeprowadzenia oceny procesu
• GOST R ISO/IEC 33003-2017 Technologie informacyjne. Ocena procesu. Wymagania dla systemów pomiaru procesów
• GOST R ISO/IEC 33020-2017 Technologie informacyjne. Ocena procesu. System pomiaru procesu do oceny zdolności procesu
• GOST R 57640-2017 Technologie informacyjne. Model referencyjny procesu (RPM) dla zarządzania bezpieczeństwem informacji
• GOST R ISO/IEC 30121-2017 Technologie informacyjne. Koncepcja zarządzania ryzykiem związanym z kryminalistycznym badaniem dowodów prezentowanych w formie cyfrowej
• GOST R 58041-2017 Gaz, kondensat gazowy, ropa naftowa i gaz oraz złoża ropy i kondensatu gazowego. System standardów oprogramowania do rozwiązywania problemów poszukiwania, rozpoznawania i zagospodarowania złóż. Podstawowe przepisy i wymagania techniczne
• GOST R 58042-2017 Gaz, kondensat gazowy, ropa naftowa i gaz oraz złoża ropy i kondensatu gazowego. Podstawowe wymagania dotyczące danych początkowych systemów oprogramowania do rozwiązywania problemów poszukiwania, rozpoznawania i zagospodarowania złóż
• GOST R ISO/IEC 10746-1-2004 Technologia informacyjna. Otwarte przetwarzanie rozproszone. Podstawowy model. Część 1. Postanowienia podstawowe
• GOST R ISO/IEC 10746-4-2004 Technologia informacyjna. Otwarte przetwarzanie rozproszone. Podstawowy model. Część 4. Semantyka architektoniczna

I tak główne standardy, metodologie i zasoby wiedzy, które wspominają o TK lub SRS (Specyfikacja wymagań oprogramowania (lub systemu)):

GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK itp.

GOST 34

Zgodnie z GOST 34 specyfikacja techniczna musi zawierać następujące sekcje:

1. Informacje ogólne
2. Cel i cele utworzenia (rozwoju) systemu
3. Charakterystyka obiektów automatyki
4. Wymagania systemowe
5. Skład i treść pracy nad stworzeniem systemu
6. Procedura kontroli i odbioru systemu
7. Wymagania dotyczące składu i treści prac przygotowujących obiekt automatyki do uruchomienia systemu
8. Wymagania dokumentacyjne
9. Źródła rozwoju

Opracowując specyfikacje techniczne dla projektów rządowych, Klienci z reguły wymagają zgodności z tą właśnie normą.

GOST 19

1. Wstęp;
2. Powody rozwoju;
3. Cel rozwoju;
4. Wymagania dotyczące programu lub oprogramowania;
5. Wymagania dotyczące dokumentacji programowej;
6. Wskaźniki techniczne i ekonomiczne;
7. Etapy i etapy rozwoju;
8. Procedura kontroli i akceptacji;
9. Aplikacje.

Oczywiście GOST 34 (i 19) są już przestarzałe i nie lubię ich używać, ale przy prawidłowej interpretacji standardów można uzyskać dobre specyfikacje techniczne, patrz Wniosek.

IEEE STD 830-1998

Opisuje zawartość i cechy jakościowe dobrze napisanej specyfikacji wymagań oprogramowania (SRS) oraz udostępnia kilka szablonów SRS. Ta zalecana praktyka ma na celu ustalenie wymagań dla oprogramowania w fazie rozwoju, ale może być również wykorzystana jako pomoc w wyborze oprogramowania zastrzeżonego i komercyjnego.

Zgodnie ze standardem zakres zadań musi zawierać następujące sekcje:

1. Wstęp

• 1. Cel
• 2. Zakres
• 3. Definicje, akronimy i skróty
• 4. Linki
• 5. Krótki przegląd

• 1. Interakcje produktu (z innymi produktami i komponentami)
• 2. Cechy produktu (krótki opis)
• 3. Charakterystyka użytkownika
• 4. Ograniczenia
• 5. Założenia i zależności

• 1. Wymagania dotyczące interfejsów zewnętrznych
  • 1. Interfejsy użytkownika
  • 2. Interfejsy sprzętowe
  • 3. Interfejsy oprogramowania
  • 4. Interfejsy interakcji
• 2. Wymagania funkcjonalne
• 3. Wymagania wydajnościowe
• 4. Ograniczenia projektowe (i odniesienia do norm)
• 5. Wymagania pozafunkcjonalne (niezawodność, dostępność, bezpieczeństwo itp.)
• 6. Inne wymagania

W rzeczywistości początkującemu dość trudno jest zrozumieć, co powinno być zawarte w tych sekcjach zgodnie z powyższą strukturą (jak w przypadku GOST), dlatego należy przeczytać sam standard, który. jednak po angielsku. język.

Cóż, dla tych, którzy doczytali do końca, bonus: przykład specyfikacji technicznych, który napisałem wiele lat temu (teraz już dawno nie pracuję jako analityk, a inne bardziej udane przykłady są zabronione) udostępniony do wglądu publicznego przez NDA).

• Prezentacja Yuri Buluy Klasyfikacja wymagań oprogramowania i jej reprezentacja w standardach i metodologiach.
• Analiza wymagań dla zautomatyzowanych systemów informatycznych. Wykład 11: Wymagania dotyczące dokumentowania.
• Zasady sporządzania specyfikacji wymagań oprogramowania (czytaj wraz z komentarzami)
• Przykłady specyfikacji technicznych i innej dokumentacji dotyczącej opracowania AS dla Ministerstwa Rozwoju
• Styl zarządzania GOST. Artykuł Gapertona na temat prawidłowej pracy ze specyfikacjami technicznymi zgodnie z GOST
• Szablony dokumentów analityka biznesowego z

Zakres obowiązków (TOR)- wykaz wymagań, warunków, celów, zadań ustalonych przez klienta na piśmie, udokumentowanych i wydanych wykonawcy prac projektowych i badawczych. Takie zadanie zwykle poprzedza opracowanie projektów i ma na celu poprowadzić dewelopera do stworzenia projektu spełniającego życzenia klienta i spełniającego warunki użytkowania, zastosowania opracowywanego projektu, a także ograniczenia zasobów.

Dlaczego potrzebujesz specyfikacji technicznej?

Wielu programistów często nie docenia znaczenia specyfikacji technicznych, jednak specyfikacje techniczne są ważnym, można powiedzieć, kamieniem węgielnym dokumentu w fazie rozwoju systemy informacyjne, strony internetowe, systemy inżynieryjne i wszystko inne.
Dziś, gdy Agile jest w modzie, może się wydawać, że dokument specyfikacji technicznych jest zbędny, ale tak jest do momentu, gdy stajesz przed rozwojem naprawdę poważnych systemów informatycznych, dużych produktów oprogramowania lub portali. Na palcach możesz wytłumaczyć, czego by sobie życzył Klient, gdyby w systemie było 3-5 obiektów-obiektów, a jeśli było ich znacznie więcej, to na pewno o czymś zapomniano. Potem zaczną rysować na papierze, pisać na serwetkach w kawiarni, wysyłać wiadomości na WhatsAppie: „Ale byłoby miło, gdyby niebieskie ikony znajdowały się w prawym rogu, a kiedy najedziesz myszką, przesuną się na środek i otrzymają większy!” Aby sformalizować ten proces, tworzona jest specyfikacja techniczna, czyli dokument mówiący, jak wszystko powinno wyglądać.
Regulamin spełnia szereg ważnych funkcji:

• Układa w głowie Klienta i Dewelopera jak system powinien wyglądać i co powinien robić.
• Chroni Programistę przed nagle pojawiającymi się nowymi wymaganiami Klienta, to znaczy Programista musi spełnić wszystko, co jest zapisane w specyfikacjach technicznych. Jeżeli Klient chce widzieć w programie inną funkcję, to musi za nią osobno zapłacić i przygotować dla niej odrębną Specyfikację Techniczną.
• Chroni Klienta przed lenistwem i niekompetencją Dewelopera, czyli program powinien wyglądać dokładnie tak, jak napisano w specyfikacji technicznej. Na podstawie Regulaminu Klient może dochodzić roszczeń wobec Dewelopera.

Ogólnie rzecz biorąc, opracowując system, pamiętaj o sporządzeniu Specyfikacji Technicznej! To uchroni Cię przed problemami.

Kto sporządza specyfikacje techniczne?

Specyfikacja techniczna jest dziełem nie jednej osoby, ale grupy osób:

• Analitycy ze strony Klienta - określają zapotrzebowanie na system i przedstawiają pisemne wymagania dla nowego programu.
• Analitycy ze strony Dewelopera - muszą zbadać obszar, w którym program będzie rozwijany, czyli firmę. Weź pod uwagę wszystkie schematy, algorytmy i niuanse pracy, którą wykona system.
• Pisarz techniczny to pracownik, który zbierze wszystkie dane analityków i zapisze je zgodnie z GOST.

Najczęściej specyfikacja techniczna wypełniona zgodnie z GOST jest wymogiem organów rządowych lub dużych przedsiębiorstw państwowych.
Pisanie specyfikacji technicznych to długa i trudna praca. Specyfikacja techniczna jest uzgadniana wielokrotnie przez kierownictwo klienta i dewelopera, a także jest wielokrotnie poprawiana i przepisana. Czasami napisanie dobrej specyfikacji technicznej zajmuje miesiąc lub dłużej, ale lepiej spędzić więcej czasu na pisaniu specyfikacji technicznych, niż później udowadniać, że nie chciało się tego i miałeś na myśli coś zupełnie innego. Przecież wszystkie błędy w Specyfikacjach Technicznych będą kosztować Dewelopera/Klienta pieniądze i czas.

Jakie standardy GOST służą do pisania specyfikacji technicznych?

Oczywiście SIWZ można sporządzić w dowolnej kolejności i jeśli Klient nie jest formalistą, małą firmą przestrzegającą standardów i nie jest instytucją rządową, to to wystarczy.

W Rosji specyfikacje techniczne są zapisywane zgodnie z dwoma GOST:

Do stworzenia modułu, programu lub zestawu programów wymagana jest Specyfikacja Techniczna zgodna z GOST. Jest to bardzo ważne, ponieważ właśnie tam opisano wszystkie punkty, co do których mogą później wyniknąć spory.

Który GOST powinienem wybrać dla specyfikacji technicznych?

Jeśli tworzysz dokumentację programu, który stworzyłeś dla konkretnego przedsiębiorstwa, wówczas Twój plik . Jeśli piszesz dokumenty do programu masowego, to twoje.

Czy istnieje możliwość wyboru replikowanego oprogramowania i systemu dla konkretnej organizacji? Tak, jest to możliwe, jeśli Klient z jakiegoś powodu nalega na to. We wszystkich innych przypadkach lepiej wybrać żądany GOST, ponieważ klauzule GOST są różne.

Czym GOST 34 różni się od GOST 19 podczas pisania specyfikacji technicznych?

Dla wygody poniżej znajduje się tabela punktów dotyczących pisania Regulaminu.

Poniżej rozważymy osobno każdą klauzulę GOST i GOST.

GOST 19 dla specyfikacji technicznych

Regulamin musi zawierać następujące sekcje:

1. wstęp;
2. powody rozwoju;
3. cel rozwoju;
4. wymagania dotyczące programu lub oprogramowania;
5. wymagania dotyczące dokumentacji programu;
6. wskaźniki techniczne i ekonomiczne;
7. etapy i etapy rozwoju;
8. procedura kontroli i akceptacji.

Dopuszcza się włączenie aplikacji do specyfikacji technicznych, a także, w zależności od cech programu lub oprogramowania, dozwolone jest doprecyzowanie treści sekcji specyfikacji technicznych, wprowadzenie nowych sekcji lub połączenie poszczególnych sekcji.

W sekcji 1” Wstęp » wskazać nazwę, krótki opis zakresu zastosowania programu lub oprogramowania oraz przedmiot, w jakim program lub oprogramowanie jest wykorzystywane.

W sekcji 2” Powody rozwoju » należy wskazać:

• dokument(-y), na podstawie którego przeprowadzane jest opracowywanie;
• organizacja, która zatwierdziła ten dokument i data jego zatwierdzenia;
• nazwa i (lub) symbol tematu opracowania.

W sekcji 3” Cel rozwoju » należy wskazać funkcjonalny i operacyjny cel programu lub oprogramowania.

Sekcja 4 " Wymagania dotyczące programu lub oprogramowania „powinien zawierać następujące podsekcje:

• wymagania dotyczące cech funkcjonalnych;
• wymagania dotyczące niezawodności;
• Warunki korzystania;
• wymagania dotyczące składu i parametrów środków technicznych;
• wymagania dotyczące kompatybilności informacji i oprogramowania;
• wymagania dotyczące etykietowania i pakowania;
• wymagania dotyczące transportu i przechowywania;
• specjalne wymagania.

W podrozdziale 4.1” Wymagania funkcjonalne » należy określić wymagania dotyczące składu wykonywanych funkcji, organizacji danych wejściowych i wyjściowych, charakterystyk czasowych itp.

W podrozdziale 4.2” Wymagania dotyczące niezawodności » należy określić wymagania zapewniające niezawodność działania (zapewnienie stabilnej pracy, monitorowanie informacji wejściowych i wyjściowych, czas regeneracji po awarii itp.).

W podrozdziale 4.3” Warunki korzystania » należy wskazać warunki pracy (temperatura otoczenia, wilgotność względna itp. dla wybranych rodzajów nośników danych), w jakich mają być zapewnione określone charakterystyki, a także rodzaj usługi, wymaganą liczbę i kwalifikacje personelu.

W podrozdziale 4.4” Wymagania dotyczące składu i parametrów środków technicznych » wskazać wymagany skład środków technicznych, wskazując ich główne cechy techniczne.

W podrozdziale „ Wymagania dotyczące kompatybilności informacji i oprogramowania » należy określić wymagania dotyczące struktur informacyjnych na wejściu i wyjściu oraz metod rozwiązywania, kodów źródłowych, języków programowania i oprogramowania wykorzystywanego przez program.

Tam, gdzie jest to konieczne, należy zapewnić ochronę informacji i programów.

W podrozdziale „ Wymagania dotyczące etykietowania i pakowania » ogólnie wskazać wymagania dotyczące oznakowania oprogramowania, możliwości i metod pakowania.

W podrozdziale „ Wymagania dotyczące transportu i przechowywania » dla oprogramowania należy podać warunki transportu, miejsca przechowywania, warunki przechowywania, warunki przechowywania, okresy przechowywania w różnych warunkach.

W sekcji 5” Wymagania dotyczące dokumentacji oprogramowania » należy wskazać wstępny skład dokumentacji programu i, jeśli to konieczne, specjalne wymagania dla niej.

W sekcji 6” Wskaźniki techniczne i ekonomiczne » należy wskazać: szacunkową efektywność ekonomiczną, szacunkowe roczne zapotrzebowanie, korzyści ekonomiczne inwestycji w porównaniu z najlepszymi wzorami lub analogiami krajowymi i zagranicznymi.

W sekcji 7” Etapy i etapy rozwoju » ustalić niezbędne etapy opracowania, etapy i treść prac (listę dokumentów programowych, które należy opracować, uzgodnić i zatwierdzić), a także co do zasady terminy opracowania i określić wykonawców.

W sekcji 8” Procedura kontroli i odbioru » należy wskazać rodzaje badań i ogólne wymagania dotyczące odbioru pracy.

W załącznikach do specyfikacji technicznych, jeśli to konieczne, podaje się:

• wykaz badań i innych prac uzasadniających rozwój;
• diagramy algorytmów, tabele, opisy, uzasadnienia, obliczenia i inne dokumenty, które można wykorzystać podczas opracowywania;
• inne źródła rozwoju.

GOST 34 dla specyfikacji technicznych

Specyfikacje techniczne oprogramowania zawierają następujące sekcje, które można podzielić na podrozdziały:

1. informacje ogólne;
2. cel i cele utworzenia (rozwoju) systemu;
3. charakterystyka obiektów automatyki;
4. wymagania systemowe;
5. skład i treść pracy nad stworzeniem systemu;
6. procedura kontroli i odbioru systemu;
7. wymagania dotyczące składu i treści pracy przygotowującej obiekt automatyki do uruchomienia systemu;
8. wymogi dokumentacyjne;
9. źródła rozwoju.

Specyfikacje techniczne mogą obejmować zastosowania.

W zależności od rodzaju, przeznaczenia, specyfiki obiektu automatyki oraz warunków pracy systemu możliwe jest sporządzanie odcinków Specyfikacji Technicznej w formie załączników, wprowadzanie dodatkowych, wyłączanie lub łączenie podrozdziałów specyfikacji technicznej .

Specyfikacje techniczne dla części systemu nie zawierają sekcji powielających treść sekcji Specyfikacji Technicznych dla systemu jako całości.

W sekcji 1” Informacje ogólne "wskazać:

• pełna nazwa systemu i jego symbol;
• kod przedmiotu lub kod (numer) zamówienia;
• nazwa przedsiębiorstw (stowarzyszeń) twórcy i klienta (użytkownika) systemu oraz ich dane;
• wykaz dokumentów, na podstawie których tworzony jest system, przez kogo i kiedy te dokumenty zostały zatwierdzone;
• planowane daty rozpoczęcia i zakończenia prac nad stworzeniem systemu;
• informacje o źródłach i trybie finansowania prac;
• procedura rejestracji i prezentacji klientowi wyników prac nad stworzeniem systemu (jego części), produkcją i dostosowaniem poszczególnych narzędzi (sprzętu, oprogramowania, informacji) oraz kompleksów oprogramowania i sprzętu (oprogramowania i metodyki) system.

Sekcja 2” Cel i cele utworzenia (rozwoju) systemu » składa się z podrozdziałów:

• cel systemu;
• cele tworzenia systemu.

W podrozdziale 2.1” Cel systemu » wskazać rodzaj działalności podlegającej automatyzacji (zarządzanie, projektowanie itp.) oraz listę obiektów automatyki (obiektów), na których ma ona zostać wykorzystana.

Dla zautomatyzowany system systemy kontroli (ACS) dodatkowo wskazują listę zautomatyzowanych jednostek kontrolnych (punktów) i kontrolowanych obiektów.

W podrozdziale 2.2” Cele tworzenia systemu » podać nazwy i wymagane wartości wskaźników technicznych, technologicznych, produkcyjno-ekonomicznych lub innych obiektu automatyzacji, które muszą zostać osiągnięte w wyniku stworzenia zautomatyzowanego systemu (AS), oraz wskazać kryteria oceny osiągnięcia celów tworzenia systemu.

W sekcji 3” Charakterystyka obiektu automatyki "dawać:

• krótka informacja o obiekcie automatyzacji lub linki do dokumentów zawierających takie informacje;
• informacje o warunkach pracy obiektu automatyki i charakterystykach środowiskowych.

Sekcja 4 " Wymagania systemowe » składa się z następujących podrozdziałów:

• wymagania dla systemu jako całości;
• wymagania dla funkcji (zadań) realizowanych przez system;
• wymogi dotyczące rodzajów zabezpieczeń.

Skład wymagań dla systemu zawartych w niniejszym rozdziale specyfikacji technicznych elektrowni jądrowej ustalany jest w zależności od rodzaju, przeznaczenia, specyfiki i warunków pracy konkretnego systemu. Każda podsekcja zawiera łącza do aktualnych dokumentów regulacyjnych i technicznych (NTD), które definiują wymagania dla systemów odpowiedniego typu.

W podrozdziale 4.1” Wymagania dla systemu jako całości "wskazać:

• wymagania dotyczące struktury i funkcjonowania systemu;
• wymagania dotyczące liczby i kwalifikacji personelu systemu oraz sposobu jego działania;
• wskaźniki przeznaczenia;
• wymagania dotyczące niezawodności;
• wymagania bezpieczeństwa;
• wymagania dotyczące ergonomii i estetyki technicznej;
• wymagania dotyczące transportu głośników przenośnych;
• wymagania dotyczące eksploatacji, konserwacji, naprawy i przechowywania elementów systemu;
• wymagania dotyczące ochrony informacji przed nieuprawnionym dostępem;
• wymagania dotyczące bezpieczeństwa informacji w razie wypadków;
• wymagania dotyczące ochrony przed wpływami zewnętrznymi;
• wymagania czystości patentowej;
• wymagania dotyczące standaryzacji i unifikacji;
• Dodatkowe wymagania.

W wymagania dotyczące struktury i funkcjonowania systemu dać (klauzula TOR 4.1.1):

• lista podsystemów, ich przeznaczenie i główne cechy, wymagania dotyczące liczby poziomów hierarchii i stopnia centralizacji systemu;
• wymagania dotyczące metod i środków komunikacji w celu wymiany informacji pomiędzy elementami systemu;
• wymagania dotyczące charakterystyki powiązań tworzonego systemu z systemami powiązanymi, wymagania dotyczące jego kompatybilności, w tym instrukcje dotyczące sposobów wymiany informacji (automatycznie, poprzez przesyłanie dokumentów, telefonicznie itp.);
• wymagania dotyczące trybów pracy systemu;
• wymagania diagnostyczne systemu;
• perspektywy rozwoju i modernizacji systemu.

W wymagania dotyczące liczby i kwalifikacji personelu w AS podano, co następuje (klauzula TOR 4.1.2):

• wymagania dotyczące liczby personelu (użytkowników) elektrowni jądrowej;
• wymagania dotyczące kwalifikacji personelu, procedury jego szkolenia oraz kontroli wiedzy i umiejętności;
• wymagany tryb pracy dla personelu zakładu.

W wymagania dotyczące wskaźników miejsca docelowego AS podaje wartości parametrów charakteryzujących stopień zgodności systemu z jego przeznaczeniem (klauzula TK 4.1.3).

Dla ACS wskazać:

• stopień przystosowania systemu do zmian procesów i metod sterowania, do odchyleń parametrów obiektu regulacji;
• dopuszczalne granice modernizacji i rozwoju systemu;
• Charakterystyka probabilistyczno-czasowa, w ramach której specjalny cel systemy.

W wymagania dotyczące niezawodności obejmują (klauzula TOR 4.1.4):

• skład i ilościowe wartości wskaźników niezawodności systemu jako całości lub jego podsystemów;
• lista sytuacji awaryjnych, dla których należy uregulować wymagania dotyczące niezawodności, oraz wartości odpowiednich wskaźników;
• wymagania dotyczące niezawodności sprzętu i oprogramowania;
• wymagania dotyczące metod oceny i monitorowania wskaźników niezawodności na różnych etapach tworzenia systemu zgodnie z obowiązującymi dokumentami regulacyjnymi i technicznymi.

W wymagania bezpieczeństwa (pkt TZ 4.1.5) zawierają wymagania dotyczące zapewnienia bezpieczeństwa podczas instalacji, rozruchu, eksploatacji, konserwacji i naprawy urządzeń technicznych systemu (ochrona przed uderzeniami prąd elektryczny, pola elektromagnetyczne, hałas akustyczny itp.), zgodnie z dopuszczalnymi poziomami oświetlenia, obciążeniami wibracyjnymi i hałasem.

W wymagania dotyczące ergonomii i estetyki technicznej (klauzula TK 4.1.4) obejmują wskaźniki AS, które określają wymaganą jakość interakcji człowiek-maszyna i komfort warunków pracy personelu.

Do głośników mobilnych w wymagania dotyczące możliwości transportu (klauzula TK 4.1.7) zawierają wymagania projektowe zapewniające możliwość transportu środków technicznych systemu, a także wymagania dotyczące pojazdów.

W wymagania dotyczące obsługi, konserwacji, naprawy i przechowywania obejmują (klauzula TOR 4.1.8):

• warunki i przepisy (tryb) działania, które muszą zapewniać wykorzystanie środków technicznych (ST) systemu o określonych wskaźnikach technicznych, w tym rodzaje i częstotliwość utrzymania TS systemu lub dopuszczalność pracy bez konserwacji;
• wstępne wymagania dotyczące dopuszczalnych powierzchni do przebywania personelu i pojazdów systemowych, parametrów sieci zasilających itp.;
• wymagania dotyczące liczby, kwalifikacji personelu serwisowego i sposobu jego pracy;
• wymagania dotyczące składu, rozmieszczenia i warunków przechowywania zestawu produktów i urządzeń zamiennych;
• wymagania regulaminu świadczenia usług.

W wymagania dotyczące ochrony informacji przed nieuprawnionym dostępem (klauzula TK 4.1.9) uwzględniają wymagania określone w dokumentacji normatywnej i technicznej obowiązującej w branży (oddziale) Klienta.

W wymogi bezpieczeństwa informacji (klauzula TK 4.1.10) podaje listę zdarzeń: wypadków, awarii urządzeń technicznych (w tym utraty zasilania) itp., w których należy zapewnić bezpieczeństwo informacji w systemie.

W wymagania dotyczące środków ochrony przed wpływami zewnętrznymi dać (klauzula TOR 4.1.11):

• wymagania dotyczące ochrony radioelektronicznej elektrowni jądrowych;
• wymagania dotyczące trwałości, stabilności i wytrzymałości na wpływy zewnętrzne (środowisko użytkowania).

W wymagania dotyczące zezwolenia patentowego (klauzula TOR 4.1.12) wskazuje listę krajów, w odniesieniu do których należy zapewnić czystość patentową systemu i jego części.

W wymagania dotyczące standaryzacji i unifikacji obejmują (klauzula TOR 4.1.13): wskaźniki określające wymagany stopień wykorzystania standardowych, ujednoliconych metod realizacji funkcji (zadań) dostarczanego systemu oprogramowanie, typowy metody matematyczne i modele, standardowe rozwiązania projektowe, ujednolicone formy dokumentów zarządczych ustanowione przez GOST 6.10.1, ogólnounijne klasyfikatory informacji technicznych i ekonomicznych oraz klasyfikatory innych kategorii zgodnie z ich obszarem zastosowania, wymagania dotyczące korzystania ze standardowych zautomatyzowanych stacji roboczych, składniki i kompleksy.

W Dodatkowe wymagania obejmują (klauzula TOR 4.1.14):

• wymagania dotyczące wyposażenia systemu w urządzenia do szkolenia personelu (symulatory, inne urządzenia o podobnym przeznaczeniu) oraz dokumentację do nich;
• wymagania dotyczące sprzętu serwisowego, stanowisk do testowania elementów systemów;
• wymagania systemowe związane ze specjalnymi warunkami pracy;
• specjalne wymagania według uznania twórcy systemu lub klienta.

W podrozdziale 4.2” Wymagania dla funkcji (zadań) „wykonywane przez system prowadzi do:

• dla każdego podsystemu wykaz funkcji, zadań lub ich zespołów (w tym zapewniających współdziałanie części systemu), które mają zostać zautomatyzowane;
• podczas tworzenia systemu w dwóch lub więcej kolejkach - lista podsystemy funkcjonalne, poszczególne funkcje lub zadania uruchomione w I i kolejnych etapach;
• regulacje czasowe realizacji każdej funkcji, zadania (lub zestawu zadań);
• wymagania dotyczące jakości realizacji każdej funkcji (zadania lub zestawu zadań), formy prezentacji informacji wyjściowych, charakterystyki wymaganej dokładności i czasu wykonania, wymagania dotyczące jednoczesnej realizacji grupy funkcji, niezawodności wyniki;
• lista i kryteria awarii dla każdej funkcji, dla której określono wymagania niezawodności.

W podrozdziale 4.3” Wymagania dotyczące rodzajów zabezpieczeń » w zależności od rodzaju systemu podane są wymagania dotyczące wsparcia matematycznego, informacyjnego, językowego, programowego, technicznego, metrologicznego, organizacyjnego, metodologicznego i innych.

Dla oprogramowanie (klauzula TK 4.3.1) systemy określają wymagania dotyczące składu, zakresu stosowania (ograniczeń) i sposobów wykorzystania metod i modeli matematycznych, algorytmów standardowych i algorytmów, które mają być opracowane w systemie.

Dla wsparcie informacyjne systemy zapewniają wymagania (klauzula TOR 4.3.2):

• do składu, struktury i sposobów organizacji danych w systemie;
• do wymiany informacji pomiędzy elementami systemu;
• do zgodności informacji z powiązanymi systemami;
• w sprawie stosowania ogólnounijnych i rejestrowanych klasyfikatorów republikańskich, branżowych, ujednoliconych dokumentów i klasyfikatorów działających w danym przedsiębiorstwie;
• w sprawie stosowania systemów zarządzania bazami danych;
• do struktury procesu gromadzenia, przetwarzania, przesyłania danych w systemie i prezentacji danych;
• chronić dane przed zniszczeniem podczas wypadków i awarii zasilania systemu;
• do kontroli, przechowywania, aktualizacji i odzyskiwania danych;
• do procedury nadawania mocy prawnej dokumentom wyprodukowanym środkami technicznymi elektrowni jądrowej (zgodnie z GOST 6.10.4).

Dla wsparcie językowe (klauzula TK 4.3.3) systemy określają wymagania dotyczące stosowania języków programowania w systemie wysoki poziom, języki interakcji użytkownika i sprzęt systemowy, a także wymagania dotyczące kodowania i dekodowania danych, języki wejścia/wyjścia danych, języki manipulacji danymi, narzędzia opisu Tematyka(obiekt automatyzacji), po sposoby organizacji dialogu.

Dla oprogramowanie (klauzula TK 4.3.4) system udostępnia listę zakupionego oprogramowania oraz wymagania:

• do niezależności oprogramowania od używanego SVT i środowiska operacyjnego;
• do jakości oprogramowania oraz metod jego zapewniania i monitorowania;
• w razie potrzeby koordynować nowo powstałe oprogramowanie z zasobami algorytmów i programów.

Dla pomoc techniczna (klauzula TOR 4.3.5) systemy zapewniają następujące wymagania:

• do rodzajów środków technicznych, w tym rodzajów zespołów środków technicznych, zespołów oprogramowania i sprzętu komputerowego oraz innych elementów dopuszczalnych do stosowania w systemie;
• do cech funkcjonalnych, projektowych i operacyjnych wsparcia technicznego systemu.

W wymagania dotyczące wsparcia metrologicznego (klauzula TOR 4.3.6) podaje:

• wstępna lista kanałów pomiarowych;
• wymagania dotyczące dokładności pomiarów parametrów i (lub) właściwości metrologicznych kanałów pomiarowych;
• wymagania dotyczące kompatybilności metrologicznej środków technicznych systemu;
• wykaz kanałów sterujących i obliczeniowych systemu, dla których konieczna jest ocena charakterystyk dokładności;
• wymagania dotyczące obsługi metrologicznej sprzętu i oprogramowania wchodzącego w skład kanałów pomiarowych systemu, wbudowanych narzędzi kontrolnych, przydatności metrologicznej kanałów pomiarowych oraz przyrządów pomiarowych stosowanych podczas rozruchu i testowania systemu;
• rodzaj certyfikacji metrologicznej (państwowy lub wydziałowy) ze wskazaniem procedury jej wdrażania oraz organizacji przeprowadzających certyfikację.

Dla wsparcie organizacyjne podać wymagania (klauzula TOR 4.3.7):

• do struktury i funkcji jednostek biorących udział w obsłudze systemu lub zapewniających eksploatację;
• do organizacji funkcjonowania systemu i trybu interakcji pomiędzy personelem zakładu a personelem automatyki;
• do ochrony przed błędnymi działaniami personelu systemu.

Dla wsparcie metodyczne CAD (klauzula TOR 4.3.8) podają wymagania dotyczące składu dokumentacji regulacyjnej i technicznej systemu (lista norm, przepisów, metod itp. stosowanych w jego działaniu).

Sekcja 5” Skład i treść pracy nad stworzeniem (rozwojem) systemu » musi zawierać wykaz etapów i faz prac nad utworzeniem systemu zgodnie z GOST 24.601, terminy ich zakończenia, listę organizacji wykonujących prace, linki do dokumentów potwierdzających zgodę tych organizacji na udział w tworzeniu systemu systemu lub zapis identyfikujący osobę odpowiedzialną (klient lub programista) za wykonanie tej pracy.

W ta sekcja zacytuj także:

• wykaz dokumentów przedstawianych po zakończeniu odpowiednich etapów i faz pracy;
• rodzaj i tryb badania dokumentacji technicznej (etap, etap, objętość sprawdzanej dokumentacji, organizacja ekspercka);
• program prac mający na celu zapewnienie wymaganego poziomu niezawodności tworzonego systemu (jeśli jest to konieczne);
• wykaz prac związanych ze wsparciem metrologicznym na wszystkich etapach tworzenia systemu, ze wskazaniem ich terminów i organizacji realizujących (jeśli to konieczne).

W sekcji 6” Procedura kontroli i odbioru systemu "wskazać:

• rodzaje, skład, objętość i metody testowania systemu i jego składniki(rodzaje testów zgodnie z obowiązującymi normami obowiązującymi dla opracowywanego systemu);
• ogólne wymagania dotyczące akceptacji prac według etapów (lista uczestniczących przedsiębiorstw i organizacji, lokalizacja i termin), procedura koordynacji i zatwierdzania dokumentacji odbiorowej;
• status komisji akceptacyjnej (stanowy, międzyresortowy, departamentalny).

W sekcji 7” Wymagania dotyczące składu i treści prac mających na celu przygotowanie obiektu automatyki do uruchomienia systemu » należy podać listę głównych czynności i ich wykonawców, które należy wykonać przygotowując obiekt automatyki do oddania instalacji do eksploatacji.

Lista głównych działań obejmuje:

• doprowadzenie informacji wprowadzanych do systemu (zgodnie z wymogami obsługi informacyjno-językowej) do postaci nadającej się do przetwarzania komputerowego;
• zmiany, które należy wprowadzić w obiekcie automatyki;
• stworzenie warunków funkcjonowania obiektu automatyki, w ramach których zapewniona jest zgodność tworzonego systemu z wymaganiami zawartymi w specyfikacjach technicznych;
• tworzenie działów i służb niezbędnych do funkcjonowania systemu;
• warunki i procedury dotyczące personelu i szkoleń.

Na przykład dla zautomatyzowanych systemów sterowania podają:

• zmiany w stosowanych metodach zarządzania;
• tworzenie warunków pracy elementów systemów automatycznego sterowania, zapewniających zgodność systemu z wymaganiami zawartymi w specyfikacjach technicznych.

W sekcji 8” Wymogi dokumentacyjne "dawać:

• wykaz zestawów i typów dokumentów do opracowania, odpowiadających wymaganiom i specyfikacjom technicznym branży Klienta, uzgodniony pomiędzy twórcą i Klientem systemu;
• wykaz dokumentów wydanych na nośnikach komputerowych;
• wymagania dotyczące dokumentacji mikrofilmowej;
• wymagania dotyczące dokumentowania komponentów do zastosowań międzybranżowych zgodnie z wymaganiami ESKD i ESPD;
• w przypadku braku norm państwowych określających wymagania dotyczące dokumentowania elementów systemu, należy dodatkowo uwzględnić wymagania dotyczące składu i zawartości tych dokumentów.

W sekcji 9” Źródła rozwoju » dokumenty muszą być wymienione i materiały informacyjne(studia wykonalności, sprawozdania z przeprowadzonych prac badawczych, materiały informacyjne dotyczące krajowych i zagranicznych systemów analogowych itp.), na podstawie których opracowano specyfikacje techniczne, które należy wykorzystać przy tworzeniu systemu.

W przypadku zatwierdzonych metod specyfikacje techniczne elektrowni jądrowych obejmują: Aplikacje zawierający:

• obliczenie oczekiwanej wydajności systemu;
• ocena poziomu naukowo-technicznego systemu.

Aplikacje są zawarte w specyfikacjach technicznych elektrowni jądrowej uzgodnionych pomiędzy twórcą a klientem systemu.

Wniosek

Napisanie specyfikacji technicznej to mnóstwo pracy! Najważniejsze jest, aby zrozumieć, co należy zapisać w specyfikacji technicznej i jakiego GOST w tym celu użyć. Specyfikacja techniczna według GOST nie jest dokumentem trudnym, niepotrzebnym i niezrozumiałym, ale układu szeregowego zasad, co pozwala uwzględnić wszystkie możliwe kwestie związane z opracowaniem nowej specyfikacji technicznej. Nie bój się używać GOST. GOST nie jest straszny, ale łatwy i bardzo przydatny!

Specyfikacje techniczne są bardzo ważne i wymagany dokument, co pozwala zrozumieć, jak powinien wyglądać nowy program, a także pozwala uniknąć nieporozumień i nieporozumień. Nie należy liczyć na pełne wzajemne zrozumienie Klienta i Dewelopera. Jeśli specyfikacja techniczna zostanie napisana niedokładnie, czas opracowania wydłuży się nowy program, co doprowadzi do straty pieniędzy i nerwów. Dzięki temu specyfikacja techniczna oszczędza czas, pieniądze, nerwy i wysiłek, a Klient będzie miał pewność, że otrzyma dokładnie taki program, o jaki prosił.

Mam nadzieję, że ten artykuł ułatwi Ci napisanie Specyfikacji Technicznej!

Niniejsza norma ustanawia procedurę konstruowania i przygotowywania specyfikacji technicznych dotyczących tworzenia programu lub oprogramowania dla komputerów, kompleksów i systemów, niezależnie od ich przeznaczenia i zakresu.

Norma jest w pełni zgodna z ST SEV 1627-79.

Zasady projektowania

Zakres obowiązków jest sporządzany zgodnie z GOST 19.106-78 na arkuszach formatu 11 i 12 zgodnie z GOST 2.301-68, z reguły bez wypełniania pól arkusza. Numery arkuszy (stron) umieszczane są w górnej części arkusza, nad tekstem.

Arkusz zatwierdzenia i arkusz tytułowy

Arkusz aprobaty i strona tytułowa są sporządzone zgodnie z GOST 19.104-78.

Część informacyjna (adnotacja i treść) oraz karta rejestracji zmiany nie mogą być zawarte w dokumencie.

Tę szansę należy wykorzystać. Mniej słów - mniej pytań.

Zmiany i uzupełnienia

Aby dokonać zmian lub uzupełnień w specyfikacjach technicznych na kolejnych etapach rozwoju programu lub oprogramowania, wydawany jest dodatek do nich. Koordynacja i zatwierdzanie uzupełnień do specyfikacji technicznych odbywa się w taki sam sposób, jak określono dla specyfikacji technicznych.

Niemożliwe jest uwzględnienie wszystkich szczegółów na początkowym etapie rozwoju. W praktyce podejście to jest stosowane dość często. W części „Etapy i etapy rozwoju” należy wyraźnie wskazać możliwość wprowadzenia zmian i uzupełnień do specyfikacji technicznych: „Treść rozdziałów niniejszej specyfikacji technicznej może być zmieniana i uzupełniana w drodze porozumienia z Klientem.”

Skład sekcji specyfikacji technicznych

Regulamin musi zawierać następujące sekcje:

• wstęp;
• powody rozwoju;
• cel rozwoju;
• wymagania dotyczące programu lub oprogramowania;
• wymagania dotyczące dokumentacji programu;
• wskaźniki techniczne i ekonomiczne;
• etapy i etapy rozwoju;
• procedura kontroli i akceptacji;
• Wnioski mogą być zawarte w specyfikacjach technicznych.

W zależności od funkcji programu lub oprogramowania możliwe jest wyjaśnienie treści sekcji, wprowadzenie nowych sekcji lub połączenie poszczególnych sekcji.

Ściśle w porozumieniu z Klientem. Zgoda Klienta musi być odzwierciedlona w tekście specyfikacji technicznych.

Celem rekomendacji jest wskazanie metodologii, podanie praktyczne zalecenia opracować specyfikacje techniczne programu (oprogramowania) z uwzględnieniem wymagań GOST 19.201-78.

Niektóre podpunkty specyfikacji technicznej mogą działać na warunkowego Klienta jak czerwona płachta na byka. Klient, nawet warunkowy, nie powinien się denerwować. W kontrowersyjnych podrozdziałach rozważone zostaną sposoby znalezienia rozwiązań kompromisowych. Omówione zostaną także kluczowe stanowiska, w których ustępstwo na rzecz Klienta jest równoznaczne z zaciśnięciem pętli na szyi Wykonawcy, wraz z uzasadnieniem twardej pozycji Wykonawcy.

Aby niepotrzebnie nie obciążać przebiegu historii, skorzystamy prawdziwy program z grafiką interfejs użytkownika, zapewniając możliwość wykonywania kilku funkcji szablonu. Niech taki program stanie się prostym edytorem tekstu.

Wstęp

Sekcja wskazuje nazwę, krótki opis zakresu zastosowania programu lub oprogramowania oraz przedmiot, w jakim program lub oprogramowanie jest używane.

Podstawową zasadą pracy z tekstem jest uszczegółowienie, dzielenie tekstu na jednostki strukturalne, podrozdziały, akapity i akapity. Spis treści tekstu będzie miał przejrzystą strukturę, która ułatwi odnalezienie potrzebnego materiału. Tekst dokumentu stanie się uporządkowany i łatwy do odczytania. Utwórz podsekcje:

Nazwa programu

Nazwa - " Edytor tekstu do pracy z plikami formacie rtf».

krótki opis Obszary zastosowań

Program przeznaczony jest do użytku w wyspecjalizowanych działach w siedzibie Klienta.

Treść poszczególnych pozycji nie zawsze jest oczywista. Jeśli masz jakiekolwiek trudności, powinieneś podejść do nich formalnie. Korekty można dokonać na etapie uzgadniania specyfikacji technicznych z Klientem.

Powody rozwoju

Sekcja powinna wskazywać:

1. dokument(-y), na podstawie którego przeprowadzane jest opracowywanie;
2. organizacja, która zatwierdziła ten dokument i data jego zatwierdzenia;
3. nazwa i (lub) symbol tematu opracowania.

Podpunkt powinien zawierać informacje zawarte w Umowie.

Podstawa rozwoju

Podstawą opracowania jest Umowa (pismo itp.) nr 666 z dnia 32 marca 2004 r. (nr przychodzący taki a taki od takiego a takiego). Umowa została uzgodniona z Dyrektorem Państwowego Przedsiębiorstwa Unitarnego „Spetstyazhmontazhstroyselkhozavtomatika” Ivanov Petr Ivanovich, zwanym dalej Klientem, i zatwierdzona przez Dyrektora Generalnego OJSC „Supersoft” Blyumkins Ivan Aronovich, zwanego dalej Wykonawcą, w dniu taki i taki marzec 2004.

Wygodne jest korzystanie z sekcji „Informacje ogólne” GOST 34.602-89, ponieważ deweloper ma pełne prawo dodawać i usuwać sekcje specyfikacji technicznych według własnego uznania. Jednocześnie informacje określone powyżej zawarte są w Umowie. To, czy należy je uwzględnić w SIWZ, zależy od konkretnego przypadku.

Cel funkcjonalny

Celem funkcjonalnym programu jest zapewnienie użytkownikowi możliwości pracy z dokumentami tekstowymi w formacie rtf.

Podrozdział powinien wskazywać „rozszerzony” cel funkcjonalny programu. Szczegóły – lista funkcji itp. - zostaną podane poniżej w odpowiednich sekcjach.

Cel operacyjny można interpretować dość szeroko. Gdzie, jak, przez kogo, z czym należy używać programu?

Opony tego samego rozmiaru można z powodzeniem stosować w pojazdach Zhiguli i Wołga, ale nie w KamAZ. I wzajemnie. Ale dla każdego konkretnego rozmiaru gumy można określić jego cel operacyjny.

Zastosujmy podejście formalne:

Wymagania dotyczące programu lub oprogramowania

Sekcja powinna zawierać następujące podsekcje:

1. wymagania dotyczące cech funkcjonalnych;
2. wymagania dotyczące niezawodności;
3. Warunki korzystania;
4. wymagania dotyczące składu i parametrów środków technicznych;
5. wymagania dotyczące kompatybilności informacji i oprogramowania;
6. wymagania dotyczące etykietowania i pakowania;
7. wymagania dotyczące transportu i przechowywania;
8. specjalne wymagania.

Jeśli istnieją standardy zawierające ogólne (techniczne) wymagania dotyczące programu, systemu lub produktu, na przykład „GOST 12345-67. Zautomatyzowane systemy informacyjno-pomiarowe. Wymagania ogólne (techniczne)” opracowywanie specyfikacji technicznych zostaje znacznie uproszczone. Większość treści określonej normy jest po prostu przepisana w specyfikacjach technicznych.

Wymagania dotyczące składu wykonywanych funkcji

Program musi zapewniać możliwość realizacji następujących funkcji:

1. funkcje umożliwiające utworzenie nowego (pustego) pliku.
2. funkcje otwierania (ładowania) istniejącego pliku.
3. funkcje umożliwiające edycję otwartego (zwanego dalej bieżącym) pliku poprzez wprowadzenie, zamianę, usunięcie zawartości pliku przy użyciu standardowych urządzeń wejściowych.
4. funkcje edycji bieżącego pliku za pomocą schowka system operacyjny.
5. funkcje zapisu pliku pod oryginalną nazwą.
6. funkcje zapisu pliku pod inną nazwą niż oryginalna.
7. funkcje umożliwiające przesłanie zawartości bieżącego pliku e-mailem za pomocą zewnętrznego programu pocztowego klienta.
8. funkcje do wyświetlania informacji online w formacie string (wskazówki).
9. funkcje systemu pomocy online.
10. funkcje wyświetlania nazwy programu, wersji programu, praw autorskich i komentarzy programistów.

Frazes „zapewnić wykonalność” odnosi się do nowoczesnego oprogramowania tworzonego z wykorzystaniem graficznego interfejsu użytkownika. Te narzędzia programowe są w większości „bezczynne” i czekają na działania operatora.

Wymagania dotyczące organizacji danych wejściowych

Dane wejściowe programu muszą być zorganizowane w formie oddzielne pliki rtf odpowiadający specyfikacji.

Pliki o określonym formacie muszą zostać umieszczone (przechowane) na dysku lokalnym lub nośniki wymienne, sformatowany zgodnie z wymaganiami systemu operacyjnego.

Nie należy otwierać plików w innym formacie, ale z rozszerzeniem rtf.

Nie należy otwierać plików http://domain.net/file.rtf lub ftp://domain.net/file.rtf. Jeśli system plików jest sformatowany jako FAT32, nie należy otwierać plików z nośników lokalnych lub wymiennych sformatowanych na przykład w formacie ext3.

Wymagania czasowe

Nie ma wymagań dotyczących charakterystyki czasowej programu.

Należy doprecyzować, czy Klient ma wymagania co do szybkości działania programu, np. ile czasu zajmuje programowi uruchomienie, otwarcie i zamknięcie plików o danym rozmiarze. Jeśli Klient poda konkretne liczby, należy zachować ostrożność i uwzględnić w wymaganiach dotyczących składu i parametrów wyposażenia technicznego superkomputer kosztujący 2500 dolarów lub więcej. To prawda, że ​​​​taka kwota będzie musiała być uzasadniona. Jeżeli charakterystyki czasowe nie są dla Klienta istotne, należy napisać o rezygnacji z wymagań dotyczących charakterystyk czasowych (patrz treść powyżej).

Wymagania dotyczące niezawodności

W podsekcji należy wskazać wymagania dotyczące zapewnienia niezawodnego działania (zapewnienie stabilnej pracy, monitorowanie informacji wejściowych i wyjściowych, czas odzyskiwania po awarii itp.).

Niezawodność to delikatna i bardzo niebezpieczna rzecz. Ale lista funkcji i ich trybów awarii, zgodnie z punktem 1.3.2. GOST 24.701-86, musi zostać sporządzony przez Zamawiającego i uzgodniony z Wykonawcą. Najprawdopodobniej nie będzie można oczekiwać od Klienta niczego zrozumiałego. Warto wyjaśnić Klientowi, że niezawodne działanie programu zależy nie tyle od Wykonawcy, ile od niezawodności sprzętu i systemu operacyjnego, a także zaproponować Klientowi szereg rygorystycznych środków zwiększających niezawodność i stabilność programu.

Wymagania zapewniające niezawodne (stabilne) działanie programu

Niezawodne (trwałe) działanie programu musi być zapewnione poprzez wdrożenie przez Klienta zestawu środków organizacyjnych i technicznych, których lista znajduje się poniżej:

1. organizowanie nieprzerwanego zasilania urządzeń technicznych;
2. korzystanie z licencjonowanego oprogramowania;
3. regularne wdrażanie zaleceń Ministerstwa Pracy i rozwój społeczny Federacji Rosyjskiej, określone w Uchwale z dnia 23 lipca 1998 r. „W sprawie zatwierdzenia międzybranżowych standardowych standardów czasu pracy praca Wsparcie w zakresie komputerów i sprzętu biurowego oraz oprogramowania”;
4. regularne przestrzeganie wymagań GOST 51188-98. Ochrona informacji. Testowanie oprogramowania pod kątem obecności wirusów komputerowych.

Do listy można dodać jeszcze kilkanaście dokumentów regulacyjnych. Podczas wstępnej akceptacji specyfikacji technicznych Klient najprawdopodobniej zacznie wykazywać skłonność do kompromisów.

Możliwe jest bardziej humanitarne podejście. Niezawodność (jednak systemu według tego samego GOST) można uznać za bezawaryjne wykonywanie określonej i-tej funkcji w określonym przedziale czasu. Sugerujemy, aby Klient wziął pod uwagę następujący wskaźnik jako kryterium niezawodnego działania programu: Klient otwiera i zamyka plik 100 razy w ciągu godziny. Jeśli program nie ulegnie awarii w określonym przedziale czasu, wymagania dotyczące niezawodności uznaje się za spełnione.

Jeżeli Klient ostatecznie przekona się, że niezawodność zależy nie tyle od Wykonawcy, ile od niezawodności sprzętu i systemu operacyjnego, i się podda, w rubryce należy wpisać zdanie:

Nie ma wymagań zapewniających niezawodne (stabilne) działanie programu.

Czas regeneracji po awarii

Czas powrotu do zdrowia po awarii spowodowanej awarią zasilania sprzętu (inne czynniki zewnętrzne), a nie awarią śmiertelną (a nie awarią) systemu operacyjnego, nie powinien przekraczać tylu minut, pod warunkiem, że warunki pracy sprzętu i oprogramowania są zauważony.

Czas powrotu do zdrowia po awarii spowodowanej nieprawidłowym działaniem sprzętu lub krytyczną awarią (crashem) systemu operacyjnego nie powinien przekraczać czasu potrzebnego na usunięcie awarii sprzętu i ponowną instalację oprogramowania.

Lista sytuacji awaryjnych jest również ustalana przez Zleceniodawcę i uzgadniana z Wykonawcą. Tak naprawdę jest to czas na ponowne uruchomienie systemu operacyjnego, jeśli awaria nie jest śmiertelna, nie jest spowodowana awarią systemu operacyjnego lub awarią sprzętu.

Warunki korzystania

W podpunkcie należy wskazać warunki pracy (temperatura otoczenia, wilgotność względna itp. dla wybranych rodzajów nośników danych), w jakich muszą być zapewnione określone charakterystyki, a także rodzaj usługi, wymaganą liczbę i kwalifikacje personelu.

Bardzo niebezpieczny podrozdział.

Klimatyczne warunki pracy

Klimatyczne warunki pracy, w których muszą być zapewnione określone właściwości, muszą spełniać wymagania dotyczące środków technicznych pod względem warunków ich pracy.

Program będzie działał idealnie od plus 5 do plus 35 ° C przy wilgotności względnej 90% i ciśnieniu atmosferycznym 462 mmHg, ponieważ takie warunki w przybliżeniu odpowiadają warunkom pracy nowoczesne komputery nieprzemysłowe wykonanie. Jednak gdy tylko specyfikacje techniczne zawierają konkrety i zadanie zostaje zatwierdzone, Klient ma doskonałą szansę, aby zmusić Wykonawcę do przeprowadzenia w całości testów klimatycznych na jego koszt.

Około piętnastu lat temu autor artykułu, ze względu na swój młody wiek i niezłomną chęć obrony swojego stanowiska (zwłaszcza w zakresie specyfikacji technicznych), „skończył” na „klimacie” i „skończył konkretnie” na całkiem fajny „sprzęt”. Autor artykułu od razu dowiedział się, co to znaczy „pokazać matkę Kuzki” i „gdzie raki spędzają zimę”. Nie daj Boże dać się złapać w zmiany klimatyczne!

Wymagania dotyczące rodzajów usług

Lub

Program nie wymaga żadnych zabiegów konserwacyjnych.

Rodzaje konserwacji należy zapożyczyć z podrozdziału „Wymagania dotyczące zapewnienia niezawodnego (zrównoważonego) działania”.

Jeżeli podczas zatwierdzania specyfikacji technicznych Klient powołuje się na brak zasobów lub chęć samodzielnego przeprowadzania wszelkiego rodzaju konserwacji, warto zaoferować opracowanie specyfikacji technicznych w zakresie utrzymania oprogramowania za pewne pieniądze w ramach osobna umowa. Jeżeli odmówi, program należy uznać za nieobsługiwany.

Wymagania dotyczące liczby i kwalifikacji personelu

Minimalna liczba personelu wymagana do obsługi programu musi wynosić co najmniej 2 etaty - administrator systemu i użytkownik końcowy programy - operator.

Administrator systemu musi posiadać wyższe wykształcenie specjalistyczne oraz certyfikaty producenta systemu operacyjnego. Lista wykonanych zadań Administrator systemu, powinno zawierać:

1. zadanie utrzymania sprawności środków technicznych;
2. zadania instalacji (instalacji) i utrzymywania funkcjonalności oprogramowania systemowego – systemu operacyjnego;
3. zadanie instalacji programu.

Użytkownik końcowy programu (operator) musi posiadać praktyczne umiejętności pracy z graficznym interfejsem użytkownika systemu operacyjnego.

Personel musi posiadać uprawnienia do II grupy kwalifikacyjnej w zakresie bezpieczeństwa elektrycznego (do pracy ze sprzętem biurowym).

W przypadku braku najbardziej kluczowego (pogrubionego) sformułowania w zatwierdzonych specyfikacjach technicznych, Klient ma prawo żądać od Wykonawcy opracowania instrukcji obsługi graficznego interfejsu użytkownika systemu operacyjnego, powołując się na fakt, że operator „nie radzi sobie ”z programem.

Osobom, które nie posiadają II grupy kwalifikacji w zakresie bezpieczeństwa elektrycznego, nie wolno nawet zbliżać się do komputerów i urządzeń biurowych. Mężczyźni nie wiedzą, ale prokurator wie.

Wymagania dotyczące składu i parametrów środków technicznych

W podsekcji wskazano wymagany skład środków technicznych, wskazując ich główne cechy techniczne.

Powinieneś wybrać sprzęt nie gorszy niż ten, na którym będzie prowadzony rozwój. Logiczne jest żądanie, aby Klient dostarczył sprzęt nie później niż w określonym terminie. Mówimy oczywiście o komputerze.

Sprzęt musi być kompatybilny z IBM Komputer osobisty(PC), w tym:

1. Procesor Pentium-1000 z częstotliwość zegara, GHz - 10, nie mniej;
2. płyta główna z FSB, GHz - 5, nie mniej;
3. Pojemność pamięci RAM, TB - 10, nie mniej;
4. i tak dalej…

Wymagania dotyczące struktur informacyjnych i metod rozwiązań

Struktura informacyjna pliku musi zawierać tekst zawierający znaczniki przewidziane w specyfikacji formatu rtf.

Lub

Nie ma wymagań dotyczących struktur informacyjnych (plików) na wejściu i wyjściu, a także metod rozwiązania.

Wymagania dotyczące oprogramowania wykorzystywanego przez program

Oprogramowanie systemowe używane przez program musi być licencjonowaną, zlokalizowaną wersją systemu operacyjnego. Możesz użyć takiego i takiego dodatku Service Pack.

Wymagania dotyczące etykietowania i pakowania

Program jest dostarczany jako oprogramowanie - na nośniku dystrybucyjnym (zewnętrznym optycznym) (CD).

Mówimy o etykietowaniu i pakowaniu mediów dystrybucyjnych - oprogramowania (patrz GOST 19.004-80).

Wymóg oznakowania

Oprogramowanie musi być oznaczone znakiem towarowym firmy deweloperskiej, typem (nazwą), numerem wersji, numerem seryjnym, datą produkcji i numerem certyfikatu zgodności z Państwową Normą Rosji (jeśli istnieje).

Oznaczenie należy nanieść na oprogramowanie w formie naklejki wykonanej metodą drukowania, z uwzględnieniem wymagań GOST 9181-74.

Jakość oznakowania sprawdza się najnowocześniejszymi metodami – najpierw próbuje się zmyć oznaczenie wodą, potem benzyną i innymi rozpuszczalnikami organicznymi. Niech drukarnia poniesie odpowiedzialność za złą jakość oznakowania. Zadaniem Wykonawcy jest ukrywanie się za certyfikatem zgodności (zażądanie certyfikatu od drukarni).

Warunki pakowania

Pakowanie oprogramowania musi odbywać się w zamkniętych, wentylowanych pomieszczeniach, w temperaturze od plus 15 do plus 40 ° C i wilgotności względnej nie większej niż 80%, przy braku agresywnych zanieczyszczeń w środowisku.

Klient otrzyma oprogramowanie w odpowiednim wyglądzie. Jeżeli oprogramowanie zostanie zwrócone w stanie nieodpowiednim (zadrapania, pęknięcia i inne wady), Kontrahent będzie mógł dochodzić roszczeń związanych z naruszeniem przez Klienta warunków opakowania i nie przyjąć oprogramowania.

Procedura pakowania

Produkty oprogramowania przygotowane do pakowania umieszczane są w pojemnikach, które są pudełkami wykonanymi z tektury falistej (GOST 7376-89 lub GOST 7933-89) zgodnie z rysunkami producenta opakowania.

Oprogramowanie pakowane jest w osłony wykonane z folii wodoodpornej z obowiązkowym dodatkiem chemicznie nieagresywnego środka osuszającego (żelu krzemionkowego).

Do wypełnienia wolna przestrzeń W pojemnikach opakowaniowych umieszczane są uszczelki wykonane z tektury falistej lub tworzywa piankowego.

Dokumentację eksploatacyjną należy umieścić w opakowaniu konsumenckim wraz z oprogramowaniem.

Dokumentacja wysyłkowa – list przewozowy i list przewozowy – umieszczane są na wierzchniej warstwie materiału amortyzującego.

Opakowania konsumenckie należy okleić taśmą klejącą 6-70 zgodnie z GOST 18251-87.

Oprogramowanie zapakowane w opakowania konsumenckie należy umieścić na palecie, owinąć taśmą zapobiegającą utracie kształtu ładunku i opakować w folię polietylenową M 0,2 w celu zabezpieczenia przed wilgocią.

Skrzynia paletowa musi zawierać dokumentację przewozową, w tym listę pakowania zgodną z GOST 25565-88.

Wymiary przestrzeni ładunkowej nie mogą przekraczać 1250 x 820 x 1180 mm.

Masa netto - nie więcej niż 200 kg.

Masa brutto - nie więcej niż 220 kg.

W podrozdziale przedstawiono procedurę pakowania na podstawie wcześniej opracowanego dokumentu dla niektórych urządzeń technicznych. Wygląda to dość nietypowo w kontekście oprogramowania. W prostym języku rosyjskim - kompletne przekomarzanie się.

Wymagania dotyczące transportu i przechowywania

Podsekcja musi wskazywać warunki transportu oprogramowania, miejsca przechowywania, warunki przechowywania, warunki przechowywania, okresy przechowywania w różnych warunkach.

W podrozdziale podano warunki transportu i przechowywania z wcześniej opracowanego dokumentu dla niektórych urządzeń technicznych. Dotyczy to również wymagań dotyczących opakowań. Wygląda to dość nietypowo w kontekście oprogramowania.

Klient nie ma prawa naruszać warunków transportu i przechowywania. Kontrahent będzie miał możliwość odmowy zwrotu oprogramowania Klientowi, twierdząc, że wygląd oprogramowania jest konsekwencją nieprzestrzegania warunków transportu i przechowywania.

Warunki transportu i przechowywania

Dopuszczalny jest transport oprogramowania w kontenerze transportowym wszystkimi rodzajami transportu (w tym w ogrzewanych, szczelnych pomieszczeniach samolotu bez ograniczeń odległości). W przypadku przewozu wagonami kolejowymi przesyłka jest niewielka, o niskim tonażu.

Podczas transportu i przechowywania oprogramowania należy zapewnić ochronę przed kurzem i opadami atmosferycznymi. Niedopuszczalne jest przechylanie oprogramowania. Warunki klimatyczne transportu podano poniżej:

• temperatura powietrza otoczenia, °C - od plus 5 do plus 50;
• ciśnienie atmosferyczne, kPa - takie i takie;
• wilgotność względna powietrza w temperaturze 25°C jest taka i taka.

Wymagania dotyczące dokumentacji oprogramowania

Sekcja powinna wskazywać wstępny skład dokumentacji programu i, jeśli to konieczne, specjalne wymagania dla niej.

Program i metody testów będą wymagane, aby wykazać Zamawiającemu, że program opracowany przez Wykonawcę spełnia wymagania uzgodnionych i zatwierdzonych specyfikacji technicznych. Po przeprowadzeniu wspólnych badań (odbiorów) Klient i Wykonawca podpiszą Protokół Odbioru Pracy. Tym samym prace zostaną zakończone, warunki Umowy zostaną spełnione.

Cenna notatka przyszła od Primadonny:

Zgodnie z punktem 2.6. GOST 19.101-77 „Dopuszcza się łączenie niektórych rodzajów dokumentów operacyjnych (z wyjątkiem wykazu dokumentów operacyjnych i formularza). Konieczność połączenia tych dokumentów jest wskazana w specyfikacjach technicznych. Łączonemu dokumentowi przypisuje się nazwę i oznaczenie jednego z łączonych dokumentów.”

Ale dla tych, którzy po raz pierwszy zaczynają opracowywać dokumentację oprogramowania, lepiej trzymać się zasady „osobne muchy, osobne kotlety”.

I jeszcze jedna cenna uwaga od Primadonny:

Dokumentacja oprogramowania zawarta na liście wstępnej musi zostać sporządzona zgodnie z wymogami GOST 19.106-78.

Wskaźniki techniczne i ekonomiczne

Szacowana efektywność ekonomiczna nie jest obliczana.

Szacunkowa liczba zastosowań programu w ciągu roku wynosi 365 sesji roboczych w jednym miejscu pracy.

W sekcji należy wskazać: szacunkową efektywność ekonomiczną, szacunkowy roczny popyt, korzyści ekonomiczne inwestycji w porównaniu z najlepszymi wzorami lub analogiami krajowymi i zagranicznymi.

Pomysł zapożyczony

Załóżmy, że Klient wyposaża w program kilkanaście stanowisk roboczych. Za inwestycję wykonawca zażądał 1000 dolarów. Klient mógł zainstalować na stacjach roboczych oprogramowanie od trzeciej firmy, co kosztuje 500 dolarów za dystrybucję i 100 dolarów za licencję na każdą stację roboczą.korzyści ekonomiczne

$1500

$1000

$500

$11500

$1000

$10500

Etapy i etapy rozwoju

Sekcja określa niezbędne etapy rozwoju, etapy i treść pracy (lista dokumentów programowych, które należy opracować, uzgodnić i zatwierdzić), a także z reguły ramy czasowe opracowania oraz określa wykonawców.

Etapy i etapy rozwoju reguluje GOST 19.102-77. GOST 19.102-77 nie zapobiega wykluczeniu poszczególnych etapów pracy, a także łączeniu poszczególnych etapów pracy.

Etapy rozwoju

Rozwój powinien przebiegać w trzech etapach:

1. opracowywanie specyfikacji technicznych;
2. szczegółowy projekt;
3. realizacja.

Etapy rozwoju

Na etapie opracowywania specyfikacji technicznych musi zostać zakończony etap opracowywania, koordynacji i zatwierdzania niniejszej specyfikacji technicznej.

Na etapie projektowania szczegółowego należy wykonać następujące etapy prac:

1. rozwój programu;
2. opracowywanie dokumentacji programowej;
3. testowanie programu.

Na etapie realizacji należy zakończyć etap developmentu – przygotowania i przekazania programu.

Na etapie opracowywania specyfikacji technicznych należy wykonać następujące prace:

1. sformułowanie problemu;
2. określenie i wyjaśnienie wymagań dotyczących środków technicznych;
3. określenie wymagań programowych;
4. określanie etapów, etapów i harmonogramu opracowania programu oraz dokumentacji do niego;
5. wybór języków programowania;
6. koordynacja i zatwierdzanie specyfikacji technicznych.

Na etapie tworzenia programu należy wykonać prace nad programowaniem (kodowaniem) i debugowaniem programu.

Na etapie opracowywania dokumentacji programowej opracowanie dokumentów programowych należy przeprowadzić zgodnie z wymaganiami GOST 19.101-77 z wymogiem ust. Wstępny skład dokumentacji programu niniejszej specyfikacji technicznej.

W fazie testowania programu należy wykonać następujące rodzaje prac:

1. opracowanie, koordynacja i zatwierdzenie programu (wydaje się, że w GOST jest literówka - „zamówienie”) i metod testowania;
2. przeprowadzanie testów akceptacyjnych;
3. dostosowanie programu i dokumentacji programu na podstawie wyników testów.

Na etapie przygotowania i przekazania programu muszą zostać zakończone prace mające na celu przygotowanie i przekazanie programu oraz dokumentacji programowej do eksploatacji w obiektach Klienta.

Procedura kontroli i odbioru

W tej sekcji należy wskazać rodzaje testów i ogólne wymagania dotyczące odbioru pracy.

Rodzaje testów

Badania odbiorcze należy przeprowadzić u Klienta w terminach...

Testy akceptacyjne programu muszą zostać przeprowadzone zgodnie z Programem i metodami testowymi opracowanymi (nie później niż w takim a takim terminie) przez Wykonawcę i uzgodnionymi z Klientem.

Klient i Wykonawca dokumentują przebieg testów akceptacyjnych w Protokole z testów.

Ogólne wymagania dotyczące odbioru pracy

Na podstawie Protokołu Testów Wykonawca wraz z Klientem podpisuje Protokół Odbioru Programu i Uruchomienia.

Aplikacje

W załącznikach do specyfikacji technicznych, jeśli to konieczne, podaje się:

• wykaz badań i innych prac uzasadniających rozwój;
• diagramy algorytmów, tabele, opisy, uzasadnienia, obliczenia i inne dokumenty, które można wykorzystać podczas opracowywania;
• inne źródła rozwoju.

Jeśli tak, dlaczego by tego nie przynieść. I pamiętaj o opublikowaniu listy GOST, na podstawie której należy przeprowadzić rozwój. Na przykład:

• GOST 19.201-78. Specyfikacje techniczne, wymagania dotyczące treści i projektu;
• i tak dalej...

wnioski

Standard ten mimo swoich 25 lat pozwala na opracowanie pełnej specyfikacji technicznej nowoczesnego programu z graficznym interfejsem użytkownika. Twórcy GOST 19.201-78 spojrzeli w przyszłość i wzięli pod uwagę prawie wszystkie aspekty związane z rozwojem oprogramowania.

Co pozostało nieuwzględnione? Warunki, wolumeny i etapy finansowania? Regulamin tworzony jest zawsze na podstawie Umowy, pisma itp. Podane informacje muszą znaleźć odzwierciedlenie w Umowie.

Jakie są kontrowersyjne punkty? Brak w normie konkretnych wymagań np. dotyczących interfejsu użytkownika? Twórcy standardu udostępniają sekcję „Wymagania specjalne”, możliwość dodawania nowych sekcji, na przykład sekcji „Wymagania dodatkowe” lub „Wymagania dotyczące interfejsu”.