Очень частый вопрос, про который вам не расскажут ни в каких материалах по подготовке к собеседованиям. Поэтому он обычно возникает уже у работающих аналитиков: как составить документ требований?
А может быть, вы занимали какую-то другую роль, и теперь вам нужно требования писать. Ну и в принципе часто оказывается, что люди не особо понимают, как документы составлять. Для документов, в которых нужно кого-нибудь в чем-нибудь убедить, есть книга "Принцип пирамиды Минто", авторства Барбары Минто.
Для документов системного анализа она тоже подходит, но давайте раскрою чуть конкретнее. Мы, на самом деле, этими документами хотим убедить заказчиков, что: - система/доработка нужна; - она решит проблему заказчика; - она гораздо сложнее, чем думал заказчик (поэтому нужно дать больше денег).
Итак, принципы пирамиды Куприянова:
1. Документ строится от общего к частному (от бизнес-понятий и целей к деталям реализации) и от знакомого к новому (от того, что уже есть, к тому, что будет). Что знакомо вашим заказчикам? Они сами и их задачи. Поэтому в начале приводим цели создания системы — на языке бизнеса, перечисляем роли пользователей и их задачи (они должны себя узнать). Можно привести обобщенную модель бизнес-процесса — на этом уровне без деталей.
2. Где-то через 1-2 страницы от начала документа должна быть БОЛЬШАЯ КАРТИНКА. Книжки без картинок читать скучно. Это должна быть картинка, иллюстрирующая знакомую заказчику обстановку, но с нового ракурса. Типичный пример — контекстная диаграмма. Окружение системы знакомо, роли знакомы, потоки данных знакомы — из нового появляется система, которая это всё объединит. В детали устройства системы вдаваться не нужно, но иногда стоит, если нужно подчеркнуть, насколько она сложная.
3. Общее правило: любая картинка требует текстовой расшифровки. Обычно это таблица, в которой перечислено всё, что изображено на картинке + новые подробности. Для контекстной диаграммы это перечисление ролей, смежных систем, входов и выходов.
4. От контекстной диаграммы легко перейти к требованиям пользователей: хотим, чтобы в систему можно было ввести то-то и то-то, а она нам сама считала/генерировала/обобщала ... и показывала. Тут отлично могут подойти юзер-стори и джоб-стори. Из нового: добавляются тригеры и контекст: когда мы этого хотим? Зачем? Как? (С какими показателями/ограничениями). Скорее всего, мы тут фиксируем то, что нам пользователи ранее рассказали в интервью, и им это должно быть знакомо. Если что, можно предоставить запись, когда именно и кто про это говорил.
5. Добавляем деталей: модель объектов предметной области + их состояния + что с ними можно делать (юскейсы). Пока только названия и цели. Проверка: системы нет, а юскейс имеет смысл (как-то же они сейчас это делают?)
На этом заканчивается описание того, что уже существует в мире — даже если нашей системы нет, это всё равно есть. Есть цели, есть объекты, есть роли, есть юскейсы. Закончили рассказывать про известное. Возможно, что-то из этого известного заказчикам ранее не было известно, или не было систематизировано — мы уже принесли пользу. Сюда же можно добавить ограничения, бизнес-правила и показатели назначения: сколько объектов/пользователей/операций должна поддерживать система, с какой частотой /интенсивностью/надежностью — это всё тоже объективно следует из потребностей и планов бизнеса.
Дальше начинается новое, что мы собственно предлагаем сделать. Сценарии юскейсов: а как пользователи будут достигать своих целей. Архитектура: как мы обеспечим показатели назначения и качества. Как мы это покажем в интерфейсах пользователя и API?
Этого ещё нет, это наши проектные решения. Из решений могут следовать новые требования. Они относятся к элементам решения: экранам, API, отчетам. Обычно эта часть документа более подробная. Может быть это даже отдельные документы. И так доходим до деталей реализации, которые бизнес-заказчик и смотреть не будет, это техника.
Очень частый вопрос, про который вам не расскажут ни в каких материалах по подготовке к собеседованиям. Поэтому он обычно возникает уже у работающих аналитиков: как составить документ требований?
А может быть, вы занимали какую-то другую роль, и теперь вам нужно требования писать. Ну и в принципе часто оказывается, что люди не особо понимают, как документы составлять. Для документов, в которых нужно кого-нибудь в чем-нибудь убедить, есть книга "Принцип пирамиды Минто", авторства Барбары Минто.
Для документов системного анализа она тоже подходит, но давайте раскрою чуть конкретнее. Мы, на самом деле, этими документами хотим убедить заказчиков, что: - система/доработка нужна; - она решит проблему заказчика; - она гораздо сложнее, чем думал заказчик (поэтому нужно дать больше денег).
Итак, принципы пирамиды Куприянова:
1. Документ строится от общего к частному (от бизнес-понятий и целей к деталям реализации) и от знакомого к новому (от того, что уже есть, к тому, что будет). Что знакомо вашим заказчикам? Они сами и их задачи. Поэтому в начале приводим цели создания системы — на языке бизнеса, перечисляем роли пользователей и их задачи (они должны себя узнать). Можно привести обобщенную модель бизнес-процесса — на этом уровне без деталей.
2. Где-то через 1-2 страницы от начала документа должна быть БОЛЬШАЯ КАРТИНКА. Книжки без картинок читать скучно. Это должна быть картинка, иллюстрирующая знакомую заказчику обстановку, но с нового ракурса. Типичный пример — контекстная диаграмма. Окружение системы знакомо, роли знакомы, потоки данных знакомы — из нового появляется система, которая это всё объединит. В детали устройства системы вдаваться не нужно, но иногда стоит, если нужно подчеркнуть, насколько она сложная.
3. Общее правило: любая картинка требует текстовой расшифровки. Обычно это таблица, в которой перечислено всё, что изображено на картинке + новые подробности. Для контекстной диаграммы это перечисление ролей, смежных систем, входов и выходов.
4. От контекстной диаграммы легко перейти к требованиям пользователей: хотим, чтобы в систему можно было ввести то-то и то-то, а она нам сама считала/генерировала/обобщала ... и показывала. Тут отлично могут подойти юзер-стори и джоб-стори. Из нового: добавляются тригеры и контекст: когда мы этого хотим? Зачем? Как? (С какими показателями/ограничениями). Скорее всего, мы тут фиксируем то, что нам пользователи ранее рассказали в интервью, и им это должно быть знакомо. Если что, можно предоставить запись, когда именно и кто про это говорил.
5. Добавляем деталей: модель объектов предметной области + их состояния + что с ними можно делать (юскейсы). Пока только названия и цели. Проверка: системы нет, а юскейс имеет смысл (как-то же они сейчас это делают?)
На этом заканчивается описание того, что уже существует в мире — даже если нашей системы нет, это всё равно есть. Есть цели, есть объекты, есть роли, есть юскейсы. Закончили рассказывать про известное. Возможно, что-то из этого известного заказчикам ранее не было известно, или не было систематизировано — мы уже принесли пользу. Сюда же можно добавить ограничения, бизнес-правила и показатели назначения: сколько объектов/пользователей/операций должна поддерживать система, с какой частотой /интенсивностью/надежностью — это всё тоже объективно следует из потребностей и планов бизнеса.
Дальше начинается новое, что мы собственно предлагаем сделать. Сценарии юскейсов: а как пользователи будут достигать своих целей. Архитектура: как мы обеспечим показатели назначения и качества. Как мы это покажем в интерфейсах пользователя и API?
Этого ещё нет, это наши проектные решения. Из решений могут следовать новые требования. Они относятся к элементам решения: экранам, API, отчетам. Обычно эта часть документа более подробная. Может быть это даже отдельные документы. И так доходим до деталей реализации, которые бизнес-заказчик и смотреть не будет, это техника.
