Бизнес аналитика функциональные требования

1.1.Настоящая должностная определяет права, ответственность и должностные обязанности бизнес-аналитика _____________________ (далее – «предприятие»).

1.2.Бизнес-аналитик принимается на работу и увольняется по приказу руководителя организации по представлению начальника отдела.

1.3.Бизнес-аналитик находится в подчинении у начальника отдела.

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

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

1.6.В своей деятельности бизнес-аналитик руководствуется действующим законодательством, касающимся его деятельности:

-стандартом организации по регламентации, описанию, и внутреннему аудиту бизнес-процессов;

-утвержденным действующим описанием системы бизнес-процессов организации;

-приказами и распоряжениями руководства организации по вопросам анализа и оптимизации бизнес-процессов, а также касающиеся общей организации деятельности сотрудников компании;

-правилами внутреннего трудового распорядка;

-нормами и правилами охраны труда;

-правилами пожарной безопасности;

-данной должностной инструкцией.

1.7.Бизнес-аналитик должен знать:

-Федеральный закон от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании»;

-ГОСТ Р ИСО 9004-2001 «Системы менеджмента качества. Рекомендации по улучшению деятельности»;

-ГОСТ Р ИСО 9001-2001 «Системы менеджмента качества. Основные положения и словарь»;

-ГОСТ Р ИСО 9001-2001 «Системы менеджмента качества. Требования»;

-основы теории организации;

-основы управления персоналом;

-основы маркетинга и менеджмента;

-основы рыночной экономики;

-правовые аспекты бизнес-анализа и управления проектами; – основы законодательства об интеллектуальной собственности;

-внутрикорпоративное бюджетирование и управленческий учет;

-локальные нормативные акты организации, ее стратегию;

-структуру компании, направления ее деятельности, распределение обязанностей между высшими должностными лицами компании;

-действующую утвержденную бизнес-процессную модель функционирования компании;

-современное программное обеспечение;

-возможности применения программных продуктов для выполнения работ по анализу и оптимизации бизнес-процессов;

-правила оформления и проведения презентаций;

-персональный компьютер на уровне опытного пользователя;

-этику делового общения;

-инструкции и положения, определяющие порядок взаимодействия подразделений компании;

-стандарты предприятия по описанию, регламентации и внутреннему аудиту бизнес-процессов;

-приказы и распоряжения руководства организации по вопросам анализа и оптимизации бизнес-процессов;

-передовой зарубежный и отечественный опыт совершенствования системы менеджмента организаций;

-нормы и правила охраны труда;

-правила пожарной безопасности.

1.8. Бизнес-аналитик должен уметь:

-использовать в работе программы графического отображения аналитической информации;

-пользоваться корпоративными базами данных.

2. Должностные обязанности

2.1.Составлять план интервью и перечень ресурсов, необходимых для проведения моделирования новых бизнес-процессов.

2.2.Подготавливать календарные планы работ по моделированию, анализу и оптимизации бизнес-процессов и его согласование с непосредственным руководителем и руководством организации.

2.3.Проводить процедуры обследования бизнес-процессов.

2.4.Осуществлять моделирование, оптимизацию и анализ бизнес-процессов с использованием принятых в организации инструментальных средств моделирования.

2.5.Формировать общий аналитический отчет после проведения анализа бизнес-процессов в виде аналитических таблиц и текстовых комментариев.

2.6.Разрабатывать структуру критериев оценки эффективности моделируемых бизнес-процессов и функций.

2.7.Осуществлять подготовку рекомендаций по внедрению оптимизированных бизнес-процессов и изменению организационной структуры.

2.8.Контролировать процесс внедрения изменений в КИС, в соответствии с оптимизированными бизнес-процессами.

2.9.Осуществлять описание оптимизированных бизнес-процессов.

2.10.Участвовать в написании технического задания на внесение изменений в КИС в соответствии с оптимизированными бизнес-процессами.

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

2.12.Эффективно выполнять все возложенные на него обязанности.

2.13.Своевременно предоставлять достоверную информацию, касающуюся анализа протекающих в организации бизнес-процессов, их оптимизации.

2.14.Контролировать соблюдение плановых сроков и прочих условий выполнения возложенных на него проектов.

2.15.Выполнять иные поручения руководства компании, в рамках действующей должностной инструкции.

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

2.17.Проводить презентацию результатов работы по оптимизации бизнес-процессов.

2.18.Принимать участие в проведении обучения сотрудников компании работе в инструментальной среде моделирования бизнес-процессов, в условиях оптимизированных бизнес-процессов.

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

2.20.Предлагать рекомендации по внедрению новых технологий оптимизации бизнес-процессов.

2.21.Разрабатывать демонстрационные материалы, требующиеся для проведения презентации бизнес-процессов.

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

2.23.Обеспечивать выполнение политики компании в области качества в рамках своей компетенции.

2.24.Обеспечивать функционирование в компании системы управления качеством в рамках своей компетенции.

2.25.Самостоятельно определять необходимость и осуществлять корректирующие и предупреждающие мероприятия в рамках настоящей инструкции.

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

3. Права

3.1.При возникновении необходимости выезжать в служебные командировки.

3.2.Осуществлять информационное взаимодействие со всеми должностными лицами всех структурных подразделений организации.

3.3.Проводить опрос или интервью, анкетирование должностных лиц компании с целью сбора необходимой информации, проведения анализа и оптимизации бизнес-процессов, определения недостатков существующей системы бизнес-процессов, изучения потребности в ее дальнейшем совершенствовании.

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

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

4. Ответственность

Бизнес-аналитик ответственен за:

4.1.Несвоевременное представление сведений и отчетности, установленной в организации.

4.2.Несоблюдение Правил внутреннего трудового распорядка.

4.3.Несоблюдение правил техники безопасности, охраны труда и противопожарной безопасности.

4.3.Невыполнение или недолжное выполнение своих должностных обязанностей, предусмотренных настоящей должностной инструкцией.

4.4.Предоставление своему руководителю и руководству организации недостоверной информации о соответствии качества бизнес-процессов, протекающих в организации, установленным соответствующим показателям.

4.5.Разглашение информации, являющейся коммерческой и иной охраняемой законом тайной.

4.6.Причинение предприятию материального ущерба.

Руководитель структурного подразделения: _____________ __________________

(подпись) (фамилия, инициалы)

С инструкцией ознакомлен,

один экземпляр получил: _____________ __________________

(подпись) (фамилия, инициалы)

Источник: www.kaus-group.ru

Становление аналитика

Примечание из будущего:
Дописав до п. 5 я понял, что в задуманном вначале объеме материал получается слишком большой. Пятый пункт заслуживает отдельной статьи, или даже нескольких. Это дело будущего. В данном посте затрону эту тему лишь поверхностно.

Короткое введение

Так же число книг по IT-аналитике заметно меньше, чем по другим IT-дисциплинам (буду рад ошибиться по данному вопросу — возможно, какие-то важные книги в этой области прошли мимо меня). Даже на Хабре статьи непосредственно по аналитике за последние пару лет можно пересчитать чуть ли не по пальцам одной руки (1, 2, 3, 4). Ну да имеем что имеем. В конце концов, все в наших руках.

Аналитики — кто это?

Системные аналитики
Бизнес-аналитики (данная роль относится не только к ИТ).

Главные задачи системного аналитика: сбор, анализ, формализация и согласование требований к системе. Другими словами, управление требованиями на протяжении всего их жизненного цикла. Основной, хотя обычно не единственный, документ на выходе – техническое задание или его аналог. На этом остановимся подробнее ниже.
Главные задачи бизнес-аналитика – изучение, описание, анализ и (при необходимости) реинжиниринг бизнес-процессов. Основной документ на выходе – описание бизнес-процессов As Is (обязательно) и To Be (при необходимости).

Краткое техническое отступление

По уровню:
Бизнес-требования
Самые высокоуровневые требования, которые определяют цели создания ПО. Примерами таких требований могут быть достижение 20%-го сокращения издержек или повышение качества управления (например, за счет возможности оперативного формирования отчетности).
Данные требования обычно описываются в отдельном документе — «Видении проекта» (Vision) или «Бизнес-требованиях», который так же включает определение основных ролей будущих пользователей Системы и перечисление ее основных сценариев использования. Если такого выделенного документа нет, то часто все это включается в техническое задание или его аналог.

Требования пользователей
Они определяют набор пользовательских задач, которые должна решать Система, с описанием сценариев решения данных задач. Требования пользователей обычно представляются в виде перечисления вариантов использования Системы и взаимосвязей между ними (как правило, в виде Use-case диаграммы языка UML).
Сами варианты использования описывается в виде составляющих их последовательностей действий со всеми возможными пред/постусловиями и ветвлениями. Часто описание является текстовым (эта тема хорошо описана в книге Алистера Коберна » Современные методы описания функциональных требований к системам «).

Функциональные требования
Детально описывают все элементы функционала, который должен быть непосредственно реализован в Системе, чтобы обеспечить возможность выполнения всех сценариев использования, описанных в Требованиях пользователей.
Функциональные требования являются наиболее детализированными. Они описывают, в том числе, входные/выходные данные и их проверки, алгоритмы обработки данных и элементы пользовательского интерфейса (без дизайна).
Как правило, данные требования оформляются в виде отдельного документа («Технического задания» и т.д.). В этом же документе детализируются сценарии использования Системы (Требования пользователей), к которым обычно и привязываются функциональные требования.
Пример функционального требования: «По клику на кнопке на форме должно отображаться модальное диалоговое окно, содержащее ».

По типу:
Функциональные требования
Описывают непосредственно функционал, реализуемый Системой (пример приведен выше в описании классификации требований по их уровню в пункте «Функциональные требования»);

Нефункциональные требования
Описывают характеристики системы и ее окружения, а так же накладываемые ограничения.
Примерами нефункциональных требований могут служить ограничения на поддерживаемые разрабатываемой Системой аппаратные платформы и операционные системы, а так же требования к производительности, к безопасности и т.д.

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

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

Произойдет смешивание в одном документе результатов различных типов работ, выполняемых разными людьми (аналитиком и архитектором);
Срок сдачи технического задания будет увеличен, т.к. для его завершения потребуются некоторые результаты этапа проектирования.
Результаты этапа проектирования эффективнее оформлять в отдельном документе, описывающем архитектуру Системы.

Сначала выявляются цели создания Системы (бизнес-требования). Может сложиться впечатление, что фиксация данных требований не является обязательной для разработки. Но в этом случае у Исполнителя не будет возможности контролировать соответствие разработанной Системы тем целям, для которых она создавалась, а так же – возможности устанавливать семантические зависимости между целями разработки системы и сценариями ее использования;
Далее определяются роли пользователей Системы (как людей, так и других программных систем). После этого выявляются и описываются сценарии использования Системы каждой из данных ролей. Так формируются Требования пользователей.
Далее разрабатывается полный набор требований к функционалу Системы таким образом, чтобы данный функционал позволял выполнить все сценарии, описанные в Требованиях пользователей. Так же фиксируются ограничения для Системы и параметры среды ее функционирования.

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

Исполнитель понимает, что требования не всегда могут быть сформулированы Заказчиком полностью и корректно на начальных стадиях проекта. Соответственно, изменения в требованиях по ходу проекта допускаются.
Заказчик понимает, что изменение требований влечет за собой увеличение трудозатрат и сроков сдачи продукта.

ко всем относящимся к разработке ПО материалам;
ко всем ключевым носителям информации и лицам, обладающим требуемыми полномочиями

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

Зачем нужны аналитики? (привет, кэп)

До сих пор от некоторых разработчиков (хотя сейчас уже очень редко) можно услышать, что аналитики (равно как руководители проектов, менеджеры по продукту и т.д.) не только не вносят полезный вклад в дело, но и просто «мешаются под ногами». Лезут, понимаешь, со своими процессами, бумажками и прочей бюрократией — не дают простому девелоперу спокойно работать (смайл).
Излишняя бюрократизация конечно зло, но реализовать большой проект «на коленке», да еще усилиями специалистов лишь одного профиля в современном мире нереально. Никто не оспаривает важную роль разработчиков, но будут ли они продавать, оформлять кучу сопутствующей документации, пытаться понять своеобразный язык заказчиков и т.д.? Позволю себе предположить, что вряд ли многих из них это заинтересует.

Выслушать заказчика. Иногда уже это бывает непросто – некоторые способны говорить часами буквально ни о чем, и не всегда легко удается перевести общение в конструктив. Тут ключевым является навык активного слушания.
Понять иногда «птичий» язык заказчика и сформулировать его требования понятным языком, полно и без противоречий. Т.е. превратить поток сознания клиента в набор формализованных требований.
В некоторых случаях, когда заказчик «сам не знает, чего хочет», предложить оптимальное решение или «подвести» к нему самого заказчика;
Проанализировать влияния новых требований на существующую архитектуру и функционал. Здесь часто будут полезны консультации архитектора.
Задокументировать требования в виде документа или набора документов в требуемом виде. Затем согласовать их и утвердить.
Завести талоны в системе такс-трекинга и в дальнейшем отслеживать их нелегкую судьбу. Завести может и архитектор или dev. lead по ТЗ, но чаще это делает аналитик.
Осуществлять верхнеуровневый контроль соответствия реализованного функционала требованиям.
Управлять изменениями требований.
Осуществлять все взаимодействие с заказчиками по вопросам требований.
Часто – участвовать в сдаче продукта заказчику.

Кто и как становится аналитиком (по трудовой)?

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

На практике, в аналитиков часто вырастают успешные тестировщики и, иногда, технические писатели. Так же нередко аналитиками становятся разработчики: кто-то из-за того, что понял, что разработка – это не его, кто-то действительно хочет быть аналитиком, для кого-то это лишь более короткий путь в ПМ-ы.
Всего один раз встречал аналитика, выросшего из системного администратора. Здесь не возьмусь делать выводы – опять же слишком маленькая выборка. Так же знаю одного ПМ-а, перешедшего в аналитики, но это скорее исключение.

Что должен знать/уметь аналитик и как этому научиться?

Читавшие упомянутую выше книгу «Путь аналитика. Практическое руководство IT-специалиста», особенно те коллеги, которые только начинают свою карьеру в ИТ, наверняка прифигели несколько удивились тому объему знаний и умений, которые автор предлагает освоить несчастному читателю. Если вкратце, то следуя данной книге, аналитик должен освоить весь накопленный человечеством опыт в данной области со всеми методологиями, техниками и инструментами, а заодно и в максимальной степени обладать всеми положительными личными качествами, присущими человеческим существам.

На мой скромный взгляд, там все-таки описан некий сферический аналитик в вакууме идеал, к которому можно (но не факт, что нужно) стремиться. Фанатичное стремление овладеть сразу всеми знаниями и навыками приведет, разве что, в Кащенко. Готов поспорить на бутылку Talisker 16 y.o., (с кем-нибудь одним, а то же, неровен час, найдутся Шелдоны (смайл)), что в природе нет ни одного человека, полностью соответствующего продвигаемому в книге образу (со всем описанным набором знаний и навыков), включая самого автора книги.
Не говорю, что предложенные там навыки не важны, просто надо уметь расставлять приоритеты. К слову, для аналитика это ключевое качество. И, что бы я тут не писал, книгу эту несомненно стоит прочитать.

о жизненном цикле ПО;
о нескольких ключевых методологиях разработки (waterfall, RUP, что-то из Agile, лучше бы Scrum, для гос. заказчиков – ГОСТ 19 (на программы) и 34 (на автоматизированные системы));
об основах системного анализа (Вигерс отлично подойдет);
о нотациях и инструментах проектирования и моделирования (самые востребованные на рынке, пожалуй: Sparx Enterprise Architect и Rational Rose; и UML/Aris/IDEF0 и IDEF3);
о теории реляционных БД;
и т.д.

Заключение

Уважаемые коллеги, я буду искренне рад, если данный пост был полезен. Готов обсудить любые возникшие вопросы, или подробнее осветить, насколько смогу, заинтересовавшие темы. Если Вы с чем-то не согласны, пожалуйста, пишите. Давайте учиться. И да здравствует Lifelong learning!

системный анализ
бизнес-анализ
управление требованиями

Источник: habr.com

Владимир Бычко об управлении проектами

Ранее я писал, какие вопросы задают на собеседовании на project manager-а. Вот вопросы и ответы для бизнес-аналитика.

Какой основной инструмент бизнес-аналитика?

Единственный правильный ответ — критический ум. Перечисление программных продуктов, при помощи которых вы пишете требования, будет ошибочным.

Какие знаете методологии разработки?

Классический проектный подход (PMI), скрам, канбан. В принципе, этого достаточно.

Какие бывают требования?

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

Также можно рассказать про уровни требований:

бизнес-правила,
бизнес-требования,
пользовательские требования,
требования к продукту.

Также можно рассказать про типы требований:

ограничения,
требования к графическим интерфейсам,
требования к данным.

Какими свойствами обладают хорошие требования?

завершённость,
последовательность,
правильность,
абстрактность,
осуществимость,
измеримость,
необходимость,
прослеживаемость,
однозначность.

Какие существуют методы сбора требований?

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

Как строится процесс работы с требованиями?

собрать,
задокументировать,
проанализировать,
управлять ими.

Что такое бизнес-требования?

Нужно разделять бизнес-цели и бизнес-требования. Бизнес-цель — то, чего хочет добиться бизнес. Бизнес-требование — как он хочет этого добиться.

Как приоритизируются требования?

Что такое «спецификация»?

Документ, наиболее полно описывающий функции и свойства системы.

Что такое Use Case?

Вариант использования. Пример поведения системы при взаимодействии с окружающей средой.

Что такое User Story?

Способ описания требований на естественном языке.

Чем юзкейс отличается от юзерстори?

Сториз, они про потребность пользователя. Raw user needs.
Сториз пишутся человеческим языком = легко читаются и бизнесом
и разработчиками. Express understanding of User needs.
Юзкейсы же про поведение, которое вы встроите в продукт, чтобы удовлетворить эти потребности. What the software needs to do.
Написание Юзкейсов это designing a functional solution.

Какова роль аналитика в команде?

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

Что делать при конфликте внутри команды?

Если конфликт вызван неоднозначностью требований, следует понять, в чём неоднозначность и переписать требования.

Кто оценивает трудоёмкость задач?

Только команда совместными усилиями.

Кто пишет тест-план и тест-кейсы?

Какие нотации для описания бизнес-процессов вы используете?

Что знаете про UML? Для чего он используется?

Тут нужно рассказать, какие диаграммы знаете и какие они бывают. В частности, диаграммы бывают структурные и поведенческие.

Какие инструменты моделирования бизнес-процессов вы знаете?

Здесь нужно рассказать, какой софт вы используете для построения этих диаграмм. Visio, draw.io, Camunda.

Какие инструменты проектирования интерфейсов вы используете?

Figma, Axure, Balsamiq.

Должны ли мы вам оплачивать какое-либо платное ПО для работы?

Существует большое количество опенсорсного софта, покрывающего все потребности.

Что такое глоссарий, зачем он нужен, можно ли без него обойтись?

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

Знаете ли вы SQL и на каком уровне?

Достаточно уметь строить простые запросы.

Что такое ООП?

Методология разработки, базирующаяся на объектах, являющихся экземплярами классов.

С какими системами управления проектами знакомы?

Крайне желательно уметь обращаться с Джирой и Конфлю.

Вот описание кейса. Что должно войти в MVP?

MVP — это продукт, который в минимальном объёме решает потребность бизнеса. Как правило, это первая версия продукта, содержащая одну фичу, решающую конкретную бизнес-проблему.

Вот фича. Напишите юзер стори и критерии приёмки.

Юзер стори — это описание функциональности на естественном языке. Как правило, формулируется в формате «Я как хочу , чтобы ». Критерии приёмки — это требования к элементу бэклога, достаточные для того, чтобы этот элемент был принят заказчиком.

Найдите ошибку в спецификации.

не указан профиль пользователя. Неясно, кто должен совершить действие.
неизвестный элемент глоссария объясняется через другой неизвестный элемент. Сепулька — предмет для сепкулькации. Сепулькация — действие, осуществляемое при помощи сепульки.
нарушен один из критериев, которым должны соответствовать требования. Например, «цвет — красный» вместо кода цвета.

Что такое RACI-матрица?

Это матрица распределения ответственности.

R – Responsible (исполняет),
A – Accountable (несет ответственность),
C – Consult before doing (консультирует до исполнения),
I – Inform after doing (оповещается после исполнения).

Как вы изобразите жизненный путь объекта?

При помощи диаграммы состояний (диаграммы конечного автомата).

До какой степени нужно декомпозировать юзер стори?

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

Какие подходы к UX вы используете?

Чем фича отличается от элемента бэклога?

Фича описывает функциональность. Элементом бэклога (кроме фичи) может быть баг или технический долг.

В чём отличие скрам от канбан?

В канбане итерации не ограничены строго по времени. В канбане отсутствуют обязательные церемонии.

До какой степени детализации моделировать бизнес-процессы?

До такой степени, до которой возможно понятно объяснить их команде.

Как понять, что мы не упустили никаких юзер стори?

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

Чем верификация отличается от валидации?

Верификация — проверка на соответствие требованиям, валидация — проверка на соответствие ожиданиям заказчика.

Чем авторизация отличается от аутентификации?

Аутентификация — процедура проверки подлинности, например проверка подлинности пользователя путем сравнения введенного им пароля с паролем, сохраненным в базе данных. Авторизация — предоставление определенному лицу или группе лиц прав на выполнение определенных действий.

Почему базы данных называются реляционными?

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

Чем left join отличается от inner join?

inner join возвращает строки, содержащие совпадения в обоих таблицах, left join — все строки из левой таблицы, даже если в правой нет совпадений.

Что такое foreign key (внешний ключ)?

Внешний ключ SQL — это ключ, используемый для объединения двух таблиц. Иногда его также называют ссылочным ключом. Внешний ключ — это столбец или комбинация столбцов, значения которых соответствуют Первичному ключу в другой таблице.

Чем Saas отличается от Paas?

При Paas клиент получает инфраструктуру и готовое для разработки приложений ПО. В случае в Saas клиент получает готовое ПО, развёрнутое в облаке.

Что такое SSO?

Это схема, при которой пользователь переходит из одного раздела или компонента ПО в другой без повторной аутентификации.

Назовите элементы архитектуры веб-приложения.

Клиент, сервер, база данных.

Что такое API?

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

Чем GET отличается от POST?

Основное отличие в способе передачи данных. В get-запросе данные передаются в url, а в post-запросе — в теле запроса.

Источник: bychko.ru