Функциональные требования

[Максим Озерцев]

Что должен в себя включать документ Функциональные требования к системе? Просьба на методологию MBS особо не ссылаться - уже читали...

[new2004]

В каком это городе начался внутренний проект?

[leshy]

Данный документ должен зафиксировать требования бизнеса к автоматизации. Как правило, включает текущую модель бизнес-процессов, а также модель будущих, оптимизированных процессов. Также фиксируются несоответствия между требованиями заказчика и базовой функциональностью системы.

[Максим Озерцев]

Максимально уточню вопрос... Включают ли ФТ в себя описания документов, которые будут регистрироваться в системе, отчетов которые формируются? Условно говоря отчет о продажах должен включать в себя: контрагент, наименование товара, цену, кол-во, цену, стоимость и т.д.
Или же детальное описание документов и отчетов делается в ТЗ? А на этапе формирования ФТ можно отделаться простым фиксированием самого факта существования такого отчета?
То есть вопрос по сути насколько глубоко необходимо копать на этапе ФТ?

[Hamster]

Если заказчик умный а внедренец дурак -
1) обследование НИКОГДА толком не будет закончено
2) требования заказчика НИКОГДА не будут подписаны

Если наоборот - то наоборот.
Если оба умные - ни то, ни другое не нужно.

[leshy]

Функциональные требования должны дать ответ на вопрос: «Что система должна делать».
А на вопрос «Как именно это будет» должен быть ответ в ТЗ.
В функциональных требованиях вы должны зафиксировать список документов, которые должны присутствовать в системе. Шаблоны этих документов вы утвердите на этапе проектирования требований на систему, т.е. составления ТЗ.
Уровень детализации зависит от конкретного проекта.

[Prof]

не удержался...

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

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

[Yprit]

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

[leshy]

Абсолютно согласен с Вами Prof.
Мы говорим об одних и тех же вещах только термины разные. Термин ТЗ я употреблял в том значении, в котором он определен в методологии MBS. Считайте ТЗ = Концептуальный дизайн. Объект автоматизации, механизмы сдачи системы и организация проекта фиксируются Уставом проекта.