Форум Сообщества Аналитиков

×


Просмотр сообщений

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


Сообщения - Elder

Страницы: 1 2 3 »
1
Приветствую!

А какова цель изучения? Он будет работать в ней как пользователь или будет вовлечен в процесс доработки этой системы в будущем?

Если 2й вариант, то:
* Изучить назначение и цели системы
* Изучить типы пользователей системы
* Изучить или составить юз-кейс диаграмму по основным функциям для пользователей, воспроизвести все юз-кейсы в реальной системе
* Изучить или составить схему функциональных подсистем, раз система большая;
* Изучить или составить ERD, понимать принципы хранения всех сущностей (знать что, где и в каком виде храниться)

Думаю, для начала должно хватить.

2
Можно описывать любую степень детализации, если она нужна по каким-то причинам.
Это больше похоже на требования к реализации UI.

И тут главное отделить функциональное описание от требований к реализации, чтобы не загружать этими избыточными требованиями саму суть документа.
Т.е. я бы вынес такие описания в самый-самый конец документа, где привел бы список используемых элементов UI и требования к их реализации/поведению.

3
Примеры / Re: Нет ни малейшего понимания.
« : 13 Октября 2016, 17:18:05 »
В ближайшей перспективе нет. Буду представлять в виде user stories и описанием в хранилище знаний.
Интересно, почитать где-то про прототипирование можно?

Для общего ознакомления советую статью: http://www.bridging-the-gap.com/using-wireframes-or-prototypes-to-elicit-analyze-and-validate-software-requirements/
Так же в книжке Вигерса есть отдельная глава, посвященная прототипам: "Прототипы как средство снижения риска".

Обзор инструментов прототипирования можно поискать на хабре или в гугле.

4
Примеры / Re: Нет ни малейшего понимания.
« : 13 Октября 2016, 17:08:28 »
Для полноты описания рекомендую в состав историй включать сценарии:
http://2015.secr.ru/lang/ru/program/submitted-presentations/bdd-by-example-russian-bylina-written-in-gherkin-language

Сценарии в формате BDD используются в первую очередь для автоматизации проверки Acceptance Criteria у User Story.

Если у вас используется автоматизация тестов, то тогда это действительно довольно удобный инструмент.
Если автоматизации нет, то сценарии можно использовать в некоторых случаях, для пояснения сложных сценариев работы.

5
Примеры / Re: Нет ни малейшего понимания.
« : 12 Октября 2016, 12:30:20 »
Любая крайность - губительна.

Если вы работаете по модели Agile, то и хранение знаний (требований) выстраивайте по этой модели.

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

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

С дизайнером проще всего будет общаться с помощью макетов экранов и описания требований к интерфейсу, тут UML вовсе не обязателен.

6
Работа / Re: Доработка use-case.
« : 06 Октября 2016, 00:00:09 »
Приветствую!

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




7
Приветствую.

А зачем так все усложнять? Здесь очень простой ВИ напрашивается:

ВИ: Ввод паспортных данных авто
Предусловия: Пользователь авторизован и находится в режиме ввода паспортных данных авто
  • Пользователь заполняет реквизиты
  • Пользователь сохраняет введенные данные
  • Система проверяет заполнение обязательных реквизитов
  • Данные сохраняются в систему

Исключения:

   3.1 Не все обязательные реквизиты заполнены
   3.2 Система уведомляет пользователя, какие реквизиты необходимо заполнить
   3.3 Переход к шагу 1


Правила: Разные типы автомобилей могут содержать разные реквизиты, которые обязательны к заполнению.

А дальше прикрепляете к ВИ табличку (Data Dictionary), где описываете список всех возможных полей и проставляете обязательность их заполнения в зависимости от типа авто.

8
IDEF0 (ICAM) был и остается одной из лучших процессных нотаций. В частности он является основной процессной нотацией 3SL Cradle.

На мой взляд владение аналитиком этой нотацией гарантирует прекрасные навыки выделения границ процессов и их декомпозиции.

А вы заметили, что по тексту объявления требуется аналитик требований, а ни аналитик бизнес-процессов? Речь идет про истории пользователей, тест-кейсы и т.д., т.е. те вещи, где IDEF абсолютно бесполезна.

9
Вот откуда все берут это требование знание IDEF?
Вы хотя бы одну современную систему по IDEF пробовали построить?

Думаю, вы даже не понимаете, что это такое и зачем оно нужно, а тем более место данной методологии в проектировании ПО..

10
2  Denis Beskov, 2 Григорий Печенкин - большое спасибо за столь развернутые ответы.

Действительно UC "Выбрать макет" не имеет смысла сам по себе. Но с другой стороны, соглашусь с Григорием, что он может сильно эволюционировать (я думал про подключение функционала импорта сторонних макетов, например) и вырасти в нечто большее, чем просто функция.

Все-таки я убедился, что нет единых правил что считать UC, а что - нет. Если я хочу акцентировать внимание разработчиков на том, что "Выбрать макет" это самостоятельный кусок функционала, то выходит, что могу добавлять его на диаграмму в качестве UC.

11
Во многих источниках информации указано, что use case - это некая цель, которую желает достич пользователь с помощью системы.
Также существует понятие, что use case <> функция системы. Хм.. тут уже сложнее. Как отделить функцию от цели и, собственно, от use case?

Используем для нашего анализа конкретный пример.
Пусть, в некой абстрактной системе, у нас будет use case "Создать веб-страницу".

Основной поток UC:

[ДЛ = Действующее лицо
Макет = HTML-шаблон, состоящий из нескольких блоков. В блоках могут выводится текст и изображения]

1. ДЛ переходит к созданию веб-страницы
2. ДЛ задает имя веб-страницы
3. Система проверяет имя на уникальность
4. ДЛ выбирает макет страницы из предустановленного перечня макетов
5. ДЛ формирует контент из текста и изображений, для каждой секции макета
6. ДЛ сохраняет веб-страницу
7. Система перенаправляет ДЛ на страницу списка созданных веб-страниц
8. Сохраненная веб-страница отображается в списке

В данном UC пункт 4 - является отдельным use case или функцией? Ведь это всего-лишь шаг, который необходим для достижения цели "Создать веб-страницу".
Ведь у пользователя нет цели "Выбрать макет", как таковой.

Итак, мы определили, что это функциональное требование - "Система должна позволить выбрать макет веб-страницы из предопределенного списка макетов".
Но в тоже время одно из определений use case говорит нам, что если мы можем вынести описание функции в список фич продукта, то это точно use case.
Если подумать, то выбор макета для веб-страницы вполне достойно этого (т.к. одно дело создавать веб-страницы с одним и тем же расположением блоков, и совсем другое - иметь возможность выбрать макет из некоего перечня).
Итак ... "Выбрать макет" это все-таки use case.. или опять нет  :-\?

Давайте попробуем описать его основной поток:

Предусловие: ДЛ находится на этапе выбора макета веб-страницы
1. ДЛ выбирает макет страницы из предустановленного перечня макетов
2. ДЛ переходит к шагу формирования контента

Получился неочень-то информативный use case, что опять смущает.

Итого:
1. Хотелось бы услышать ваше мнение и рассуждения по поводу явлется-ли "Выбрать макет" функцией или UC в данном случае?
2. Как вы определяете, что есть use case? На основании каких признаков?

12
Вакансии / Re: Аналитик-консультант 1С, Мск
« : 23 Сентября 2013, 19:52:08 »
Удаленно кандидатов рассматриваете?

3+ года опыта разработчиком 1С (знание всех основных конфигураций УТ, УПП, БП и т.д., управляемые формы, знание конвертации данных, СКД и др.)

2 года опыта работы на позиции системного/бизнес аналитика (организовывал сбор требований и разработку документации по веб-проектам, разработке мобильных приложений (не игр), разработке ПО для настольных систем).

13
А на Украине можно как-то эту книгу приобрести?

14
Приветствую.

Есть предложение сделать раздел - Предметная область
Сделать темы с возможность модерирования первого поста и в нем хранить ссылки на литературу по предметной области, а в теме обсуждать вопросы.

Например предметки которые можно выделить:
Банки
Управление проектами
Бухгалтерия (1С)
ITIL
и т.п.

Меня вот интересуют в данный момент документы по функционированию банков + бухгалтерия.

Ну это ИМХО :)

Отличная идея, как по мне.

Страницы: 1 2 3 »