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

Технічне завдання (ТЗ, техзавдання) - вихідний документ для розробки і випробування вироби. [1]


1. Поняття ТЗ

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

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

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

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

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

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


2. Місце ТЗ в структурі проектування

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

Стадії проектування регламентовані стандартами. [2] [3] Це наступна послідовність:

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

Як правило, ТЗ складають на основі аналізу результатів попередніх досліджень, розрахунків і моделювання.


2.1. Окремі технічні завдання

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

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

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

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

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


3. Необхідність ТЗ

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

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

Составление ТЗ - сложная и ответственная задача: многие данные ещё не известны, но то, как задание будет поставлено, способно облегчить или затруднить последующее проектирование (образно говоря, "как корабль назовешь, так он и поплывет").

Специалисты считают, что грамотное ТЗ - это более 50 % успеха в решении задачи, а время, затраченное на подготовку ТЗ, - одно из лучших вложений, которые фирма может сделать в период проектирования. Недаром составление ТЗ поручается ведущим специалистам - главным конструкторам, руководителям проектов и работ и т. п.

Академік А. Н. Крылов рассказывал. На одной фабрике установили новую машину, но никак не могли её запустить. Тогда обратились за помощью к профессору университета. Приехав на фабрику, он долго ходил вокруг машины, внимательно что-то высматривая и к чему-то прислушиваясь. Затем, взяв молоток, ударил по её корпусу. И машина заработала. За свою помощь профессор запросил у правления фабрики 100 рублей (дело было в начале 20 века). Но правление фабрики посчитало, что за один удар молотком это слишком большая плата. На что профессор ответил, что сам удар стоит один рубль, а вот то, куда ударить - 99 рублей. [4]
Замечено, что если стоимость исправления проектной ошибки, допущенной на этапе технического проектирования принять за 1, то стоимость её исправления возрастает приблизительно в 10, 100 и 1000 раз, если ошибка была допущена соответственно на этапах эскизного проектирования, технического предложения и ТЗ!

Как инструмент коммуникации в связке общения заказчик-исполнитель, ТЗ позволяет:

  • Обеим сторонам:
    • представить (вообразить) готовый продукт,
    • выполнить попунктную проверку готового продукта (приёмочное тестирование - проведение испытаний),
    • уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний).
  • Заказчику:
    • осознать, что именно ему нужно,
      • в том числе, опираясь на существующие на данный момент технические возможности и свои ресурсы,
    • требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ.
  • Исполнителю:
    • понять суть задачи, показать заказчику "технический облик" будущего изделия, программного продукта или автоматизированной системы,
    • спланировать выполнение проекта и работать по намеченному плану,
    • отказаться от выполнения работ, не указанных в ТЗ.

4. Содержание ТЗ

4.1. Регламентированное ТЗ

Несмотря на свою важность, содержание ТЗ мало регламентировано нормативными документами (ГОСТ, ОСТ).

  • ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению [5] (кратко изложено содержание ТЗ);
  • ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы [6] (достаточно подробно изложены состав и содержание ТЗ);
  • ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления [1] (приведен порядок построения ТЗ).

В части выполнения научно-исследовательских работ ТЗ регламентируется следующими документами:

  • ОСТ 95 18-2001. Порядок проведения научно-исследовательских и опытно-конструкторских работ. Основные положения.
  • Приложение №3 к Правилам приемки НИОКР, утвержденным Приказом Роспрома16.09.2004 №95. Техническое задание на научно-исследовательскую работу [7] (приложен образец технического задания на разработку в рамках ГОЗ)

4.1.1. Разделы ТЗ по ГОСТ 34.602-89 (пример)

Согласно ГОСТ 34.602-89 ТЗ должно содержать следующие разделы (приведены в сокращенном виде):

  1. Загальні відомості
    1. полное наименование системы и ее условное обозначение;
      1. Приклад:

Полное наименование системы: Автоматизированная система "Управление" Условное обозначение: АСУ

    1. шифр темы или шифр (номер) договора;
      1. Приклад:

Договор № ХХХ от ДД.ММ.ГГГГ

    1. наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;
      1. Приклад:

ЗАКАЗЧИК Наименование заказчика: ООО "МИР" Юридический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Почтовый адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Фактический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Телефон: +7 903 456 67 67 Факс: +7 903 453 34 54 Адрес электронной почты: Pro@mir.com ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО "БанкСтрой", г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423 {{[[Шаблон:|]]}} 400000000234

ИСПОЛНИТЕЛЬ Наименование исполнителя: ООО "ДЯТЕЛ" Юридический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Почтовый адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Фактический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Телефон: +7 495 345 63 63 Факс: +7 495 433 34 54 Адрес электронной почты: Gena@gizni.net ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО "БанкСтрой", г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423400000000234

    1. перечень документов, на основании которых создается система, кем и когда утверждены эти документы;
    2. плановые сроки начала и окончания работы по созданию системы;
    3. сведения об источниках и порядке финансирования работ;
    4. порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.
  1. Назначение и цели создания системы
  2. Характеристика объекта автоматизации
    1. краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;
    2. сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.
  3. Требования к системе
    1. Требования к системе в целом;
    2. Требования к функциям (задачам), выполняемым системой;
    3. Требования к видам обеспечения.
  4. Состав и содержание работ по созданию системы
    1. перечень документов по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ;
    2. вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);
    3. программа работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);
    4. перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организации-исполнителей (при необходимости).
  5. Порядок контроля и приемки системы
    1. виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);
    2. общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;
    3. статус приемочной комиссии (государственная, межведомственная, ведомственная).
  6. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
    1. приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;
    2. изменения, которые необходимо осуществить в объекте автоматизации;
    3. создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;
    4. создание необходимых для функционирования системы подразделений и служб;
    5. сроки и порядок комплектования штатов и обучения персонала.
  7. Требования к документированию
    1. согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и научно-технической документации отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;
    2. требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
    3. при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.
  8. Источники разработки: документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

4.2. Вид и состав требований ТЗ

Часто содержание ТЗ устанавливается внутренними документами предприятия либо соглашением заказчика и исполнителя проектных работ.

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

  • Цели в функциональном виде. Изделие является лишь материальным носителем определенных функций, выполнение которых и позволяет достигать заданные цели (удовлетворять потребности). Но одну и ту же функцию могут выполнять разные устройства. Поэтому функциональное, а не предметное указание цели расширяет область возможных решений, что необходимо для поиска оптимального решения. Также, функция - более четкий термин для описания сути назначения устройства. Уточнение целей и назначение соответствующих им функций - наиболее важная часть работы по составлению ТЗ;
  • Выполнение функций, реализующих заданные потребности, всегда увязывается с удовлетворением определенных требований (см. перечень типовых требований к техническим устройствам), которые делают изделия более привлекательными, учитывают и конкретизируют особенности производства и эксплуатации и т. п. Для удобства требования по виду подразделяют на три группы:
    • условия, характеризуются конкретными значениями данных (формально их можно представить в виде равенств). Например, масса изделия должна составлять 10 кг, применять сталь 40Х, место эксплуатации - тундра. Важную часть условий формирует оценка доступных ресурсов;
    • ограничения, задают допустимую область данных (формально их можно представить в виде односторонних или двусторонних неравенств). Например, вес изделия не должен превышать 10 кг, применять углеродистые стали;
    • показатели качества (которые преобразуются в критерии оптимизации), задают только перечень характеристик и направление поиска предпочтительного значения (максимальное или минимальное значение, например, вес изделия должен быть минимальным, а удобство обслуживания - максимальным). Конкретное значение показателя становится известным только в конце этапа или всего цикла проектных работ и служит мерой предпочтения в процессе поиска оптимального варианта (основой выбора окончательного варианта).

Как и процесс проектирования, работа с требованиями также подлежит управлению. Эти процедуры хорошо отработаны, например, в управлении требованиями к программному обеспечению.

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

Стоит отметить, что приведённые в условии данные - это номинальные параметры, но было бы более правильно приводить нормированные значения этих параметров, задаваемые своими предельно-допустимыми значениями (например, масса изделия 9,810,1 кг). То есть то, что считают условиями, на практике являются ограничениями в виде двусторонних неравенств. Ширина диапазона является следствием величины допуска на этот параметр.

При формировании системы требований обязателен анализ следующих источников:

  • Доступность ресурсов, находящихся в распоряжении заказчика и разработчика: финансовые, производственные, людские, временные. Все ресурсы взаимосвязаны, например, за счет увеличения финансирования проекта можно добиться сокращения периода разработки. Следствием степени доступности является введение ограничений на методы и точность решения проектной задачи, что, в свою очередь, влияет на вид выбираемой модели. Так, при ограниченности времени ведут оценочные расчеты упрощенными методами или используют готовое программное обеспечение, стандартные методики, типовое оборудование, стандартные и покупные детали и узлы и т. д. В то же время модель, метод и точность решения должны обеспечивать исполнение требований ТЗ, даже если они и высоки.
  • Учет требований надзорных и лицензионных органов при проектировании, например, технологических комплексов (производств). В соответствии с законами Российской Федерации любое производство требует получения региональной лицензии на эксплуатацию. Помимо этого многие производства лицензируются надзорными органами и подлежат с их стороны контролю. Наиболее часто контролирующими являются региональные органы Ростехнадзора, Росстандарта, Минрегион России (бывш. Госстрой), Роспотребнадзора, Росприроднадзора, ГПС, МВД России, Роструда.
  • Жизненная среда проектируемой системы. Она задает требования, характеризующие взаимное влияние спроектированной системы и окружающих её живых и неживых объектов и внешней среды. Основные указания на нее приводятся в технических требованиях в условиях потребления будущей продукции. Эти условия могут быть охарактеризованы достаточно обобщенно и нуждаться в конкретизации.

5. Составление списка требований ТЗ

Работа над ТЗ включает выполнение ряда этапов. А неопределенность, свойственная этой работе, вызывает прохождение их по несколько раз, итерационно, от более общей постановки задачи - к детальной её проработке (проектирование носит итерационный характер и то, что не учтено в начале, может быть учтено на последующих этапах).

Сначала приведем рассказ о том, как Эдисон ставил перед собой техническую задачу. [8]

Прежде, чем приступить к разработке электрического освещения в быту, Эдисон провел исследования, при каких условиях оно выдержит конкуренцию в цене, яркости и удобстве с газовым освещением (рожком). Он до тонкостей изучил газовую промышленность, разработал план центральной электростанции и схему линий электропередач к домам и фабрикам. Затем подсчитал стоимость меди и других материалов, которые потребуются для изготовления ламп и добычи электроэнергии с помощью динамо-машины, движимой паром. Анализ данных определил не только размеры лампы, но и её конкурентоспособную цену, равнявшуюся 40 центам. И лишь когда Эдисон убедился, что сможет решить проблему электрического освещения, он принялся работать над лампой накаливания с угольной нитью, помещенной в стеклянный шар, из которого откачан воздух. В поисках материала нити он опробовал около 6 000 разновидностей растительного волокна.

5.1. Анализ задания заказчика

Исходное задание выдаётся заказчиком и оформляется в виде технических требований. Перевести эти требования на язык предметной области, сформулировать задачу максимально полно и грамотно, обосновать необходимость её решения, осмыслить и уточнить исходные данные - первый этап работы. Исполнитель выполняет его в тесном контакте с заказчиком.

Следует выявлять и стараться избегать решения следующих задач:

  • завдання, не відповідають суспільним потребам - кримінальні, аморальні, негуманні. Їх рішення - справа совісті розробника;
  • технічні псевдозадачі, з помилково висунутими цілями. Це - завдання, які вже мають рішення, або не мають об'єктивних передумов для свого рішення (передчасні завдання, але це потребує обгрунтування, щоб відмова в рішенні не був наслідком психологічної інерції або інших суб'єктивних причин);
  • химерні завдання. Це - завдання з помилково поставленою метою, досягнення якої суперечить законам фізики (наприклад, створення пристрої з ККД більше 100%, пристрої миттєвої дії і т. п.), або абстрактно висунуті завдання, принципово не мають рішення (типу філософського каменю).

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

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

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

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

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

Якщо прообраз існує, то рекомендують:

  • або забути про його існування і, відштовхуючись від вихідної потреби, запропонувати можливі варіанти з наступним вибором кращого;
  • або удосконалити прообраз, скориставшись ДКР;
  • або локалізувати потреба. Зазвичай незадовільна робота пов'язана з недосконалістю тільки деяких підсистем. З цією метою прообраз декомпозіруется за функціональною ознакою, а протиріччя представляють у вигляді елементарних проблем. Співвідносячи елементарні проблеми з певними підсистемами прообразу, виявляють "недосконалі" підсистеми. Таким чином, від вирішення загальної та складної задачі переходять до більш простої приватної завданню. Але ступінь поліпшення властивостей може виявитися невисокою, можуть виникнути проблеми з стикуванні вдосконалених підсистем з колишніми.

5.2. Конкретизація цілей проектування

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

У процесі пошуку найбільш повної і точної формулювання будується ланцюжок функцій ( дерево цілей) - від спочатку запропонованої до остаточно прийнятої. Цьому допомагає відповідь на питання "Навіщо це потрібно?" (І інші питання методу контрольних запитань). У більшості випадків за наведеною у вимогах метою варто необхідність виконання (послідовно або одночасно) декількох функцій. Ланцюжок функцій будується для кожної з них.

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


5.3. Обробка зібраної інформації

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

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

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

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

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

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

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

Проблемами оцінки якості допомогою кількісних показників займається наука "Кваліметрія".

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

Варто брати до уваги слова Лі Якокки : "... біда в тому, що ти вчився в Гарварді, де тобі вбили в голову, що не можна робити ніяких дій, поки не збереш всі факти. У тебе 95% інформації, а для того, щоб зібрати відсутні 5%, тобі знадобиться ще шість місяців. За цей час всі факти застаріють, тому що ринок розвивається набагато швидше. Найголовніше в житті - все робити вчасно.
... Головне завдання полягає в тому, щоб зібрати всі важливі факти і точки зору, які вам доступні. Але в якийсь момент треба починати діяти рішуче. По-перше, тому, що навіть найбільш правильне рішення виявляється невірним, якщо воно прийнято занадто пізно. По-друге, тому, що в більшості випадків не існує такої речі, як повна впевненість. Вам ніколи не вдасться зібрати всі 100% інформації. На жаль, життя не буде чекати, поки ви оціните всі можливі прорахунки і втрати. Іноді треба просто рушити вперед навмання і виправляти помилки по ходу руху ". [9]

6. Зведення вимог в єдиний документ і затвердження його замовником.