Please enable JavaScript.

Coggle requires JavaScript to display documents.

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

- - - - Контекстная диаграмма — простая модель анализа, отображающая место новой системы в соответствующей среде. Она определяет границы и интерфейсы между разрабатываемой системой и сущностями, внешними для этой системы, например пользователями, устройствами и прочими информационными системами. Карта экосистемы показывает различные системы в пространстве решения, которые взаимодействуют друг с другом, а также природу их взаимосвязей.
    - - Если разработчики или пользователи не совсем уверены насчет требований, создайте прототип — частичную, возможную или предварительную версию продукта, которая сделает концепции и возможности более осязаемыми. Оценка прототипа поможет разработчикам и пользователям достичь взаимопонимания по решаемой проблеме, а также проверить требования.
    - - Аналитик совместно с разработчиками должен определить, насколько возможно реализовать каждое требование при разумных затратах и с приемлемой производительностью в предполагаемой среде. Это позволяет заинтересованным лицам понять риски, связанные с реализацией каждого требования, включая конфликты с другими требованиями, зависимость от внешних факторов и препятствия технического характера. Технически нереализуемые или очень дорогие в реализации требования можно попытаться упростить и в таком виде включить в проект для достижения бизнес-целей.
    - - Очень важно определить приоритеты требований, чтобы быть уверенным, что команда реализует самую важную и своевременную функциональность в первую очередь. Воспользуйтесь аналитическим подходом и определите относительные приоритеты реализации функций продукта, решаемых задач, пользовательских историй или отдельных требований. На основании приоритетов установите, в какой версии будет реализована та или иная функция или набор требований. В ходе работы над проектом периодически корректируйте приоритеты в соответствии с потребностями клиента, условиями рынка и бизнес-целями.
    - - В нем соберите определения всех элементов и структур данных, связанных с системой, что позволит всем участникам проекта использовать согласованные определения данных. На стадии работы над требованиями словарь должен содержать определения элементов данных, относящихся к предметной области, чтобы клиентам и разработчикам было проще общаться.
    - - Модель анализа представляет собой диаграмму, которая визуально отображает требования, в отличие от текстового представления списка функциональных требований. Модели позволяют выявить некорректные, несогласованные, отсутствующие и избыточные требования. К таким моделям относятся диаграммы потоков данных, диаграммы «сущность-связь», диаграммы перехода состояний, таблицы состояний, карты диалоговых окон, деревья решений и другие
    - - Во всех программных системах существуют связи с другими частями, реализованные как внешние интерфейсы. Информационные системы имеют пользовательские интерфейсы и часто обмениваются данными с другими программными системами. Встроенные системы обеспечивают связь между программными и аппаратными компонентами. В приложениях с подключением к сети есть коммуникационные интерфейсы. Анализ всего этого позволит обеспечить гладкую интеграцию вашего приложения в среду.
    - - Требования к сложному продукту, включающему несколько подсистем, следует соразмерно распределять между программными, аппаратными и операторскими подсистемами и компонентами. В качестве примера такого продукта можно привести систему доступа для защиты здания, которая включает магнитные или оптические бейджи, сканеры, видеокамеры и регистраторы, дверные замки и охранников
- - - - Определение источников требований
        
        Присвоение уникальных идентификаторов
        
        Документирование бизнес-правил
        
        Определение нефункциональных требований
        
        Можно реализовать решение, которое делает ровно то, что ожидается, но не реализует ожиданий пользователей в плане качества. Чтобы избежать подобной проблемы, нужно выйти за рамки обсуждения функциональности, чтобы понять характеристики качества, которые важны для успеха проекта. К этим характеристикам относятся производительность, надежность, удобство использования, возможность внесения изменений и многое другое. Информация от клиента об относительной важности эти атрибутов качества позволяет разработчику принимать соответствующие проектные решения. Также нужно указать требования внешних интерфейсов, ограничения дизайна и реализации, проблемы интернационализации и другие нефункциональные требования.
        
        К бизнес-правилам относятся корпоративные политики, правительственные распоряжения и алгоритмы вычислений. Ведите список бизнес-правил отдельно от требований проекта, поскольку правила обычно существуют вне рамок конкретного проекта. То есть бизнес-правила нужно рассматривать как актив уровня предприятия, а не проекта. Для выполнения некоторых приходится создавать реализующие их функциональные требования, и поэтому необходимо определить связь между этими требованиями и соответствующими правилами.
        
        Выработайте соглашение о присвоении уникальных идентификаторов требованиям. Соглашение должно обеспечивать возможность дополнения, удаления и изменения требований. Присвоение идентификаторов позволяет отслеживать требования и фиксировать вносимые изменения.
        
        Чтобы гарантировать, что все заинтересованные лица понимают, зачем нужно то или иное требование, выявите источники всех требований. Это может быть вариант использования или другая информация от пользователей, системное требование высокого уровня или бизнес-правило. Указав всех лиц, заинтересованных в каждом требовании, вы будете знать, к кому обратиться при поступлении запроса на изменение. Источники требований устанавливают на основе связей или определяют для этой цели атрибут требования.
      - Создайте стандартные шаблоны для документирования требований к ПО в вашей организации, такие как документ концепции и границ в главе 5, шаблон варианта использования в главе 8 и шаблон SRS в главе 10. Шаблон предоставляет согласованную структуру, позволяющую фиксировать описания разной информации, касающейся требований. Даже если вы не храните требования в традиционной документарной форме, шаблон напомнит вам о разных видах информации требований, которые нужно собрать и записать.
- - - - Определение критериев приемки
        
        Моделирование требований
        
        Моделирование это следующий уровень после прототипов, который позволяет аналитику в процессе взаимодействия с пользователями быстро построить макет системы. Пользователи могут работать с моделью системы, выбирая дизайн и проверяя требования до того, как они застынут в коде. Моделирование не заменяет вдумчивого выявления и анализа требований, но является мощным вспомогательным средством.
        
        Предложите пользователям описать, как они собираются определять соответствие продукта своим потребностям и его пригодность к работе. Критерии приемки сочетают в себе прохождение продуктом приемочных тестов, основанных на требованиях, удовлетворение определенным нефункциональным требованиям, отслеживание открытых дефектов и проблем, наличие инфраструктуры и обучения, готовых для успешного развертывания и многое другое.
      - Тесты составляют альтернативное представление требований. При написании тестов приходится задумываться, как определить, что ожидаемая функциональность реализована правильно. Создавайте тесты на основе пользовательских требований для документирования ожидаемого поведения продукта в определенных условиях. Пройдите тесты с клиентами, чтобы убедиться, что они отражают ожидания пользователей. Свяжите тесты с функциональными требованиями, чтобы убедиться, что ни одно требование не было упущено и что каждому соответствует тест. Используйте тесты для проверки правильности моделей анализа и прототипов. В проектах гибкой разработки часто создают приемочные тесты вместо подробных функциональных требований.