Разработка технических заданий и спецификаций программных продуктов.

[Dimka]

Вот здесь можно разделить два подхода к составлению ТЗ/спецификаций, а в более общем виде - разработке программ.

Конфликт:

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

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

Опуская экономические вопросы, сконцентрируемся на технических. Можно сказать, что Заказчик постоянно вносит некоторую долю хаоса в работу Исполнителя. Исполнитель занят недопущением хаоса в своей работе. Как Исполнитель, так и Заказчик испытывают взаимное давление.

Рассматривая Заказчика и Исполнителя как субъектов, мы опускаем массу деталей. В частности, реальная структура как Исполнителя, так и заказчика - это множества людей и множество интересов. Это живые динамичные системы. Тогда ТЗ/спецификации - это документы, фиксирующие "статус кво" Заказчика и Исполнителя на момент подписания. После подписания стороны связаны формальным соглашением, хотя реально "статус кво" не сохраняется. В результате могут рождаться неудачные или не совсем удачные проекты, не удовлетворяющие никого.

Alf предложил ввести посредника - Аудитора. Задачей Аудитора является поиск такого компромисса, который минимизирует взаимное давление Заказчика и Исполнителя друг на друга. Т.е. в идеале разделить деятельность так, чтобы и Заказчик, и Исполнитель жили в своих "мирах", в которых они не хотят слышать о проблемах друг друга.

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

Другой, противоположный подход предлагался в ЛЕСах. Естественно, сторонники первого подхода восприняли его не иначе как ересь.

Заказчик хочет решать какие-то свои проблемы, он выбрал в качестве средства некое ПО.

Исполнитель, понимая, что ПО - это не цель, а средство, изготавливает такое ПО, с которым Заказчик может "играться", сколько ему влезет. (Как это делать - бурно обсуждалось в ЛЕСах.)

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

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

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

[Hooter]

Наверное, не скажу ничего нового, но попытаюсь сформулировать свою точку зрения на создание макетов. Безусловно, макеты нужны не всегда.

Заказчик хочет увидеть в будущем продукте решение своих проблем. Думаю, что макеты необходимы для того, чтобы не просто уточнять требования Заказчика, а попытаться сформировать устойчивое представление Заказчика о решении проблем с помощью нашего продукта еще до начала реализации. Потому, что наличие макета дает Заказчику совершенно новый уровень восприятия будущего продукта, нежели схемы и требования. То есть, макет существует в проекте не вместо схем, а требования и схемы плюс макет. Иными словами, только "увидев и пощупав", Заказчик сможет реально оценить будущую функциональность продукта, как решения своих проблем. Грубо говоря, Заказчик перед подписанием ТЗ должен получить "рыбу" и попробовать её.

Здесь возможны несколько вариантов:
1. Создание макета(ов) после согласования ТЗ.
2. Создание макета(ов) до согласования ТЗ.

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

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

К сожалению, не удалось попробовать метод макетирования на практике в полном объеме, но мое мнение по поводу макетов звучит примерно так.

Добавлено через 12 минут и 29 секунд:
Да, я хотел добавить, что неизменность требований после согласования - это недостижимый идеал , но идеал к которому нужно стремиться. Существуют существенные различия между изменением требований по объективным причинам и изменениями требований просто потому, что Заказчик утром встал не с той ноги.

[Alf]

Макет - удовольствие дорогое, и весьма высок риск делать его за свой счет, если заказ не выгорит. Оправдан только для объемных и выгодных заказов, когда прибыль с избытком перекроет эти издержки. Мне такие всего несколько раз в жизни попадались (один из примеров - тот самый масляный заказ, где мы за свой счет оборудовали один из баков и на нем продемонстрировали систему в действии). Потребовалось около года экспериментов, пока Заказчик созрел.

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

Сам проект в этом случае вырождается в перманентный макет, поскольку результаты работы Исполнителя идут в корзину, не приближая завершение проекта. Макет макета - это уже перебор.

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

На самом деле он не так уж трудно достижим. Если по условиям договора Заказчик оплачивает все, что было сделано до корректировки ТЗ, независимо от того, остается ли сделанная часть в составе изделия или ее придется выбросить, то почему бы и не пойти на корректировку? Несколько ударов по карману заставят собраться и думать прежде, чем что-то требовать.

[Dimka]

Существуют существенные различия между изменением требований по объективным причинам и изменениями требований просто потому, что Заказчик утром встал не с той ноги.

Проблема не в том, почему его требования меняются, проблема в том, чем занимается программист. Если Исполнитель настаивает на каких-то требованиях - он "выступает в лице Заказчика" перед самим собой.

А уж хорошо это или плохо - вопрос отдельный. Я не даю оценок, я лишь обрисовываю положение.

Добавлено через 3 минуты и 34 секунды:

Макет макета - это уже перебор.

Напротив, "итерационная разработка" - версия 1.0, версия 2.0 и т.д. Всё зависит лишь от точки зрения: чем макет отличается от продукта. Если макет - это нечто изменчивое, а продукт - окончательное, то сейчас продуктов не выпускают - одни макеты (Beta, Release Candidate - знакомые слова, наверно)

[Hooter]

Макет - удовольствие дорогое, и весьма высок риск делать его за свой счет, если заказ не выгорит. Оправдан только для объемных и выгодных заказов, когда прибыль с избытком перекроет эти издержки.

Безусловно, каждый конкретный случай нужно рассматривать отдельно.


Добавлено через 3 минуты и 47 секунд:

Макет макета - это уже перебор.

Напротив, "итерационная разработка" - версия 1.0, версия 2.0 и т.д. Всё зависит лишь от точки зрения: чем макет отличается от продукта. Если макет - это нечто изменчивое, а продукт - окончательное, то сейчас продуктов не выпускают - одни макеты (Beta, Release Candidate - знакомые слова, наверно)

Макет - это "рыба". То есть нечто, имеющее форму, но не имеющее содержания.
Если подходить на уровне программного кода, то продолжать реализацию продукта на основе изготовленного макета - грубое нарушение, не приводящее ни к чему хорошему.

Имхо, бета-версии продуктов нельзя отностить к "рыбам". Это полноценный продукт находящийся на стадии тестирования.

[Alf]

Макет макета - это уже перебор.

Напротив, "итерационная разработка" - версия 1.0, версия 2.0 и т.д. Всё зависит лишь от точки зрения: чем макет отличается от продукта.

Я бы отличал по простому признаку: за продукт тплатят деньги, а на макет любуются, хлопают по плечу и говорят: "Маладец! А вот теперь давай-ка снесем тут пяток жилых кварталов и посмотрим, как на этом месте будет смотреться аэропорт...".

Заплати за версию 1.0 и получи апгрейд до 2.0 по льготной цене - вот это, в моем понимании, и есть версии
Все остальное - экзерсисы и этюды для повышения мастерства.

[Dimka]

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

Оправдан ли такой перенос физики в области сугубо идеальные и теоретические? Есть ли в программировании нечто настолько "твёрдое", что без макета проект грозит оказаться "физически" нереализуемым?

[Hooter]

За концепцией макета не стоит какая-то конкретная область деятельности человека. Всего лишь желание исполнителя, чтобы продукт соответствовал желаниям заказчика.

Например, если если Заказчик хочет некий программный комплекс с GUI, то логично создать макет этого GUI, для большей конкретизации желаний Заказчика.

[Alf]

Я бы, например, на небольших макетах пытался получить ответ на вопросы типа "успеет ли сервер баз данных фирмы NNN отрабатывать m таких-то транзакций в секунду, будучи установленным на компьютер такой-то конфигурации?". Закладываться на данные от производителя особо не следует, поскольку согласно этим данным все без исключения серверы умудряются одновременно быть лидерами производительности, сколько бы их ни присутствовало на рынке. Если предполагается, например, что регистрация входных данных будет узким местом системы, имеет смысл проверить это как можно раньше, зная, что с остальным принципиальных проблем не будет.

То есть я считаю целесообразным попытаться выделить наиболее проблематичную и в то же время компактную часть проекта и при помощи макета получить для себя ответ "да, я смогу сделать это".

Например, если если Заказчик хочет некий программный комплекс с GUI, то логично создать макет этого GUI, для большей конкретизации желаний Заказчика.

Тоже хороший вариант макета - сделать "пустышку", которая выглядит словно окончательное изделие, но реальных функций не выполняет, вместо нее пишет "выполняется функция такая-то". Особенно подходит, если интерфейса достаточно много, а Заказчик имеет склонность к капризам типа "а у вас нет такого же, но с перламутровыми пуговицами?". Много усилий не отнимет, а возиться потом с интерфейсом, подбирая варианты, уже не придется.

[PooH]

Alf, в первой части предыдущего поста, мне кажется ты говоришь, о "технических испытаниях".
а во второй о макете интерфейса. Но макет может быть не обязательно интерфейса, макеты модулей тоже могут быть, только, например, модуль будет эмулировать свою работу.

Кстати, программые макеты, по сути своей очень похожи на, например, архитектурные (ну, такие, домики из бумаги)

[Dimka]

Значит этап создания макета находится после разработки ТЗ и до составления спецификаций. Это исследование вариантов решения задачи, целью которого является определение а) принципиальной возможности варианта, б) лучшего из возможных вариантов. Делается в том случае, когда теоретически вопрос не решается, либо его теоретическое обоснование более трудоёмко, нежели проверка на лабораторном макете?

[Alf]

Alf, в первой части предыдущего поста, мне кажется ты говоришь, о "технических испытаниях".
а во второй о макете интерфейса. Но макет может быть не обязательно интерфейса, макеты модулей тоже могут быть, только, например, модуль будет эмулировать свою работу.

Испытывать имеет смысл готовое изделие или заготовку. Тут скорее речь об эксперименте, а не испытании.

Макетировать можно что угодно - внешний вид системы, взаимодействие между компонентами, поведение в критической ситуации... Самые главные для меня при этом две вещи:

1) макет должен быть простым, чтобы его можно было построить гораздо быстрее, чем такой же модуль реального проекта. Если по трудоемкости макет равен или даже превосходит прототип, его изготовление теряет смысл - я лучше сделаю систему и проверю все на ней.

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

Макетировать можно как систему в целом, так и отдельные ее части. Главное - это вопросы, на которые макет должен дать ответы. Если ответов нет, это просто безделушка.

[PooH]

Alf, полностью согласен с твоим последним постом.

[Hooter]

Значит этап создания макета находится после разработки ТЗ и до составления спецификаций. Это исследование вариантов решения задачи, целью которого является определение а) принципиальной возможности варианта, б) лучшего из возможных вариантов. Делается в том случае, когда теоретически вопрос не решается, либо его теоретическое обоснование более трудоёмко, нежели проверка на лабораторном макете?

"Значит" - откуда? Макет создается для уточнения требований. Например, "успеет ли сервер баз данных фирмы NNN отрабатывать m таких-то транзакций в секунду, будучи установленным на компьютер такой-то конфигурации?" - это тоже требование Заказчика. Если мы подписали ТЗ, а после этого наш макет показывает, что такое требование физически невыполнимо, какие должны быть наши действия? Позвоним заказчику и скажем "ой, извините"? С макетом GUI - такая же история.

Если же цель исследований - не уточнение требований, а поиск оптимального решения - это уже не макет, а экперимент. Думаю, что, в некоторых случаях, эксперимент - это внутренний процесс Исполнителя. Заказчик не обязан знать о нём.

[Alf]

По поводу подходящего времени для макетирования - считаю, что макет наиболее уместен до составления ТЗ или, в крайнем случае, во время его составления.

Например, в ТЗ оговорено, что моя система должна обрабатывать 1000 транзакций в секунду. Испытание на макете показывает, что приобретенная техника и системное программное обеспечение позволяют обработать не более 100 таких транзакций. Если ТЗ уже подписано - то все, я уже в капкане. Только от милости заказчика теперь зависит, снизить ли требования к системе, приобрести технику помощнее или содрать с меня неустойку за невыполнение договорных обязательств.

Если же ТЗ находится в стадии разработки, я просто ставлю Заказчика в известность о результате макетирования и говорю, что предлагаемые требования реализовать нереально. Тогда мы вместе ищем выход, но уже как равные партнеры, а не как рассерженный Заказчик и виноватый Исполнитель, наобещавший сгоряча лишнего и не сумевший сдержать обещания.

То же самое и с макетом интерфейса. Заказчик хочет одновременно видеть 10 графиков, 20 диаграмм и 150 кнопок на одной форме, и при этом закупил самые дешевые 15-дюймовые дисплеи, на экране которых разместить это просто нереально. Простое заполнение макета пустышками реальных размеров сделает очевидным нереальность такого варианта и позволит избежать оправданий впоследствии.

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

[Dimka]

"Значит" - откуда?

"Значит" оттуда, что постановка задачи идёт впереди перебора вариантов её решения. И если не найдено ни одного подходящего решения, меняют постановку задачи. Не станет же никто утверждать, что решает задачу до того, как она была поставлена?

Для крупных проектов "макетирование" лучше оформлять отдельно, как НИОКР, за отдельные деньги. Никакого ущерба в РФ Исполнитель не понесёт - весь риск обязан взять на себя Заказчик.

Статья 775. Последствия невозможности достижения результатов научно-исследовательских работ
Если в ходе научно-исследовательских работ обнаруживается невозможность достижения результатов вследствие обстоятельств, не зависящих от исполнителя, заказчик обязан оплатить стоимость работ, проведенных до выявления невозможности получить предусмотренные договором на выполнение научно-исследовательских работ результаты, но не свыше соответствующей части цены работ, указанной в договоре.

Статья 776.Последствия невозможности продолжения опытно-конструкторских и технологических работ
Если в ходе выполнения опытно-конструкторских и технологических работ обнаруживается возникшая не по вине исполнителя невозможность или нецелесообразность продолжения работ, заказчик обязан оплатить понесенные исполнителем затраты.

Такие положения закона быстро вправляют мозги заказчикам. "Невменяемость" стоит дорого.

Если всё же не "значит", мы опять возвращаемся к вопросу, чем занимается Исполнитель. Пытается выполнить требования Заказчика, или же сам сочиняет себе работу на деньги Заказчика? (Кстати, последний вариант вполне реален, когда какой-либо госструктуре нужно "освоить" средства.)

Можно и так спросить. До составления ТЗ, в котором перечислены все требования, существуют ли промежуточные соглашения, например, некий "протокол о намерениях"?

[Hooter]

"Значит" - откуда?

"Значит" оттуда, что постановка задачи идёт впереди перебора вариантов её решения. И если не найдено ни одного подходящего решения, меняют постановку задачи. Не станет же никто утверждать, что решает задачу до того, как она была поставлена?

Не хочу спорить, но, мне кажется, что Alf своим последним постом ответил тебе более полно, чем я

Кроме этого, мне всегда казалось, что подписанное ТЗ означает следующее: Заказчик считает, что достаточно ясно и полно выразил требования, а Исполнитель в свою очередь обязуется выполнить эти требования. Или ТЗ это просто бумажка, а не документ, разрешающий открыть проект и начать его финансирование?

[PooH]

по ГОСТ-у ТЗ может только дополнятся (доп.соглашения)

[Dimka]

Не хочу спорить, но, мне кажется, что Alf своим последним постом ответил тебе более полно, чем я

А я не об этом. Я о том, как разграничить (и сделать это формально) цель разработки и собственно процесс разработки. Макетирование - это уже процесс, имхо. А значить цель где-то рядом, но точно известно, что до макетирования.

Из ответа Alf'а следует, что такая цель - неформальная цель, лишь потом обретающая форму в ТЗ. Не будет ли правильным полагать, что процесс формирования цели - это процесс Заказчика, а Исполнитель выступает лишь в качестве консультанта (профильного эксперта), отвечающего на возникающие вопросы заказчика?

И если это правильное полагание, то в течение этого процесса речь не идёт о разработке ПО, речь идёт лишь о принятии решения о разработке ПО. Но всегда ли осознаёт это Исполнитель? Ведь если он этого не осознаёт, получаем концепцию "Исполнитель выступает в лице Заказчика".

Насколько я понял, многие против такой концепции. (Это уже оценка.) С такой концепцией хорошо разводить заказчика на деньги, но никак не писать хорошие, а самое главное полезные и нужные людям программы.

[Sla]

PooH, дай номер ГОСТа
Вот dimka привел статью из ГК РФ
тема может свестись к вопросу "как составить договор, чтоб нам не было плохо", imho

Потери Исполнителя и Заказчика оговариваются на этапе подписывания Договора, согласно действующим законным актам. Например, у меня в конторе, одна из визирующих подписей договора - подпись юриста.
Естественно не везде есть юрист, но и не у всех есть объемы работ, требующие проведения, например, НИОКРовских работ.
Предлагаю продолжить...
В общем-то мы уже все-таки определились КТО составляет ТЗ. Что дальше?


Добавлено через 13 минут и 34 секунды:

И если это правильное полагание, то в течение этого процесса речь не идёт о разработке ПО, речь идёт лишь о принятии решения о разработке ПО. Но всегда ли осознаёт это Исполнитель? Ведь если он этого не осознаёт, получаем концепцию "Исполнитель выступает в лице Заказчика".

Насколько я понял, многие против такой концепции. (Это уже оценка.) С такой концепцией хорошо разводить заказчика на деньги, но никак не писать хорошие, а самое главное полезные и нужные людям программы.

Исполнитель выступает в лице Заказчика при составлении ТЗ, чтобы принять решение о разработке
И куда тогда смотрит Заказчик, подписавший ТЗ?

[Dimka]

Исполнитель выступает в лице Заказчика при составлении ТЗ, чтобы принять решение о разработке
И куда тогда смотрит Заказчик, подписавший ТЗ?

Тогда так: договор на разработку раньше ТЗ или позже?

[Alf]

Следующим пунктом у нас обозначено:

- что нас в этом не устраивает и мешает работать;

Целое сочинение тут писать не имеет смысла. Скорее пойду от противного. Я более-менее описал процесс, каким я его предпочитаю видеть. Мешают мне все факторы, которые препятствуют нормальному течению этого процесса, а именно:

- нечеткость мышления (заказчик имеет полное право не разбираться в информационных технологиях, иначе ему незачем было бы привлекать сторонних исполнителей, управился бы собственными силами; но вот в своей области он должен быть как рыба в воде, разбираться в бизнес-процессах, владеть терминологией, уметь четко объяснить суть своих проблем, не вдаваясь в лишние детали). Особую проблему в этом плане представляют руководители, выдвинутые в свое время по партийно-комсомольской линии, и их отпрыски. Им все равно, чем руководить, - культурой ли, производством, наукой, методы всюду одинаковы - демагогия и давление. Чем крупнее организация и чем ближе к официальной власти, тем выше вероятность наткнуться на этот тип руководителя. К сожалению, именно в их руках зачастую находится судьба наиболее крупных и выгодных контрактов; впрочем, человеку с улицы все равно не слишком реально встрять в такие контракты, так что на самом деле эта проблема встречается не столь часто;

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

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

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

Вроде бы в общих чертах все.

[Dimka]

Книжка Йордона "Смертельный марш" - там более подробно, полно и с примерами.

[PooH]

Sla, посмотри пост №87 на 3-ей странице

[Alf]

- как должны выглядеть идеальные с нашей точки зрения спецификации;

Полагаю, что в пригодном для работы ТЗ должны присутствовать следующие пункты.

1. Входные данные (если есть).
Если данные допускают перечислимое множество значений, то перечень этих значений.
Если данные должны лежать в определенном диапазоне, то диапазон этих значений.
Если данные можно описать регулярным выражением, то, соответственно, вид этого регулярного выражения.
Если данные можно представить в виде некоторого формального языка, то грамматика этого языка (БНФ либо синтаксические диаграммы).
Если программа непосредственно взаимодействует с оборудованием, то полное описание интерфейса этого оборудования.

2. Выходные данные.
Если результат представляется в виде экранной формы или бумажного бланка, то образец бланка или эскиз формы (при необходимости - с точными размерами каждого поля вывода, форматом поля и т.д.).
Если результат предназначен для дальнейшей компьютерной обработки (импорта в другие приложения), то спецификация формата выходного файла (для CSV, например, порядок и формат полей и вид разделителя, для XML - перечень тэгов и т.д.).

3. Базы данных.
Если программа должна получать данные из БД и/или записывать их в БД и при этом структура БД имеет значение для заказчика, то скрипт SQL, позволяющий сгенерировать все требуемые объекты БД, и по возможности диаграмма ее структуры (предпочитаю в нотации IDEF1X). Если БД уже имеется у заказчика, то еще и набор тестовых данных, соответствующих реальным.

4. Функциональное описание.
Если задача не является тривиальной, то схема той части бизнес-процесса, которую она реализует (IDEF0, IDEF3, DFD) плюс словарь (ранее это обсуждалось).
Если задача достаточно проста, можно обойтись просто текстовым описанием, при условии, что оно компактно (1-2 печатные страницы) и непротиворечиво.

5. Интерфейс с внешней средой.
Если интерфейс программы с внешней средой не исчерпывается несколькими опциями командной строки или парой-тройкой кнопок и других элементов управления, то диаграммы прецедентов UML + тексты сценариев. Если сценарии не тривиальны, для каждого из них - диаграмма устойчивости UML.
Здесь же - пожелания заказчика по части эргономики, например, наиболее часто используемые элементы интерфейса должны быть скомпонованы поближе друг к другу, иметь удобные акселераторы, размер кнопок сделан побольше, порядок обхода элементов управления - естественный для наиболее часто используемого сценария. Возможно, какие-то эстетические пожелания - скины, украшения и пр.

6. Нефункциональные требования.
Перечень всех прочих требований, не имеющих непосредственного отношения к решаемой задаче, но существенных для заказчика при эксплуатации программы. Примеры таких требований:
- недопустим запуск на одном компьютере более одного экземпляра програмы;
- расчет итогов за месяц должен длиться не более 3 часов;
- программа не должна использовать более 30 Мбайт оперативной памяти.

7. Эталонные данные.
Наборы входных данных и соответствующих им выходных, которые заказчик считает правильными, для фунционального тестирования.

8. Среда выполнения программы.
Описание среды выполнения програмы (оборудование + операционная система), если она не соответствует стандартному де-факто персональному компьютеру на момент начала разработки (экзотическая версия ОС и/или прикладных программ, которые могут оказать влияние на разрабатываемую программу, ограниченные аппаратные ресурсы и т.п.).

9. Передача программы заказчику.
Перечень материалов (исходные и/или исполняемые файлы, скрипты, руководства по эксплуатации, диаграммы, прочие уместные для данного случая документы), передаваемые заказчику для эксплуатации программы.

10. Формальности.
К этой категории я скопом отнес сроки окончания работ, календарные графики, промежуточную отчетность, порядок приемки-сдачи и прочие формальные вопросы, которые не имеют непосредственного отношения к функциональности программы, но соблюдение которых важно во избежание конфликтов между исполнителем и заказчиком.

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

[Dimka]

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

Вот здесь вскрылось то, о чём я раньше подозревал, читая эту тему. Лично для меня ТЗ и спецификации - это разные вещи. У нас ТЗ называется Customer Requirements Specification, а спецификации - Software Specification Document.

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

Если данные допускают перечислимое множество значений, то перечень этих значений.
Если данные должны лежать в определенном диапазоне, то диапазон этих значений.

Так как в машине непрерывные величины отсутствуют, то я бы добавил ещё и точность.

Если программа должна получать данные из БД и/или записывать их в БД и при этом структура БД имеет значение для заказчика, то скрипт SQL, позволяющий сгенерировать все требуемые объекты БД, и по возможности диаграмма ее структуры (предпочитаю в нотации IDEF1X). Если БД уже имеется у заказчика, то еще и набор тестовых данных, соответствующих реальным.

Помимо структуры БД, если задача не сводится к "механической" переработке данных без вникания в их содержимое, нужно ещё семантическое описание БД. Из моей практики вытекает, что по названиям таблиц и полей не всегда можно судить, что хранит БД. Ещё реже бывает понятно, как пользоваться данными. Был у меня один "оффшорный" проект, в котором БД содержала тысячи таблиц, да ещё и с испанскими названиями. В таких системах без иерархически упорядоченного описания ориентироваться просто невозможно.

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

[PooH]

Alf, ты про это:

-  Требования к справочной системе и документации

упомянул, только вскользь. Случайно или преднамеренно?

[Dimka]

PooH, развитая система помощи актуальная для так называемых программных продуктов - тех, которые продаются на рынке. Для систем (особенно небольших), разрабатываемых на заказ (если это не субподряд для программного продукта), этот пункт не так важен. Часто достаточно руководства.

[PooH]

Я имею ввиду не только помощь, но и техническую документацию.

[Alf]

Продолжаю по пунктам:

- какие формализмы могут помочь приблизиться к этому идеалу;

Наиболее полезные с моей точки зрения формализмы, использование которых в ТЗ идет последнему явно на пользу, я уже упоминал ранее в нескольких постах. Постараюсь здесь собрать их вместе.

Итак, краткий перечень полезных формализмов:

- регулярные выражения;
- формы Бэкуса-Наура;
- синтаксические диаграммы;
- функциональные диаграммы IDEF0;
- диаграммы процессов IDEF3;
- диаграммы потоков данных DFD;
- диаграммы данных IDEF1X;
- диаграммы прецедентов UML (совместно с текстовым описанием сценариев);
- диаграммы устойчивости UML.

Если кто знает (и реально использует) еще какие-либо формализмы, не упомянутые здесь, - поделитесь.