На мой взгляд книга очень интересная, скажу по секрету, что я читала ее не с начала, а с конца к началу, так как все самое интересное, включая лексику и направления приложения в рамках сбора требований, все написано прямо в конце книги.
Даны четкие рекомендации по составлению списка требований и описанию системы с разной степенью детализации, начиная от общей концепции того, как должно работать приложение, до постраничного написания скриптов.
Зачем это нужно - чтобы лучше понимать, что на самом деле делают ясноглазые бизнес-аналитики, когда поступает запрос - мне нужен сайт, типа ссылки там.
Возможно, стоит попробовать прочитать эту книгу в оригинале, так как в русских переводах мне зачастую было непонятно, о чем идет речь.
Базовые концепты:
Вариант использования — последовательность шагов, которая обычно определяет все взаимодействия между некоторой ролью/функцией (называемой «Актер» в UML) и системой для достижения некоторой конкретной цели.Актер — в данном случае это либо человек, который взаимодействует с системой, либо некая внешняя система, которая может инициировать какие-то действия в нашей системе.
Проще говоря, вариант использования — это все варианты сценариев, все, что происходит на странице.
Цели - цель, Провал цели - соответственно, недостигнутая цель.
Хороший вариант использования должен быть написан простым и понятным языком, чтобы информация была легко и просто понятна другому человеку.
Описаны основные характеристики: Объем - что представляет собой проект или часть проекта, Главный актер (основной субъект или элемент системы, который инициирует взаимодействие с системой в рамках основной цели) описание того, кто (пользователи/администраторы) или что будет работать на этой странице и Уровень - уровень, на котором все происходит; Предпосылки и гарантии — что должно произойти до и после запуска варианта использования; Основной сценарий успеха — основной сценарий того, что должно быть успешно завершено; Расширения — различные варианты отклонения системы от основного сценария.
Лично мне очень понравилась ссылка на Стива Дольфа: «используйте Наконец, вернемся к поверхности: что изменилось с тех пор, как вы углубились в детали? Настройте модель, а затем повторите погружение для следующего варианта использования.
"
Основные правила
Наверное, стоит процитировать их полностью: 1. описание системы должно быть читабельным; 2. всегда нужно начинать с общей концепции и переходить к подуровням, Для каждого шага: Сначала вам следует описать процесс (шаг за шагом) для достижения цели и описать намерение Актера, а не вдаваться в подробности пользовательского интерфейса.(где Actor — это не актер, как любят писать в русских переводах, это может быть человек или система, выполняющая сумму вычислений, действий и операций на заданном уровне приложения или на данной странице).
Затем вам следует указать информацию, которая должна идентифицировать субъекта, по каким критериям или как именно следует проверять обновления статуса.
За этим должен следовать комментарий о том, что происходит между различными шагами или отсутствуют ли эти шаги.
После этого стоит задаться вопросом, какая цель достигается этим шагом на следующем, более высоком уровне.
Для описания данных: Включайте в описание варианта использования только соответствующий уровень детализации.
Уровень детализации 1: заголовок данных Уровень детализации 2: поля данных, связанные с заголовком.
Уровень детализации 3: Типы полей, длина поля и способ проверки введенных данных.
То, что не входит в вариант использования, но всегда так или иначе связано с ним и необходимо учитывать: форматы данных, протоколы ввода-вывода, требования к производительности и требования к пользовательскому интерфейсу, дизайн пользовательского интерфейса, бизнес-правила.
Существует несколько стадий точности: 1. Персонажи и цели: Перечислите действующих лиц и каждую из целей, которые будет преследовать система.
Проверьте точность и полноту этого списка.
Расставьте приоритеты и распределите цели между командами разработчиков и выпусками.
Теперь у вас есть функциональные требования для первого уровня точности.
2. Краткое описание варианта использования или основного сценария: В случае использования вы решили следовать основному сценарию в общих чертах.
Просмотрите его в общих чертах, чтобы убедиться, что система действительно отвечает потребностям участников, которые вам интересны.
Это второй уровень точности функциональных требований.
Этот материал довольно легко подобрать, в отличие от следующих двух уровней.
3. Условия отказа: Завершите основной сценарий и подумайте, какие сбои могут произойти.
Перечислите их, прежде чем решить, как система должна с ними обращаться.
Описание процессов обработки сбоев является более трудоемким, чем перечисление сбоев.
<.
> 4. Обработка сбоев: Напишите, как система должна реагировать на каждый сбой.
Зачастую это сложный, утомительный и непредсказуемый процесс, поскольку он может выявить новых участников или новые цели, которых должна достичь система.
Продолжение следует. Теги: #бизнес-аналитика #бизнес-анализ #сценарии использования #Чулан #сценарий использования для бизнеса #Алистер Кокберн #Написание вариантов использования
-
Преимущества Внутренних Систем Id-Карт
19 Oct, 24 -
Сага О Персональных Данных Продолжается
19 Oct, 24 -
Кланг Api. Начало
19 Oct, 24 -
Ms-Dos – С 30-Летием
19 Oct, 24 -
Космос И Гена
19 Oct, 24
