Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: HMR от 07 Мая 2008, 15:33:42
-
Здравствуйте!
В книге К Вигерса «Разработка требований к ПО» выделены 3 уровня требований: бизнес-требования, требования пользователей и функциональные требования. Говорим о 2-х последних уровнях. Как сказано в книге:
требования пользователей – цели и задачи, которые пользователям позволит решить система. Способ представления этого вида требований – напр., варианты использования (UC).
функциональные требования – определяют функциональность ПО, которую разработчики должны обеспечить, чтобы пользователи могли выполнить свои задачи. Функциональные требования описывают, что разработчику необходимо реализовать.
Пример – UC диаграмма для банкомата (ATM):
(http://fotoplenka.ru/photo/adis/402211/7880873.jpg)
А также упрощенный сценарий UC «Использовать банкомат»:
(http://fotoplenka.ru/photo/adis/402211/7880874.jpg)
Вопрос – верны ли следующие рассуждения (верно ли я понимаю требования пользователей и функциональные требования):
Требованиями пользователей являются 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. По большому счету, логин в систему сложно считать целью пользователя. Логин - это некое решение, процедура, ... цель которой по сути конфиденциальность, защита от НСД и т.п. Я обычно не пишу такого юзкейса, но в предусловиях отмечаю, что пользователь должен быть идентифицирован в системе. А собственно логин представляю уже как некую возможность системы -- т.е. по сути на уровне функциональных требований.
А вот с этого момента поподробнее! Т.е. ты пред условие трассируешь к ФТ? Это разве правильно? Ты не опускаешь некую возможность пользователя на уровне ПТ?
Где же красиво описывать как открывается главная форма приложения и например показываются только та ф-ть, которая определены пользователю?
-
Нет, я не трассирую предусловие к ФТ ... я просто трассирую весь (точнее все) UC на ФТ о логине ... Интересно, как в данном случае рациональнее поступать ;-) .. хорошая тема для обсуждения в качестве кейса.
Насчет описания функциональности доступной пользователю то в ФТ можно просто завести таблицу, где перечислить пересечения функции и ролей. Если функции оттрасированы с юзкейсами будем иметь целостную картину.
-
Вот еще вопросики:
- Среди артефактов управления требованиями по К. Вигерсу есть SRS-документ (спецификация требований)-"А", где: функциональные требования, внешние интерфейсы, ограничения, атрибуты качества.
- Стандарт IEEE 830 описывает SRS-документ-"В"
Скажите, пож-та, "А" и "В" - один и тот же документ, или разные?
Если один и тот же, то почему в одной концепции (Вигерса) используется другая (IEEE) ?
А если разные, то в чем, и почему их решили одинаково назвать?
А я ничего не путаю ?
-
RT,
По сути это документы, которые описывают одно и тоже. В них только разделы называются по разному и возможно один более расширен, чем другой. Сравнение Вигерса и IEEE можно увидеть в презентации Юры Булуй (http://www.mail333.com/download.php/?file=:Yury_Buluy_%28ReqClassification%29.pdf&host=bouloui.mail333.com/flashcard#http://bouloui.mail333.com/flashcard/Yury_Buluy_(ReqClassification).pdf).
Если Вы возмете что-то одно за основу, то не ошибетесь, это два хороших шаблона для описания требований.