"ТЗ" больше похоже на sprint backlog в SCRUM. Т.е. подходит в качестве опорного плана для неформального разговора с заказчиком - чтобы ничего не забыть. Но никак не для фиксации обязательств. Так что смотрите: если заказчик - вменяемый "свой человек", такого ТЗ достаточно, если не нормальный и/или не свой - систему по такому ТЗ можно делать всю жизнь, и (формально) не сделать.

>>Система должна быть реализована на базе СУБД Microsoft Access 2000. При разработке системы должен использоваться язык программирования Visual basic for Applications (VBA), а также язык запросов SQL.
MS Access 2000 "настольная" СУБД, разработанная 7 лет назад. Почему не 2007 или хотя бы 2003?

>>Система должна быть приспособлена к многопользовательской работе с распределением прав доступа.
Сколько пользователей? Сколько из них работают одновременно?
Права доступа к чему? Да и сможете ли их реализовать:
http://www.msvb.narod.ru/doc_access.htm
http://www.msvb.narod.ru/soft_access.htm .
Где требования к объёму данных?

>>Для обеспечения информационного обмена компоненты Системы должны работать в составе единой вычислительной сети.
Про структуру и пропускную способность сети - ни слова.

>>В качестве основного средства связи между компонентами Системы должна быть использована локальная вычислительная сеть.
Масло масляное.

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

>>а также надежную защиту от утери хранимой и вводимой информации при программно-аппаратных сбоях (отключения электропитания,
Что такое "надёжная"?
>>отказах носителей информации, вирусах
Не бывает.
>>и т.д.).
А именно?

>>После сбоя серверной операционной системы или СУБД в процессе выполнения пользовательских задач должно быть обеспечено восстановление данных в БД до состояния на момент окончания последней нормально завершенной перед сбоем транзакции.
Вы работаете в MS и имеете возможность усовершенствовать MS Access?

>>С целью обеспечения сохранности информации, хранимой в Системе, должно осуществляться регулярное (1 раз в месяц) автоматическое резервное копирование исходных таблиц БД.
Работы за целый месяц не жалко?

>>Обеспечивать минимум усилий и временных затрат пользователя для навигации по Системе;
Невозможно проверить - зачем писать?

>>Обладать системой контекстных подсказок для функциональных элементов, с которыми у пользователя потенциально могут возникнуть затруднения;
Для всех?

>>Корректно отображаться при всех возможных разрешениях и количестве одновременно отображаемых цветов монитора.
400x300 4 цвета?

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

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

>>1. Модуль... 2. Модуль ... 3. Модуль Финансового диспетчера... 4. Модуль Начальника Отдела продаж... 5. Модуль Заведующего Складом исходных материалов... 6. Модуль Разработчика Спецификаций на готовую продукцию... 7. Модуль Начальника Цеха...
1) Смесь требований и архитектуры.
2) IMHO - нужно либо повысить уровень абстракции, либо описать на этом уровне, со всей полнотой или подробностью.

Считаю, что на разработку всего перечисленного даже при хорошем опыте, индивидуальной разработке и применении MS Access, не дающего уйти в разработку абстракций и интерпретаторов :), уйдёт не меньше половины человеко-года. Аренда помещения и амортизация компьютера за это время уже скушают больше $500.

Так_забежал_простоЯ бы сказал, начиная от "на три порядка больше".
IMHO - переоценка. То, что продавцы и консультанты ERP-систем готовы мастерски обосновать проедание даже куда больших денег - не аргумент, работа у них такая. Для компании среднего размера - максимум на два порядка. $50k - вполне приличные деньги, если работать не в Москве с Питером, и не нанимать дорогих ПМов с аналитиками и архитекторами.

Так_забежал_просто
Где-то за 2500 американских рублей и две недели потраченного времени, может быть, хороший специалист посмотрит Ваше ТЗ и примерно поймёт, что Вы от него действительно хотите.
IMHO - это плохой специалист. Не знающий предметной области, ленивый и дорогой.

Так_забежал_просто
На Access этого делать нельзя - самоубийство.
Да, точно. Делать надо непременно на SAP и/или Oracle. Чтобы взять побольше денег и увеличить цену своего времени.
При наличии прямых рук и на MS Access можно написать вполне приличный клиент для MS SQL Server'а. При этом, повторяюсь, из-за упрощённости языка не будет возникать желание углубляться в архитектурные изыски и написание компилляторов.

Так_забежал_просто<...>
На MS SQL Server (не на чистом Access, как предлагает digit) - да, это можно написать, наверное. Хотя при достаточно гибкой лицензионной политике Оракла - не факт, что нужно.
У работников , знающих продукты Oracle, недостаточно гибкая ценовая политика. Так что IMHO нужно.

Так_забежал_просто
В общем, надо думать, конечно. При этом клиента на Access писать - довольно дорогой вариант, потому что на каждый комп придётся Office ставить, а сейчас местами можно обойтись OpenOffice-ом, плюс хоть какое-то увеличение скорости разработки Access вряд ли даст.
MS Office и так везде стоит. Лицензионная чистота - то, к чему нужно стремиться, но лучше рассчитывать не на идеалы, а на реальность.

Так_забежал_просто<...>
Где-то за 2500 американских рублей и две недели потраченного времени, может быть, хороший специалист посмотрит Ваше ТЗ и примерно поймёт, что Вы от него действительно хотите.
<...>Практика показывает, что в течение первых двух недель даже заказчик не понимает своего ТЗ, у разных людей внутри компании могут быть разные мнения насчёт того, что действительно нужно. Минимум две недели подготовительных работ для таких систем всяко потребуется, хотя бы чтобы утрясти разногласия.
Насколько я понял, ТЗ в данном случае пишет исполнитель. Поэтому смотреть его должен не другой исполнитель, а эксперт, не один раз участвовавший в создании аналогичных систем в роли бизнес- и/или системного аналитика. Не! согласовывать с заказчиком, а сказать: "здесь не хватает вот этого", "здесь обычно потом хотят ещё вот это", "это лишнее", "тут неправильно". Ничего утрясать не нужно, нужно несколько раз прочитать с красной ручкой в руках.

Так_забежал_просто
>>Налоги,
>>аренда
- часть комнаты в здании того же предприятия и/или квартира разработчика; считаем бухгалтерские, а не экономические издержки, а значит 0
>>отпуска
- сдельная оплата
>>лицензии
- для разработчиков - большие скидки и российская реальность; для заказчиков - речь идёт, насколько я понял, только о разработке своего ПО, не о посредничестве в поставках другого ПО...
>>оборудование
- ... и не о посредничестве в поставках железа, хотя нагреть руки на этой спекуляции тоже можно
>>убраться в комнате кто-то должен
- заводская уборщица, ну очень дёшево
>>сумма как минимум ополовинивается, остаётся $25k
- это если большой системный интегратор делает, в основном на прокорм инвесторов, больших гламурных начальников, и на поддержку убыточных проектов.

>>Если даже ЗП хорошего программиста где-нибудь на периферии $1000 - получается два года работы одного человека. Но, господа, речь идёт о пяти модулях!
- два года для одного среднего предприятия - это неприемлемо много; IMHO людей должно быть от двух до пяти :)
>>Включая планирование, где требования меняются достаточно регулярно.
- быстро реализовать утверждённые требования, пока они не устарели; поддержка - за отдельные деньги

>>От этого человека (среди прочего) требуется реализовать что-то вроде WMS-системы, насколько я понимаю. Там одни только формочки документов делать и переделывать полгода минимум.
- полгода, 6*4*40=960 ч., с формочками? IMHO хватит не на одну сотню формочек.

>>Это должен быть сверхчеловек, к тому же он должен работать безотказно, никогда не ходить в отпуск - потому что для системы такого масштаба хотя бы один активный разработчик должен постоянно сидеть на поддержке, никто другой в ней просто не разберётся, а ошибки (тестировщика-то мы не считаем!) и задания на доработку будут валиться регулярно.
- не боги горшки обжигают; комментировать и документировать нужно всегда; тестировать можно и самим, при этом самокритичность и качество зависит от собственной заинтересованности в результате

>>Это всё ещё и админить как-то надо. Кто будет это делать, если ИТ-отдел знает только Access?
- за отдельные деньги; да и админинья в хорошей системе не слишком много, ввод новых пользователей, раздача полномочий, раз в год - пляска с бубном над секциями, раз в полгода - пляска с бубном и плачем над резервными копиями

>>В общем, в $50000 - не верю.
- да я понимаю, что $500'000 для разработчика лучше, но за такие деньги заказчик может лишний десяток сотрудников нанять, которые 5 лет (время жизни системы) будут выполнять её функции вручную. Ну или существующим за повышение качества и неудобство приплачивать. Чем не альтернатива?