Здравствуйте!

В книге К Вигерса «Разработка требований к ПО» выделены 3 уровня требований: бизнес-требования, требования пользователей и функциональные требования. Говорим о 2-х последних уровнях. Как сказано в книге:
требования пользователей – цели и задачи, которые пользователям позволит решить система. Способ представления этого вида требований – напр., варианты использования (UC).
функциональные требования – определяют функциональность ПО, которую разработчики должны обеспечить, чтобы пользователи могли выполнить свои задачи. Функциональные требования описывают, что разработчику необходимо реализовать.
Пример – UC диаграмма для банкомата (ATM):

А также упрощенный сценарий UC «Использовать банкомат»:

Вопрос – верны ли следующие рассуждения (верно ли я понимаю требования пользователей и функциональные требования):
Требованиями пользователей являются UC-ы:
•   Получить наличные;
•   Проверить баланс;
•   Перевести деньги,
а функциональными требованиями являются действия ATM – ATM должен:
•   Считать данные с магнитной карточки;
•   Запросить PIN;
•   Проверить PIN на корректность;
•   Отобразить список типов транзакций;
•   Вернуть карту.

RT,

Ну что за ВИ - Использовать Банкомат?? 
Ну какая у него цель?? Грязно воспользоваться Банкоматом или использовать как молоток???

Ну назовите хоть - "Выполнить операцию со счетом"

И как-то обобщение и включение у Вас не правильное. Не понимаю я их смысл зачем два верхних ВИ?? Они не несут никакого смысла.

Лучше взять ВИ:
* Получить наличные;
* Проверить баланс;
* Перевести деньги,
+ Войти в Систему

Это и будут ПТ, т.е. Цели Пользователей

ФТ - это Вы правильно определили.

Лучше не «проверить баланс», а «узнать состояние счёта».

«Использовать банкомат» — такой задачи ни у одного вменяемого пользователя нет. Можно ограничиться одним обобщённым сценарием «Выполнить финансовую операцию».

С пониманием функциональных требований более-менее всё хорошо, кроме того, что клиент выполняет транзакцию. Там запускается отдельный вариант использования, в котором как минимум 2 стороны будет участвовать, потому рисовать его в одном потоке не совсем верно.

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

Не нраввиЦа UC "Использвать банкомат" ?! Ну какая у него цель??
Хорошо, давайте так..
Этот UC описывает СЕССИЮ работы с банкоматом.
Можно назвать "Выполнить операцию со счетом", хотя, конечно: "операциИ" (их в одной сессии может быть много)

2bas:
И как-то обобщение и включение у Вас не правильное. Не понимаю я их смысл зачем два верхних ВИ?? Они не несут никакого смысла.

Это еще почему ?!


Сессия состоит из транзакций.
Транзакцией м.б.:
•   Получить наличные;
•   Проверить баланс;
•   Перевести деньги и т.д.

Если как Вы предлагаете:
"Лучше взять ВИ:
* Получить наличные;
* Проверить баланс;
* Перевести деньги,
+ Войти в Систему"

Тогда даже интуитивно не понятно, в чем же заключаеЦа работа с ATM !
Хотя, сначала я тоже так сделал, как Вы предлагаете.
> Лучше не «проверить баланс», а «узнать состояние счёта».
По сути то же, тока называеЦа подругому. В том то и ужас, что одному нравиЦа одна формулировка, другому - другая..


> Ну и функциональных требований будет гораздо больше — показать приглашение вставить карточку, запросить > > > проверку кода у дата-центра, получить подтверждение корректности кода, отобразить сообщение о корректности > кода, отобразить сообщение об ошибочном коде, заблокировать карту.

Понятно дело.. Я нарисовал но уж очень урезанную версию

а, вот еще что хотел спросить:
 получается, что функциональные требования можно получать так:
 - берем на activity diagram swimline нашей системы (SID) и из каждой активности получаем свое функциональное требование ?

RT,

Цитируйте плиз правильно, а то трудно читать и не понятно что Ваше, а что Наше

Не нраввиЦа UC "Использвать банкомат" ?! Ну какая у него цель??
Хорошо, давайте так..
Этот UC описывает СЕССИЮ работы с банкоматом.
Можно назвать "Выполнить операцию со счетом", хотя, конечно: "операциИ" (их в одной сессии может быть много)

А срисовывать бессмысленно с иностранного сайта - это плохо

2bas:
И как-то обобщение и включение у Вас не правильное. Не понимаю я их смысл зачем два верхних ВИ?? Они не несут никакого смысла.

Это еще почему ?!

Хорошо. Чем отличает ВИ "Использовать Банкомат" отличатся от ВИ "Выполнить Транзакцию"? Правильно логином только. Вот его и надо вывести в отдельный ВИ, не связывая ни с чем.

> Лучше не «проверить баланс», а «узнать состояние счёта».
По сути то же, тока называеЦа подругому. В том то и ужас, что одному нравиЦа одна формулировка, другому - другая..

Это еще ничего, а вот когда сама диаграмма отличается, вот это хуже. Я эту проблему выявлял здесь:
http://www.uml2.ru/forum/index.php?topic=71.0

получается, что функциональные требования можно получать так:
 - берем на activity diagram swimline нашей системы (SID) и из каждой активности получаем свое функциональное требование ?

По сути - ДА

Цитируйте плиз правильно, а то трудно читать и не понятно что Ваше, а что Наше

Хорошо

А срисовывать бессмысленно с иностранного сайта - это плохо

Честно говоря, доверие к иностранным сайтам испытываю.
Простите за прямоту, как не прискорбно, но, полагаю, юзкейсы пока лучше всех пишет иностранный гражданин Кокберн, а не наш, напр., Василий Иванов Никого не хотел обидеть.

Чем отличает ВИ "Использовать Банкомат" отличатся от ВИ "Выполнить Транзакцию"?

Как я показываю на 2-й диаграммке (активности):
"Использовать банкомат" включает - идентификация (логин) Клиента и выполнение им ряда транзакций ("Выполнить Транзакцию")
Зато, показывая сессию ("Использовать банкомат"), мы уже видим, что Клиент сначала вставляет в щель банкомата карточку, вводит ПИН (логируеЦа), потом запускает транзакции, а потом - забирает карточку.

Если же не будет этого всеобъемлющего UC ("Использовать банкомат"), то долго придеЦа мутить, прежде чем понять последовательность.

Я не буду с Вами спорить чья диаграмма правильная, т.к. этот пример не показатель, здесь можно сделать так и так. Но если Вы описываете большую Систему, то Логин надо выделять отдельно, иначе будут проблемы с декомпозицией. Для этого и придумали Пред и Пост Условия.

Я готов доверять "гражданину Кокберну", но ИМХО эту диаграмму Вы взяли у тамошнего "Василия Иванова".

этот пример не показатель, здесь можно сделать так и так.

Ну да, в том то и дело!

По поводу автомата - вот прекрасный пример http://www.math-cs.gordon.edu/courses/cs211/ATMExample/

По поводу автомата - вот прекрасный пример http://www.math-cs.gordon.edu/courses/cs211/ATMExample/

Ну да, от туда я и слизал его

А вообще - спасибо за ответы - что б без них делал бы!

По поводу автомата - вот прекрасный пример http://www.math-cs.gordon.edu/courses/cs211/ATMExample/

Да все знают этот пример, в том числе и RT. Я сразу понял откуда ноги растут
Но я бы не назвал его прекрасным:
1. ВИ названы как существительные, а не глаголы. Что не правильно!
2. Что за цель у ВИ - Session.  Session может быть где угодно, да и Transaction чего? По крайне мере названия ВИ выбраны не удачно.
3. Как я уже говорил, я бы сделал два основных ВИ - "Войти в Систему" и "Выполнить фин операцию", последнюю из кот. можно в принципе разобщить на множество фин операций
4. Человек, кот. нарисовал эту ДВИ не является признанным гуру и не чем по сути не отличается от нашего "Василия Иванова"
5. Не стоит все слизывать, не задумавшись, мы же все таки Аналитики!

> Лучше не «проверить баланс», а «узнать состояние счёта».
По сути то же, тока называеЦа подругому. В том то и ужас, что одному нравиЦа одна формулировка, другому - другая..

Роман, это вам так кажется. Есть правило — чтобы название варианта использования отражало достижение состояния, в котором реализованы интересы основного участника. Форма «узнать состояние счёта» более точно фокусируется на интересах агента-инициатора. Рассмотрим возможные варианты завершения сценария — цель достигнута, цель не достигнута.

Если в ходе выполнения сценария возникнет ошибка, то с точки зрения формы «проверить баланс» — баланс собственно проверен, да только в ходе проверки возникла ошибка (например, «недостаточно средст на счёте длы выполнения операции»). А вот в форме «узнать состояние счёта» двух мнений быть не может — либо ты его знаешь, либо нет.

1. По большому счету, логин в систему сложно считать целью пользователя. Логин - это некое решение, процедура,  ... цель которой по сути конфиденциальность, защита от НСД и т.п. Я обычно не пишу такого юзкейса, но в предусловиях отмечаю, что пользователь должен быть идентифицирован в системе. А собственно логин представляю уже как некую возможность системы -- т.е. по сути на уровне функциональных требований.
2. Совершенно согласен, что UC "Использовать банкомат" бестолковый, так же как и "выполнить транзакцию". Думаю, что в оригинале он введен исключительно для того, чтобы показать как красиво на ДИАГРАММЕ все декомпозируется. Т.е. больше для того, чтобы показать что юзкейсы не столько техника, сколько целостная модель.

1. По большому счету, логин в систему сложно считать целью пользователя. Логин - это некое решение, процедура,  ... цель которой по сути конфиденциальность, защита от НСД и т.п. Я обычно не пишу такого юзкейса, но в предусловиях отмечаю, что пользователь должен быть идентифицирован в системе. А собственно логин представляю уже как некую возможность системы -- т.е. по сути на уровне функциональных требований.

А вот с этого момента поподробнее! Т.е. ты пред условие трассируешь к ФТ? Это разве правильно? Ты не опускаешь некую возможность пользователя на уровне ПТ?
Где же красиво описывать как открывается главная форма приложения и например показываются только та ф-ть, которая определены пользователю?