Сейчас мы подведем итоги первой лекции курса «Анализ требований к информационным системам», состоящую из четырех модулей, каждый из которых дополнял первоначальное представление об анализе требований и способствовал тому, чтобы вы расценивали этот предмет как междисциплинарный и относились к нему как к комплексной дисциплине, позволяющей применять и развивать разные навыки.
Сегодня мы акцентируем наше внимание на основных моментах, которые необходимо осмыслить и осознать. Каждая лекция будет заканчиваться кратким конспектом, который закрепляет знания и фокусирует внимание на основных данных прошедшей лекции.
Каждая зрелая деятельность характеризуется артефактами. Ценность артефактов обосновывает затраты на проведение деятельности. Анализ требований, как практическая прикладная дисциплина, – не исключение. Основным здесь является результат, то есть артефакт. Каждый артефакт имеет свою целевую аудиторию, формат представления информации и назначения. Для формирования разных артефактов используются разные виды деятельности – это бизнес-анализ или системный анализ. Анализ требований получает на вход информацию, представленную в виде документа, сформированного вокруг какой-то идеи, которая потенциально может принести ценность, и передает ее в виде структурированного реализуемого описания в процессы разработки конкретной функциональности. Требования делятся по категориям. У всех собираемых и формализуемых требований должно быть практическое назначение.
Вокруг требований строят свое развитие многие методы и методологии. Приведем, к примеру, крайне распространенный подход к построению информационной и корпоративной архитектуры предприятия – TOGAF (The Open Group Architecture Framework), представляющий собой метод и инструменты для содействия в принятии, разработке, использовании и поддержке архитектуры предприятия.
В основе TOGAF лежит предмет управления требованиями. Это ядро этого подхода. Все остальные активности проходят через управление требованиями и зависят от того, насколько правильно для предприятия собраны и представлены требования. Управление требованиями взаимосвязано с разработкой и сопровождением концепции архитектуры, бизнес-архитектурой, архитектурой информационных систем, технологической архитектурой предприятия. Оно обосновывает возможности и формирует решения, планирует переход к целевой архитектуре предприятия. С управлением требованиями связаны управление реализацией решения и управление изменениями, которые происходят по ходу реализации целевых процессов и проектов.
Итак, мы подвели итоги лекции 1. В лекции 2 мы рассмотрим анализ требований под углом конкретных методологий разработки информационных систем, поговорим о различиях и общих чертах этапов анализа требований. До встречи!
Лекция подводит итог первому модулю курса, утверждая, что анализ требований следует воспринимать как комплексную междисциплинарную область.
Главный тезис лекции заключается в том, что зрелость деятельности в этой сфере определяется создаваемыми артефактами. Именно артефакты (документы, спецификации) являются конечным результатом, имеющим ценность для конкретной аудитории и оправдывающим затраты на проведение анализа.
Процесс анализа требований описывается как преобразование входной информации (идеи, документа) в структурированное описание, которое передается в разработку. Требования при этом делятся на категории и должны иметь практическую ценность.
В качестве иллюстрации важности требований рассматривается методология TOGAF (архитектура предприятия). В этой методологии управление требованиями является центральным (ядерным) процессом, через который проходят и с которым связаны все остальные этапы построения архитектуры: от бизнес-архитектуры до технологической и управления изменениями.
1. Успех в анализе требований напрямую зависит от умения создавать качественные артефакты, которые несут пользу для бизнеса и разработки.
2. Понимание места требований в более широком контексте (например, в архитектуре предприятия TOGAF) помогает осознать их фундаментальную роль.
3. Задача аналитика — быть «переводчиком» между сырой бизнес-идеей и структурированным техническим заданием.
4. Следующий этап изучения будет посвящен практическому применению анализа требований в различных методологиях разработки.
1. Почему анализ требований называют междисциплинарной дисциплиной?
2. Что такое «артефакт» в контексте анализа требований и чем определяется его ценность?
3. В чем заключается основная трансформация информации в процессе анализа требований (что приходит на «вход» и что получается на «выходе»)?
4. Какую роль играет управление требованиями в методологии TOGAF?
5. С какими разделами архитектуры предприятия (по TOGAF) связано управление требованиями?
