1

Для всех / Re: План изучения готовой ИТ-системы

« : 19 Октября 2016, 22:48:25 »

Приветствую!

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

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

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

2

Системный Анализ и Требования / Re: Требования к дизайну

« : 13 Октября 2016, 17:23:08 »

Можно описывать любую степень детализации, если она нужна по каким-то причинам.
Это больше похоже на требования к реализации 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

Бизнес-анализ и Целеполагание / Re: Как перейти из основн сценария об общих полях к сценарию о заполнении уникальных

« : 30 Сентября 2016, 14:32:11 »

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

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

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

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

Исключения:

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


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

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

8

Вакансии / Re: Требуется главный системный аналитик (локация г. Владимир)

« : 23 Августа 2016, 09:10:37 »

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

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

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

9

Вакансии / Re: Требуется главный системный аналитик (локация г. Владимир)

« : 18 Августа 2016, 21:19:05 »

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

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

10

Системный Анализ и Требования / Re: Давайте поговорим про Use Case и функции. В чем отличия?

« : 15 Июля 2016, 01:00:33 »

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

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

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

11

Системный Анализ и Требования / Давайте поговорим про Use Case и функции. В чем отличия?

« : 13 Июля 2016, 01:05:42 »

Во многих источниках информации указано, что 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

Книги, статьи и ресурсы / Re: Анонс книги Требования для программного обеспечения: Рекомендации по сбору и док

« : 18 Июня 2013, 11:40:36 »

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

14

О Сайте и Форуме / Re: Заявки на новые подразделы форума

« : 28 Марта 2013, 15:24:30 »

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

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

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

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

Ну это ИМХО

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

15

Книги, статьи и ресурсы / Re: Анонс книги Требования для программного обеспечения: Рекомендации по сбору и док

« : 04 Марта 2013, 19:54:40 »

Когда выходит книга?