Загальні відомості про засіб інформатизації

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

Відомості про робочий процес (бізнес-процеси) та пов’язані з ними об’єкти інформатизації, умови їх експлуатації та характеристики

Посилання

Вимоги до засобу інформатизації

Посилання

Склад та зміст робіт із створення (модернізації, модифікації, розвитку) засобу інформатизації.

Опис функціональних вимог. Надається в кожному ТЗ окремо і містить детальний опис, який відповідає на питання "що ми робимо в цій розробці"

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

Основні етапи порядку контролю та приймання:

1. Планування робіт – Визначення тестових сценаріїв

2. Документальне оформлення – написання тест-кейсів

3. Контроль якості – Перевірка, що реалізація відповідає вимогам

4. Демонстрація функціональності – проводиться демо за необхідності

5. Фінальне затвердження – звітування щодо статусу тестування та прийняття рішення про введення в експлуатацію.

Тестові сценарії та тест-кейси описуються окремо до кожної розробки.

Вимоги до документування

Загальні вимоги

• Всі документи мають бути структурованими та актуальними

• Використання уніфікованого формату для всіх документів одного типу

• Використання Confluence, Google Docs для створення документації

• Оновлення документації разом зі змінами в коді або логіці системи.

• Наявність версійності (збереження історії змін документів).

Види документації

Технічні вимоги - загальні бізнес-вимоги

Технічне завдання - детальна технічна специфікація (функціональні та нефункціональні вимоги)

Техно-робочий проект - схема архітектури (залежності, компоненти, API).

Документація коду

• Коментарі у коді відповідно до стандартів (PEP-257 для Python)

• README.md у кожному модулі (опис, як розгорнути, залежності).

• Документація для розробників (Developer Guide).

Документація тестування

• Тестові сценарії

• Тест-кейси

Документація користувача

• Інструкції (User Guide) – як користуватися системою (для внутрішніх клієнтів або майданчиків).

Контроль якості документації

• Аудит документації з певною періодичністю

• Відповідальність за оновлення (наприклад, аналітик оновлює технічні вимоги разом із аналізом змін по CR).

Джерела розробки

Порядок внесення змін і доповнень до технічного завдання

Загальні положення

• Будь-які зміни та доповнення до ТЗ мають бути зафіксовані.

• Зміни можуть ініціюватися продуктом, розробником або іншими зацікавленими сторонами.

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

Ініціація змін

1. Ініціатор змін формує запит на зміну (Change Request)

2. Запит оформлюється у вигляді таски в системі управління проєктами Jira

Аналіз та оцінка змін

1. Аналітик з командою розробки аналізують запит і готують висновок:

   • Оцінка трудовитрат

   • Вплив на інші частини системи

   • Потенційні ризики

2. Оцінка передається на схвалення замовником або керівництвом проєкту.

Внесення змін до документації

1. Після затвердження зміни вносяться в ТЗ та інші пов’язані документи

2. Всі зацікавлені сторони отримують оновлену версію документа

Контроль виконання

• Після внесення змін проводиться тестування

• Якщо зміни не пройшли перевірку – проводиться повторне коригування або відкат до попередньої версії.

Висновки

Можуть бути вказані з ТЗ по розробці конкретного продукту.