Метод быстрого анализа требований

Цель: Наиболее полно извлечь требования.

Проблема: у вас очень мало времени.

Думаю, вы часто сталкивались с тем, что появляется требование, которое уже завтра надо брать в разработку, но оно должно быть проанализировано. Оставляя за рамками причины, попытаемся решить проблему.

Я искал и пытался применять разные паттерны, но остановился на одном, который немного доработал.

Есть такая аббревиатура - CRUD, я её немного расширил до SCRUDADeV.

С помощью этой формулы можно быстро начать и получить довольно много полезной информации, а следовательно, требований.

Теперь сам метод:

Возьмем сферическое требование - система должна нотифицировать администратора о неуспешных попытках логина (именно в такой формулировке).

1. Определим, какие данные тут используются. Как минимум - логин и нотификация.
2. Теперь пытаемся выяснить куда какие данные идут: login - GUI, authorization server; notification message - syslog server, gui, db, external system.

Уже на этом этапе вы выяснили, что из авторизационного сервиса должно куда-то складываться сообщение.

3. Далее берем логин, а затем сообщение нотификации, и проходим по списку.

Search

Искать логин нужно?

Искать нотификационное сообщение нужно?

Как/Зачем?

Create

Какие требования с созданию данных?

Логин зашифрованный/нет, первичная валидация по формату, etc.

Какого формата создаем сообщение, триггеры создания etc.. 

Read

Как считывать логин (Никак, не особо применимо, хотя случаи могут быть разные).

Как читать сообщение (Кто, когда, как?) Нужна ли интерпретация?

Delete

Как и когда удаляем данные логина (Опять же, не особо применимо).

Как, когда удаляем нотификационные сообщения, ограничения и т.д.

Audit

Логирование and all about it.

Default Value

Нужны ли какие-либо дефолтные значения в тех или иных случаях.

Опять же, про логин и нотификационные сообщения придумать не могу, т.к. они не меняются в течение всего жизненного цикла. Но если взять, к примеру, любое требования типа "… должно быть конфигурируемым". Тут появляется необходимость вопроса про значение по умолчанию.

Validate

Нужна ли какая-либо валидация данных в течение жизненного цикла.

Например, проверяем, что сообщение содержит значение логина, в противном случае мы инвалидируем пакет и выкидываем его, чтобы не копить в базе ненужные данные.

Вывод:

Мы получаем алгоритм получения информации, позволяющий в короткие сроки получить информацию.

Однако стоит помнить главный вопрос аналитика - зачем. Может и извлекать ничего не придется.

p.s. Вторым по эффективности идет проработка use cases. Там также охватывается довольно большой объем серых областей.