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

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

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

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

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

Есть такая аббревиатура - 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. Там также охватывается довольно большой объем серых областей.

Как описать требования к резервному копированию

Проблема: необходимо выявить и описать требования к резервному копированию.

Техники выявления требования: интервью, изучение документации.

Требования к резервному копированию системы могут быть разными, поэтому полноту надо оценивать исходя из вашего контекста. Однако, в большинстве проектов, где я работал, требования были достаточно стандартны.

Как же описать требования?

Непосредственно процесс сбора требований:

1. Выявляем типы данных для резервного копирования

Это могут быть различные данные, не только реляционные базы данных. 
Пример:

  a.      Файлы (XSD, JSON схемы, снапшоты виртуальных машин, ...)

  b.     Key-value storage (MongoDB), в т.ч. и держащие данные в памяти (Redis).

  c.      Реляционные базы данных.

  d.     Данные из очередей (Kafka).

Для примера, возьмем резервное копирование данных из очередей – пункт d.

2. Определяем целевые показатели для резервного копирования 

  a. Recovery Point Objective (RPO) - как много данных мы можем потерять(за какой период)? Очевидно, что для каждого типа данных может быть свое значение. 

Из очередей данных можно потерять за последний час, т.е. PRO - 1 час. 

  b. Recovery Time Objective (RTO) - как быстро система должна восстановиться после сбоя до нужного уровня работоспособности. 

RTO в нашем случае – 15 минут.

*Нужный уровень работоспособности нужно прояснять и согласовать. Для каких-то систем это выполнение определенного типа функций в заданное время, для каких-то полное восстановление функциональности.

3. Определяем процесс, по которому будет происходить процесс резервного копирования и восстановления

Правильный подход: спросить администраторов, какой процесс, какие основные проблемы, также можно почитать статьи и найти лучше практики. Подход чуть похуже: опираться на свои знания, но тоже выход.

Я опишу процесс копирования с точки зрения обывателя, в для статьи правильный процесс – не самоцель.

 Основные шаги:

1. Подготовка данных.
2. Резервное копирование (Инициализация копирования, копирование, завершение и проверка резервной копии).
3. Восстановление из резервной копии (опционально).
4. Удаление данных.

4. Выявляем Use Cases и строим диаграмму

Я выявляю UC по шагам процесса:

• 1-й шаг – UC с целью подготовить данные.
• 2-й шаг – UC с целью получить резервную копию в определенном месте.
• 3-й шаг – UC с целью получить работающую систему с данными, актуальными на момент копирования.
• 4-й шаг – UC с целью получить файловое хранилище с местом, достаточным для последующего резервного копирования.

Напомню, цели UC тоже формулируются заинтересованным лицом и могут кардинально отличаться от придуманных мной).

Note: Если вы жестко придерживаетесь концепции описания и применения use cases, то, вероятно, диаграмму вариантов использования вам строить не стоит. Сценарии backup и save queues state, где эктором является scheduler – это не совсем сценарии использования в их классическом значении, поскольку и пользу эктор не получает, и логически находится в рамках системы резервного копирования, да и пресловутого взаимодействия как такового нет, особенно, если в качестве триггера для UC обозначить «наступление времени копирования». Сами UC можно описать в качестве activity diagram. Но все ж у вас есть оправдание, можно ссылаться на UML 2.5:

"Also, all UML 2.x specifications until UML 2.5 stated that use cases "are defined according to the needs of actors." This sentence was removed from UML 2.5 as some actors might have neither needs nor requirements by themselves"

5. Далее, описываем сценарии использования

Для примера возьмем UC «резервное копирование».

UC-ID-Name|Служебная информация: triggers, actors, post and pre-conditions|Main flow:
1. Scheduler инициализирует задачу резервного копирования.
2. System проверяет наличие данных для копирования.
3. System проверяет доступность хранилища и наличие свободного места.
4. System копирует подготовленные данные в хранилище.
5. System проверяет сохраненные данные.
6. End with success.

Alternative flow:
3a. Данные не были подготовлены.
1. System запускает процедуру подготовки данных
2. Kafka готовит данные для копирования [ссылка на UC подготовки данных].
3. Переходим к шагу 3 основного потока.
3a2a Данные не готовы.
1. System оповещает администратора об ошибке.
2. Failed end.
И т.д.

При расписывании сценария у вас возникнет куча требований по тому КАК должна система выполнять те или иные действия, а это и есть цель извлечения требований

6. Формализуем требования и начинаем анализ на непротиворечивость, выполнимость, проверяемость, понятность, нужность и т.д.

Отдельно хочу отменить нужность, т.к. есть шанс придумать что-то очень крутое инженерное, но ненужное.

7. Согласовываем и можно разрабатывать дизайн систем

Источники:
http://wikibon.org/wiki/v/Recovery_point_objective_-_recovery_time_objective_strategy
https://en.wikipedia.org/wiki/Backup

Как показать "найденное сообщение" на диаграмме последовательностей

Eng: How to Show "found message" in EA on Sequence Diagram

Проблема: На диаграмме последовательностей вам надо изобразить найденного сообщение (found message), вы используете Enterprise Architect.

Делается это довольно просто.

1. Добавляем на диаграмму endpoint

2. А уже от неё ведем связь взаимодействия 

Готово.

Подробнее можно почитать тут:

1. http://www.sparxsystems.com/enterprise_architect_user_guide/10/standard_uml_models/endpoint.html
2. http://www.visual-paradigm.com/VPGallery/diagrams/Sequence.html