2.4.2. Формати і протоколи для вихідних даних

Вихідна інформація буде представлена в вигляді «найменування поля = дані поля». Тобто кожний тип інформації буде представлена користувачу інформаційними блоками. Наприклад:

Виробник:	Intel
Модель:	Celeron M900
Тактова частота:	2.2 Гц

Вихідна інформація поділятиметься на категорії. Тобто інформація про «процесори» не буде виводитись в категорії «відеоадаптери».

2.4.3. Формати та правила зміни керуючих параметрів

Доступ до зміни інформації матимуть тільки адміністратори системи. Для користувачів буде доступно перегляд, пошук та фільтрація даних.

Якщо при змінні даних буде виявлено системою, що дані повторюються з іншим полем(або полями) таблиці БД, то зміни не будуть прийняті.

В системі буде доступно змінити дані тільки тих полів даних, які вже існують.

2.5. Якість системи

2.5.1. Виконання стандартів та узгодження

На створення та виконання було узгоджено стандарт ДЕСТ 34. ДЕСТ 34 – технічне завдання(ТЗ) на створення автоматизованої системи, яка регламентує структуру ТЗ на створення саме системи, в яку входять:

• Програмне забезпечення(ПЗ);

• Апаратне забезпечення;

• Люди, які працюють з ПЗ та системою;

• Автоматизовані процеси системи.

По вибраному стандарту, люди, які працюють з ПЗ – це виробники та супровідники системи. Люди, які працюють з системою – це користувачі та адміністратори.

2.5.2. Можливість перенесення із точки зору апаратного та обчислювального середовища

Дану систему можна розробляти та зберігати як локально, так і в мережі інтернет. Для повноцінної роботи системи її потрібно розміщувати в мережі інтернет.

Для того щоб перенести систему з ПК(персональний комп’ютер) на хостинг можна використовувати ПЗ «Filezilla». Якщо використовувати систему GitHub, то можна скористатись можливостями які вона надає та надати репозиторію(місце зберігання файлів розроблюваної системи в GitHub) доменне ім’я та використовувати його в якості доступу в розроблювану систему.

При перенесенні системи слід враховувати її апаратні та програмні вимоги для середовища виконання.

2.5.3. Надійність функціонування

В свою чергу стійкість системи залежить від рівня неліквідованих дефектів, помилок та здібності системи реагувати на їх проявлення так, щоб це не відображалось в показниках надійності.

Передбачити блокування некоректних дій користувача при роботі з системою.

Стійкість системи проявляється ефективністю контролю вхідних даних та відображення їх аномалій функціонування(дублікати, неправильне внесення та редагування даних, проблеми з видаленням даних).

При виконанні всіх перелічених вимог до системи, вона повинна працювати стабільно.

2.6. Документація системи

2.6.1. Перелік та вимоги до опису посібника керівника

Розроблювана система повинна мати так звану «Карту системи» - перелік всіх статичних посилань системи. Елементи системи(кнопки, посилання, поля введення даних, тощо) повинні мати підкази користувачу.

Вимоги до опису посібника керівника системи:

• Опис основних вікон системи;

• Опис полів введення даних;

• Опис кнопок системи;

• Опис посилань системи;

• Інформація про розробника системи;

• Призначення системи;

• Опис функцій системи.