Мене часто запитують: Як правильно розробити технічне завдання для автоматизованої системи? Аналогічна тема постійно обговорюється різних форумах. Це питання настільки широке, що відповісти двома словами ніяк не можна. Тому я вирішив написати велику статтю на цю тему.

• У першій частині « Розробка технічного завдання. Що це таке, навіщо воно потрібно, з чого почати і як має виглядати?» я докладно спробую відповісти на питання теми, розгляну структуру та призначення Технічного завдання, дам деякі рекомендації щодо формулювання вимог.
• Друга частина " Розробка технічного завдання. Як формулювати вимоги?» буде повністю присвячена виявленню та формулюванню вимог до інформаційної системи.

Для початку треба розібратися, яке насправді питання цікавить тих, хто запитує: «Як розробити технічне завдання?». Справа в тому, що від того, для яких цілей це робиться, а також ким буде використовуватися, сильно залежатиме і підхід до розробки технічного завдання. Про які варіанти я говорю:

• Комерційна організація вирішила впровадити в собі автоматизовану систему. Вона не має власної IT-служби і вирішила вчинити так: Зацікавлена ​​особа має розробити Технічне завдання та віддати його на розробку сторонньої організації;
• Комерційна організація вирішила впровадити в собі автоматизовану систему. Вона має власну службу IT. Вирішили вчинити так: розробити Технічне завдання, потім узгодити його між IT-службою та зацікавленими особами, та реалізувати власними силами;
• Держструктура вирішила починати IT-проект. Тут все настільки каламутно, купа формальностей, відкатів, розпилів та ін. Я не розглядатиму такий варіант у цій статті.

• IT-компанія займається послугами з розробки та впровадження автоматизованих систем. Це найбільш складний випадок, адже доводиться працювати в різних умовах:

  • Клієнт має своїх фахівців зі своїми поглядами, і вони висувають конкретні вимоги до Технічного завдання;
  • Технічне завдання розробляється для розробників (клієнту однаково);
  • Технічне завдання розробляється передачі підрядчику (тобто. групі програмістів, які перебувають за штатом компанії, чи окремому спеціалісту);
  • Між компаній і клієнтом виникає нерозуміння в питанні отриманого результату, і компанія знову і знову запитує: «Як треба розробляти Технічне завдання?». Можливо останній випадок здається парадоксом, але це правда.
  • Можливі й інші варіанти, що рідше зустрічаються;

Думаю, зараз у читача мають виникнути питання:

• А чому не можна розробляти Технічне завдання завжди однаково?
• Чи є якісь стандарти, методики, рекомендації? Де їх взяти?
• Хто має розробляти технічне завдання? Чи має ця людина мати якісь спеціальні знання?
• Як зрозуміти, чи добре складено Технічне завдання чи ні?
• За чий рахунок має воно розроблятися, та й чи потрібне воно взагалі?

Цей список може бути нескінченним. Говорю так упевнено від того, що вже 15 років у професійній розробці програмного забезпечення, а питання про Технічні завдання спливає у будь-якому колективі розробників, з ким доводиться працювати. Причини цього різні. Порушуючи тему розробки Технічного завдання, я чудово усвідомлюю те, що не зможу викласти її на 100% для всіх, хто цікавиться темою. Але, спробую, як то кажуть, «розкласти все по поличках». Ті, хто вже знайомий з моїми статтями знають, що я не користуюся копі-пастом праці інших людей, не передруковую чужі книги, не цитую багатосторінкові стандарти та інші документи, які Ви і самі зможете знайти в інтернеті, видаючи їх за свої геніальні думки. Достатньо набрати в пошуковій системі «Як розробити Технічне завдання» і Ви зможете прочитати багато цікавого, але, на жаль, багаторазово повторюваного. Як правило, ті, хто любить розумнічати на форумах (спробуйте все-таки пошукати!), самі ніколи не робили тлумачного Технічного завдання, і безперервно цитують рекомендації ГОСТів з цього питання. А тим, хто справді серйозно займається питанням, зазвичай ніколи сидіти на форумах. Про ГОСТИ, до речі, ми теж поговоримо. У різні роки своєї роботи мені доводилося бачити безліч варіантів технічної документації, складеної як окремими фахівцями, так і відомими командами та консалтинговими компаніями. Іноді ще я займаюся такою діяльністю: виділяю собі час і займаюся пошуком інформації на тему, що цікавить, за незвичайними джерелами (такою невеликою розвідкою). В результаті доводилося бачити документацію і за такими монстрами, як ГазПром, РЗ та багато інших цікавих компаній. Звичайно ж, я дотримуюсь політики конфіденційності, незважаючи на те, що ці документи потрапляють до мене з загальнодоступних джерел або безвідповідальності консультантів (розкидають інформацію по інтернету). Тому відразу кажу: конфіденційною інформацією, яка належить іншим компаніям не поділяюся, незалежно від джерел виникнення (професійна етика).

Що таке технічне завдання?

Перше, що ми зараз зробимо, то це розберемося з тим, що за звір такий, «Технічне завдання».

Так, дійсно існують ГОСТи та стандарти, в яких зроблено спроби регламентувати цю частину діяльності (розробки програмного забезпечення). Колись усі ці ГОСТи були актуальними та активно застосовувалися. Наразі існують різні думки щодо актуальності даних документів. Одні стверджують, що ГОСТи були розроблені дуже далекоглядними людьми і досі актуальні. Інші кажуть, що вони безнадійно застаріли. Можливо, хтось зараз подумав, що правда десь посередині. Я б відповів словами Гете: «Кажуть, що між двома протилежними думками є істина. Ні в якому разі! Між ними лежить проблема». Так от, між цими думками істини немає. Тому що ГОСТи не розкривають практичних проблем сучасної розробки, а ті, хто їх критикує, альтернативи (конкретної та системної) не пропонують.

Зауважимо, що у ГОСТі явно не дано навіть визначення, сказано лише: «ТЗ на АС є основним документом, що визначає вимоги та порядок створення (розвитку чи модернізації - далі створення) автоматизованої системи, відповідно до якого проводиться розробка АС та її приймання під час введення у дію».

Якщо комусь цікаво, про які ГОСТи я говорю, то ось вони:

• ГОСТ 2.114-95 Єдина система конструкторської документації. Технічні умови;
• ГОСТ 19.201-78 Єдина система програмної документації. Технічне завдання. Вимоги до змісту та оформлення;
• ГОСТ 34.602–89 Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання створення автоматизованої системи.

Куди вдале визначення представлено у вікіпедії (щоправда про ТЗ загалом, а чи не лише програмного забезпечення): « Технічне завдання- Це вихідний документ на проектування технічногооб'єкт. Технічне завданнявстановлює основне призначення об'єкта, що розробляється, його технічні та тактико-технічні характеристики, показники якості та техніко-економічні вимоги, розпорядження щодо виконання необхідних стадій створення документації (конструкторської, технологічної, програмної тощо) та її склад, а також спеціальні вимоги. Завдання як вихідний документ на створення чогось нового існує у всіх галузях діяльності, розрізняючись за назвою, змістом, порядком оформлення тощо (наприклад, проектне завдання у будівництві, бойове завдання, домашнє завдання, договір на літературний твір тощо). д.)»

І так, як випливає з визначення, основне призначення Технічного завдання - сформулювати вимоги до об'єкта, що розробляється, в нашому випадку до автоматизованої системи.

Саме головне, але єдине. Настав час взятися за головне: розкласти все «по поличках», як і обіцяв.

Що потрібно знати про вимоги? Необхідно чітко розуміти, що всі вимоги потрібно розділяти за видами та властивостями. Нині ми навчимося це робити. Для поділу вимог за видами нам допоможе ГОСТ. Той перелік видів вимог, який там представлений, є добрим зразком того, вимоги яких видів слід розглядати. Наприклад:

• Вимоги до функціональності;
• Вимоги до безпеки та прав доступу;
• вимоги до кваліфікації персоналу;
• …. І т.д. Ви можете прочитаєте про них у згаданому ГОСТі (а нижче я їх теж розгляну трохи детальніше).

Думаю, для Вас очевидно, що ключовим фактором успішного Технічного завдання є добре сформульовані вимоги до функціональності. Саме цим вимогам присвячено більшість робіт та методик, про які я говорив. Вимоги до функціональності – це 90% складності робіт із розробки Технічного завдання. Решта найчастіше є «камуфляжем», який одягнений на ці вимоги. Якщо вимоги сформульовані погано, який красивий камуфляж на них не натягуй, успішного проекту не вийде. Так, формально всі вимоги будуть дотримані (за ГОСТом J), ТЗ розроблено, затверджено та підписано, гроші за нього отримано. І що? А далі почнеться найцікавіше: що робити? Якщо це проект на ДержЗамовленні, то проблем немає – там бюджет такий, що в жодну кишеню не влізе, у процесі реалізації (якщо вона буде) все і з'ясовуватиметься. Саме таким чином і пиляється більшість бюджетів проектів на ДержЗамовленнях (накалякали «ТЗ», злили десяток мільйонів, а проект робити не стали. Усіх формальностей дотримано, винних немає, нове авто біля будинку. Краса!). Але ж ми говоримо про комерційні організації, де гроші рахують, та й результат потрібен інший. Тому давайте розбиратися з головним, як розробляти корисні та працюючі Технічні завдання.

Про види вимог я сказав, а що ж із властивостями? Якщо види вимог можуть бути різними (залежить від цілей проекту), то з властивостями все простіше, 3:

1. Вимога має бути зрозумілим;
2. Вимога має бути конкретним;
3. Вимога має бути тестованим;

Причому остання властивість неможлива без двох попередніх, тобто. є таким собі «лакмусовим папірцем». Якщо результат виконання вимоги неможливо протестувати, отже, вона або незрозуміла, або не конкретна. Подумайте про це. Саме у володінні цими трьома властивостями вимог і полягає майстерність та професіоналізм. Насправді все дуже просто. Коли розберешся.

У цьому розповідь у тому, що таке Технічне завдання можна було б завершити і перейти до головного: як формулювати вимоги. Але не так швидко. Є ще один украй важливий момент:

• якою мовою (у сенсі складності розуміння) має бути написане технічне завдання?
• Чи мають бути описані у ньому специфікації різних функцій, алгоритми, типи даних та інші технічні штуки?
• А що таке технічне проектування, про яке, до речі, сказано і в ГОСТах, і як воно пов'язане з технічним завданням?

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

Технічне завдання– це документ, в основі якого лежать вимоги, сформульовані зрозумілою (звичайною, звичною) для Замовника мовою. При цьому може і повинна використовуватися галузева термінологія, зрозуміла Замовнику. Жодних прив'язок до особливостей технічної реалізації не повинно бути. Тобто. на етапі ТЗ у принципі не важливо, на якій платформі реалізовуватимуться ці вимоги. Хоча є винятки. Якщо йдеться про впровадження системи на основі вже існуючого програмного продукту, то така прив'язка може мати місце, але тільки на рівні екранних форм, форм звітів та ін. бізнес аналітик.І аж ніяк не програміст (якщо він не поєднує в собі ці ролі, таке трапляється). Тобто. ця людина має говорити із Замовником мовою його бізнесу.

Технічний проект– це документ, призначений для технічної реалізації вимог, сформульованих у Технічному завданні. Якраз у цьому документі описуються структури даних, тригери та процедури, що зберігаються, алгоритми та інші штуки, які будуть потрібні технічним фахівцям. Замовнику в це вникати зовсім не обов'язково (йому і такі терміни можуть бути незрозумілі). Технічний проект робить Архітектор системи(Ось поєднання цієї ролі з програмістом цілком нормально). А точніше група фахівців АТ на чолі з архітектором. Чим більший проект, тим більше людей працює над Технічним завданням.

Що ми маємо на практиці? Забавно спостерігати, коли директору приносять на узгодження Технічне завдання, яке рясніє технічною термінологією, описом типів даних та їх значень, структури бази даних та ін. бізнес-вимог. Що, знайома ситуація? І що це закінчується? Зазвичай, таке ТЗ стверджується, потім реалізується, а 80% випадків потім зовсім відповідає факту виконаних робіт, т.к. багато чого вирішили змінити, переробити, неправильно зрозуміли, не так думали тощо. і т.п. А потім починається серіал про здачу робіт. "А ось тут не так як нам треба", а "це в нас працювати не буде", "це занадто складно", "це незручно" і т.д. Знайомо?!! Ось і мені знайомо, довелося набити шишок свого часу.

То що ми маємо на практиці? А на практиці ми маємо розмитий кордон між Технічним завданням та Технічним проектом. Вона плаває між ТЗ і ТП у найрізноманітніших проявах. І це погано. А виходить так тому, що культура розробки стала слабкою. Частково це пов'язано з компетенціями фахівців, частково із прагненням скоротити бюджети та терміни (адже документація займає багато часу – це факт). Є ще один важливий фактор, що впливає на використання Технічного проекту як окремого документа: стрімкий розвиток засобів швидкої розробки, а також методологій розробки. Але це окрема історія, трохи нижче за кілька слів про це скажу.

Ще невеликий, але важливий момент. Іноді Технічним завданням називають невеликий шматочок вимог, простий та зрозумілий. Наприклад, доопрацювати пошук об'єкта за будь-якими умовами, додати колонку у звіт тощо. Такий підхід цілком виправданий, навіщо ускладнювати життя. Але застосовується не так на великих проектах, але в дрібних доопрацюваннях. Я сказав би це ближче до супроводу програмного продукту. У цьому випадку в Технічному завданні може бути описано конкретне технічне рішення реалізації вимоги. Наприклад, «В алгоритм такий-то внести таку зміну», із зазначенням конкретної процедури та конкретної зміни для програміста. Це випадок, коли кордон між Технічним завданням і Технічним проектам повністю стирається, т.к. немає жодної економічної доцільності роздмухувати паперотворчість там, де це не потрібно, а корисний документ створюється. І це вірно.

А чи потрібне взагалі технічне завдання? А Технічний проект?

Чи не перегрівся я? Хіба таке можливо, взагалі без Технічного завдання? Уявіть собі можливо (точніше, зустрічається), і такий підхід має багато послідовників, і їх кількість збільшується. Як правило, після того, як молоді фахівці начитаються книг про Scrum, Agile та інші технології швидкої розробки. Насправді це чудові технології, і вони працюють, тільки в них не йдеться дослівно «не треба виконувати технічні завдання». У них говориться «мінімум паперів», особливо непотрібних, ближче до Замовника, більше за конкретику і швидше до результату. Але фіксування вимог ніхто не скасовував, і там це сказано. Саме там вимоги і фіксуються, виходячи з трьох чудових властивостей, про які я говорив вище. Просто у деяких людей так влаштована свідомість, що якщо можна щось спростити, то давайте це спростимо до повної відсутності. Як сказав Ейнштейн « Зроби так просто, як можливо, але не простіше за це» . Адже золоті слова, до всього підходять. Так що Технічне завданняПотрібно, інакше успішного проекту Вам не бачити. Інше питання, як складати і що туди вмикати. У світлі методологій швидкої розробки треба зосередитись лише на вимогах, а весь «камуфляж» можна відкинути. В принципі я з цим згоден.

А що ж із Технічним проектом? Цей документ дуже корисний і не втратив своєї актуальності. Більше того, часто без нього просто не обійтись. Особливо, якщо йдеться про передачу робіт із розробки набік, тобто. за принципом аутсорсингу. Якщо цього не зробити, є ризик дізнатися багато нового про те, як має виглядати система, яку Ви задумали. Чи повинен з ним знайомитись Замовник? Якщо хоче, чому ні, але наполягати і затверджувати цей документ немає жодної необхідності, він лише стримуватиме і заважатиме працювати. Спроектувати систему до дрібниць практично неможливо. В цьому випадку доведеться безперервно вносити зміни до Технічного проекту, що займає чимало часу. А якщо організація сильно забюрократизована, то загалом усі нерви там залишите. Якраз про скорочення такого роду проектування і йдеться у сучасних методологіях швидкої розробки, про які я згадував вище. До речі, всі вони базуються на класичному XP (екстремальному програмуванні) - підході, якому вже близько 20 років. Тож зробіть якісне Технічне завдання, зрозуміло Замовнику, а Технічний проект використовуйте як внутрішній документ для взаємовідносин між архітектором системи та програмістами.

Цікава деталь з приводу технічного проектування: деякі засоби розробки, влаштовані за принципом предметної орієнтованості (типу 1С та аналогічних) припускають, що проектування (мається на увазі процес документування) потрібне тільки на справді складних ділянках, де потрібна взаємодія між собою цілих підсистем. У найпростішому випадку, наприклад, створити довідник, документ, достатньо лише правильно сформульованих бізнес-вимог. Про це свідчить і стратегія бізнесу цієї платформи щодо підготовки фахівців. Якщо подивитися на екзаменаційний квиток фахівця (саме так він називається, а не програміста), то Ви побачите, що там присутні лише бізнес-вимоги, а як їх реалізувати програмною мовою це і є завдання фахівця. Тобто. ту частину завдання, яку покликаний вирішувати Технічний проект, фахівець повинен вирішити «в голові» (йдеться про завдання середньої складності), причому тут і зараз, дотримуючись певних стандартів розробки та проектування, які формує знову ж таки компанія 1С для своєї платформи. Таким чином, з двох фахівців, результат роботи яких зовні виглядає однаково, один може скласти іспит, а другий ні, т.к. грубо порушив стандарти розробки. Тобто свідомо передбачається, що фахівці повинні мати таку кваліфікацію, щоб типові завдання проектувати самостійно, без залучення архітекторів системи. І такий підхід працює.

Продовжимо дослідження питання: «Які вимоги включати до Технічного завдання?»

Формулювання вимог щодо інформаційної системи. Структура Технічного завдання

Відразу визначимося: ми говоритимемо саме про формулювання вимог до інформаційної системи, тобто. припускаючи, що з вироблення бізнес-вимог, формалізації бізнес-процесів і вся попередня консалтингова робота вже виконано. Звичайно, деякі уточнення можуть виконуватись і на цьому етапі, але саме уточнення. Сам проект автоматизації не вирішує проблем бізнесу – пам'ятайте про це. Це аксіома. Чомусь деякі керівники намагаються її спростувати, вважаючи, що якщо куплять програму, то настане лад у хаотичному бізнесі. Але аксіома на те й аксіома, що доказів не вимагає.

Як і будь-яку діяльність, формулювання вимог можна (і потрібно) поділити на етапи. Всьому свій час. Це важка інтелектуальна праця. І якщо ставиться до нього з недостатньою увагою, то результат буде відповідний. За експертними оцінками вартість витрат на розробку Технічного завдання може становити 30-50%. Я дотримуюсь такої самої думки. Хоча 50 – мабуть, перебір. Адже Технічне завдання – це ще останній документ, який має бути розроблений. Адже ще має бути технічне проектування. Такий розкид обумовлений різними платформами автоматизації, підходами та технологіями, які застосовуються проектними командами при розробці. Наприклад, якщо йдеться про створення класичною мовою типу С++, то без детального технічного проектування тут не обійтися. Якщо йдеться про впровадження системи на платформі 1С, то тут із проектуванням ситуація дещо інша, як ми бачили вище (хоча, при розробці системи «з нуля», вона проектується за класичною схемою).

Незважаючи на те, що формулювання вимог є основною частиною Технічного завдання, а в деяких випадках вона ставати єдиним розділом ТЗ, слід звернути увагу на те, що це важливий документ, і оформляти його слід відповідно. З чого почати? Насамперед почати треба зі змісту. Складіть зміст, а потім почніть його розгортати. Особисто я роблю так: спочатку накидаю зміст, описую цілі, всю вступну інформацію, а потім приймаюсь за основну частину – формулювання вимог. Чому не навпаки? Не знаю, мені так зручніше. По-перше, це набагато менша частина часу (порівняно з вимогами), по-друге, поки описуєш всю вступну інформацію, налаштовуєшся на головне. Ну, це кому як подобається. Згодом у Вас виробиться свій шаблон Технічного завдання. Для початку рекомендую як зміст взяти саме той, що описаний в ГОСТ. Для змісту він підходить чудово! Потім беремо і починаємо описувати кожен розділ, не забуваючи про рекомендації дотримання трьох властивостей: зрозумілості, конкретності та тестованості. Чому я так наполягаю? Про це у наступному розділі. А зараз пропоную все-такт пройтися тими пунктами ТЗ, які рекомендуються в ГОСТі.

1. загальні відомості;
2. призначення та цілі створення (розвитку) системи;
3. характеристика об'єктів автоматизації;
4. вимоги до системи;
5. склад та зміст робіт зі створення системи;
6. порядок контролю та приймання системи;
7. вимоги до складу та змісту робіт з підготовки об'єкта автоматизації до введення системи у дію;
8. вимоги до документування;
9. Джерела розробки.

Разом, 9 розділів, кожен із яких теж ділиться на підрозділи. Розберемо їх по порядку. Для зручності представлю все як таблиці по кожному пункту.

Розділ 1. Загальні відомості.

Рекомендації щодо ГОСТ
повне найменування системи та її умовне позначення;	Тут усе зрозуміло: пишемо, як називатиметься система, її коротке найменування
шифр теми чи шифр (номер) договору;	Це не актуально, але можна і вказати, якщо потрібно
найменування підприємств (об'єднань) розробника та замовника (користувача) системи та їх реквізити;	вказують, хто (які організації) працюватимуть над проектом. Можна вказати і їх ролі. Можна взагалі видалити цей розділ (досить формальний).
перелік документів, на підставі яких створюється система, ким і коли затверджено ці документи;	Корисна інформація. Тут варто зазначити ту нормативно-довідкову документацію, яку Вам надали для ознайомлення з певною частиною вимог
планові терміни початку та закінчення роботи зі створення системи;	Побажання щодо термінів. Іноді у ТЗ про це пишуть, але найчастіше такі речі описуються у договорах на роботи
відомості про джерела та порядок фінансування робіт;	Аналогічно, як і в попередньому пункті термінів. Більше актуально для державних замовлень (для бюджетників)
порядок оформлення та пред'явлення замовнику результатів робіт із створення системи (її частин), з виготовлення та налагодження окремих засобів (технічних, програмних, інформаційних) та програмно-технічних (програмно-методичних) комплексів системи.	Не бачу потреби у цьому пункті, т.к. вимоги до документування винесені окремо, крім цього є цілий окремий розділ «Порядок контролю та приймання» системи.

Розділ 2. призначення та цілі створення (розвитку) системи.

Рекомендації щодо ГОСТ	Що з цим робити на практиці
Призначення системи	З одного боку, з призначенням все просто. Але бажано формулювати конкретно. Якщо написати щось на кшталт «якісно автоматизувати складський облік у компанії Х», то потім можна довго обговорювати результат при його завершенні навіть незалежно від хорошого формулювання вимог. Т.к. Замовник завжди може говорити, що під якістю він мав на увазі щось інше. Загалом нервів можна зіпсувати один одному багато, а навіщо? Краще відразу написати приблизно так: «Система призначена для ведення складського обліку в компанії Х відповідно до вимог, зафіксованих у даному Технічному завданні».
Цілі створення системи	Цілі – це безумовно важливий розділ. Якщо його вмикати, то треба вміти ці цілі формулювати. Якщо у Вас проблеми з формулюванням цілей, то краще взагалі виключити цей розділ. Приклад невдалої мети: "Забезпечити швидке оформлення документів менеджером". Що таке швидке? Це можна потім доводити нескінченно. Якщо це важливо, краще переформулювати цю мету так: «Менеджер з продажу повинен мати можливість оформити документ «Реалізація товарів» зі 100 рядків за 10 хвилин». Подібна мета може з'явитися, якщо, наприклад, в даний час менеджер витрачає на це близько години, що дуже багато для цієї компанії і для них це важливо. У такому формулюванні мета вже перетинається з вимогами, що природно, т.к. при розгортанні дерева цілей (тобто дроблячи їх на дрібніші пов'язані цілі), ми і так будемо наближатися до вимог. Тому захоплюватися не варто.

Взагалі, вміння виділяти цілі, формулювати їх, будувати дерево цілей – це тема абсолютно окрема. Запам'ятайте головне: вмієте – пишіть, не впевнені – взагалі не пишіть. А що буде, якщо не сформулювати цілі? Працюватимете за вимогами, таке часто практикується.

3. Характеристика об'єктів автоматизації.

Розділ 4. Вимоги до системи

ГОСТ розшифровує перелік таких вимог:

• вимоги до структури та функціонування системи;
• вимоги до чисельності та кваліфікації персоналу системи та режиму його роботи;
• показники призначення;
• вимоги до надійності;
• вимоги безпеки;
• вимоги до ергономіки та технічної естетики;
• вимоги до транспортабельності для рухомих АС;
• вимоги до експлуатації, технічного обслуговування, ремонту та зберігання компонентів системи;
• вимоги щодо захисту інформації від несанкціонованого доступу;
• вимоги щодо збереження інформації при аваріях;
• вимоги щодо захисту від впливу зовнішніх впливів;
• вимоги до патентної чистоти;
• вимоги щодо стандартизації та уніфікації;

Незважаючи на те, що основним, безумовно, буде розділ із конкретними вимогами (функціональними), цей розділ теж може мати велике значення (і здебільшого має). Що може виявитися важливим та корисним:

• Вимоги до кваліфікації. Можливо, система, що розробляється, вимагатиме перепідготовки фахівців. Це можуть бути як користувачі майбутньої системи, так і IT-фахівці, які будуть потрібні для її підтримки. Недостатня увага до цього питання нерідко переростає у проблеми. Якщо кваліфікація наявного персоналу явно недостатня, краще прописати вимоги до організації навчання, програми навчання, термінів тощо.
• Вимоги щодо захисту інформації від несанкціонованого доступу.Тут коментарі зайві. Це і є вимоги до розмежування доступу до даних. Якщо такі вимоги плануються, їх потрібно розписати окремо, як можна детальніше за тими самими правилами, як і функціональні вимоги (зрозумілість, конкретність, тестируемость). Тому можна ці вимоги включити і в розділ з функціональними вимогами
• Вимоги до стандартизації.Якщо існують будь-які стандарти розробки, які застосовуються до проекту, вони можуть бути включені до вимог. Як правило, такі вимоги ініціює ІТ-служба Замовника. Наприклад, у компанії 1С є вимоги до оформлення програмного коду, проектування інтерфейсу та ін;
• Вимоги до структури та функціонування системи.Тут можуть бути описані вимоги до інтеграції систем, представлений опис загальної архітектури. Найчастіше вимоги до інтеграції виділяють взагалі окремий розділ і навіть окреме Технічне завдання, т.к. ці вимоги можуть бути досить складними.

Всі інші вимоги менш важливі і їх можна не описувати. На мій погляд, вони лише ускладнюють документацію і практичної користі несуть небагато. А Вимоги до ергономіки описувати як загальних вимог дуже складно, краще їх перенести до функціональним. Наприклад, може бути сформульована вимога «Отримати інформацію про ціну товару, натиснувши лише одну кнопку». На мій погляд, це все-таки ближче до конкретних функціональних вимог, хоч і відноситься до ергономіки. Вимоги до функцій (завдань), що виконуються системою. Навіть якщо все інше зробити на відмінно, а цей розділ на «3», то результат по проекту буде в кращому випадку на «3», а то й взагалі проект провалиться. Саме ці ми і займемося детальніше у другій статті, яка увійде до 5-го випуску розсилки. Саме до цього пункту належить «правило трьох властивостей вимог», про які я говорив. Вимоги до видів забезпечення

ГОСТ виділяє такі види:

• Математичне
• Інформаційне
• Лінгвістичне
• Програмне
• Технічне
• Метрологічне
• Організаційне
• Методичний
• та інші…

На перший погляд може здатися, що ці вимоги не є важливими. У більшості проектів це справді так. Але не завжди. Коли варто описувати ці вимоги:

• Рішення про те, якою мовою (або якою платформою) буде вестися розробка не прийнято;
• До системи пред'являються вимоги мультимовного інтерфейсу (наприклад, російська/англійська)
• Для функціонування системи має бути створений окремий підрозділ або прийняті на роботу нові працівники;
• Для функціонування системи у Замовника мають відбутися зміни у методиках роботи та ці зміни мають бути конкретизовані та заплановані;
• Передбачається інтеграція з будь-яким обладнанням і до нього висуваються вимоги (наприклад, сертифікації, сумісності та ін.)
• Можливі інші ситуації, все залежить від конкретних цілей проекту.

Розділ 5. Склад та зміст робіт зі створення системи

Розділ 6. Порядок контролю та приймання системи

Загальні вимоги до приймання робіт по стадіях (перелік підприємств і організацій, що беруть участь, місце та строки проведення), порядок погодження та затвердження приймальної документації; Настійно рекомендую з відповідальністю поставитися до порядку здачі робіт та перевірки системи. Саме для цього і потрібні вимоги, що тестуються. Але навіть наявність тестованих вимог може виявитися недостатньо при здачі системи, якщо чітко не прописаний порядок приймання-передачі робіт. Наприклад, поширена пастка: система зроблена, цілком працездатна, але Замовник з якихось причин не готовий у ній працювати. Причини ці можуть бути будь-які: колись змінилися цілі, хтось звільнився і т.п. І каже: «Оскільки ми ще не працюємо в новій системі, то й не можемо бути впевнені, що вона працює». Так що вчіться правильно виділяти етапи робіт, способи перевірки результатів цих етапів. Причому Замовнику такі способи мають бути зрозумілі спочатку. Якщо вони зафіксовані на рівні Технічного завдання, то завжди можна за потреби до них звернутись та підвести роботи з передачі.

Розділ 7. Вимоги до складу та змісту робіт з підготовки об'єкта автоматизації до введення системи в дію

Можуть бути будь-які інші правила введення інформації, прийняті в компанії (або плановані). Наприклад, інформація про договір раніше заносили текстовим рядком у довільному вигляді, а тепер потрібно номер окремо, дату окремо тощо. Таких умов може бути дуже багато. Частина з них може бути сприйнята з опором персоналу, тому краще всі такі випадки прописати на рівні вимог до порядку введення даних Зміни, які необхідно здійснити в об'єкті автоматизації

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

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

Можливо, щось спрощувалося, а тепер потрібно враховувати детальніше, відповідно хтось має збирати інформацію за певними правилами.

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

Терміни та порядок комплектування штатів та навчання персоналу Про це ми вже говорили раніше. Можливо, система розробляється під нову структуру чи вид діяльності, якого раніше не було. Якщо не буде відповідного персоналу, та ще й навченого, то система не запрацює, як грамотно її не будуй.

Розділ 8. Вимоги до документування

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

Можливо, Замовник має прийняті корпоративні стандарти, отже треба до них звертатися.

Ігнорування вимог до документації дуже часто призводить до найнесподіваніших наслідків на проектах. Наприклад, все зроблено та все працює. Користувачі також вміють працювати. Про документацію взагалі не домовлялися та не розмовляли. І раптом при здачі робіт хтось із топ-менеджерів Замовника, який навіть не брав участі у проекті, але бере участь у прийманні робіт, Вас запитує: «А де посібники користувача?» І починає Вас переконувати, що про наявність посібників користувача домовлятися було і не потрібно, це «само собою» нібито мається на увазі. І все не хоче приймати у Вас роботу. За чий рахунок розроблятимете керівництва? На цей гачок потрапляло вже багато команд.

Розділ 9. Джерела розробки

Тому краще послатися просто на звіт про обстеження, вимоги ключових осіб.

І так ми розглянули всі розділи, які можуть бути включені в Технічне завдання. «Можуть», а не «Зобов'язані» саме тому, що будь-який документ має розроблятись для досягнення результату. Тому якщо для Вас очевидно, що якийсь окремий розділ до результату не наблизить, значить він Вам не потрібен і не треба витрачати на нього час.

Але без головного: функціональних вимог жодне грамотно Технічне завдання не обходиться. Хочу зауважити, що на практиці такі Технічні завдання зустрічаються, та ще й як! Є діячі, які зможуть розвести води по всіх розділах, опишуть загальні вимоги загальними словами, і документ виходить дуже важкий, і слів у ньому розумних багато, і навіть Замовнику може сподобається (тобто він його затвердить). Але працювати по ньому може не вийти, тобто. практичної користі від нього мало. У більшості випадків такі документи народжуються, коли треба отримати багато грошей саме під технічне завдання, а зробити його треба швидко і не занурюючись у деталі. А особливо якщо відомо, що далі справа не піде, або її робитимуть зовсім інші люди. Загалом просто для освоєння бюджету, особливо державного.

У другій статті говоритимемо лише про розділ 4 «Вимоги до системи», саме ми будемо формулювати вимоги з міркувань зрозумілості, конкретності і тестируемости.

Чому вимоги мають бути зрозумілими, конкретними та тестованими.

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

Чи тестована ця вимога? Начебто проста річ, але як її перевіряти, якщо немає конкретики?

Як можна було б це переформулювати: «Сума витрат, зазначена в документі, повинна розподілитися на всі товари, зазначені в цьому документі, пропорційно вартості цих товарів». Вийшло і зрозуміло, і конкретно. Як перевірити теж не важко.

Ергономічність Програма повинна мати зручний інтерфейс Признатися, під цим формулюванням довелося одного разу підписатися самому - проблем потім було не порахувати. Звичайно ж, подібних формулювань не повинно бути. Тут немає конкретики, ні можливість перевірити цю вимогу. Хоча, безперечно, зрозуміле (суб'єктивно). Тут переформулювати не можна, треба докладно розписувати кожен елемент «зручності», якщо Замовник на цьому наполягає. Наприклад:

• Рядки в документ повинні додаватися як натисканням на кнопку «Додати», так і при натисканні на клавіші «insert», а також вводі користувачем частини найменування;
• При перегляді списку товарів має бути можливість пошуку за найменуванням, штрихкодом та артикулом;
• та ін.

Розмежування прав доступуДоступ до даних із прибутку має бути доступний лише фінансовому директоруЗрозуміло? Майже. Правда, прибуток буває різний, треба уточнити. Конкретно? Звичайно, ні. Як це бачиться у реалізації? Якщо мова йде про валовий прибуток, то необхідно обмежувати доступ до даних про вартість закупівлі, т.к. в іншому випадку валовий прибуток обчислити не складе труднощів, оскільки дані про вартість реалізації відомі широкому колу осіб. До того, що стосується прав доступу, треба ставитися дуже акуратно. А якщо у менеджерів з продажу мотивація побудована на валовий прибуток, то ці вимоги ще й суперечать одна одній, т.к. менеджери ніколи не зможуть перевірити це. Якщо вже включати таку вимогу, потрібно вказувати конкретні звіти та об'єкти системи, в яких вказувати, яка частина даних повинна бути доступна окремим категоріям осіб. І розглядати кожен такий випадок індивідуально. Продуктивність Звіт з продажу повинен формуватися за 1 хвилину. І навіть є конкретне обмеження часу: 1 хвилина. Але не відомо, яка деталізація при цьому передбачається: по кожному товару, групам товарів, клієнтам чи якось ще? Можна сформулювати приблизно так: «Звіт з продажу в розрізі клієнтів з деталізацією до кожної товарної позиції повинен виводитися не більш ніж за 1 хвилину за умови, що кількість товарів у вибірці не перевищує 5000 рядків».

Сподіваюся, ідея зрозуміла. Якщо будуть конкретні питання, пишіть спробую допомогти.

Щоб у Технічне завданнябуло більше конкретики, є чимало рекомендацій. Навіть є список слів, які вживати в Технічному завданні не рекомендується. Цікаво про це пише К.Вігерс у своїй книзі «Розробка вимог до програмного забезпечення». Наведу найцікавіші та найпростіші, на мій погляд, рекомендації:

• Не слід використовувати слова, що мають безліч синонімів. Якщо це необхідно, краще дати чітке визначення терміну в розділі «Терміни та визначення» до Технічного завдання.
• Слід намагатися не використовувати довгі пропозиції;
• Якщо якась вимога Вам здається занадто загальною, її необхідно деталізувати до дрібніших, але конкретних вимог;
• Використовуйте більше схем, графіків, таблиць, малюнків – так сприймається інформація набагато легше;
• Слід уникати таких слів: "ефективний", "адекватний", "простий", "зрозумілий", "швидкий", "гнучкий", "покращений", "оптимальний", "прозорий", "стійкий", "достатній", " дружній», «легкий» та ін. Перелік можна продовжувати, але мені здається ідея зрозуміла (спробуйте його продовжити самостійно).

Все, що написано вище, це інформація важлива, але не сама. Як Ви пам'ятаєте, на початку статті це назвав терміном «камуфляж», т.к. найголовніше, що складе щонайменше 90% часу та складності роботи над документом – це виявлення та формулювання вимог. А інформацію про вимоги треба ще зуміти зібрати, структурувати та сформулювати. У цьому, до речі, багато спільного між обстеженням діяльності підприємств із подальшим описом бізнес-процесів. Але є й важливі відмінності. Одна з таких ключових відмінностей – наявність етапу побудови прототипу майбутньої системи, або як його ще називають «моделі інформаційної системи».

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

Види робіт під час збору вимог до системи обліку та інформації для опису бізнес-процесів. Частина 2

У цій частині ми будемо говорити про те, як організувати етап робіт зі збирання вимог, з чого він має складатися та якими інструментами можна користуватися. Повторюся, що ці роботи з погляду етапів дуже схожі на обстеження підприємства з метою опису бізнес-процесів.

Як зазвичай відбувається у житті:

Як це відбувається у більшості проектів
	Як це відбувається
	Зрозуміло, що є привід для радості, особливо, якщо проект великий, нічого поганого в цьому немає! Головне, не радіти надто довго, відтягуючи початок фактичних робіт, з цієї хвилини час йтиме інакше.
	Зазвичай цей процес обмежується кількома зустрічами з керівництвом, потім із керівниками підрозділів. Зафіксувавши деякі «позиви» із боку Замовника, вони фіксуються як загальних формулювань. Іноді до цього додають наявну документацію (хтось колись намагався вже поводити обстеження, документи з існуючих регламентів, форми звітів, що використовуються). Ну, трохи налаштувати і все буде працювати». На питання, чи треба обговорювати, як усе має працювати (або як виконується конкретний процес) з кінцевими користувачами, відповідь зазвичай негативна. Висловлюється думка, що керівник усе знає про своїх підлеглих. А дарма ... За цим ховається безліч пасток і перешкод, і здавання робіт може перетворитися на марафон смужкою з перешкодами. Як відомо, марафон прийнято бігати рівною дорогою, а біг з перешкодами можливий лише на коротких дистанціях (можна і не добігти).
Документування результатів роботи	Після цього починається документування результатів залежно від цілей робіт: Якщо потрібно розробити Технічне завдання, консультант починає розсовувати отриману інформацію за заготовленим шаблоном документа, щоб і виглядало красиво, і основні вимоги були зафіксовані (ті, що озвучені від керівництва, а то можуть не затвердити). Розуміючи, що на практиці таке Технічне завдання особливо не використовується і доводиться все з'ясовувати "по ходу справи", головною метою Технічного завдання він ставить мінімальний час узгодження та затвердження. І, якщо вийде, інформація для зразкової оцінки вартості майбутніх робіт (до речі, теж важливо). Якщо потрібно описати бізнес-процеси. Як не дивно, але часто всі попередні дії виглядають аналогічно, як і у випадку розробки Технічного завдання. Різниця лише в оформленні документації. Тут можливі варіанти: консультанти описують процес довільними словами або використовують будь-які правила опису бізнес-процесів (нотації). У першому випадку такий документ виходить дивовижно схожим на Технічне завдання. Буває навіть таке, що якщо замінити титульний лист, жодної різниці не побачиш. В останньому випадку часто наголошують не на відповідності дійсності, а на «правильності опису», тобто. формальне дотримання правил описи. На жаль, обидва варіанти є не найкращою практикою, т.к. є скоріше формальністю, а користі приносять небагато.

Чому склалася така практика, як описано вище? Зізнаюся, я не знаю. У кого не спитай, ніхто не знає. При цьому ситуація змінюється не дуже швидко, хоча на цю тему постійно дискутують, обмінюються досвідом, пишуть книги… Мені здається, що одна з причин – низька якість відповідної освіти. Може ще позначається і те що, що багато фахівців приходить взагалі їх іншого бізнесу, і осягають все практично, тобто. їх досвід формується у тому середовищі, куди вони потрапили. Про ставлення ВНЗ та відсутність їхнього прагнення бути ближчим до реальності, теж факт відомий, але мене іноді дивує їхня позиція. Наприклад, у мене був випадок, коли дипломниця, талановитий фахівець, хотіла писати дипломну роботу на платформі 1С (хорошу галузеву розробку), але на кафедрі їй сказали, що незалежно від теми, на оцінку «відмінно» розраховувати не можна буде, т.к. 1С несерйозна система. Тут справа не в серйозності та об'єктивності такої думки, а в тому, що примітивне завдання класичною мовою програмування відразу вважалося гідним оцінки «відмінно».

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

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

Хочу особливо наголосити, що до останнього кроку на схемі (там, де питання) загальний принцип збору інформації про діяльність компанії виглядає однаково, незалежно від того, що планується робити надалі, описувати бізнес-процеси чи впроваджувати автоматизовану систему. Так, сама послідовність кроків однакова, але інструменти, які застосовуються на деяких з них, можуть відрізнятися. Ми зараз обов'язково розглянемо, коли вивчатимемо методики та інструменти окремих етапів. Докладно це робитимемо в окремих статтях, а зараз розглянемо тільки найголовніше. Подальші кроки відрізнятимуться і визначатиметься тим, що потрібно від проекту: описати бізнес-процеси чи впроваджувати систему обліку.

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

Як це може відбуватися за більш грамотної організації робіт
	Як це відбувається
Рішення прийнято, проекту бути!	Тут нічого не змінюється щодо першого варіанта, емоції ніхто не скасовував
Провели нараду з керівниками, зібрали деяку інформацію про їхнє бачення результату.	Цей крок також залишається, і він має велике значення. Але основне призначення першої зустрічі (або кількох зустрічей) із керівниками та власниками це знайомство. Знайомство насамперед із людьми та компанією. Сформульовані цілі та побажання на таких спільних зустрічах можуть бути різними, у тому числі фантастичними. Всі вони будуть, звичайно ж, вислухані, але не факт, що їх буде реалізовано. При глибшому зануренні в бізнес компанії будуть з'являтися інші цілі, так і відкидатися попередні. Я це до того, що з попередніх зустрічей не можна сформулювати чіткі цілі, все це потребуватиме ретельного опрацювання. Навіть просте здавалося б вимога може бути нереалізованим чи дуже трудомістким.
Формування робочої групи від Замовника та Виконавця, розподіл ролей	Необхідно визначитися, хто працюватиме над проектом як з боку Замовника, так і Виконавця. Незважаючи на простоту даного етапу, він має дуже велику роль. Якщо не зафіксувати чітко, хто за що відповідає, під час реалізації робіт Ви ризикуєте зіткнутися з плутаниною. Якщо зі свого боку Ви завжди можете конкретизувати ролі у своїй команді, то у Замовника з цим можуть виникнути проблеми. На що слід звернути увагу: до складу робочої групи Замовника обов'язково мають увійти ті люди, які надалі хоч якось впливатимуть на прийняття результату. Якщо припустити ситуацію, що під час здачі робіт підключаться співробітники Замовника, які не брали участь у роботах щодо формування цілей та виявлення вимог, то проблеми гарантовані. Можлива навіть така абсурдна ситуація, що все, виявляється, зроблено не так, як вимагалося. У моїй практиці я стикався з такою ситуацією не раз. може брати участь у прийманні-здачі робіт. А найкраще прописати таке в договірних умовах (У договорі або Статуті проекту). Пам'ятаю, був такий випадок: в одному великому проекті засновник вирішив підключитися до процесу (не знаю чому, нудно бачити стало) і відвідав одну з робочих зустрічей, де обговорювалося питання формування рахунків клієнтам. Він із подивом для себе дізнався, що рахунок клієнту виставляє менеджер із продажу. У його поданні рахунок має виставляти бухгалтер і ніяк інакше. Але насправді бухгалтер взагалі не уявляв, про що йдеться, а менеджер не міг уявити, як так працювати, якщо за кожним рахунком бігати до бухгалтера. В результаті втратили купу часу, але нічого не змінилося, рахунок, як і раніше, виставляв менеджер. А засновник залишився на своїй думці, але більше в процес не втручався. На цьому етапі доцільно розробити Статут проекту, у якому зафіксувати ролі учасників, порядок комунікацій, регламент і склад звітності, і навіть решта, що слід прописати у Статуті. Розробка Статуту проекту це тема знову ж таки окрема.
Навчання проектної команди методикам та інструментам роботи, узгодження правил роботи, видів та складу документації	По-перше, необхідно роз'яснити проектній команді все, що прописано у Статуті, як це застосовуватиметься на практиці. По-друге, проектну команду Замовника необхідно навчити тим методам роботи, які Ви збираєтеся використати на всіх наступних етапах. Має сенс обговорити формати документів, які будуть використовуватись, розглянути зразки. Якщо будуть застосовуватися будь-які правила опису моделей або бізнес-процесів, то треба обговорити і ці правила, щоб вони були зрозумілими.
Анкетування	Етап анкетування дозволяє порівняно швидким способом отримати достовірний зріз інформації про компанію. Якість такої інформації визначатиметься трьома факторами: Насамперед тим, як Ви навчили проектну групу Замовника. Вони повинні чітко розуміти, як відбувається процес анкетування та вміти донести інформацію до всіх учасників. Сама форма анкет. Анкети мають бути зрозумілими. Бажано, щоб була інструкція із заповнення анкет. Ще краще, якщо буде приклад наповнення. Склад учасників. Необхідно правильно вибрати склад учасників. Якщо обмежитись лише керівниками, зібрати достовірну інформацію не вдасться. Я рекомендую включати до складу анкетування всіх, хто буде в майбутньому користувачем кінцевих результатів. Наприклад, якщо йдеться про впровадження автоматизованої системи, то варто включити всіх, хто буде користувачем. Бувають випадки, коли з 10 співробітників однієї посади знайдеться один, який виконує якусь особливу функцію, про яку ніхто з 9-ти більше не знає (наприклад, готує особливий звіт для керівництва). Якщо йдеться про подальший перерозподіл обов'язків або розробку посадових інструкцій, слід зробити аналогічно. Звертаю увагу, що методика анкетування для подальшого впровадження автоматизованої системи або опис бізнес-процесів у правильному випадку відрізняється. Звичайно, структура анкет може бути і однакова, але це не найкращий варіант. Коли ми описуємо бізнес-процеси, то анкети зазвичай мають загальніший характер, т.к. невідомо точно, із чим доведеться зіткнутися. Якщо ж йдеться про впровадження конкретної автоматизованої системи, то краще мати анкети, що враховують особливості цієї системи. При такому підході можна відразу виявити всі вузькі місця системи, які не підходять для цього підприємства. Як правило, методики впровадження готових систем передбачають наявність таких анкет. Такі анкети можуть розроблятися або за окремими областями обліку (наприклад, облік замовлень, продажу, ціноутворення) або для конкретних посад (фінансового директора, наприклад). Склад питань приблизно однаковий.
Опитування	Опитуванням називається проведення усної співбесіди з фахівцями з метою з'ясувати особливості окремих процесів. Необхідно організувати опитування так, щоб воно не виглядало як просто «зустрілися-поговорили», а організовано. Для цього потрібно підготувати так званий план опитування. До нього можна включити ті частини анкети, які викликають питання, суперечать відомостям інших анкет чи інформація представлена ​​поверхнево. Відповіді треба конспектувати в обов'язковому порядку. Ідеально, якщо Ви домовитеся про аудіозапис. На цьому етапі слід простежити за повнотою наданої інформації про документообіг (як форм первинних документів, так і різних звітів)
Виділення ключових бізнес-процесів або областей автоматизації	Після анкетування та опитування можна обґрунтовано вважати, що інформації достатньо, щоб робити висновки щодо виділення ключових бізнес-процесів. Насправді, вже можна виділити не лише ключові бізнес-процеси, а й практично всі (якщо склад учасників було обрано правильно). Питання виділення бізнес-процесів це тема дуже окрема і не проста. Навчитися тут складно і виробляється переважно досвідом. З виділених бізнес-процесів слід скласти список (класифікатор). Потім можна буде приймати рішення, які з них слід досліджувати глибше, які ні, а також виділяти пріоритети.
Формулювання ключових вимог до системи, цілей, критеріїв успішності проекту, процесів для детального вивчення	До цього етапу має бути зібрана вся первинна інформація про діяльність компанії, складено перелік бізнес-процесів. Тепер саме час повернутися до цілей, конкретизувати їх, за необхідності обговорити з першими особами компанії. При формулюванні цілей слід врахувати конкретні показники, при досягненні яких вважатимемо проект успішним. Якщо йдеться про впровадження автоматизованої системи, окремим переліком можна виділити вимоги до системи від ключових користувачів. Я це роблю у вигляді окремої таблиці, де всі вимоги згруповані за підсистемами, для кожної вимоги вказується автор вимоги, формулювання та пріоритет. Цю інформацію можна буде використовувати для складання плану розгортання системи (послідовності впровадження окремих підсистем), а також для пропозицій щодо подальшого розвитку системи (якщо окремі підсистеми в поточному проекті не планується впроваджувати). Якщо необхідно описати бізнес-процеси, приймаються рішення про процеси, які необхідно досліджувати більш детально.

От і дісталися питання «Що далі?». Далі розглядатимемо завдання опису бізнес-процесів та розробки Технічного завдання окремо. Я невипадково розглядаю ці завдання паралельно. Між ними справді багато спільного, що я хочу продемонструвати. Спочатку розглянемо послідовність робіт під час опису бізнес-процесів.

	Що і як робити
Виділяємо бізнес-процес	Із загального переліку бізнес-процесів, отриманого на попередніх етапах, виділяємо один (за пріоритетом) для детального опрацювання. З рештою потім чинимо аналогічно.
Детальне вивчення бізнес-процесу	Виділений бізнес-процес піддаємо детальному вивченню: аналізуємо отримані первинні документи, звіти та їх структуру, що використовуються в процесі програми, різні файли (наприклад, Excel), розмовляємо з кінцевими виконавцями. Збираємо різні ідеї про те, як можна покращити процес. Дуже корисно, якщо вдасться поспостерігати за процесом саме в тих умовах, в яких він виконується (не багато хто любить, коли за ними спостерігає, але що робити)
Графічний та/або текстовий опис бізнес-процесу (первинний)	Отриману докладну інформацію починаємо описувати. Перш ніж описувати процес, треба визначитися, чи вимагатиме він графічного опису. Якщо процес простий і зрозумілий, функцій у ньому мало, і, графічне уявлення поліпшить його розуміння чи сприйняття, то треба витрачати цей час. І тут досить описати їх у текстовому вигляді у табличній формі. Якщо ж процес складний, з різними логічними умовами, краще навести його графічну схему. Діаграми завжди сприймаються легше. Якщо Ви вирішили описати процес у графічному вигляді, це зовсім не означає, що не треба наводити його текстовий опис. Тобто. текстовий опис процесу має бути у будь-якому випадку, причому виконаний за однаковою схемою. Зручно це робити у вигляді таблиці, де вказати: виконавців кожного кроку, яку інформацію вони отримують на вході, опис кожного кроку, яку інформацію формують на виході. Нижче подивимося на прикладі, як це може виглядати.
Погодження з виконавцями та власником бізнес-процесу	Кращий спосіб зрозуміти, наскільки вдало ви вибрали стиль викладу інформації, це показати результат користувачам (виконавцям) процесу. На найголовніше в такій демонстрації це розуміння того, наскільки правильно Ви зрозуміли, як процес виконується. від виконавців цілком адекватного зворотного зв'язку. А якщо їм стане цікаво, то просуватися все почне набагато швидше. Виявлені уточнення та невідповідності необхідно відобразити в описі (актуалізувати), за необхідності операцію повторити.
Виділення показників бізнес-процесу	Після того, як вироблено правильне розуміння, як виконується бізнес-процес, треба подумати над показниками, якими можна виміряти якість чи швидкість виконання процесу. Це не просто, але потрібно. Показник може бути вимірюваним, тобто. виражений у числовому вираженні і має існувати простий спосіб цю величину отримати. Якщо показник, що вимірюється, виділити неможливо, є ризик того, що бізнес-процес виділено невдало. Крім того, не буде можливості зрозуміти (адже виміряти не можна), приведуть зміни процесу до його поліпшення чи ні.
Остаточне документування бізнес-процесу	Після того, як ми переконалися у правильному розумінні, як процес виконується (або має виконуватися), можна включати його до документації.
	Далі можливі варіанти: аналізовані процеси аналізуватимуться і оптимізуватимуться, розроблятимуться посадові інструкції, прийматимуться рішення про необхідність автоматизації окремих процесів тощо. Це може бути і окремий проект: опис бізнес-процесів.

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

	Що і як робити
Виділяємо бізнес-вимогу/область автоматизації	Виділення як вимог цілої області автоматизації (наприклад, «Складські запаси») практично використовується, проте, це найефективніший спосіб деталізації вимог. Область автоматизації є групою вимог, і розглядати їх краще за кожне окремо. Наприклад, «Облік надходження матеріалу на склад»
Детальне вивчення бізнес-вимоги	Під детальним вивченням бізнес-вимоги розуміється те, як це хоче бачити і використовуватиме кінцевий користувач (зрозуміло, відповідно до цілей проекту). У технологіях розробки програмного забезпечення часто називають «варіант використання». Таким чином, детальне вивчення бізнес-вимоги зводиться до опрацювання варіантів використання. Приклад такого варіанту наведено у додатку 2 до статті. У найпростіших випадках варіанти використання зовсім не обов'язково малювати у вигляді графічних схем, можна обмежитися і текстовим формулюванням. Наприклад, вимога «Під час введення номенклатури ціна має розрахуватися як ціна закупівлі +20%» малювати не має сенсу. У вигляді діаграми є сенс представляти вимоги, об'єднані в область автоматизації, як показано в прикладі в додатку 2.
Моделювання вимог в інформаційній системі	Ось воно! Як Ви, напевно, пам'ятаєте, я вже звертав увагу на цей найважливіший елемент у методиці розробки Технічних завдань. «Побудуй модель – отримаєш результат!» А що треба моделювати? Моделювати треба варіанти використання, отримані на попередньому етапі. Що має бути на виході моделювання? Повинна вийти демонстраційна програма, в яку внесені дані користувача, причому бажано звичні його (користувача) слуху, з урахуванням галузевої специфіки, актуальних проблем. І не просто так внесено, а має бути зрозуміло, звідки ці дані взялися, як розрахувалися. У цьому місці у читача мають виникнути питання: А що, якщо планується розробка нової системи і моделювати просто нема в чому? Що якщо для демонстрації не вистачає функціональності, і систему треба доопрацьовувати? Звичайно, Ви маєте зіткнутися з такою ситуацією, і це нормально. Що робити? Якщо система зовсім нова (як то кажуть «з нуля»), то моделювати доведеться здебільшого на папері, тут Вам діаграми варіантів використання дуже допоможуть. Частково має сенс накидати деякі екранні форми, які передбачається розробити (у тому середовищі, у якій вестиметься розробка), т.к. малювати їх у якомусь редакторі буде довше і ця робота нудна. Якщо впроваджується готова система, і в ній не вистачає функціональності, то нічого страшного немає, дані вносяться руками, а користувачеві так і розповідається, що після необхідних доробок має розрахуватися так і так (і він це бачить). Доцільно супроводити таку модель текстовим описом, нехай навіть стислим, щоб користувач міг самостійно спробувати попрацювати з моделлю у вільний час. У цьому описі можна формулювати вимоги до доработок.
Демонстрація інформаційної моделі робочої групи	Отриману модель показуємо Замовнику і розповідаємо, як усе має працювати. Демонстрацію моделі краще проводити підсистемами, тобто. за групами вимог. У випадку, якщо з'ясується, що у клієнта пропонована схема не працюватиме, треба подумати про інші варіанти використання, внести зміни в модель і показати ще раз. Тільки якщо є впевненість, що запланована модель у даного клієнта «житиме», можна вважати модель вдалою.
Розробка тестів	Для чого потрібні тести? Те, як ми змогли реалізувати вимоги, потрібно перевіряти. Відповідно, на всі ключові ділянки, складні алгоритми та ін тести бажано зробити. У тому числі, ці тести можуть бути використані при здачі робіт. Зовсім необов'язково робити тести на кожну функцію системи, скрізь має бути здоровий глузд. Якщо йдеться про готову систему, то робити тест на «введення нового елемента до довідника клієнтів» буде виглядати безглуздо і марною тратою сил і часу. А якщо це зовсім нова система, таке цілком можливо. Навіщо робити тести, якщо ще немає системи? По-перше, розробнику буде зрозуміліше, чого від нього хочуть досягти. По-друге, ми полегшуємо життя тестувальнику (адже хтось тестуватиме результат розробки). Взагалі, тестування це окрема дисципліна, вельми не проста з безліччю методик. Насправді, зазвичай, однаково використовуються найпростіші методи тестування.
Документування вимог у вигляді Технічного завдання	Зібрана інформація на попередніх етапах буде саме тим, що й має увійти в основу документа «Технічне завдання» у розділі з вимогами. Отже залишається все це грамотно оформити.
Подальші дії (або їх відсутність), залежно від цілей проекту	Далі може початися процес розробки, пошук партнерів для проекту, тендер тощо, все залежить від ситуації.

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

Підготовка до лабораторної роботи

Ознайомитись з лекційним матеріалом на тему «Моделі ЖЦ ПЗ. Етапи ЖЦ відповідно до ГОСТ 19.102-77. Постановка задачі» навчальної дисципліни «Розробка та стандартизація ПС та ІТ».

1. Вивчити відповідні розділи у виданнях.

Теоретична частина. Розробка технічного завдання

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

Порядок розробки технічного завдання

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

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

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

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

1.1. Технічне завдання оформлюють відповідно до ГОСТ 19.106-78 на аркушах формату А4 та A3 за ГОСТ 2.301-68, як правило, без заповнення полів аркуша. Номери аркушів (сторінок) проставляють у верхній частині аркуша над текстом.

1.2. Лист затвердження та титульний лист оформляють відповідно до ГОСТ 19.104-78. Інформаційну частину (анотацію та зміст), лист реєстрації змін допускається до документа не включати.

1.3. Для внесення змін та доповнень до технічних задні на наступних стадіях розробки програми або програмного виробу випускають додаток до нього. Узгодження та затвердження доповнення до технічного завдання проводять у тому самому порядку, який встановлено для технічного завдання.

1.4. Технічне завдання має містити такі розділи:

Вступ;

Найменування та сфера застосування;

Підстава для розробки;

призначення розробки;

Технічні вимоги до програми чи програмного виробу;

Техніко-економічні показники;

Стадії та етапи розробки;

Порядок контролю та приймання;

Програми.

Залежно від особливостей програми чи програмного виробу допускається уточнювати зміст розділів, вводити нові розділи чи об'єднувати окремі. При необхідності допускається до технічного завдання включати додатки.

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

2.2.У розділі «Найменування та сфера застосування» вказують найменування, коротку характеристику області застосування програми або програмного виробу та об'єкта, в якому використовують програму або програмний виріб.

2.3.У розділі "Підстава для розробки" повинні бути вказані:

Документ (документи), виходячи з яких ведеться розробка. Таким документом може бути план, наказ, договір тощо;

Організація, яка затвердила цей документ, та дата його затвердження;

Найменування та (або) умовне позначення теми розробки.

2.4. У розділі "Призначення розробки" має бути зазначено функціональне та експлуатаційне призначення програми або програмного виробу.

2.5. Розділ «Технічні вимоги до програми чи програмного виробу» повинен містити такі підрозділи:

Вимоги до функціональних характеристик;

Вимоги до надійності;

Умови експлуатації;

Вимоги до складу та параметрів технічних засобів;

Вимоги до інформаційної та програмної сумісності;

Вимоги до маркування та упаковки;

Вимоги до транспортування та зберігання;

Спеціальні вимоги

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

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

2.5.3.У підрозділі «Умови експлуатації» повинні бути зазначені умови експлуатації (температура навколишнього повітря, відносна вологість тощо для обраних типів носіїв даних), за яких повинні забезпечуватися задані характеристики, а також вид обслуговування, необхідна кількість та кваліфікація персоналу.

2.5.4.У підрозділі «Вимоги до складу та параметрів технічних засобів» вказують необхідний склад технічних засобів із зазначенням їх технічних характеристик.

2.5.5.У підрозділі «Вимоги до інформаційної та програмної сумісності повинні бути зазначені вимоги до інформаційних структур на вході та виході та методів рішення, вихідних кодів, мов програмування. За потреби повинен забезпечуватися захист інформації та програм.

2.5.6.У підрозділі «Вимоги до маркування та пакування» у загальному випадку вказують вимоги до маркування програмного виробу, варіанти та способи пакування.

2.5.7.У підрозділі «Вимоги до транспортування та зберігання» повинні бути зазначені для програмного виробу умови транспортування, місця зберігання, умови зберігання, умови складування, термін зберігання в різних умовах.

2.5.8. У розділі «Техніко-економічні показники» мають бути зазначені: орієнтовна економічна ефективність, передбачувана річна потреба, економічні переваги розробки порівняно з найкращими вітчизняними та зарубіжними зразками чи аналогами.

2.6.У розділі «Стадії та етапи розробки» встановлюють необхідні стадії розробки, етапи та зміст робіт (перелік програмних документів, які мають бути розроблені, узгоджені та затверджені), а також як правило, терміни розробки та визначають виконавців.

2.7.У розділі «Порядок контролю та приймання» мають бути зазначені види випробувань та загальні вимоги до приймання роботи.

2.8.У додатках до технічного завдання при необхідності наводять:

Перелік науково-дослідних та інших робіт, що обґрунтовують розробку;

Схеми алгоритмів, таблиці, описи, обґрунтування, розрахунки та інші документи, які можуть бути використані для розробки;

Інші джерела розробки.

У випадках, якщо будь-які вимоги, передбачені технічним завданням, замовник не висуває, слід у відповідному місці вказати «Вимоги не пред'являються».

Приклади розробки технічного завдання наведено у додатках Б та В.

Контрольні питання

1. Дайте поняття моделі життєвого циклу ПЗ.

2. Наведіть етапи розробки програмного забезпечення.

3. Що включає постановка завдання і передпроектні дослідження?

4. Перерахуйте функціональні та експлуатаційні вимоги до програмного продукту.

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

6. Назвіть основні розділи технічного завдання.

Додаток А

Варіанти завдань

Лабораторні роботи № 1-5 виконуються для одного й того ж варіанту.

1. Розробити програмний модуль «Облік успішності студентів». Програмний модуль призначений для оперативного обліку успішності студентів у сесію деканом, заступниками декана та співробітниками деканату. Відомості про успішність студентів повинні зберігатися протягом усього терміну їх навчання та використовуватися при складанні довідок про прослухані курси та додатки до диплому.

2. Розробити програмний модуль «Особисті справи студентів». Програмний модуль призначений для отримання відомостей про студентів співробітниками деканату, профкому та відділу кадрів. Дані повинні зберігатися протягом усього терміну навчання студентів та використовуватися при складанні довідок та звітів.

3. Розробити програмний модуль «Рішення комбінаторно-оптимізаційних завдань». Модуль повинен містити алгоритми пошуку циклу мінімальної довжини (завдання комівояжера), пошуку найкоротшого шляху та пошуку мінімального сполучного дерева.

4. Розробити програмний модуль "Обробка матриці". Модуль повинен містити алгоритми пошуку сум та добутку елементів матриці по рядках та стовпцях, а також обчислення середніх, мінімальних та максимальних величин у матриці.

5. Розробити програму Windows «Органайзер». Програма призначена для запису, зберігання та пошуку адрес та телефонів фізичних осіб та організацій, а також розкладу, зустрічей та ін. Програма призначена для будь-яких користувачів комп'ютера.

6. Розробити програму Windows «Калькулятор». Програма призначена для будь-яких користувачів і повинна містити всі арифметичні операції (з дотриманням пріоритетів) та бажано (але не обов'язково) кілька математичних функцій.

7. Розробити програмний модуль «Кафедра», що містить відомості про співробітників кафедри (ПІБ, посада, науковий ступінь, дисципліни, навантаження, громадська робота, сумісництво та ін.). Модуль призначений для використання співробітниками відділу кадрів та деканату.

8. Розробити програмний модуль «Лабораторія», що містить відомості про співробітників лабораторії (ПІБ, стать, вік, сімейний стан, наявність дітей, посада, науковий ступінь). Модуль призначений для використання співробітниками профкому та відділу кадрів.

9. Розробити програмний модуль "Хімчистка". При записі на обслуговування заповнюється заявка, в якій зазначаються ПІБ власника, опис виробу, вид послуги, дата прийому замовлення та вартість послуги. Після виконання робіт роздруковується квитанція.

10. Розробити програмний модуль «Облік порушень правил дорожнього руху». Для кожної машини (і її власника) в основі зберігається перелік порушень. Для кожного порушення фіксується дата, час, вид порушення та розмір штрафу. При сплаті всіх штрафів машина видаляється з бази.

11. Розробити програмний модуль "Картотека автомагазину", призначений для використання працівниками агентства. У основі містяться відомості про автомобілі (марка, об'єм двигуна, дата випуску та ін.). При надходженні заявки на купівлю проводиться пошук відповідного варіанта. Якщо такого немає, клієнт заноситься в базу клієнта і повідомляється, коли варіант з'являється.

12. Розробити програмний модуль "Картотека абонентів АТС". Картотека містить відомості про телефони та їх власників. Фіксує заборгованості з оплати (абонентської та погодинної). Вважається, що погодинну оплату місцевих телефонних розмов уже запроваджено.

13. Розробити програмний модуль «Автокаса», який містить відомості про наявність вільних місць на автобусні маршрути. У базі повинні міститися відомості про номер рейсу, маршрут, водія, тип автобуса, дату та час відправлення, а також вартість квитків. При надходженні заявки на квитки програма здійснює пошук відповідного рейсу.

14. Розробити програмний модуль «Книгарня», що містить відомості про книги (автор, назва, видавництво, рік видання, ціна). Покупець оформляє заявку потрібні йому книжки, якщо таких немає, він заноситься у основу і сповіщається, коли необхідні книжки надходять у магазин.

15. Розробити програмний модуль "Автостоянка". У програмі міститься інформація про марку автомобіля, його власника, дату і час в'їзду, вартість стоянки, знижки, заборгованість з оплати та ін.

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

Що таке технічне завдання

Загальне визначення цього терміна виглядає так: технічне завдання - це спеціальний документ, розроблений замовником і затверджений виконавцем, у якому викладено вимоги, параметри та основні експлуатаційні характеристики проекту, об'єкта чи системи.

Крім іншого, до складу цього документа може входити список вимог щодо тестування (стосовно розробки програмного забезпечення).

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

Технічне завдання - це документ, який розробляється професіоналом, який добре знається на специфіці конкретного виду робіт. Від того, наскільки докладно буде описано очікування замовника, залежить успіх всього заходу. Іншими словами, технічне завдання – це інструкція для працівників, яка дозволяє зіставити кінцевий результат із запланованим.

Особливості техзавдання

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

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

Призначення технічного завдання

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

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

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

Склад ТЗ: вимоги до функціональності

Усі вимоги, зазначені у технічному завданні, можна класифікувати за видами та властивостями.

Зразком вимог різних видів стає більшість ГОСТів. Вони регулюють процес складання ТЗ на будівництво великих об'єктів та інших відповідальних робіт. Вони зазвичай перераховують такі требования:

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

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

Найчастіше вимоги щодо функціональності виступають ядром, навколо якого розробляється кожне технічне завдання. Система інших технічних умов та інструкцій стає своєрідним «камуфляжем», надітим на ці вимоги. При невдалому формулюванні основного завдання навіть найкращий «камуфляж» не врятує становище, і проект буде провалений.

Характеристика вимог

На відміну від численних видів вимог, властивостей їх характеристики набагато менше:

• Зрозумілість.
• Конкретність.
• Тестованість.

Остання властивість не може бути відокремлена від перших двох, оскільки зрозумілі та конкретні вимоги можуть бути втілені та протестовані. Однак якщо немає ніякого способу перевірити результат, то можна стверджувати, що вимоги не мають одну з двох перших властивостей.

Технічне завдання – це не технічний проект

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

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

Прихильники іншого методу наполягають на тому, що проект технічного завдання має бути максимально простим та зрозумілим. Цей документ може містити галузеву термінологію, зрозумілу замовнику, але вказівки технічних аспектів, пов'язаних із реалізацією проекту, допускати не варто. У сфері розробки програмного забезпечення адаптацією вимог замовника до пунктів техзавдання займається бізнес-аналітик, але не програміст (звісно, ​​якщо він не виконує обов'язки і того, й іншого).

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

Структура технічного завдання

Щоб полегшити складання та виконання технічного завдання, його розробляють за певною системою.

Як правило, спочатку, у вступній частині, викладають мету та призначення проекту. Далі слідує перерахування розділів, вимог та їх розшифрування. Щоб зрозуміти, як виглядає ТЗ для автоматизованої системи, можна розглянути структуру, яку рекомендує ГОСТ 34.602-89:

• Вказівка ​​загальних відомостей.
• Опис призначення та мети, задля досягнення якої планується створення чи розвиток системи.
• Характеристики об'єктів, що підлягають автоматизації.
• Виклад вимог до системи.
• Склад та зміст заходів та робіт, що застосовуються для створення системи.
• Опис того, як повинен проходити контроль створення та процедура приймання готової системи.
• Перелік вимог до робіт, що будуть проводитись з об'єктом автоматизації для його підготовки.
• порядок ведення документації.
• Вказівка ​​джерел розробки.

Таке технічне завдання (зразок якого містить розгорнутий опис усіх пунктів) охоплює більшість аспектів проекту, але при необхідності може бути доповнено пунктами, що уточнюють.

Навіщо складати ТЗ для ремонту кімнати

Процес капітального ремонту внутрішніх приміщень - справа не така проста, як здається на перший погляд. Це не тільки зміна шпалер і фарбування батарей, йдеться про виправлення порушеної геометрії, усунення архітектурних недоліків, внесення корективів у планування, оснащення та вдосконалення кімнат.

Тому технічне завдання на ремонт стає одним з найважливіших етапів, оскільки дозволяє:

• Наперед продумати зміст майбутніх робіт.
• Скласти детальний кошторис, а також виявити можливості для економії.
• Досягти граничної ясності щодо бажаного результату всім учасників процесу (замовника, підрядника, виконавців).

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

Які пункти включає техзавдання для ремонту кімнати

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

1. Назва та призначення кімнати. Це необхідно, оскільки специфіка приміщення вимагає дотримання певних правил при оформленні (вітальня, спальня, кабінет).

2. Характеристика статі: обсяг робіт, які потрібно виконати на цій ділянці. Тут можна докладно вказати, що саме необхідно виконати майстрам:

• Демонтувати покриття, плінтуса і чернові підлоги (тип і квадратура), що прийшло в непридатність.
• Нанести вирівнюючу, роздільну стяжку та термоізоляцію (площа та висота матеріалів).
• При необхідності встановити систему «тепла підлога» (тип та висота конструкції).
• Нанести стяжку над нагрівальними кабелями (близько 30-50 мм).
• Підготувати поверхню до укладання плитки, ламінату, ковроліну чи іншого матеріалу (характер розташування елементів).
• Встановити плінтус (вказують кількість погонних метрів, а також всі внутрішні та зовнішні куточки).

3. Роботи зі стелею:

• Очистити від побілки або шпалер (площа в квадратних метрах).
• Вирівняти шпаклівкою (площа).
• Нанести штукатурку (квадратура та середня товщина).
• Якщо потрібно встановити стелю із гіпсокартону, потрібно вказати його тип, квадратуру та висоту. Для багаторівневих моделей потрібно додати креслення.
• Зашпаклювати і пофарбувати стелю (площа, колір).

4. Що потрібно зробити зі стінами:

• Очистити від попереднього шару шпалер чи іншого покриття (площа).
• Відбити штукатурку.
• Заштукатурити стіни (з армуванням або без нього). Тут потрібно вказати не тільки лише загальну квадратуру стінок, та й товщину шару. Довжину укосів, що використовуються, приводять у погонних метрах.
• Зашпаклювати стіни.
• Вказати скільки в кімнаті зовнішніх кутів, щоб можна було підрахувати довжину перфорованого куточка.

5. Параметри вікна:

• Вказати дані про виробника.
• Привести інформацію про тип профілю, фурнітуру, склопакет, підвіконня. Описати, чи буде й москітна сітка, додати креслення з розмірами. Для якіснішого виконання робіт краще створити окреме технічне завдання для замовлення вікна.

6. Характеристики дверей:

• Описати параметри дверей, виробника, матеріали (зокрема і фурнітуру), тип коробки, наличників і петель.
• Окремо прописати необхідність зміни розмірів дверного отвору (збільшення, зменшення, переміщення) з розмірами та переліком робіт.

7. Роботи з електричними мережами:

• Перелік робіт (установка, заміна,
• Необхідність прокладання телефонних або інтернет-кабелів.
• Докласти схему.

8. Заходи щодо монтажу опалювальних систем та кондиціонерів:

• Встановлення, перенесення, заміна або фарбування опалювального приладу.
• Демонтаж традиційного приладу та встановлення системи «теплі підлоги».
• Позначити на схемі місце розташування кондиціонера та траси. Уточнити, як буде проведено його живлення від електромережі.

Чи потрібне обстеження приміщення перед складанням технічного завдання на ремонт

Усі фахівці сходяться на думці, що обстеження кімнати є обов'язковим етапом при складанні ТЗ для її ремонту. При цьому процедура повинна проводитися не лише до розробки техзавдання, а й у процесі складання.

Головним завданням цього заходу стає отримання інформації про стан приміщення та точнішого опису майбутніх ремонтних робіт.

При обстеженні кімнати звертають увагу на основні параметри та виконують такі дії:

• Перевіряють правильність геометрії.
• Вивчають горизонтальність стелі (чи є нахили, перепади). Це допомагає визначити тип обробки та дає поняття про майбутню висоту кімнати.
• Перевіряють вертикальність стін та правильність кутів. Якщо знадобиться їх вирівнювати, майстрам слід знати, які матеріали застосувати і скільки їх потрібно закупити.
• Перевірка горизонтальності статі. Найчастіше підлоги доводиться повністю змінювати (особливо якщо передбачено монтаж опалювальної системи під ними), тому слід заздалегідь визначити обсяг робіт.

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

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

Ця інформація дозволяє оцінити рівень трудових та фінансових витрат. Техзавдання має містити креслення майбутніх робіт.

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

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

Один із найпоширеніших способів зниження витрат та скорочення бюджету проекту – самостійне написання ТЗ (технічного завдання) .

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

У технічному завданні необхідно чітко описати вимоги до об'єкта робіт, встановити технічні параметри, призначення об'єкта, підготувати склад потрібної проектної документації, визначити терміни та порядок виконання робіт.

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

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

Технічне завдання це

Технічне завдання - це основний документ всього проекту та взаємовідносин замовника з виконавцем, який дозволяє чітко визначити порядок робіт, обов'язки сторін та строки виконання проекту.

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

Види ТЗ (технічного завдання)

Технічне завдання - перший крок на шляху реалізації будь-якого проекту. Можна виділити безліч видів технічного завдання виконання робіт:
- Технічне завдання на розробку сайту;
- Технічне завдання на розробку логотипу;
- Технічне завдання на розробку програми;
- Технічне завдання на розробку фірмового стилю;
- Технічне завдання на розробку дизайну;
- Технічне завдання на розробку назви компанії;
- Технічне завдання на просування сайту і т.д.

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

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

Структура технічного завдання

Структура технічного завдання (форма технічного завдання) виглядає так:

1. Цілі проекту
У ТЗ необхідно вказати яких цілей хоче досягти компанія, використовуючи результати завершеного проекту. Такими цілями, наприклад, може бути: випуск нового товару, проведення ребрендингу компанії чи торгової марки, проведення рекламної кампанії тощо.
2. Опис компанії замовника
- сфера діяльності та масштаби компанії, її місія та позиції на ринку;
- Опис портфеля брендів компанії – з якими торговими марками працює фірма;
- список основних компаній-конкурентів;
- Перелік основних конкурентних переваг компанії та УТП (унікальна торгова пропозиція).
3. Опис ситуації та останніх тенденцій ринку, для якого розробляється бренд
- ціновий сегмент продукту чи послуг компанії;
- портрет споживача (вік, стать, географічні дані, соціальний рівень цільової аудиторії);
- тактичні та стратегічні маркетингові цілі компанії (на період від 1 до 3 років);
- модель поведінки споживача та опис ситуацій, при яких споживач здійснює покупку;
- опис основних характеристик існуючого бренду, його концепції позиціонування, слогана, маркетингових комунікацій, необхідне у разі проведення ребрендингу.
4. Референси
Список прикладів аналогічних робіт, які подобаються замовнику в контексті даного проекту.
5. Вимоги
У цьому розділі необхідно прописати всі технічні та функціональні вимоги до проекту. А також вимоги та побажання замовника до графіки, тексту, кольорової гами, до стилю, шрифтів,

Пам'ятаєте закон Мерфі? Якщо вас можуть зрозуміти неправильно, вас неодмінно зрозуміють неправильно. Це справедливо не лише у спілкуванні між людьми, а й у створенні сайтів. Клієнт хотів другий "Фейсбук", а отримав форум юних собаківників. Розробник не вгадав хотівку замовника - змарнував час.

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

Стаття буде корисною:

• Усім, хто має відношення до створення сайтів: розробникам, дизайнерам, верстальникам.
• Менеджерам проектiв.
• Керівникам діджітал-студій.
• Підприємцям, які планують замовити розробку сайту.

Щоб матеріал вийшов слушний, я зібрав коментарі кількох розробників, дизайнерів, проект-менеджерів та власників діджитал-студій. Найцінніші додав до кінця статті. Поїхали розбиратися.

Що таке техзавдання і навіщо воно потрібне

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

Головна мета технічного завдання: переконатися, що клієнт та виконавець правильно зрозуміли один одного.

Користь від технічного завдання багато. Для кожної сторони вона своя.

Користь для клієнта:

• Зрозуміти, за що він платить гроші і яким буде сайт.Можна одразу побачити структуру, зрозуміти, що і як працюватиме. Прикинути, чи все влаштовує. Якщо ні – без проблем змінити ще до початку розробки.
• Побачити компетентність виконавця.Якщо техзавдання зрозуміле та чітке – довіра до розробника підвищується. Якщо там написана каша – можливо, варто бігти і не озиратися.
• Застрахуватися від несумлінності виконавця.Коли сайт готовий, його можна перевірити на технічне завдання. Чи є невідповідності? Розробник зобов'язаний їх виправити. Якщо ви співпрацюєте офіційно і укладали договір, можна навіть примусити через суд.
• Спростити заміну виконавців.Якщо клієнт і розробник посварилися та розбіглися, створення сайту може сильно затягнутися. Коли є докладне техзавдання, його можна передати новій команді – вона втягнеться у роботу в рази швидше.
• Дізнатись вартість розробки складного продукту.Оцінити точні терміни та вартість розробки складного веб-сервісу відразу не можна. Спочатку потрібно зрозуміти, як працюватиме сервіс, і які у ньому будуть функції. Для цього і потрібно підготувати техзавдання.

Користь для виконавця:

• Зрозуміти, що хоче замовник.Клієнту ставлять десятки запитань, показують приклади, пропонують рішення. Потім записують у єдиний документ і узгоджують. Якщо все окей – ура, ви зрозуміли правильно.
• Застрахуватися від раптових бажань клієнта.Іноді трапляються замовники, які хочуть поміняти завдання на півдорозі. Якщо ви погодили та підписали ТЗ, вам не страшно подібне. У разі чого навіть суд буде на вашому боці.
• Показати свою компетентність.Класно підготовлене техзавдання покаже клієнту експертність розробників. Якщо компанія сумнівалася, чи довіряти вам розробку сайту, сумніви з великою ймовірністю розвіються.
• Заробити гроші.Деякі студії та розробники пропонують складання ТЗ як окрему послугу.

• Полегшити та прискорити процес розробки. У хорошому ТЗ вказано структуру сайту, необхідні функції та елементи на кожній сторінці. Коли всі вимоги вже перед очима – залишається тільки задизайнить та написати код.

Тепер давайте розберемося, як скласти хороше техзавдання, яке виконує всі ці функції.

Техзавдання складає виконавець

Взагалі техзавдання може скласти будь-хто. "Потрібен сайт-візитка для стоматологічної клініки" - це вже техзавдання. Але чи виконуватиме він свої функції? Навряд чи.

Хороше ТЗ завжди складає виконавець: проект-менеджер чи розробник. Очевидно, що веб-розробник розуміє створення сайтів більше, ніж власник кафе або стоматологічної клініки. Тому описувати проект доведеться йому.

Це не означає, що клієнт зникає і з'являється наприкінці, щоб написати: «Збс, схвалюю». Він також має брати участь у процесі:

Звісно, ​​замовник може накидати свій варіант ТЗ. Можливо, це прискорить процес створення кінцевого техзавдання. А можливо, вийде сміття, яке нишком викинуть на смітник.

Пишіть однозначно та точно

Ця порада випливає з головної мети техзавдання - «Переконатися, що клієнт і виконавець правильно зрозуміли одне одного».

У технічному завданні не повинно бути якісних прикметників: гарний, надійний, сучасний. Їх не можна однозначно зрозуміти. У кожного свої поняття краси та сучасності.

Подивіться. Адже хтось вважав цей дизайн красивим і дозволив використовувати на своєму сайті:

Те саме - з невиразними формулюваннями, які нічого самі по собі не означають:

• Сайт має сподобатися замовнику.А якщо він матиме поганий настрій?
• Сайт має бути зручним.Що це означає? Зручним для чого?
• Сайт має витримувати великі навантаження. 10 тисяч відвідувачів? Чи 10 мільйонів?
• Якісний експертний контент.Ну ви зрозуміли.

Перевірте, чи немає тексту неоднозначностей. Якщо є – перепишіть. Ваші формулювання мають бути чіткими та точними:

• Сайт повинен завантажуватись швидко → Будь-яка сторінка сайту повинна мати більше 80 балів у Google PageSpeed ​​Insights.
• Великі навантаження → 50 тисяч відвідувачів одночасно.
• На головній сторінці відображається список статей → На головній сторінці відображається список останніх 6 опублікованих статей.
• Мінімалістичний зручний інтерфейс передплати → Поле «Залишіть e-mail» та кнопка «Підписатися» → * намальований ескіз *.

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

Вкажіть загальну інформацію

Усі члени команди повинні правильно розуміти, чим займається компанія та хто її цільова аудиторія. Щоб ніхто не заплутався, це краще прописати на початку техзавдання.

А ще варто вказати мету сайту та описати його функціонал у двох словах – щоб не отримати інтернет-магазин замість блогу.

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

Перше правило техзавдання - воно має бути зрозумілим для всіх, для кого призначено. Якщо ви збираєтеся використати терміни, які може не зрозуміти ваша клієнтка – власниця магазину дитячих іграшок – обов'язково поясніть їх. Зрозумілою мовою, а не копіпастою з «Вікіпедії».

Опишіть інструменти та вимоги до хостингу

Уявіть, що ви 2 місяці робили крутий сайт. Кожен етап узгоджували з клієнтом – він у захваті. І ось настав час здавати роботу. Ви показуєте адмінку, а клієнт кричить: Це що таке? Модекс? Я думав, ви зробите на "Вордпресі"!"

Щоб таких проблем не було, опишіть інструменти, движки та бібліотеки. Заодно вкажіть вимоги до хостингу. Мало, ви зробите на PHP – а у клієнта сервер на .NET.

Перерахуйте вимоги до роботи сайту

Сайт повинен працювати у всіх браузерах актуальних версій та на всіх типах пристроїв. Так, це очевидно для будь-якого розробника та будь-якого замовника. Але краще написати, щоб захистити клієнта від несумлінно виконаної роботи.

Сюди ж напишіть вимоги до швидкості завантаження сайту, стійкості до навантажень, захисту від атак хакерів і подібних речей.

Вкажіть структуру сайту

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

Поспілкуйтеся із замовником, з'ясуйте, що йому треба. Зберіть розробників, сеошників, маркетологів, головного редактора - і вирішіть, які сторінки потрібні на сайті. Подумайте, як вони пов'язані між собою, з якою на яку можна перейти.

Можна показати структуру списком, можна намалювати блок-схему. Як вам зручніше.

Це один із найважливіших етапів роботи на сайті. Структура – ​​це фундамент. Якщо вона невдала – сайт вийде кривою.

Поясніть, що буде на кожній сторінці

Клієнт повинен зрозуміти, навіщо потрібна кожна сторінка та які елементи на ній будуть. Є два способи це показати.

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

Перелік елементів- лінива альтернатива прототипу. Просто напишіть, які блоки мають бути на сторінці і що вони роблять.

Розпишіть сценарії використання сайту

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

• Дія користувача.
• Дія сайту у відповідь.
• Результат.

Звісно, ​​якщо ви робите стандартну візитку чи лендинг, писати сценарії не потрібно. Але якщо на сайті будуть якісь інтерактивні сервіси дуже бажано.

Докладніше про сценарії використання читайте у «Вікіпедії».

Визначте, хто відповідає за контент

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

Вигадати об'єктивні критерії оцінки якості текстів досить складно. Краще не пишіть нічого, ніж «Якісний, цікавий контент, що продає, корисний для цільової аудиторії». Це сміття, воно нікому не потрібне.

Вказати, що весь контент має бути унікальним – це корисно. Ще один захист клієнта від несумлінних виконавців.

Опишіть дизайн (якщо зможете)

Як і у випадку з текстом, об'єктивні критерії оцінки дизайну придумати складно. Якщо ви з клієнтом домовилися про колірну гамму – напишіть її. Якщо у нього є брендбук, у якому прописані шрифти, - вкажіть їх.

Писати про гарний та сучасний дизайн не треба. Це нічого не означає, не має сили і взагалі фу.

Замість висновку: структура техзавдання

Для різних завдань структура ТЗ буде своєю. Безглуздо робити однакові технічні завдання для нової соціальної мережі та лендингу з оптового продажу моркви. Але загалом вам потрібні такі розділи:

• Інформація про компанію та цільову аудиторію, цілі та завдання сайту.
• Глосарій термінів, які можуть бути незрозумілими для клієнта.
• Технічні вимоги до верстки та роботи сайту.
• Опис використовуваних технологій та список вимог до хостингу.
• Детальна структура сайту
• Прототипи сторінок чи описи елементів, які мають бути.
• Сценарії використання нестандартного інтерфейсу (опційно).
• Список контенту, який розробник.
• Вимоги до дизайну (опціонально).

• Правила упорядкування Software Requirements Specification. SRS – наступний ступінь еволюції техзавдання. Потрібна для великих та складних проектів.
• Стандарти та шаблони ТЗ на розробку ПЗ. Опис різних ГОСТів та методологій створення технічних завдань.

Це кінець тієї частини, що писав я. Але є й інша – коментарі спеціалістів, які допомагали робити гайд. Почитайте це теж цікаво.

Коментарі розробників

Я поспілкувався з кількома розробниками, щоб дізнатися, як вони складають техзавдання. Передаю мікрофон ім.

Насамперед ТЗ потрібно клієнту - щоб він зрозумів, яким буде його сайт, і на що йдуть гроші. Якщо щось зроблено не так – він може послатися на ТЗ та попросити переробити.

ТЗ складає менеджер проекту після спілкування з клієнтом та обговорення завдання з дизайнером.

Великі замовники часто просять докладні ТЗ, в яких описана кожна кнопка. Невеликі компанії, навпаки, не люблять скрупульозні документи на 100 сторінок. Довго читати і легко упустити щось важливе. Найчастіше ми робимо лаконічні ТЗ на 10–15 сторінок.

Ми вказуємо:

• Інформацію про компанію та мету сайту.
• Вимоги до дизайну, кольорова гама.
• Використовувані технології та CMS.
• Хто займається контентом – ми чи клієнт.
• Структуру сайту до кожної сторінки.
• Описи кожної сторінки. Ми не робимо прототипи, але вказуємо, які елементи мають бути на сторінці та як вони повинні працювати.

Останні 2 розділи – найважливіші. Саме вони забезпечують розуміння, якими буде сайт і як він працюватиме.

Дуже важливий момент – не можна просто віддати техзавдання розробникам та сподіватися, що вони все зроблять добре. ТЗ – це список вимог до сайту, він не може замінити спілкування. Важливо переконатись, що кожен член команди розуміє загальну мету, а не просто виконує завдання на потоці. Якщо щось незрозуміло – треба пояснити, обговорити, дати докладні коментарі.