Кто такой Бизнес-Аналитик?

[ax_mct]

Цитата:

Сообщение от twilight

Хм, я бы сказал, что это пример как не надо писать спецификации )

В случае UI, когда с системой взаимодействуют через UI,
функциональная спецификация должна описывать процесс и требования в терминах UI. В основном через use/user cases/scenarios и возможно test scenarios.

Беда, когда не понимают сути документов и используют недофунциональные и недотехнические документы ради красивого но бестолкового документа.

Чума, когда нетехнические специалисты, определяют технические подробности в функциональном документе.

И задница на горизонте, когда из-за левого технического наполнения, в функциональном документе нет главного - входных и выходных сценариев.

Лично я предпочитаю глупейшее описание в терминах UI чем неадекватное и ненужное перечисление технических деталей от лица полных в этом неспециалистов.

И речь не о том что я не знаю UI, вопрос в том как его знают постановщики задач.
При том что техническую часть должны определять специалисты.

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

[Bobkov]

Цитата:

Сообщение от ax_mct

В случае UI, когда с системой взаимодействуют через UI,
функциональная спецификация должна описывать процесс и требования в терминах UI. В основном через use/user cases/scenarios и возможно test scenarios.
Беда, когда не понимают сути документов и используют недофунциональные и недотехнические документы ради красивого но бестолкового документа.

Самая Главная Беда - это когда пишут о системе, но не определяют ее границ (главным образом конечно, функциональных). Например, если система - это то что по "кликам" изображает "окошечки" - так и надо сразу написать. Если же система - это то что превращает "бумажную первичку" в "красивые диаграммы" - так и надо написать. Потому что система, которая делает "красивые диаграммы" не из "бумажной первички", а из "данных в базе" - это уже другая система.

Только определив конкретную систему, можно сделать следующий шаг - детально описать требования к ее входам и выходам (это то, о чем пишешь ты). Если же автор документа не определил систему, то ему самому непонятно, к чему он должен предъявлять требования. Именно из этого вытекает вся дальнейшая муть в его документах, потому что писать что-то надо, а что - автору непонятно

В России, документ, который это описывает, действительно называется "Техническое задание на создание (развитие или модернизацию) автоматизированной системы". Так уж исторически сложилось Если интересно, содержание этого документа раскрывает ГОСТ 34.602-89 - http://prj-exp.ru/gost/gost_34-602-89.php.

[ax_mct]

Цитата:

Сообщение от Bobkov

Самая Главная Беда - это когда пишут о системе, но не определяют ее границ (главным образом конечно, функциональных). Например, если система - это то что по "кликам" изображает "окошечки" - так и надо сразу написать. Если же система - это то что превращает "бумажную первичку" в "красивые диаграммы" - так и надо написать. Потому что система, которая делает "красивые диаграммы" не из "бумажной первички", а из "данных в базе" - это уже другая система.

Только определив конкретную систему, можно сделать следующий шаг - детально описать требования к ее входам и выходам (это то, о чем пишешь ты). Если же автор документа не определил систему, то ему самому непонятно, к чему он должен предъявлять требования. Именно из этого вытекает вся дальнейшая муть в его документах, потому что писать что-то надо, а что - автору непонятно

В России, документ, который это описывает, действительно называется "Техническое задание на создание (развитие или модернизацию) автоматизированной системы". Так уж исторически сложилось Если интересно, содержание этого документа раскрывает ГОСТ 34.602-89 - http://prj-exp.ru/gost/gost_34-602-89.php.

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы (пример) - http://prj-exp.ru/patterns/pattern_tech_task.php
Ужос . Устарело на 20-30 лет. Хорошо для общения между юрлицами, но никак не для человеков на проекте когда роль-человек ставит задачу другой роли-человеку.

Хабрахабр "Документирование по ГОСТ 34* — это просто"
http://habrahabr.ru/post/122700/

Цитата:

Описание технологического процесса обработки данных (включая телеобработку). Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик.

Действующий ГОСТ 34.602-89 (1990 года) какой-то безлюдный, больше для введения перфокарты годиться или для того чтобы от заказчика отмахаться.

Скажите государю, что у англичан ружья кирпичом не чистят: пусть чтобы и у нас не чистили, а то, храни Бог войны, они стрелять не годятся

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.

Денег правда стоит но хоть что-то в 2012 году.

Но это оффтоп по сути. Очевидно же что тех.задание это одно а спецификации это другое.

На данный момент действующий ГОСТ 1992 года
РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.
http://www.rugost.com/index.php?opti...d=22&Itemid=53

Но он тоже устарел как минимум лет на 30. То есть для создания терминала внесения платежей он подойдет, но не для информационной системы предприятия.