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

Будет ли корректным описывать задачу выше в виде одного варианта использования (например "Модифицировать конфигурационные настройки системы"), который будет сначала описывать шаги того, как пользователь скачивает файл, потом просто уточнить, что перед тем, как загружать новую конфигурацию, ему её следует отредактировать и внести необходимые изменения вне системы, а затем описать шаги по загрузке фала обратно в систему и того, как система его валидирует?

Или все-таки нужно писать два юзкейса: один - на скачивание из системы, а другой - на загрузку обратно в систему?

Написанные варианты использования (не только этот будут являться функциональными требованиями к системе.

1. Варианты использования сами по себе, строго говоря, не являются функциональными требованиями ... это (по Вигерсу) пользовательские требования. Функциональное требование будет выглядеть в данном случае как некая возможность системы/модуля по сохранению/использованию настроек, и "подтребованием" -- возможность обновлять настройки через обновление файлов настроек.
2. Я бы не стал для данного случая писать UC, а обошелся бы именно функциональными требованиями. Но если уж есть желание выделить именно UC -- то я бы сделал один общий UС, который бы назвал (CRUD по Коберну) "Управлять настройками системы" и в нем бы выделил отдельный сценарий, который бы описывал просто возможность ИЗМЕНЕНИЯ настроек. А то, что этот файл может быть скачан (или перенесен на флэшке) -- указал бы в разделе UC "Вариации технологий и данных" одной фразой.

1) Хотел бы добавить, что мы, по крайней мере, заявляем :-), что работаем в соответствии с RUP. А там все же основным артефактом, который фиксирует фунциональные требования, является юзкейс(ы). Получается, у меня выбора нет. Исправьте меня, если считаете, что я что-то не правильно понимаю.

2) Есть такая книжка: Use Cases Patterns and Blueprints, By Gunnar Övergaard, Karin Palmkvist, ISBN : 0-13-145134-0
Так вот там тоже упоминается этот CRUD pattern. Но там (в этой же книжке) упоминается такой Common Mistake, как "Modeling a business process as a system use case". Там есть пример:
"An example of a business use case that will be supported to a high degree by a software system is Manage Order in a warehouse business. The flow comprises among other things the registration of an order, the generation of a pick-list for the assembly of the shipment, the generation of an invoice when the order has been shipped, and finally the registration of the payment from the customer. It should also comprise the possibility to change or to delete a registered order.

Why not capture this as a single use case in the system use-case model? The problem is that this use case does not model one usage of the software; it models one usage of the business. The flow consists of several subflows that will be performed at different points in time, at irregular time intervals, and possibly initiated by different persons. Furthermore, each of these subflows provides a value to someone inside the warehouse. Hence, every subflow constitutes a use case in the software; that is, they are complete usages of the software. If we change focus and study the entire warehouse, however, none of them constitutes a use case on its own; they are only fragments in the usage of the warehouse business. The key here is the subject of the model: Is it the software system or is it the business?"

Еще там пишется про "Pauses in Use Cases
A somewhat related situation is when the performance of a use case includes a scheduled pause. A typical example is the telephone exchange system supporting a hotel, where one important service to the customers is to offer automatic wake-up calls. From the business perspective, the complete flow starts when a customer requests a wake-up call at some future point in time and ends when the wake-up call has been performed the next morning.

It is tempting to model this flow as one use case, but this is not the best way to do it. First, there is a long period of time during this process when nothing happens, and it is generally considered bad practice to model use cases whose execution largely consists of doing nothing. Second, it may be the case that the wake-up call is never performed at all (for example, if the customer cancels the request or decides to check out before the wake-up time). In this case, the use case has been waiting for a long time for nothing (see also Chapter 28, "Future Task")."

Отсюда и возникли мои сомнения, а не повторю ли я эту ошибку у себя в юзкейсе, если сделаю его единым, как описывал. И, соответственно, для меня не понятно, почему CRUD не подпадает под эту ошибку?

3) Что вы думаете про Pluggable use cases http://alistair.cockburn.us/index.php/Pluggable_use_cases

1. РУП в чистом виде никто не использует. Его адаптируют под себя. Вы все артефакты используете из дисциплины по УП? См. ниже

2.1. С первым высказыванием согласен, т.к. у приведенных СВИ есть свои цели и разные пользователи, кот. иницирует процесс. КРУД ВИ все таки инициируется одним пользователем и имеет первичную цель что-то добавить, а остальное уже альтернативные сценарии.
2.2. Со вторым не согласен в корне, т.к. это уже получаются ф-ции, а не ВИ.

3. Пока не читал ...

3. Прочитал я про Pluggable use cases. Это ничто иное как ФТ, т.е. шаг сценария ВИ детализируется с помощью ФТ или как назвал Коберн - Pluggable use case. Это очень удобно, когда несколько детальных шагов сценария объединяешь в одно ФТ или Pluggable use case, а потом на него ссылаешься из основных ВИ.

Прочитал комментарий по поводу того, что ВИ не являются функциональными требованиями.

Варианты использования сами по себе, строго говоря, не являются функциональными требованиями ... это (по Вигерсу) пользовательские требования. Функциональное требование будет выглядеть в данном случае как некая возможность системы/модуля по сохранению/использованию настроек, и "подтребованием" -- возможность обновлять настройки через обновление файлов настроек

Прочитал комментарии в теме: Как Вы описываете требования к ПО?

На сколько я понимаю, имелось в виду, что просто не все требования возможно описать в ВИ и какие-то нужно будет задокументировать в Supplementary Specification.

Это Ок. А то сначала подумал, что параллельно с юзкейсами предлагается вести отдельный документ, где функциональные требования, описанные в ВИ, необходимо было бы прописать явно.

Это Ок. А то сначала подумал, что параллельно с юзкейсами предлагается вести отдельный документ, где функциональные требования, описанные в ВИ, необходимо было бы прописать явно.

очень рекомендую прочитать Коберна от корки до корки и не один раз. Также советую посмотреть в сторону Левингуэлла. У последнего есть специальная глава, объясняющая когда стОит, а когда не стОит использовать UC