Требования к ПО

а что оно вообще делать должно?

ТЗ придётся писать самому и согласовывать с заказчиком.

разговора глухого со слепым

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

с подводной лодки не убежать.

Работать с неким встраиваемым устройством по ethernet-порту.

http://dilbert.com/strips/comic/2006-01-29/

Смотреть фильмы, слушать музыку, выходить в инет, компилировать, скачивать гиббоны, ***дастрадать. Это сделай, а потом если чего не хватает доделаешь.

А можно поподробнее с этого места? =)

ПО должно быть стабильным и достаточно простым для пользователя.

Ну если известно _как_ работать, то в этом и должен состоять документ. Есть спецификация/стандрат по _как_ или по _некоему устройству_?

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

ТЗ нет и не будет

будь мужиком, ...! составь тз сам по результатам разговора с заказчиком и отдай на утверждение.

если это всё никак, то беги оттуда.
денег много дают? тогда не ной! :-D

Заказчик должен хотя бы догадываться, что ему нужно.

Какие же вы, мужчины, нечуткие. (C)

Сделай прототип. Окно, большая кнопка «Сделать всё заебись.» которая автоматически нажимается через 15 секунд.

плюсую. хорошая use-case диаграмма дает ответ на 90% вопросов

ок, попробую так :-)

с подводной лодки не убежать

Тогда забухай. Или в бильярд сбацай. Неформальное общение заюзай, короче.

У меня был однажды случай, писал софтину для конторы офицера-запасника. Нормальный мужик, но объяснять суть задачи довольно образно.

Работать с неким встраиваемым устройством по ethernet-порту.

Тем более придётся изучать спеки и ТЗ на себя брать.

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

живу в провинции, з\п устраивает, неохота терять работу.

это мне знакомо.

Работаешь программистом или админом? А заказчик кто?

ЗЫ в какой провинции обитаешь?

На что он попросил меня, что бы мы лучше друг - друга поняли, выслать ему бланк с наводящими пунктами которые он сможет заполнить. Собственно, есть ли у кого что нибудь подобное, что бы не такое объемное как ТЗ, но и не двусмысленное как телефонный разговор. Как то я мозгами собраться не могу :-)

Обычно всегда ТЗ пишет ИСПОЛНИТЕЛЬ. Разумеется по результатам обсуждений и согласований с заказчиком. Потому что заказчик часто слабо представляет, что конкретно в нем должно быть, как раз твой случай.

Алистер Коберн - Cовременные методы описания функциональных требований к системам (Writing effective иse cases) пролистай по диагонали.

21

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

Примеры причин срыва сроков:

• Целевой ОС окажется gentoo, на которую наотрез откажутся ставить какие-либо пакеты, а также будут недели две молчать насчёт версий основных пакетов, установленных там
• Найдётся несколько или несколько десятков фич, которые заказчик считает ну очень простыми, по незнанию проецирует эту простоту на разработку и потому думает что запрограммировать их тоже можно минут за 5. Он обязательно хочет иметь эти фичи в своём приложении, но упомянуть о них как-то всё забывает, ведь мелочи же. Примеры: VoIP-телефония с возможностью звонить абонентам скайпа, геолокация, печать отчётов для 1С и т.д.
• У заказчика могут быть свои требования к производительности — например, чтобы N операций в минуту выполнялись без тормозов и лишней нагрузки на сеть.
• Заказчик может просто ограничить доступ к устройству, под готорое надо писать. Самыми разными способами.

Без ТЗ работать не стоит, потому что уложиться в сроки можно только с ТЗ и вот такой строчкой в договоре: «в случае, если ТЗ не уточняет какой-либо аспект поведения программы, исполнитель может трактовать этот аспект как ему угодно».

супер, особый тебе респект!

я попросил его составить четкие требования к ПО (ТЗ нет и не будет)

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

В качестве хренового примера. Требования: Пользователь набирает имя пользователя в поле «имя пользователя», пароль в поле «пароль» и нажимает кнопку Ok. Правильно будет: Для входа в систему (конечная цель) пользователь должен идентифицировать себя набрав имя под которым зарегистрирован в системе и пароль подтвредив набраное нажатием кнопки Ok. Из правильного варианта можно например вывести, что пользователь может идентифицировать себя еще каким-то способом, например ключем, поскольку конечной целью (здесь) является вход в систему то даже идентифицированого пользователя можно в систему не пускать - работает система прав и допусков, кнопку не обязательно нажимать мышкой, а можно потверждать Enter-ом.