|
17.10.2014, 01:02 | #1 |
Banned
|
Цитата:
Постановка технических заданий разработчикам;
Упаси боже от такого счастья. Слово "техническое" явно лишнее. И наличии такого в описании вакансии - неуместно для роли. FSD/FRD более уместно. Но никак не TSD/TRD Есть разница между функциональной и технической спецификацией/документом/задачей. Можно обойтись без технической, документируя после, но результатом работы "первой прокладки" обязан быть функциональный документ. Но никак не технический. https://ru.wikipedia.org/wiki/Функци...фикация Цитата:
Функциональная спецификация не определяет операции, происходящие внутри данной системы и каким образом будет реализована её функция. Вместо этого, она рассматривает взаимодействие с внешними агентами (например, персонал, использующий программное обеспечение; периферийные устройства компьютера или другие компьютеры), которые могут "следить", взаимодействуя с системой.
Пример из типичной функциональной спецификации: Когда пользователь нажимает кнопку ОК, окно диалога закрывается и в фокусе оказывается главное окно, которое было до появления диалога. |
|
|
За это сообщение автора поблагодарили: zemlyn (1), S.Kuskov (2). |
17.10.2014, 02:12 | #2 |
MCTS
|
Хм, я бы сказал, что это пример как не надо писать спецификации )
__________________
I could tell you, but then I would have to bill you. |
|
17.10.2014, 07:40 | #3 |
Участник
|
Угу, а то складывается впечатление, что это функциональный дизайн системы, чьей первоочередной функцией является показ окошек.
Но мысль ax_mct мне понятна. Возможно это вопрос терминологии, но ведь и вся эта тема об этом. |
|
17.10.2014, 15:25 | #4 |
Banned
|
В случае UI, когда с системой взаимодействуют через UI,
функциональная спецификация должна описывать процесс и требования в терминах UI. В основном через use/user cases/scenarios и возможно test scenarios. Беда, когда не понимают сути документов и используют недофунциональные и недотехнические документы ради красивого но бестолкового документа. Чума, когда нетехнические специалисты, определяют технические подробности в функциональном документе. И задница на горизонте, когда из-за левого технического наполнения, в функциональном документе нет главного - входных и выходных сценариев. Лично я предпочитаю глупейшее описание в терминах UI чем неадекватное и ненужное перечисление технических деталей от лица полных в этом неспециалистов. И речь не о том что я не знаю UI, вопрос в том как его знают постановщики задач. При том что техническую часть должны определять специалисты. Та практика при которой аналитики/консультанты/первая прокладка потеют и составляют псевдо технические документы в ущерб функциональному описанию - порочна. Последний раз редактировалось ax_mct; 17.10.2014 в 15:28. |
|
|
За это сообщение автора поблагодарили: Kabardian (1). |
20.10.2014, 12:11 | #5 |
Участник
|
О системе
Цитата:
Сообщение от ax_mct
В случае UI, когда с системой взаимодействуют через UI,
функциональная спецификация должна описывать процесс и требования в терминах UI. В основном через use/user cases/scenarios и возможно test scenarios. Беда, когда не понимают сути документов и используют недофунциональные и недотехнические документы ради красивого но бестолкового документа. Только определив конкретную систему, можно сделать следующий шаг - детально описать требования к ее входам и выходам (это то, о чем пишешь ты). Если же автор документа не определил систему, то ему самому непонятно, к чему он должен предъявлять требования. Именно из этого вытекает вся дальнейшая муть в его документах, потому что писать что-то надо, а что - автору непонятно В России, документ, который это описывает, действительно называется "Техническое задание на создание (развитие или модернизацию) автоматизированной системы". Так уж исторически сложилось Если интересно, содержание этого документа раскрывает ГОСТ 34.602-89 - http://prj-exp.ru/gost/gost_34-602-89.php. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
21.10.2014, 21:06 | #6 |
Banned
|
Цитата:
Сообщение от Bobkov
Самая Главная Беда - это когда пишут о системе, но не определяют ее границ (главным образом конечно, функциональных). Например, если система - это то что по "кликам" изображает "окошечки" - так и надо сразу написать. Если же система - это то что превращает "бумажную первичку" в "красивые диаграммы" - так и надо написать. Потому что система, которая делает "красивые диаграммы" не из "бумажной первички", а из "данных в базе" - это уже другая система.
Только определив конкретную систему, можно сделать следующий шаг - детально описать требования к ее входам и выходам (это то, о чем пишешь ты). Если же автор документа не определил систему, то ему самому непонятно, к чему он должен предъявлять требования. Именно из этого вытекает вся дальнейшая муть в его документах, потому что писать что-то надо, а что - автору непонятно В России, документ, который это описывает, действительно называется "Техническое задание на создание (развитие или модернизацию) автоматизированной системы". Так уж исторически сложилось Если интересно, содержание этого документа раскрывает ГОСТ 34.602-89 - http://prj-exp.ru/gost/gost_34-602-89.php. Ужос . Устарело на 20-30 лет. Хорошо для общения между юрлицами, но никак не для человеков на проекте когда роль-человек ставит задачу другой роли-человеку. Хабрахабр "Документирование по ГОСТ 34* — это просто" http://habrahabr.ru/post/122700/ Цитата:
Описание технологического процесса обработки данных (включая телеобработку). Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик.
Скажите государю, что у англичан ружья кирпичом не чистят: пусть чтобы и у нас не чистили, а то, храни Бог войны, они стрелять не годятся ISO/TS 10303-1616:2006 http://www.iso.org/iso/home/store/ca...csnumber=42394 Цитата:
ISO/TS 10303-1616:2006 specifies the application module for AP210 functional specification.
ISO/TS 10303-1616:2006 deals with the representation of functional specification. This data provides information sufficient to allow communication of the behavioural specification of product functions. Formal encapsulation of external data type definitions is made for parametric data and signal characterization. Configuration management information and design change management information is provided. The following is within the scope of ISO/TS 10303-1616:2006: behavioural specification of a functional unit based on observed signals within a functional testbench. Но это оффтоп по сути. Очевидно же что тех.задание это одно а спецификации это другое. На данный момент действующий ГОСТ 1992 года РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов. http://www.rugost.com/index.php?opti...d=22&Itemid=53 Но он тоже устарел как минимум лет на 30. То есть для создания терминала внесения платежей он подойдет, но не для информационной системы предприятия. Последний раз редактировалось ax_mct; 21.10.2014 в 21:10. |
|
|
За это сообщение автора поблагодарили: Bobkov (0). |