Цитата:
Сообщение от
ax_mct
В случае UI, когда с системой взаимодействуют через UI,
функциональная спецификация должна описывать процесс и требования в терминах UI. В основном через use/user cases/scenarios и возможно test scenarios.
Беда, когда не понимают сути документов и используют недофунциональные и недотехнические документы ради красивого но бестолкового документа.
Самая Главная Беда - это когда пишут о
системе, но не определяют ее границ (главным образом конечно, функциональных). Например, если
система - это то что по "кликам" изображает "окошечки" - так и надо сразу написать. Если же
система - это то что превращает "бумажную первичку" в "красивые диаграммы" - так и надо написать. Потому что система, которая делает "красивые диаграммы" не из "бумажной первички", а из "данных в базе" - это уже другая система.
Только определив конкретную
систему, можно сделать следующий шаг - детально описать требования к ее входам и выходам (это то, о чем пишешь ты). Если же автор документа не определил
систему, то ему самому непонятно, к чему он должен предъявлять требования. Именно из этого вытекает вся дальнейшая муть в его документах, потому что писать что-то надо, а что - автору непонятно
В России, документ, который это описывает, действительно называется "Техническое задание на создание (развитие или модернизацию) автоматизированной системы". Так уж исторически сложилось
Если интересно, содержание этого документа раскрывает ГОСТ 34.602-89 -
http://prj-exp.ru/gost/gost_34-602-89.php.