Виды документации, разрабываемой аналитиками




В теме 11 ответов, и 8 участников, последнее обновление сделано пользователем Аватар (Normalnaja) Normalnaja 6 г, 5 мес. назад.

Показано 12 ответов - от 1 до 12 (всего 12)
  • Автор
    Сообщения
  • 13.02.2010 в 23:53 # 5717
    Привет всем,
    Я вот на досуге задумался, а какие вообще документы должен знать, уметь и разрабатывать аналитик по долгу службы?
    Вопрос довольно общий, и я постараюсь сформулировать исходные факты и предпосылки, которые собственно и вызвали у меня интерес:

    1) Методик и принципов бизнес-анализа довольно много. Некоторые из них общеизвестны и приняты повсеместно; другие же используется только в отдельных командах. Соответственно и выходная документация бывает разная по содержанию и назначению.
    2) Опять же, исходя из многообразия методов бизнес-анализа, документы можно называть по-разному, хотя суть остается одна и та же. Тем не менее интересно будет узнать, если вдруг у кого-то в процессах есть тот же Vision and Scope, только под названием Вася Пупкин :) .

    Можно начать со следующего исходного набора документов, которые я либо использую, либо когда-то использовал на своих проектах:

    1. Proposal — письменное формальное предложение потенциальному заказчику. Зачастую пишется как ответ на Request for Proposal (RFP) от заказчика. Так как RFP есть плод творения заказчика, то здесь я его не упоминаю. Кстати, очень часто путают Proposal и RFP, думая, что аналитик пишет RFP, хотя даже по названию можно понять, что это не так.
    2. Vision and Scope — общее видение на систему и ее границы.
    3. Software Requirements Specification — полное описание поведения разрабатываемой системы, включающее функциональные и нефункциональные требования.
    4. Software Design Document — описание системы с точки зрения ее архитектуры и реализации. Пишется естесственно не бизнес-аналитиком, но он может принимать активное участие в ее написании как опытный "писатель документов".
    5. User Guide — понятная и удобная инструкция пользования системой, предназначенная для конечного пользователя.

    Какие еще есть варианты?

    Поделиться:

    Цитировать

    17.02.2010 в 11:22 # 5718
    Аватар (Михаил Сорокин)
    Михаил Сорокин
    Подписчик
    Скажу с колокольни тех. писателя :)
    я бы сказал что юзер гайды пишут именно техрайтеры, зачастую основываясь на спеках.
    В данный момент пишу Software Design Document. Но имхо такого типа документ должен писать сист. архитектор.
    Поделиться:

    Цитировать

    19.02.2010 в 11:34 # 5719
    Аватар (check)
    check
    Участник
    Мне приходилось сталкивать со следующими типами документов, не считая перечисленных выше:

    1) Marketing Documents — описание системы/продукта с точки зрения маркетинга и продаж. Как правило включает краткое описание системы и задач которые она решает, сравнение со схожими продуктами, возможные плюсы приобретения конкретного продукта.

    2) Manuals — тут вроде все понятно. ИМХО один из основных документов, создаваемых техническими писателями.

    3) EULA (End User License Agreement) — что то вроде соглашения пользователя на условия распространения ПО (практически при каждой установке нового ПО каждый из нас подписывает такое соглашение). Как правило, подписывая EULA, пользователь отказывается от каких-либо претензий к разработчику ПО в случае если оно нанесет вред/ущерб системе пользователя, а так же обязуется не распространять ПО "пиратскими" способами.
    К сожалению понятия не имею, кто создает такого типа документы. :)

    4) Online Documentation — WIKI для отдельно взятого проекта. Доступ к такой документации имеют одновременно исполнитель и заказчик, что является несомненным плюсом. Создается и поддерживается проектным менеджером и/или аналитиком.

    Поделиться:

    Цитировать

    25.02.2010 в 02:50 # 5720
    Ниже будут и документы и не совсем.. ну, в общем, я решил припомнить всё, что вы ещё не назвали :wink:

    · Meeting Minutes — формализированные результаты встреч, статус, action items, follow ups и т.д. (Meeting Minutes in Wiki)
    · Communication Plan — (Communication Plan in Wiki)
    · BRD (Business Requirements Document)
    · BAP (Business Analysis Plan)
    · RMP (Requirements Management Plan)

    Поделиться:

    Цитировать

    08.06.2010 в 16:27 # 5721
    Аватар (Anna)
    Anna
    Подписчик
    Вспомнила и я:
    1. Acceptance matrix — перечисление всех разработанных фич с целью сбора комментариев по результатам разработанного функционала для приемки продукта.
    Поделиться:

    Цитировать

    09.06.2010 в 17:31 # 5722
    Аватар (Aliaksei Rudzko)
    Aliaksei Rudzko
    Подписчик
    На IBM (по крайней мере, когда я там работал) были такие документы:
    Statement Of Work — документ, описывающий суть и скоуп работы. Можно сказать, что он является подмножеством Vision.
    Architecture Specification — описание всей системы "с высоты птичьего полета". Как ни странно, это описание полностью оторвано от специфических технологий или решений. Включает перечисление основных бизнес-объектов и свяей между ними.
    Functional Specification — описание системы на уровне Use Cases. Т.е.: "когда пользователь делает это — программа отвечает вот так".
    Detailed Specification — описание каждой кнопочки и галочки, каждого поля с указанием допустимых значений, умолчаний. Часто включает даже описание алгоритмов на псевдо-программном языке.
    Поделиться:

    Цитировать

    31.08.2010 в 23:38 # 5723
    Аватар (Vitrimak)
    Vitrimak
    Подписчик
    Состав документов может определяется методологией на проекте. Гляньте RUP , там столько артефактов нужно делать, что мама не горюй. Если на проекте как таковых требований к документации нет, то я бы рекомендовал писать следующие документы (причем в указанной последовательности):
    1) Vision and Scope
    2) User requirements document (URD)
    3) SRS

    Если бизнес заказчика очевиден для команды, то URD можно опускать. Если проект простой, то можно URD объединять с SRS.

    Поделиться:

    Цитировать

    01.09.2010 в 10:56 # 5724
    Ну, собственно, так оно и есть на большинстве проектов — Vision and Scope + SRS :)
    Я бы даже сказал, что в половине случаев — только SRS… и это себя оправдывает.
    Поделиться:

    Цитировать

    20.12.2010 в 16:30 # 5725
    А кто-нибудь сталкивался с документами Business Case и Executive Summary?
    Судя по всему их пишут именно бизнес-аналитики — еще до того, как начать работу над Vision and Scope.
    Может у кого-нибудь есть хорошие шаблоны?
    Поделиться:

    Цитировать

    20.12.2010 в 16:51 # 5726

    А кто-нибудь сталкивался с документами Business Case и Executive Summary?
    Судя по всему их пишут именно бизнес-аналитики — еще до того, как начать работу над Vision and Scope.
    Может у кого-нибудь есть хорошие шаблоны?

    Эмм.. никогда не слышал, чтобы Executive Summary создавался как отдельный документ. Я его писал только как секцию Коммерческого Предложения (Proposal). Сказать, что для него есть шаблон? Ммм.. ну у меня есть некоторые правила и рекомендации по его написанию. А шаблона нет, к сожалению.

    Поделиться:

    Цитировать

    20.12.2010 в 17:14 # 5727
    Да, executive summary — это некое обобщенное и часто употребимое понятие. Это может быть и секция, и отдельный документ. Причем применимость у него абсолютно разная.
    2Юра — а поделись рекомендациями и правилами в контексте твоей применимости.
    2All — а вы писали когда-нибудь по желанию заказчика такой документ?
    Поделиться:

    Цитировать

    24.06.2011 в 15:57 # 5728
    Аватар (Normalnaja)
    Normalnaja
    Подписчик
    Позвою себе вместо Юры предоставить те самые рекомендации по Proposal (т.к. столкнулась сегодня с необходимостью качественного написания КП). http://www.slideshare.net/greesha/laf2010-vedenin
    Простите, если это уже где-то есть на сайте. И отдельное спасибо Юре за шикарную презентацию. Для меня такие вещи на вес золота)))
    Поделиться:

    Цитировать

Показано 12 ответов - от 1 до 12 (всего 12)

Вы должны авторизироваться для ответа в этой теме.