Please enable JavaScript.

Coggle requires JavaScript to display documents.

Бизнес-анализ ИТ-инициатив - Coggle Diagram

- - - - Качество (Quality) — Степень соответствия набора характеристик требованиям.
      - Дефект (Defect) — Недостаток продукта или сервиса, который понижает его качество или отличается от желаемого атрибута, состояния или функционала. См. также дефект требований.
      - Риск (Risk) — Неопределенное событие или условие, которое в случае наступления затронет цели или задачи предложенного изменения.
  - - - Plan-driven подход — направлен на минимизацию неопределенности (риска) и максимальный контроль.
      - Change-driven подход — нацелен на быстрое получение ценности для бизнеса.
    - - Лица, официально уполномоченные принимать решения;
      - Лица, официально уполномоченные блокировать решения;
      - Лица, чьи интересы затрагивают данные решения;
      - Лица, обладающие необходимой информацией или знаниями.
    - - Выбор методов Сбора, Анализа, Спецификации и Проверки, Управления требованиями, Обучения, Управления проектом
        по книге Вигерса (Глава 3)
    - - Разделяется на 2 этапа:
        
        2.5.1. Планирование управления бизнес-анализом
        
        как будет выполняться работа по бизнес-анализу и как будут определяться приоритеты задач;
        
        процесс для предложения изменений в информации для бизнес-анализа;
        
        кто имеет власть и обязанность предлагать изменения и кто должен быть вовлечен в обсуждение изменений;
        
        кто несет ответственность за анализ запросов на изменение;
        
        кто имеет полномочия утвердить изменения;
        
        как изменения будут задокументированы и
        
        донесены до потребителей.
        
        2.5.2. Планирование управлением информацией бизнес-анализа
        
        как информация должна быть организована;
        
        с каким уровнем детализации информация должна быть получена;
        
        любые связи между информацией;
        
        как информация может быть использована в нескольких инициативах и в компании в целом;
        
        как информация должна храниться и как ее получить;
        
        характеристики информации, которая должна быть сохранена.
- - - - Пользовательские требования обычно представляют в виде вариантов применения или пользовательских историй (Use Case ans User Stories).
      - Подробные функциональные и нефункциональные требования к ПО фиксируются в спецификации требований к ПО (SRS) или другом хранилище, таком как средство управления требованиями.
      - Зафиксировать бизнес-требования можно в положении об образе (концепции) и границах (Vision and Scope).
- - - - Требования сводятся в набор, обычно представленный в виде документа
      - Каждый документ должен иметь уникальный номер версии;
      - Версия документа может быть целым числом (Требования 1, Пользовательские требования 54, SRS 12), последовательностью чисел (Требования 1.0, Пользовательские требования 54.1, SRS 12.0.3), датой (SRS 12/08/2016) или текстом (SRS 315a);
        Каждая вер
      - Каждая версия и требование должно иметь историю изменений (дата, редактор, причина);
      - Текущая версия должна быть доступна всем членам
        команды разработки.
    - - дата создания требования;
      - номер текущей версии требования;
      - автор, создавший требование;
      - приоритет;
      - состояние требования;
      - происхождение или источник требования;
      - логическое обоснование требования;
      - номер выпуска или итерации, на которую назначено требование;
      - контактное лицо или ответственный за принятие решений по внесению изменений в требование;
      - метод проверки или критерий приемки.
    - - все изменения требований должны вноситься в соответствии с процессом;
      - нельзя заниматься проектированием или реализовывать неутвержденные изменения, кроме проверки их осуществимости;
      - сам по себе запрос на изменение не гарантирует выполнение этого изменения;
      - содержимое базы данных изменений должно быть видимым для всех заинтересованных в проекте лиц;
    - - анализ влияния изменения необходимо выполнять для каждого изменения;
      - каждое включенное изменение требования должно отслеживаться вплоть до утверждения запроса на это изменение;
      - обоснование каждого утверждения или отклонение запроса на изменение необходимо документировать.
    - - In Progress (Разработка) Бизнес-аналитик работает над требованием;
      - Drafted (Подготовлено) Написана начальная версия требования;
      - Approved (Одобрено) Ключевые заинтересованные в проекте лица согласились с этим требованием, а разработчики ПО обязались реализовать его;
      - Implemented (Реализовано) Код, реализующий требование, разработан, написан и протестирован. ПО, реализующее требование теперь готово для тестирования, рецензирования и другой проверки;
      - Verified (Проверено) Требование удовлетворяет критериями приемки, то есть подтверждено корректное функционирование реализованного требования.
    - - Вперед к требованиям - определяются связи бизнес-целей (пользовательских требований) и требований
      - Назад от требований определяется - связь требования с бизнес-целью
      - Вперед от требований - связь требований с элементами продукта
      - Назад к требованиям - связь элементов продукта с требованиями