Принимайте участие в зарплатном опросе! Уже собрано почти 8 000 анкет.
×Закрыть

Вимоги до написання технічного завдання

Прошу допомогти розібратись.
Чи є якісь стандарти по написанню ТЗ на софт?
Цікавлять в Україні і окремо міжнародні стандарти.

Прохання повідомити наслідки написання ТЗ не по стандартах.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А чому взагалі виникло таке питання? Зазвичай саме ТЗ готують для держорганізацій.

Добре коли взагалі є ТЗ. Але часто плутають ТЗ і ТВ (технічні вимоги), та видають їх за ТЗ

Скажіть, а ТВ це типу «паспорт продукту»?

Йдеш на prozorro і шукаєш тендери на розробку програмного забезпечення, часто в умовах тендеру є технічне завдання і вимоги до відповідності стандартам.
P.S.
Якщо фінансування тендерів йде в рамках допомоги/кредитування міжнародних організацій, там свій перелік вимог, але також є посилання.

Если это не госпроект (проект за госбаблос) — техзадание может бытъ даже в свободных форме и содержании, удовлетворяющих обе стороны договора.

Если это госзаказ, то там в 95% случаях будет ТЗ по ГОСТу.

Да, видал я такие задания в свободной форме, которые составляют люди далекие от технической части.

Оно обычно из 2 слов: «Сделайте пиздато» (без мата тут никак).

ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению 4 действует в Украине до 01-01-19

78 если что это год разлива ГОСТА

Вот ещё ссылочка на тему, там и про международные стандарты.
habr.com/post/328822

Прохання повідомити наслідки написання ТЗ не по стандартах.

Ви не зможете гордо заявити що написали ТЗ згідно такому-от стандарту. Ну і якщо взагалі не розумієте що в ТЗ писати то напевно напишете фігню. А взагалі наразі то є зміст розглядати швидше як рекомендації наприклад 830-1998 — IEEE Recommended Practice for Software Requirements Specifications прямо в назві містить слово Recommended

Ви не зможете гордо заявити що написали ТЗ згідно такому-от стандарту

Ну і відповідно не зможете сертифікувати свій процесс розробки по відповідним стандартам... якщо воно вам зівстно треба.

а сертифікація обов’язкова? (онлайн-сервіс працюватиме у всіх країнах Світу)

Якщо юрист задає таке питання, то є вірною ознакою того що не обовязкова.
Ні, простому онлайн сервісі не потрібна ніяка сертифікація.

дуже вам дякую.
Із сертифікацією взагалі ніколи не працював)

Справедливости ради. Есть еще
ГОСТ 34.602-89 «Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.» Посвежее. И тоже — пока действующее в Украине до 01.01.2019.

В принципі дуже конкретно написано про 19 і потім про 34 ГОСТ, я би ще поставив питання, а з якою метою потрбіна відсилка до стандарту? якщо для того щоб найти шаблон і зрозуміти, що писати так тоді ліпше IEEE і якість живі приклади, якщо для виконання вимог договору (вимог замовника, якщо це наприклад держ установи), то рекомендував би почитати той самий договір, або спитати замовника

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

Ціль ТЗ, це можливість нових учасників команди швидко розібратись у розробках, які були до них. По-суті лише для себе ну і на випадок продажу софту)

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

Ми колись писали для кожної фічі щось типу
1. мета і короткий опис проблеми яку рішаємо так сказати мотивація
2. детальні вимоги — як правило кейпоінти списком
3. Рішеня в загальному (яущо є що писати на пару речень текстом)
4. Деталі — тут можна і малюночки і по пунктах ключові моменти реалізаціі
5. відкриті питання.

ну і додати пунктів на власний россуд. Для нас то тоді мало зміст, чи має то зміст для вас — я не знаю.

Подписаться на комментарии