Tworzenie specyfikacji technicznych dla rozwoju systemu informatycznego. Zakres wymagań i obowiązków w zakresie projektowania systemów informatycznych

Niedawno zwrócili się do mnie, aby doradzić mi w sprawie standardów pisania specyfikacji technicznych (TOR) dla rozwoju systemów zautomatyzowanych (AS) i oprogramowanie(PRZEZ). Myślę, że teraz pójdę do Yandex, znajdę odpowiedni artykuł i wyślę go. Ale tego tam nie było! Jeden artykuł zawierający listę standardów specyfikacji technicznych, w tym szablony i przykłady gotowe dokumenty, Nie znalazłem. Będę musiał sam napisać ten artykuł...

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

GOST 34.602-89 Zakres obowiązków dotyczący tworzenia zautomatyzowanego systemu reguluje strukturę specyfikacji technicznych dotyczących tworzenia SYSTEMU, który obejmuje oprogramowanie, Sprzęt komputerowy, ludzie pracujący z oprogramowaniem i zautomatyzowane procesy.

Według GOST 34 zadanie techniczne powinien 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

„GOST 19.xxx jeden system dokumentacja programu(ESPD)” to zbiór standardów stanowych, które ustanawiają powiązane zasady opracowywania, projektowania i rozpowszechniania programów (lub oprogramowania) oraz dokumentacji programów. Te. Norma ta ma zastosowanie w szczególności do tworzenia oprogramowania.
Zgodnie z GOST 19.201-78 Specyfikacje techniczne, wymagania dotyczące treści i projektu, specyfikacje techniczne muszą 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 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

Wystarczająco dobra definicja norma 830-1998 - Zalecana praktyka IEEE dotycząca specyfikacji wymagań oprogramowania jest podana w samym jej opisie:

Opisuje zawartość i cechy jakościowe poprawnie napisaną specyfikację wymagań oprogramowania (SRS) i udostępnia kilka szablonów SRS. Ta zalecana praktyka ma na celu ustalenie wymagań dla tworzonego oprogramowania, 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

2. Opis ogólny

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

3. Szczegółowe wymagania (można je uporządkować na różne sposoby, np. w ten sposób)

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

4. Aplikacje
5. Indeks alfabetyczny

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.
(czytaj razem z komentarzami)
Przykłady specyfikacji technicznych i innej dokumentacji dotyczącej opracowania AS dla Ministerstwa Rozwoju
Styl zarządzania GOST. Artykuł autorstwa Gapertona prawidłowe działanie ze specyfikacji technicznych zgodnie z GOST
Szablony dokumentów analityka biznesowego z

GOST 34.602-89 Technologia informacyjna. Zbiór standardów dla systemów zautomatyzowanych. Specyfikacje techniczne tworzenia zautomatyzowany system(Zamiast GOST 24.201-85)

Data wprowadzenia od 01.01.1990

Niniejsza norma dotyczy zautomatyzowanych systemów (AS) do automatyzacji różnego rodzaju działań (zarządzanie, projektowanie, badania itp.), W tym ich kombinacji, oraz ustala skład, treść, zasady sporządzania dokumentu „Specyfikacje techniczne dotyczące tworzenia ( rozwoju lub modernizacji) systemów” (zwany dalej TK dla AS).

1. POSTANOWIENIA OGÓLNE

1.1. Specyfikacja techniczna elektrowni jądrowej jest głównym dokumentem określającym wymagania i tryb tworzenia (rozwoju lub modernizacji – następnie tworzenia) zautomatyzowanego systemu, zgodnie z którym prowadzona jest rozbudowa elektrowni jądrowej i jej odbiór po uruchomieniu.

1.2. Specyfikacje elektrowni jądrowej opracowywane są dla systemu jako całości, przeznaczonego do pracy samodzielnej lub jako część innego systemu.

Dodatkowo można opracować specyfikacje techniczne dla części elektrowni jądrowej:

dla podsystemów AS, zestawów zadań AS itp. zgodnie z wymaganiami niniejszej normy;
dla komponentów pomoc techniczna oraz systemy oprogramowania i sprzętu komputerowego zgodne ze standardami ESKD i SRPP;
za oprogramowanie zgodne ze standardami ESPD;
dla produktów informacyjnych zgodnie z GOST 19.201 i NTD obowiązujących w dziale klienta AS.

Notatka. Specyfikacje techniczne zautomatyzowanego systemu sterowania grupą wzajemnie powiązanych obiektów powinny zawierać wyłącznie wymagania wspólne dla tej grupy obiektów. Specyficzne wymagania odrębnego obiektu kontroli powinno znaleźć odzwierciedlenie w specyfikacjach technicznych zautomatyzowanego systemu sterowania tego obiektu.

1.3. Wymagania dotyczące głośników w zakresie określonym w niniejszej normie mogą zostać ponownie uwzględnione w zadaniu projektowym stworzony obiekt automatyzacja. W tym przypadku nie są opracowywane specyfikacje techniczne dla elektrowni jądrowej.

1.4. Wymagania zawarte w specyfikacjach technicznych dla elektrowni jądrowych muszą odpowiadać aktualnemu poziomowi rozwoju nauki i technologii i nie ustępować podobnym wymaganiom stawianym najlepszym nowoczesnym odpowiednikom krajowym i zagranicznym. Wymagania określone w specyfikacjach technicznych elektrowni jądrowej nie powinny ograniczać twórcy systemu w poszukiwaniu i wdrażaniu najskuteczniejszych rozwiązań technicznych, technicznych, ekonomicznych i innych.

1,5. Specyfikacje techniczne dla elektrowni jądrowych opracowywane są na podstawie danych wstępnych, w tym zawartych w dokumentacji końcowej etapu „Badania i uzasadnienie budowy elektrowni jądrowych”, ustalonej przez GOST 24.601.

1.6. Specyfikacje techniczne dla AS obejmują tylko te wymagania, które uzupełniają wymagania dla systemów tego typu (ACS, CAD, ASNI itp.) zawarte w aktualnej dokumentacji normatywnej i technicznej i są określone specyfiką konkretnego obiektu, dla którego system jest tworzony.

1.7. Zmiany w specyfikacji technicznej elektrowni jądrowej formalizowane są poprzez dodatek lub protokół podpisany przez klienta i dewelopera. Dodatek lub określony protokół stanowi integralną część specyfikacji technicznych elektrowni jądrowej. Na stronie tytułowej specyfikacji technicznej głośnika powinien znajdować się wpis „Ważne od...”.

2. SKŁAD I ZAWARTOŚĆ

2.1. Specyfikacja techniczna elektrowni jądrowej zawiera 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) procedurę kontroli i odbioru systemu;
7) wymagania dotyczące składu i treści prac mających na celu przygotowanie obiektu automatyki do uruchomienia systemu;
8) wymagania dokumentacyjne;
9) źródła rozwoju.

Wnioski mogą być zawarte w specyfikacjach technicznych głośników.

2.2. W zależności od rodzaju, przeznaczenia, specyfiki obiektu automatyki i warunków pracy systemu istnieje możliwość opracowania odcinków specyfikacji technicznych w formie wniosków, wprowadzenia dodatkowych, wyłączenia lub połączenia podrozdziałów specyfikacji technicznych .

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

2.3. W sekcji „Informacje ogólne” należy wskazać:

1) pełną nazwę systemu i jego symbol;
2) kod przedmiotu lub kod (numer) zamówienia;
3) nazwę przedsiębiorstw (stowarzyszeń) twórcy i klienta (użytkownika) systemu oraz ich dane;
4) wykaz dokumentów, na podstawie których tworzony jest system, przez kogo i kiedy te dokumenty zostały zatwierdzone;
5) planowane terminy rozpoczęcia i zakończenia prac nad utworzeniem systemu;
6) informację o źródłach i trybie finansowania dzieła;
7) procedura rejestracji i prezentacji klientowi wyników prac nad stworzeniem systemu (jego części), produkcją i dostosowaniem poszczególnych środków (sprzętu, oprogramowania, informacji) oraz kompleksów oprogramowania i sprzętu (oprogramowania i metodologii) systemu.

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

1) cel systemu;
2) cele tworzenia systemu.

2.4.1. W podrozdziale „Przeznaczenie systemu” wskazują rodzaj działalności podlegającej automatyzacji (zarządzanie, projektowanie itp.) oraz listę obiektów automatyki (obiektów), na których ma być wykorzystany.

W przypadku zautomatyzowanych systemów kontroli dodatkowo wskazany jest wykaz zautomatyzowanych organów kontrolnych (punktów) i kontrolowanych obiektów.

2.4.2. W podrozdziale „Cele stworzenia systemu” podano nazwy i wymagane wartości wskaźników technicznych, technologicznych, produkcyjnych, ekonomicznych lub innych obiektu automatyki, które należy osiągnąć w wyniku stworzenia zautomatyzowanego systemu, oraz wskazują kryteria oceny osiągnięcia celów tworzenia systemu.

2.5. W części „Charakterystyka obiektu automatyki” podano:

1) krótka informacja o obiekcie automatyzacji lub linki do dokumentów zawierających takie informacje;
2) informacje o warunkach pracy obiektu automatyki i charakterystyce otoczenia.

Notatka: W przypadku CAD sekcja zawiera dodatkowo główne parametry i cechy obiektów projektowych.

2.6. Sekcja „Wymagania systemowe” składa się z następujących podsekcji:

1) wymagania dla systemu jako całości;
2) wymagania dotyczące funkcji (zadań) realizowanych przez system;
3) wymagania 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. W każdym podrozdziale znajdują się łącza do aktualnej dokumentacji normatywnej i technicznej, która określa wymagania dla systemów odpowiedniego typu.

2.6.1. W podrozdziale „Wymagania dla systemu jako całości” wskaż:

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 eksploatacyjne, konserwacja, naprawa i magazynowanie elementów systemu;
wymagania dotyczące ochrony informacji przed nieuprawnionym dostępem;
wymagania dotyczące bezpieczeństwa informacji na wypadek wypadków;
wymagania dotyczące ochrony przed wpływami zewnętrznymi;
wymagania czystości patentowej;
wymagania dotyczące standaryzacji i unifikacji;
Dodatkowe wymagania.

2.6.1.1. Wymagania dotyczące struktury i działania systemu obejmują:

1) wykaz podsystemów, ich przeznaczenie i główne cechy, wymagania dotyczące liczby poziomów hierarchii oraz stopnia centralizacji systemu;
2) wymagania dotyczące metod i środków komunikacji wymiany informacji pomiędzy elementami systemu;
3) wymagania dotyczące cech relacji stworzonego 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.);
4) wymagania dotyczące trybów pracy systemu;
5) wymagania dotyczące diagnozowania systemu;
6) perspektywy rozwoju i modernizacji systemu.

2.6.1.2. Wymagania dotyczące liczby i kwalifikacji personelu w elektrowniach jądrowych obejmują:

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.

2.6.1.3. W wymaganiach dotyczących wskaźników celu AS podano wartości parametrów charakteryzujących stopień zgodności systemu z jego przeznaczeniem.

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.

2.6.1.4. Wymagania dotyczące niezawodności obejmują:

1) skład i wartości ilościowe wskaźników niezawodności systemu jako całości lub jego podsystemów;
2) lista sytuacje awaryjne, zgodnie z którymi należy regulować wymagania niezawodności i wartości odpowiednich wskaźników;
3) wymagania dotyczące niezawodności środki techniczne i oprogramowanie;
4) wymagania dotyczące metod oceny i monitorowania wskaźników niezawodności przy ul różne etapy stworzenie systemu zgodnie z obowiązującymi dokumentami regulacyjnymi i technicznymi.

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

2.6.1.6. Wymagania dotyczące ergonomii i estetyki technicznej obejmują wskaźniki głośników, które określają wymagana jakość interakcję człowiek-maszyna i komfortowe warunki pracy personelu.

2.6.1.7. W przypadku głośników mobilnych wymagania dotyczące możliwości transportu obejmują wymagania projektowe zapewniające możliwość transportu środków technicznych systemu, a także wymagania dotyczące pojazdów.

2.6.1.8. Wymagania dotyczące obsługi, konserwacji, naprawy i przechowywania obejmują:

1) warunki i przepisy (tryb) funkcjonowania, 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 ;
2) wstępne wymagania dotyczące dopuszczalnych powierzchni do pomieszczenia urządzeń personelu i pojazdów, parametrów sieci zasilających itp.;
3) wymagania dotyczące liczby, kwalifikacji personelu obsługującego i sposobu jego pracy;
4) wymagania dotyczące składu, rozmieszczenia i warunków przechowywania zestawu wyrobów i urządzeń zamiennych;
5) wymagania dotyczące przepisów utrzymania ruchu.

2.6.1.9. Wymagania dotyczące ochrony informacji przed nieuprawnionym dostępem obejmują wymagania określone w dokumentacji normatywnej i technicznej obowiązującej w branży (oddziale) Klienta.

2.6.1.10. Wymagania dotyczące bezpieczeństwa informacji zawierają listę zdarzeń: wypadki, awarie urządzeń technicznych (w tym utratę zasilania) itp., w których należy zapewnić bezpieczeństwo informacji w systemie.

2.6.1.11. Wymagania dotyczące środków ochrony przed wpływami zewnętrznymi obejmują:

1) wymagania dotyczące ochrony radioelektronicznej elektrowni jądrowych;
2) wymagania dotyczące trwałości, stabilności i wytrzymałości wpływy zewnętrzne(środowisko aplikacji).

2.6.1.12. Wymagania dotyczące czystości patentowej wskazują listę krajów, w odniesieniu do których należy zapewnić czystość patentową systemu i jego części.

2.6.1.13. Do wymagań standaryzacji i unifikacji zaliczają się: wskaźniki określające wymagany stopień wykorzystania normy, ujednolicone metody 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.

2.6.1.14. Dodatkowe wymagania obejmują:

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

2.6.2. W podrozdziale „Wymagania dla funkcji (zadań)” realizowanych przez system podano:

1) dla każdego podsystemu wykaz funkcji, zadań lub ich zespołów (w tym zapewniających współdziałanie części systemu) podlegających automatyzacji;

przy tworzeniu systemu w dwóch lub więcej kolejkach - lista podsystemów funkcjonalnych, poszczególnych funkcji lub zadań uruchomionych w pierwszej i kolejnych kolejkach;

2) regulacje czasowe realizacji każdej funkcji, zadania (lub zestawu zadań);

3) wymagania dotyczące jakości realizacji każdej funkcji (zadania lub zestawu zadań), formy prezentacji informacji wyjściowych, charakterystyk wymaganej dokładności i czasu wykonania, wymagań dotyczących jednoczesnego wykonywania grupy funkcji, niezawodności wyników;

4) listę i kryteria awarii dla każdej funkcji, dla której określono wymagania niezawodnościowe.

2.6.3. W podrozdziale „Wymagania dotyczące rodzajów wsparcia” w zależności od rodzaju systemu podano wymagania dotyczące wsparcia matematycznego, informacyjnego, językowego, oprogramowania, technicznego, metrologicznego, organizacyjnego, metodologicznego i innego rodzaju wsparcia dla systemu.

2.6.3.1. Dla matematycznego wsparcia systemu podano wymagania dotyczące składu, zakresu (ograniczeń) i sposobów wykorzystania metod i modeli matematycznych w systemie, algorytmów standardowych i algorytmów do opracowania.

2.6.3.2. Wymagania dotyczące wsparcia informacyjnego systemu to:

1) składu, struktury i sposobów organizacji danych w systemie;
2) do wymiany informacji pomiędzy elementami systemu;
3) zgodności informacji z powiązanymi systemami;
4) o stosowaniu ogólnounijnych i rejestrowanych klasyfikatorów republikańskich, branżowych, ujednoliconych dokumentów oraz klasyfikatorów działających w danym przedsiębiorstwie;
5) w sprawie stosowania systemów zarządzania bazami danych;
6) do struktury procesu gromadzenia, przetwarzania, przesyłania danych w systemie i prezentacji danych;
7) zabezpieczenie danych przed zniszczeniem podczas wypadków i awarii zasilania systemu;
8) kontrola, przechowywanie, aktualizacja i odzyskiwanie danych;
9) do trybu nadania moc prawna dokumenty wytworzone środkami technicznymi elektrowni jądrowej (zgodnie z GOST 6.10.4).

2.6.3.3. Dla obsługi językowej systemu podano 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.

2.6.3.4. W przypadku oprogramowania systemowego podawana jest lista zakupionego oprogramowania oraz wymagania:

1) do niezależności oprogramowania od używanego SVT i środowiska operacyjnego;
2) jakości oprogramowania oraz sposobów jego dostarczania i kontroli;
3) w razie potrzeby koordynować nowo powstałe oprogramowanie z zestawem algorytmów i programów.

2.6.3.5. Dla wsparcia technicznego systemu podane są następujące wymagania:

1) 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 dopuszczonych do stosowania w systemie;
2) funkcjonalne, konstruktywne i charakterystyka operacyjnaśrodki wsparcia technicznego systemu.

2.6.3.6. Wymagania dotyczące wsparcia metrologicznego obejmują:

1) wstępny wykaz kanałów pomiarowych;
2) wymagania dotyczące dokładności pomiarów parametrów i (lub) właściwości metrologiczne kanały pomiarowe;
3) wymagania dotyczące kompatybilności metrologicznej środków technicznych systemu;
4) wykaz kanałów sterowniczych i obliczeniowych systemu, dla których należy ocenić charakterystyki dokładnościowe;
5) 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;
6) rodzaj certyfikacji metrologicznej (państwowa lub wydziałowa) ze wskazaniem trybu jej realizacji oraz organizacji przeprowadzających certyfikację.

2.6.3.7. W przypadku wsparcia organizacyjnego podano następujące wymagania:

1) ze strukturą i funkcjami jednostek biorących udział w eksploatacji systemu lub zapewniających jego funkcjonowanie;

2) organizacji funkcjonowania systemu oraz trybu współdziałania personelu zakładu z personelem automatyki;

3) w celu ochrony przed błędnymi działaniami personelu systemu.

2.6.3.8. W celu wsparcia metodologicznego CAD zapewnia wymagania dotyczące składu normatywnych i dokumentacja techniczna systemu (lista norm, przepisów, metod itp. stosowanych w jego działaniu).

2.7. Sekcja „Skład i treść prac nad stworzeniem (rozwojem) systemu” powinna zawierać listę etapów i faz prac nad stworzeniem systemu zgodnie z GOST 24.601, termin ich wdrożenia, listę organizacji wykonywania pracy, linki do dokumentów potwierdzających zgodę tych organizacji na udział w tworzeniu systemu lub zapis identyfikujący osobę odpowiedzialną (klient lub programista) za wykonanie tych prac.

W ta sekcja zacytuj także:

1) wykaz dokumentów zgodnie z GOST 34.201-89, przedstawiany na końcu odpowiednich etapów i faz pracy;
2) rodzaj i tryb przeprowadzania badania dokumentacji technicznej (etap, etap, objętość sprawdzanej dokumentacji, organizacja ekspercka);
3) program prac mający na celu zapewnienie wymaganego poziomu niezawodności opracowywanego systemu (jeżeli jest to konieczne);
4) wykaz prac związanych ze wsparciem metrologicznym na wszystkich etapach tworzenia systemu, ze wskazaniem ich terminów i organizacji realizujących (jeżeli jest to konieczne).

2.8. W sekcji „Procedura kontroli i odbioru systemu” należy wskazać:

1) rodzaje, skład, zakres i metody badań systemu i jego elementów składniki(rodzaje testów zgodnie z obowiązującymi normami obowiązującymi dla opracowywanego systemu);
2) Ogólne wymagania w sprawie odbioru prac według etapów (lista uczestniczących przedsiębiorstw i organizacji, miejsce i termin), procedura koordynacji i zatwierdzania dokumentacji odbiorowej;
H) status komisji akceptacyjnej (stanowa, międzyresortowa, departamentalna).

2.9. W części „Wymagania dotyczące składu i zakresu prac przygotowujących obiekt automatyki do uruchomienia systemu” należy podać listę głównych czynności i ich wykonawców, które należy wykonać podczas przygotowania obiektu automatyki do oddania zakład oddany do użytku.

Lista głównych działań obejmuje:

1) doprowadzenie informacji wprowadzanych do systemu (zgodnie z wymogami obsługi informacyjno-językowej) do postaci nadającej się do przetwarzania komputerowego;
2) zmiany, które należy wprowadzić w obiekcie automatyki;
3) stworzenie warunków funkcjonowania obiektu automatyki, zapewniających zgodność tworzonego systemu z wymaganiami zawartymi w specyfikacjach technicznych;
4) tworzenie jednostek i służb niezbędnych do funkcjonowania systemu;
5) harmonogram i procedura obsadzania stanowisk 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.

2.10. W części „Wymagania dotyczące dokumentacji” podano:

1) wykaz zestawów i rodzajów dokumentów do opracowania, uzgodniony pomiędzy twórcą a Klientem systemu, spełniający wymagania GOST 34.201-89 i NTD branży Klienta;
wykaz dokumentów wydanych na nośnikach komputerowych;
wymagania dotyczące dokumentacji mikrofilmowej;
2) wymagania dotyczące dokumentowania elementów składowych do zastosowań międzybranżowych zgodnie z wymaganiami ESKD i ESPD;
3) w przypadku braku norm państwowych określających wymagania dotyczące dokumentowania elementów systemu, dodatkowo uwzględnić wymagania dotyczące składu i zawartości tych dokumentów.

2.11. W części „Źródła opracowania” należy wymienić dokumenty i materiały informacyjne (studia wykonalności, raporty z zakończonych prac badawczych, materiały informacyjne o krajowych i zagranicznych systemach analogowych itp.), na podstawie których opracowano specyfikacje techniczne i które powinny być użyte do stworzenia systemu.

2.12. W przypadku zatwierdzonych metod specyfikacje techniczne dla elektrowni jądrowych zawierają załączniki zawierające:

1) obliczenie oczekiwanej efektywności systemu;
2) ocena poziomu naukowo-technicznego systemu.

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

3. ZASADY REGULAMINU

3.1. Sekcje i podsekcje specyfikacji technicznych elektrowni jądrowej muszą być umieszczone w kolejności ustalonej w pkt. 2 tej normy.

3.2. Specyfikacje techniczne AS są sporządzane zgodnie z wymogami GOST 2.105.95 na arkuszach A4 zgodnie z GOST 2.301 bez ramki, głównego napisu i dodatkowych kolumn.

Numery arkuszy (stron) umieszcza się począwszy od pierwszego arkusza po stronie tytułowej, na górze arkusza (nad tekstem, w środku) po wskazaniu kodu TK na AC.

3.3. Wartości wskaźników, norm i wymagań są z reguły podawane z maksymalnymi odchyleniami lub maksymalnymi i wartości minimalne. Jeżeli te wskaźniki, normy i wymagania są jasno uregulowane w dokumentacji naukowo-technicznej, specyfikacje techniczne zakładu powinny zawierać odnośnik do tych dokumentów lub ich rozdziałów, a także dodatkowe wymagania, które uwzględniają cechy instalowanego systemu Utworzony. Jeżeli w trakcie opracowywania specyfikacji technicznych dla elektrowni jądrowej nie można ustalić konkretnych wartości wskaźników, norm i wymagań, powinna ona sporządzić zapis procedury ustalania i uzgadniania tych wskaźników, norm i wymagań:

„Ostateczny wymóg (wartość) jest doprecyzowywany w procesie... i uzgadniany protokołem z... na etapie...”

Jednocześnie nie wprowadza się żadnych zmian w tekście specyfikacji technicznych elektrowni jądrowej.

3.4. Podpisy organizacji klienta, programisty i zatwierdzającego są umieszczone na stronie tytułowej, która pieczętuje oficjalna pieczęć. W razie potrzeby strona tytułowa jest sporządzana na kilku stronach. Na ostatnim arkuszu umieszcza się podpisy twórców specyfikacji technicznych elektrowni jądrowej oraz urzędników zaangażowanych w zatwierdzanie i rozpatrywanie projektu specyfikacji technicznych elektrowni jądrowej.

Formę strony tytułowej zakresu zadań AS podano w dodatku 2. Formularz ostatni arkusz Specyfikację techniczną elektrowni jądrowej podano w Załączniku nr 3.

3.5. W razie potrzeby dopuszcza się umieszczenie na stronie tytułowej specyfikacji technicznych głośników ustalonych w branży kodów, np.: klauzula bezpieczeństwa, kod pracy, numer rejestracyjny T.K. itp.

3.6. Strona tytułowa dodatku do specyfikacji technicznych AS jest zaprojektowana w ten sam sposób Strona tytułowa Specyfikacja techniczna. Zamiast nazwy „Specyfikacje techniczne” wpisano „Dodatek nr… do specyfikacji technicznych AC…”.

3.7. Na kolejnych arkuszach aneksu do specyfikacji technicznych AS umieszczona jest podstawa zmiany, treść zmiany oraz linki do dokumentów, zgodnie z którymi dokonano tych zmian.

3.8. Prezentując tekst dodatku do specyfikacji technicznych, należy wskazać numery odpowiednich akapitów, akapitów, tabel głównych specyfikacji technicznych w AS itp. i użyć słów: „zamienić”, „uzupełnić”, „ wykluczyć”, „stan w nowym wydaniu”.

PROCEDURA OPRACOWANIA, ZATWIERDZANIA I ZATWIERDZANIA TOR DLA EJ

1. Projekt specyfikacji technicznych elektrowni jądrowej opracowuje na tej podstawie organizacja deweloperska systemu przy udziale klienta wymagania techniczne(zastosowania, specyfikacje taktyczne i techniczne itp.).

W trakcie konkurencyjnej organizacji prac warianty specyfikacji projektu elektrowni jądrowej są rozważane przez klienta, który albo wybiera preferowaną opcję, albo na podstawie analizy porównawczej przygotowuje ją przy udziale przyszłego dewelopera elektrowni jądrowej wersja ostateczna TK na AC.

2. Konieczność uzgodnienia z władzami projektu specyfikacji technicznych elektrowni jądrowej nadzór państwowy i inne zainteresowane organizacje są ustalane wspólnie przez klienta systemu i twórcę projektu specyfikacji technicznych dla elektrowni jądrowej,

Prace nad koordynacją projektu specyfikacji technicznych AC prowadzone są wspólnie przez twórcę specyfikacji technicznych AC i klienta systemu, każdy w organizacjach swojego ministerstwa (departamentu).

3. Termin zatwierdzenia projektu specyfikacji technicznych elektrowni jądrowej w każdej organizacji nie powinien przekraczać 15 dni od dnia jego otrzymania. Zaleca się przesłanie kopii projektu specyfikacji technicznych AS (kopii) jednocześnie do wszystkich organizacji (oddziałów) w celu zatwierdzenia.

4. Uwagi do projektu specyfikacji technicznych elektrowni jądrowej należy zgłaszać wraz z uzasadnieniem technicznym. Decyzje w sprawie uwag muszą zostać podjęte przez twórcę projektu specyfikacji technicznych elektrowni jądrowej i klienta systemu przed zatwierdzeniem specyfikacji technicznych elektrowni jądrowej.

5. Jeżeli przy uzgadnianiu projektu specyfikacji technicznych elektrowni jądrowej powstanie rozbieżność pomiędzy deweloperem a klientem (lub innymi zainteresowanymi organizacjami), wówczas sporządza się protokół rozbieżności (forma dowolna) i konkretne rozwiązanie zaakceptowane w odpowiednim czasie.

6. Dopuszcza się zatwierdzenie projektu specyfikacji technicznych elektrowni jądrowej odrębny dokument(listem). W takim przypadku pod nagłówkiem „Uzgodniono” znajduje się łącze do tego dokumentu.

7. Zatwierdzenia specyfikacji technicznych elektrowni jądrowej dokonują kierownicy przedsiębiorstw (organizacji) dewelopera i klienta systemu.

8. Przed przedłożeniem specyfikacji technicznej do zatwierdzenia specyfikacja techniczna elektrowni jądrowej (dodatek do specyfikacji technicznej) musi zostać sprawdzona przez służbę kontroli regulacyjnej organizacji, która opracowała specyfikację techniczną i, w razie potrzeby, poddana badaniom metrologicznym.

9. Kopie zatwierdzonych specyfikacji technicznych instalacji twórca specyfikacji technicznych instalacji przesyła uczestnikom tworzenia systemu w terminie 10 dni od zatwierdzenia.

10. Koordynacja i zatwierdzanie uzupełnień do specyfikacji technicznych elektrowni jądrowej odbywa się w sposób określony dla specyfikacji technicznych elektrowni jądrowej.

11. Nie dopuszcza się zatwierdzania zmian w specyfikacji technicznej elektrowni jądrowej po poddaniu systemu lub jego kolei próbom odbiorowym.

12. Rejestracja, rozliczanie i przechowywanie specyfikacji technicznych elektrowni jądrowej oraz uzupełnień do niej odbywa się zgodnie z wymogami GOST 2.501.

FORMULARZ STRONY TYTUŁOWEJ TOR NA AC

________________________________________________________

Nazwa
organizacja - twórca specyfikacji technicznych dla elektrowni jądrowej

ZATWIERDZIŁEM

Kierownik
(stanowisko, nazwa przedsiębiorstwa – klient AS)

Podpis osobisty
Pełne imię i nazwisko

Foka

data

ZATWIERDZIŁEM

Kierownik
(stanowisko, nazwa przedsiębiorstwa - „Programista AS”)

Podpis osobisty
Pełne imię i nazwisko

Foka

data

________________________________________________________

nazwa typu głośnika

________________________________________________________

Nazwa obiektu
automatyzacja

________________________________________________________

w skrócie
imię i nazwisko mówcy

ZADANIE TECHNICZNE

Na ____ arkuszach

Ważny
Z

ZGODA

Kierownik
(stanowisko, nazwa organizacji zatwierdzającej)

Podpis osobisty
Pełne imię i nazwisko

Foka

data

FORMUŁA OSTATNIEGO ARKUSZY TOR NA AC

(kod TK)

WYKOŃCZONE ZGODNIE Z UZGODNIENIEM

ZAŁĄCZNIK 4
Informacja

ZAPISY DOTYCZĄCE TWORZENIA JEDNOLITEGO ZESTAWU STANDARDÓW SYSTEMÓW AUTOMATYCZNYCH

1. Wstępne przesłanki do utworzenia kompleksu

1.1. Tworzenie i wdrażanie zautomatyzowanych systemów różnych klas i celów odbywa się w wielu branżach zgodnie z dokumentacją regulacyjną i techniczną, która ustanawia różne standardy organizacyjne, metodologiczne i techniczne, zasady i przepisy, które komplikują integrację systemów i ich efektywne wspólne funkcjonowanie.

1.2. W okresie, gdy Standard Państwowy ZSRR podjął decyzję o udoskonaleniu międzybranżowych kompleksów norm, obowiązywały następujące kompleksy i systemy norm, ustanawiające wymagania dla różne rodzaje klimatyzacja:

1) ujednolicony system standardów zautomatyzowanych systemów sterowania (24. system), obejmujący zautomatyzowane systemy sterowania, zautomatyzowane systemy sterowania, systemy sterowania procesami oraz inne systemy organizacyjno-ekonomiczne;
2) zbiór standardów (system 23501); rozszerzenie na systemy projektowania wspomaganego komputerowo;
3) czwarta grupa XIV systemu norm, obejmująca zautomatyzowane systemy technologicznego przygotowania produkcji.

1.3. Praktyka stosowania standardów dla zautomatyzowanych systemów sterowania, CAD, zautomatyzowanych systemów sterowania procesami, zautomatyzowanych systemów sterowania procesami pokazała, że korzystają one z tego samego aparatu pojęciowego, istnieje wiele wspólnych obiektów normalizacji, lecz wymagania norm nie są ze sobą spójne inne, istnieją różnice w składzie i treści dzieła, różnice w przeznaczeniu, składzie, treści i wykonaniu dokumentów itp.

1.4. Na tle braku jednolitej polityki technicznej w zakresie tworzenia AS, różnorodność standardów nie zapewniała szerokiej kompatybilności AS podczas ich interakcji, nie pozwalała na replikację systemów i utrudniała rozwój obiecujących obszarów dla wykorzystanie technologii komputerowej.

1,5. Obecnie dokonuje się przejścia w kierunku tworzenia złożonych systemów automatyki (za granicą, systemy CAD - CAM), które obejmują zautomatyzowane systemy sterowania procesy technologiczne i produkcji, CAD - projektant, CAD - technolog, ASNI i inne systemy. Stosowanie sprzecznych zasad przy tworzeniu takich systemów prowadzi do obniżenia jakości, wzrostu kosztów pracy i opóźnienia w uruchomieniu elektrowni jądrowych.

1.6. Do systemów zautomatyzowanych powinien mieć zastosowanie jeden zestaw norm i dokumentów zawierających wytyczne do różnych celów: ASNI, CAD, OASU, ASUP, ASUTP, ASUGPS, ASK, ASTPP wraz z ich integracją.

1.7. Przy opracowywaniu dokumentów międzybranżowych należy wziąć pod uwagę następujące cechy AS jako przedmiotu normalizacji:

1) specyfikacja techniczna jest głównym dokumentem, zgodnie z którym dokonuje się utworzenia systemu operacyjnego i jego akceptacji przez klienta;
2) elektrownie jądrowe co do zasady tworzone są według projektu, wyposażone w wyroby seryjne i jednorazowe oraz wykonujące prace konstrukcyjne, instalacyjne, rozruchowe i rozruchowe niezbędne do uruchomienia elektrowni jądrowej;
3) w ogólnym przypadku AS (podsystem AS) składa się z oprogramowania i sprzętu komputerowego (PTK), kompleksów oprogramowania i metodologii (PMK) oraz sprzętu technicznego, oprogramowania i wsparcie informacyjne.
Elementy tego typu obudowy, a także PMC i PTK muszą być produkowane i dostarczane jako produkty do celów przemysłowych i technicznych.
Komponenty mogą być zawarte w AS jako niezależne części lub mogą być łączone w kompleksy;
4) utworzenie AS w organizacjach (przedsiębiorstwach) wymaga specjalnego przeszkolenia użytkowników i personelu obsługującego system;
5) funkcjonowanie AS i kompleksów zapewnia zespół dokumentów organizacyjnych i metodologicznych, uwzględnianych w procesie tworzenia jako elementy wsparcia prawnego, metodologicznego, językowego, matematycznego, organizacyjnego i innego rodzaju wsparcia. Indywidualne rozwiązania uzyskane w procesie tworzenia tego oprogramowania mogą być wdrażane w postaci komponentów sprzętu, oprogramowania lub wsparcia informacyjnego;
6) wspólne funkcjonowanie i interakcja różne systemy i kompleksy przeprowadza się na tej podstawie sieci lokalne KOMPUTER.

Specyfikacje i uzgodnienia przyjęte dla lokalnych sieci komputerowych są obowiązkowe w celu zapewnienia kompatybilności systemów, kompleksów i komponentów.

2. Powiązania CEN AS z innymi systemami i zbiorami norm

2.1. Standaryzacja w dziedzinie głośników jest część integralna pracuje nad uogólnionym problemem „Technologie informacyjne”.

2.2. Ujednolicony zbiór standardów regulujących dokumenty dla systemów zautomatyzowanych wraz z innymi systemami i zbiorami standardów powinien stanowić kompletne wsparcie regulacyjne i techniczne dla procesów tworzenia i eksploatacji systemów zautomatyzowanych.

2.3. CEN AU powinna obejmować obszary normalizacji specyficzne dla systemów zautomatyzowanych i rozszerzać tradycyjne obszary normalizacji na oprogramowanie i sprzęt, kompleksy oprogramowania i metodologii oraz ogólnie systemy zautomatyzowane.

2.4. Kierunki i zadania normalizacji w zakresie regulacyjnego i technicznego wsparcia procesów powstawania i eksploatacji elektrowni jądrowych pogrupowano następująco:

1) ustalanie wymagań technicznych dla wyrobów;
2) regulacje dotyczące metod badań oraz zasad certyfikacji i certyfikacji wyrobów;
3) określenie zasad i trybu opracowywania;
4) ustalanie zasad dokumentacji;
5) zapewnienie kompatybilności;
6) regulowanie zagadnień organizacyjnych i metodologicznych funkcjonowania systemów.

Kierunki 1-4 są tradycyjne w zakresie rozwoju, produkcji i dostarczania produktów. Kierunki 5, 6 mają charakter specyficzny i wynikają z cech właściwych AS.

2.5. Inaczej wygląda wyposażenie elektrowni jądrowych jako całości i ich elementów w dokumentację regulacyjną i techniczną w ramach przyjętych kierunków i zadań normalizacyjnych.

Składniki sprzętu komputerowego, oprogramowania i wsparcia informacyjnego, jako produkty do celów przemysłowych i technicznych, uważa się odpowiednio za produkty projektowe, oprogramowanie i produkty informacyjne. Produkty te podlegają aktualnym zbiorom norm ESKD, SRPP, ESPD, SGIP, USD, klasyfikatorom i kodyfikatorom informacji techniczno-ekonomicznej, zbiorom norm typu „OTT”, „Metody badań”, „TU”, a także OTT klienta.

2.5.1. Wszystko koło życia produkty projektowe są w pełni wyposażone w dokumentację regulacyjną i techniczną obowiązującą w inżynierii mechanicznej i budowie przyrządów.

2.5.2. Oprogramowanie dostarczane jest z dokumentacją naukową i techniczną zawartą w ESPD i OTT Klienta. Należy jednak rozszerzyć zakres tej dokumentacji technicznej, aby uwzględnić zagadnienia związane z rozwojem, tworzeniem, dystrybucją i działaniem oprogramowania.

2.5.3. Produkty informacyjne nie są obecnie opatrzone dokumentacją naukowo-techniczną, choć w ramach USD zostały opracowane pewne zagadnienia, klasyfikatory i kodyfikatory informacji techniczno-ekonomicznej.

2.6. Kompleksy oprogramowanie-sprzęt i oprogramowanie-metodologia są uważane za złożone produkty, które nie mają odpowiedników w inżynierii mechanicznej. Biorąc pod uwagę status PTC i PMK jako wyrobów do celów przemysłowych i technicznych, zasady i tryb ich opracowywania powinny być zbliżone do wymagań stawianych przez normy systemu rozwoju i wytwarzania wyrobów (SRPP).

Wyjątkowość własności intelektualnej jako produktu do celów przemysłowych i technicznych, wyrażająca się w jego złożoności, przy braku standardów dla większości rodzajów procedur i prac, sprawia, że proces ich planowania i projektowania jest bardzo złożony i trudny. Kiedy przedsiębiorstwo w jakimkolwiek celu współpracuje z twórcą IS, do rozpoczęcia pracy wymagane są dwa główne dokumenty: umowa i specyfikacja techniczna (TOR). Opracowanie specyfikacji technicznych jest odrębnym zadaniem. Sama specyfikacja techniczna jest w rzeczywistości dokumentem odzwierciedlającym wszystkie życzenia klienta; powinna być sporządzona tak szczegółowo, jak to możliwe, i wskazywać wszystkie szczegóły i wizję wyniku. Dopiero na jej podstawie zostanie ustalone, co mają zrobić deweloperzy, dlatego też SIWZ powinna być sporządzona możliwie szczegółowo.

Przy projektowaniu jakichkolwiek systemów informatycznych są one wymagane szczegółowy opis. Do tych celów możesz użyć różne drogi i metody, ale większość skuteczne rozwiązanie to opracowanie specyfikacji technicznych (TOR), które opisują cele, zadania, interfejs i inne wymagania dla opracowywanego obiektu.

Specyfikacja techniczna to dokument określający cele, wymagania i podstawowe dane wejściowe niezbędne do opracowania SI. Specyfikacja techniczna IP jest głównym dokumentem określającym wymagania i procedurę tworzenia, rozwoju lub modernizacji IP, zgodnie z którą przeprowadzany jest jego rozwój, uruchomienie i akceptacja.

Sukces we wdrażaniu IP leży w poprawności postawionego przez Klienta zadania. Spadam niezbędne warunki napisać dobrą specyfikację techniczną, wynik zmieni się z oczekiwanego w wykonalny.

przez samego Klienta;

przez wykonawcę, ale w tym przypadku do jego obowiązków będzie należeć projektowanie i testowanie;

wykonawcy konkurencyjni, do których obowiązków należy jedynie pisanie specyfikacji technicznych;

przez wykonawców zewnętrznych.

W przypadku specyfikacji technicznych napisanych przez wykonawcę istnieje szereg dokumentacji regulacyjnej:

GOST 21.408-93 „Zasady wdrażania dokumentacji roboczej dotyczącej automatyzacji procesów technologicznych”;

GOST 34.201-89 „Rodzaje, kompletność i oznaczenie dokumentów przy tworzeniu zautomatyzowanych systemów”;

GOST 24.703-85 „Standardowe rozwiązania konstrukcyjne w zautomatyzowanych systemach sterowania. Przepisy podstawowe”;

GOST 34.003-90 „Systemy zautomatyzowane. Warunki i definicje";

GOST 34.601-90 „Systemy zautomatyzowane. Etapy tworzenia”;

GOST 34.602-90 „Specyfikacje techniczne dotyczące tworzenia zautomatyzowanego systemu”;

GOST 19.201-78 Ujednolicony system dokumentacji programu;

GOST 2.114-95 Ujednolicony system dokumentacji projektowej.

Specyfikacja techniczna dla SI to lista podstawowych wymagań operacyjnych, technologicznych, technicznych, organizacyjnych, programowych, informacyjno-logicznych i językowych, ekonomicznych i innych, które SI musi spełniać na wszystkich etapach swojego istnienia.

TK jest dokument tekstowy, skompilowany w dowolnej formie. Zaleca się przesłanie niezbędnych rysunków, schematów i dużych tabel w formie załączników. W zależności od rodzaju, przeznaczenia i specyfiki obiektu automatyki oraz warunków pracy systemu, istnieje możliwość opracowania sekcji specyfikacji technicznych w formie wniosków, wprowadzenia dodatkowych, wyłączenia lub połączenia jego podrozdziałów.

Nie ma konkretnych zaleceń co do tego, co powinna zawierać specyfikacja techniczna, co oznacza, że sekcje i podrozdziały należy opracować i ułożyć w kolejności ustalonej przez wykonawcę. Są tylko Ogólna charakterystyka sekcje i podrozdziały. Deweloper może samodzielnie zmieniać, dodawać i edytować swoją nazwę i ilość.

Numery arkuszy (stron) umieszcza się zaczynając od pierwszego arkusza po stronie tytułowej, na górze arkusza (nad tekstem, w środku) po wskazaniu kodu TK na IP.

Podpisy klienta, dewelopera i firm zatwierdzających są umieszczane na stronie tytułowej i opieczętowane. W razie potrzeby strona tytułowa jest sporządzana na kilku stronach. Podpisy twórców specyfikacji technicznych i urzędników zaangażowanych w zatwierdzanie i rozpatrywanie projektu specyfikacji technicznych dla Paktu Uczciwości znajdują się na ostatnim arkuszu.

Strona tytułowa dodatku do specyfikacji technicznych jest zaprojektowana podobnie jak strona tytułowa specyfikacji technicznych. Zamiast nazwy „Specyfikacje techniczne” wpisano „Dodatek nr.... do specyfikacji technicznych AC…”

Na kolejnych arkuszach dodatku do specyfikacji technicznych umieszczana jest podstawa zmiany, treść zmiany oraz linki do dokumentów, zgodnie z którymi dokonano tych zmian.

Przedstawiając tekst dodatku do specyfikacji technicznych, należy wskazać numery odpowiednich akapitów, akapitów, tabel głównych specyfikacji technicznych itp. oraz użyć słów: „zamienić”, „uzupełnić”, „wykluczyć”, „stan w nowym wydaniu”.

NA etap początkowy opracowując specyfikacje techniczne, wykonawca tworzy ogólny plan treści.

Informacje ogólne;

Cel i cele stworzenia systemu;

Charakterystyka obiektu automatyki;

Wymagania systemowe;

Warunki korzystania;

Wymagania dotyczące dokumentacji programu;

Wskaźniki techniczne i ekonomiczne;

Etapy i etapy rozwoju;

Procedura kontroli i odbioru.

Sekcje te można podzielić na podrozdziały. Specyfikacje techniczne mogą również obejmować zastosowania opisane zgodnie z ustalonymi standardami. W razie potrzeby wykonawca może dodać lub usunąć wymagane sekcje wszystkie te czynniki należy omówić z klientem. Trzymając się ustalonego planu, wykonawca może sprawnie i w krótkim czasie opracować specyfikację techniczną.

W razie potrzeby wykonawca tworzy listę akceptowane skróty i słownik.

Warunki korzystania z własności intelektualnej instytucja medyczna zamieszczono w Załączniku B.

Niedawno zwrócili się do mnie, aby doradzić mi w sprawie standardów pisania specyfikacji technicznych (TOR) dla rozwoju systemów zautomatyzowanych (AS) i oprogramowania (SW). Myślę więc, że teraz pójdę do Yandex, znajdę odpowiedni artykuł i wyślę go. Ale tego tam nie było! Nie znalazłem ani jednego artykułu, który wymieniałby standardy specyfikacji technicznych, zawierające wzory i przykłady gotowych dokumentów. Będę musiał sam napisać ten artykuł...

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

GOST 34.602-89 Zakres obowiązków dotyczący tworzenia zautomatyzowanego systemu reguluje strukturę specyfikacji technicznych dotyczących tworzenia SYSTEMU, który obejmuje oprogramowanie, sprzęt, osoby pracujące z oprogramowaniem oraz zautomatyzowane procesy.

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

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

GOST 19

„GOST 19.xxx Unified System of Program Documentation (USPD)” to zestaw standardów stanowych, które ustanawiają powiązane zasady opracowywania, projektowania i obiegu programów (lub oprogramowania) oraz dokumentacji programu. Te. Norma ta ma zastosowanie w szczególności do tworzenia oprogramowania.
Zgodnie z GOST 19.201-78 Specyfikacje techniczne, wymagania dotyczące treści i projektu, specyfikacje techniczne muszą zawierać następujące sekcje:

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

Dość dobra definicja normy 830-1998 - Zalecana praktyka IEEE dotycząca specyfikacji wymagań oprogramowania jest podana w samym jej opisie:

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

2. Opis ogólny

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

3. Szczegółowe wymagania (można je uporządkować na różne sposoby, np. w ten sposób)

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

4. Aplikacje
5. Indeks alfabetyczny

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

ZADANIE TECHNICZNE

na rozwój systemu informatycznego

1. Informacje ogólne

4. Wymagania systemowe

6. Procedura kontroli i odbioru systemu

1. Informacje ogólne

Zgodnie z umową nr MP23 pomiędzy TechnoPlus LLC (zwaną dalej Deweloperem) a OptoTorgovlya LLC (zwaną dalej Klientem), Deweloper projektuje bazę danych, opracowuje i uruchamia system informacyjny „Księgowość” operacje handlowe»

Za datę rozpoczęcia projektowania BDB uważa się dzień następujący po podpisaniu niniejszej Specyfikacji Technicznej

Jeżeli w trakcie rozwoju Klient zmieni wymagania opisane w tym dokumencie, wówczas zostaną one sporządzone w odrębnym dokumencie i pociągają za sobą zmianę lub uzupełnienie Umowy pomiędzy Klientem a Deweloperem DB w sprawie terminu wykonania i zapłaty umowy

Klient płaci za pracę Twórcy Bazy Danych zgodnie z Umową nr XXX

2. Cel i cele utworzenia (rozwoju) systemu

IS „Rachunkowość operacji handlowych” służy do przechowywania, przetwarzania i analizowania informacji związanych z główną działalnością Klienta.

Celem utworzenia IS „Rachunkowość operacji handlowych” jest:

Przechowywanie informacji o zakończonych operacjach handlowych;

Odzwierciedlenie transakcji handlowych w rachunkowości;

Analiza wyników finansowych działalności handlowej;

Analiza działalności handlowej według asortymentu i kontrahentów.

3. Charakterystyka obiektów automatyki

3.1. Główną działalnością Klienta jest handel meblami i wyrobami pokrewnymi za pośrednictwem przelewu bankowego.

3.2. Klient nie jest płatnikiem podatku VAT

3.3. W ciągu dnia Klient dokonuje nie więcej niż 100 transakcji handlowych kupna i sprzedaży towarów.

3.4. Całkowita wielkość asortymentu nie przekracza 3000 sztuk

3.5. Łączna liczba kontrahentów - dostawców wynosi nie więcej niż 100 jednostek.

3.6. Liczba kontrahentów – nabywców – nie jest ograniczona. W momencie podpisania umowy N XXX wynosiło 300 sztuk.

3.7. Klient spisuje towar z magazynu metodą średnioważonego kosztu.

3.9. Jako konta wydatków wykorzystywane są wyłącznie konta klasy 9.

3.10. Wyniki finansowe działalności handlowej przedsiębiorstwa (rentowność i rentowność działalności) obliczane są na podstawie różnicy pomiędzy sektorami 702 i 902.

3.11. Transakcje handlowe są rejestrowane w dokumentach podstawowych: Faktura odbioru, Faktura wydatków, Wyciąg bankowy.

Faktura Pributkowa (PN) wskaże fakt, że towar dotarł do magazynu przedsiębiorstwa i będzie zawierał następujące informacje:

- liczba;

- data;

– Nazwa kontrahenta (firma – właściciel poczty);

– nazwa produktu;

- wytrzymałość;

– cena jednostkowa produktu;

- suma.

Faktura Widatkowa (VN) oznacza fakt, że towar został wypromowany z magazynu kupującego i zawiera informacje podobne do informacji w PN (zamiast firmy kurierskiej wskazywana jest firma kupująca).

Wiersz wyciągu bankowego potwierdza fakt otrzymania/wibracji środków od przedsiębiorstwa rozrakhunku (r/r) i zawiera następujące informacje:

- data;

– znak przybycia/wypłaty środków;

– Nazwa kontrahenta (który został znaleziony / który był nadmiernie ubezpieczony).

3.12. Podstawowy dokument skóry Jest to platforma służąca do dokonywania regularnych zapisów, których efektem są zmiany w istniejących księgach rachunkowych. Transakcje handlowe wymagają następujących transakcji (Tabela 3.1)

Tabela 3.1 – Księgowania stosowane w księgowości w przedsiębiorstwie Klienta

Operacja	Dokument	Obciążenie konta	Kredyt na konto	Kwota wpisu
Mianowanie	Faktura zakupu			kwota dokumentu
Wysyłka towaru	Faktura sprzedaży			kwota dokumentu
				koszt wysłanego towaru
Otrzymanie pieniędzy na rachunek bieżący	Wyciąg bankowy (paragon)			kwota dokumentu
Przelew pieniędzy z rachunku bieżącego	Wyciąg bankowy (wydatki)			kwota dokumentu
Ustalanie wyników finansowych				na kwotę zamknięcia 902 rachunków
				na kwotę zamknięcia 702 rachunków

de 281 – towar w magazynie;

311 – rozrahunkovy rakhunok w błędnej walucie;

361 – punkty sprzedaży detalicznej ze skupem wikliny;

631 – rozrakhunki z pracownikami poczty;

702 – dochód ze sprzedaży towarów;

902 – zgodność sprzedanych towarów (wycofanie).

3.13. Bilans w formie syntetycznej wygląda jak w tabeli 3.2.

Tabela 3.2 – Bilans obrotów produktami syntetycznymi

Numer przedmiotu	Bilans kolby	Obrót	Równowaga Kintseve’a







Razem

4. Wymagania systemowe

IS „Rachunkowość operacji handlowych” musi spełniać następujące wymagania:

4.1. Baza danych IS „Rachunkowość operacji handlowych” musi zapewniać przechowywanie, wyświetlanie i edycję informacji referencyjnych i operacyjnych.

Informacje referencyjne:

o opis towaru:

Numer nomenklatury (produktu);

Nazwa produktu;

Opis;

o kontrahenci – dostawcy;

numer kontrahenta;

nazwa wykonawcy;

Adres kontrahenta;

Łączność;

o kontrahenci – nabywcy;

numer kontrahenta;

nazwa wykonawcy;

Adres kontrahenta;

Łączność;

o plan kont, na którym prowadzona jest księgowość w celu rejestrowania operacji handlowych i analizy wyników finansowych;

o lista transakcji podstawowych do wyświetlania transakcji handlowych w księgowości spowodowana dokumentami pierwotnymi, które wyglądają tak, jak w tabeli 3.1;

Informacje operacyjne:

o Dokumenty podstawowe: Faktura paragonowa, Faktura rozchodowa, Wyciąg bankowy (opis dokumentów znajduje się w 3.11)

o Zapisy księgowe spowodowane dokumentami pierwotnymi (rodzaj zapisów przedstawiono w tabeli 3.2)

o Informacje o towarach dostępnych na magazynie:

Numer przedmiotu;

Ilość;

Suma;

Średnia cena.

4.2. IS „Rachunkowość operacji handlowych” powinien umożliwiać automatyzację następujących działań:

4.2.1 Odzwierciedlić fakty odbioru (odbioru) i wysyłki towarów w magazynie, a mianowicie ponownie obliczyć ilość towarów w magazynie i ich średni koszt.

4.2.2 Automatyczne generowanie zapisów księgowych na podstawie dokumentów pierwotnych.

4.2.3 Wyszukaj następujące informacje:

Podstawowe dokumenty określonego typu na określony okres;

Księgowania dla określonego typu dokumentu na konkretną datę;

Informacje o kontrahentu

Informacje o produkcie

4.2.4 Przeprowadź analizę działalności handlowej w określonym okresie w następujących sekcjach:

Wyniki finansowe działalności handlowej;

Wyniki rozliczeń dla każdego kontrahenta;

Pozostały towar w magazynie dla każdej pozycji;

Koszt transakcji dla każdego kontrahenta;

Koszt i liczba sprzedaży każdego rodzaju produktu

4.2.5 Generuj raporty za zadany okres:

Sprzęt, na którym zainstalowany jest układ scalony, musi być wyposażony w zasilacz awaryjny. W przypadku przerwy w dostawie prądu IS powinien automatycznie wyłączyć się bez utraty danych.

IS musi posiadać mechanizmy tworzenia kopii zapasowych, a IS musi być wyposażony w odpowiedni sprzęt i oprogramowanie:

Ilościowe wartości wskaźników niezawodności:

- czas automatyczne uzupełnianie praca nie powinna trwać dłużej niż 1 minutę;

- czas odzyskiwania po awarii nie powinien być dłuższy niż 30 minut;

- indeks tolerancja błędów IP powinno wynosić 11/7, tj. nieprzerwane działanie TO 11 godzin dziennie, 7 dni w tygodniu.

Konserwację IS należy przeprowadzać bez przerywania jego pracy.

4.5 Wymagania dotyczące metod oceny i monitorowania wskaźników niezawodności na etapie eksploatacji próbnej

Aby monitorować wskaźniki niezawodności na etapach próbnego działania IS, personel konserwacyjny musi prowadzić dziennik awarii, który musi zawierać następujące znaki informacyjne:

Data wystąpienia błędu;

Całkowity czas pracy obiektu od początku jego działania do momentu wykrycia błędu;

Znaki zewnętrzne i charakter błędu;

Rodzaj pracy, w której wykryto błąd.

4.6 Wymagania eksploatacyjne układu scalonego

System musi obsługiwać możliwość przetwarzania do 1000 dokumentów dziennie

System musi mieć następującą wydajność:

80% operacji musi mieć czas odpowiedzi (czas wykonania operacji) krótszy niż 1 sekunda;

15% operacji – od 5 sekund. do 10 sekund;

5% operacji - więcej niż 10 sekund, ale nie więcej niż 30 minut.

4.7 Wymagania dotyczące woluminów (skalowalność)

System musi obsługiwać dostęp do danych przez 10 lat.

Szacunkowy wzrost objętości bazy danych na dzień działania wynosi 20 MB.

4.8 Wymagania dotyczące liczby, funkcji i kwalifikacji personelu IS oraz sposobu jego działania

Praca z IS będzie prowadzona przez następujący personel Klienta:

Administrator:

Ilość: 1;

Kwalifikacja: Administrator sieci, Administrator bazy danych;

Funkcje: zarządzanie bezpieczeństwem systemu, kopia zapasowa dane na początku każdego dnia roboczego, archiwizacja danych raz w roku;

Godziny pracy: 1 godzina dziennie, 5 dni w tygodniu

Operator (użytkownik) rejestrujący fakt przeprowadzenia operacji handlowej i analizujący wyniki czynności handlowych:

Ilość: 2;

Kwalifikacje: księgowy, użytkownik komputera PC;

Funkcje: wprowadzanie dokumentów podstawowych, obsługa stan aktulany informacje magazynowe, generowanie zapisów księgowych, analizowanie wyników handlowych, tworzenie kopii zapasowych danych na początku dnia roboczego przypadającego na sobotę i niedzielę.

Godziny pracy: w systemie zmianowym, aby zapewnić pracę systemu 11 godzin na dobę, 7 dni w tygodniu;

Dostęp do pracy: 8-godzinne szkolenie;

Przed oddaniem IS do eksploatacji, w celu uzyskania pozwolenia na pracę, personel musi odbyć 8-godzinne szkolenie. Po ukończeniu kursu przeprowadzane są testy, podczas których oceniana jest poprawność i szybkość rozwiązania problemy praktyczne oraz znajomość instrukcji roboczych i technicznych.

System powinien zapewniać dostęp do swoich funkcji wyłącznie zarejestrowanym użytkownikom IS po podaniu hasła.

4.10 Wymagania dotyczące oprogramowania oraz składu, struktury i metod organizacji bazy danych IS

Dane w Systemie muszą być przechowywane w relacyjny system DBMS SM Serwer SQL 2000.

- T-SQL (dialekt języka SQL);

Z # .

Oprogramowanie składa się z ogólnego oprogramowania systemowego zakupionego na koszt Klienta (oprogramowanie zakupione) oraz oprogramowania specjalnego opracowanego w ramach prac nad stworzeniem IP.

Następujące oprogramowanie powinno być używane jako oprogramowanie ogólnosystemowe:

System operacyjny;

System zarządzania bazami danych MS SQL Server 2000;

Oprogramowanie do tworzenia kopii zapasowych;

4.11 Wymagania sprzętowe

Serwer baz danych, 2 stacje robocze.

Przepustowość sieci wynosi 100 Mbit na sekundę.

4.12 Wymagania dotyczące perspektyw rozwoju i modernizacji SI

Musi istnieć możliwość modernizacji i rozwoju SI bez angażowania Dewelopera przez administratora IS na poziomie:

- uzupełnienia, zmiany, skreślenia informacje referencyjne adres IP;

- podłączanie/usuwanie nowych użytkowników IS;

- zmiany hasła;

- importuj/eksportuj dane z/do źródeł zewnętrznych dane.

Powinna istnieć możliwość modernizacji i rozwoju SI przy ograniczonym udziale Dewelopera (konsultacje telefoniczne) na poziomie modernizacji starych raportów i tworzenia nowych raportów. Możliwość i warunki konsultacji telefonicznych Dewelopera w sprawie modernizacji SI negocjowane są odrębnie w drodze podpisania nowej umowy.

5. Skład i treść pracy nad stworzeniem systemu

Prace nad projektem IS „Rachunkowość operacji handlowych” prowadzone są w trzech etapach.

Pierwszy etap obejmuje:

Sprawdzenie możliwości uzyskania wszystkich żądanych przez Klienta informacji na podstawie danych wyjściowych;

Projekt bazy danych IS;

Wypełnienie opracowanej bazy danych zestaw testowy dane;

Opracowanie projektu interfejsu użytkownika;

Opracowanie specyfikacji technicznej niskiego poziomu dla rozwoju IS „Rachunkowość operacji handlowych”

Zakończenie pierwszego etapu potwierdzane jest podpisaniem wewnętrznego Certyfikatu Ukończonych Prac i zatwierdzeniem specyfikacji technicznej niskiego poziomu dla opracowania Paktu Uczciwości.

Drugi etap to opracowanie wersji testowej IS „Rachunkowość operacji handlowych”. Kończący się ten etap polega na uruchomieniu wersji testowej w trybie próbnym.

Trzeci etap to próbne działanie SI „Rachunkowość operacji handlowych”, które obejmuje eliminację zidentyfikowanych błędów, niedociągnięć i niezgodności z niniejszą Specyfikacją Techniczną. Zakończeniem drugiego etapu jest wprowadzenie IS do komercyjnej eksploatacji.

Zakończenie każdego drugiego i trzeciego etapu Strony umowy potwierdzają podpisaniem Protokołu Przejęcia i Odbioru.

Czas trwania pierwszego etapu wynosi 10 dni. Za początek pierwszego etapu uważa się dzień następujący po dniu podpisania przez Klienta i Dewelopera DB niniejszej Specyfikacji Technicznej.

Czas trwania drugiego etapu wynosi 20 dni. Za początek drugiego etapu uważa się dzień następujący po dniu zatwierdzenia specyfikacji technicznej niskiego poziomu dla rozwoju własności intelektualnej.

Czas trwania trzeciego etapu wynosi 20 dni. Za początek trzeciego etapu uważa się dzień następujący po dniu, w którym Klient i Deweloper DB podpisali Certyfikat Przyjęcia wersji testowej IS do pracy próbnej.

Zbiór danych do testowania IS udostępnia Klient.

Na zakończenie drugiego etapu prac Deweloper DB instaluje testowy IS na serwerze testowym Klienta i przekazuje Klientowi wstępną instrukcję obsługi zawierającą opis procedur niezbędnych do pracy z IS „Trade Accounting”. Opisy znajdują się w w formacie elektronicznym.

Na zakończenie trzeciego etapu prac Deweloper DB przekazuje Klientowi program do instalacji bazy danych na serwerze, a także instrukcje dla użytkownika i programisty oraz instrukcje instalacji IS wraz z opisami procedur niezbędnych do pracy z bazą danych IS „Rachunkowość operacji handlowych”.

6. Procedura kontroli i odbioru systemu

Na zakończenie pierwszego etapu podpisywany jest wewnętrzny Certyfikat Ukończonej Pracy i zatwierdzana jest praca niskopoziomowa arkusz danych dla rozwoju IS.

Na koniec drugiego i trzeciego etapu projektowania Deweloper instaluje IS u Klienta, demonstruje działanie IS zgodnie z wymaganiami określonymi w niniejszej Specyfikacji Technicznej oraz podpisuje Certyfikat Przejęcia i Odbioru.

7. Wymagania dotyczące składu i treści prac przygotowujących obiekt automatyki do uruchomienia systemu

W dniu rozpoczęcia działania próbnego Klient zobowiązany jest zapewnić Deweloperowi niezbędny dostęp do serwera, na którym będzie wdrożona wersja testowa IS „Trade Operations Accounting”.

Brak serwera do zainstalowania bazy danych IS „Księgowość operacji handlowych” nie może być podstawą do odmowy podpisania Certyfikatu przyjęcia IS „Księgowość operacji handlowych” do pracy próbnej lub komercyjnej.

Pod koniec drugiego etapu rozwoju IS „Rachunkowość operacji handlowych” Deweloper przeprowadza 8-godzinne szkolenie z personelem Klienta w zakresie konserwacji IS. Po zakończeniu ten kurs Personel Klienta jest poddawany testom.

8. Wymagania dokumentacyjne

Na koniec trzeciego etapu Twórca IS „Rachunkowość operacji handlowych” przekazuje Klientowi następującą dokumentację:

1. Instrukcje programisty.

Instrukcje Programisty opisują procedury niezbędne do pracy z IS „Rachunkowość Operacji Handlowych”. Opis procedur obejmuje:

Nazwa procedury;

Opis działań wykonywanych przez procedurę;

Opis Parametry wejściowe, wskazujący typ parametru, format jego zapisu oraz wartość domyślną, jeśli dla parametru została zdefiniowana;

Opis parametrów wyjściowych i (lub) zwracanych zestawów rekordów, ze wskazaniem ich typów i formatów

Przykład wywołania procedury i zwracanych przez nią wartości. Jeżeli procedura może mieć kilka opcji wywołania, to przykłady dla każdej opcji.

2. Instrukcje instalacji IS „Rachunkowość operacji handlowych”.

3. Instrukcje dla użytkownika IS „Rachunkowość operacji handlowych”.

Klientowi nie jest przekazywana żadna inna dokumentacja. Instrukcje są dostarczane zarówno w formie drukowanej, jak i elektronicznej. Drukowane instrukcje dostarczane są w jednym egzemplarzu.