Можно ли обойтись одними Use Case’ами?




В теме 17 ответов, и 8 участников, последнее обновление сделано пользователем Аватар (Юрий Веденин) Юрий Веденин 7 г, 1 мес. назад.

Показано 15 ответов - от 1 до 15 (всего 18)
  • Автор
    Сообщения
  • 13.03.2010 в 20:26 # 17177
    Вот слышал такое мнение, что в системах, которые взаимодействуют с пользователями, для специфицирования функциональных требований можно обойтись одними юз-кейсами. Само собой, что можно добавить сюда еще макеты (mockups, wireframes, etc.) и маппинг одного на другое (например, на макетах будет обозначено, с помощью какого элемента можно вызвать какой юз-кейс).
    Что скажете? Можно ли? Если нет, то почему или в каких случаях можно, а в каких — нет?
    Поделиться:

    Цитировать

    20.03.2010 в 22:30 # 17178
    Ну… При желании можно вообще одними словами обойтись — без написания спецификаций :) . А можно сделать юз кейсы размером со слона и в них поместить всяко-разно требований (включая мокапы и т.д.). А можно скрам замутить и т.д… На мой взгляд — все зависит от ситуации — проекта, SDLC, имеющихся ресурсов и т.д. Но в одном я уверен исходя из опыта — для конечного приложения наилучший вариант (если условия позволяют) — это полноценная спецификация, детально и полностью описывающая требования к системе. Юз кейсы VS features? Юз кейсы не всегда описывают систему полностью, ведь кроме "сделать что-то с системой" есть функционал, который классическими юз кейсами не опишешь. Wireframes? Крутая штука, но допускает 90% девелоперского креатива при имплементации. здесь детальное описание каждого контрола незаменимо. В общем, я — за полноценный процесс разработки софта — с блэкджеком и SRS :)
    Поделиться:

    Цитировать

    24.03.2010 в 19:00 # 17179
    Аватар (Belle Morte)
    Belle Morte
    Админ
    Соглашусь с Герычем, одними юз-кейсами не обойтись.
    Допускаю такой вариант, что приложение очень простое, состоит не более чем из 10 страниц, наполнено статическим контентом и позволяет совершить 2-3 действия — здесь можно, конечно, ограничиться юз-кейсами да мокапами (хотя бы потому, что для такого маленького проекта не составит труда неочевидные моменты обговорить устно либо зафиксировать на салфетке). Но как быть, если приложение сложнее? Если присутствуют сложные вычисления, механизм roles and permissions, взаимодействия со сторонними системами? Где показать, к примеру, структуру xml запроса, отправляемого на сторонний сервис — в юз-кейсе или на мокапе? :) так что я считаю все зависит от специфики проекта. Часто можно пожертвовать теми или иными разделами спецификации, но выкинуть все, кроме юз-кейсов и мокапов — это чревато.
    Поделиться:

    Цитировать

    08.04.2010 в 11:30 # 17180
    Я так понял, что ответ Аси — в принципе можно.
    Ответ Геры — всегда и везде полноценный SRS (:

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

    Поделиться:

    Цитировать

    13.04.2010 в 14:02 # 17181
    Нее… Юра, не утрируй :) .
    Я не имел в виду, что пипец только SRS и хоть вешайся — в противном случае не хочу работать…
    Я согласен, что есть разные проекты и продукты.. да и не только — есть и разные методологии, и разный уровень аналитов, да и вообще наличие аналитов в команде не всегда есть реальность. Во всех этих случаях продукты получаются не хуже.
    Так вот, отвечая на твой вопрос — да, можно. Но — если позволяют время и ресурсы, то лучше SRS (я не имею в виду полноценный шаблонный SRS здесь, скажем лучше спецификация в необходимом объеме).
    Вот банальный пример — маааааалюсенькое приложение, состоящее из одного скрина с полями ввода данных. Нарисовал мокап, набабахал два юз кейса — сё гуд. Но ведь каждый контрол имеет свои особенности — обязателен ли для заполнения, автопостбэки с привязанной логикой, четкий формат и т.д. С помощью мокапов и юз кейсов этого не опишешь, ну то есть может и опишешь, если захочешь конечно, только смысл так над ними извращаться? А не имея всего этого — нужен либо постоянный контакт девелопера с аналитом, где аналит супервайзит девелопмент и тестирует сам перед сборкой, либо потом будет активный багофикс (вернее даже не багофикс, а доработка, ведь это не баги :)). Короч, как то так… Я надеюсь, что мысль свою донес.. :)
    Поделиться:

    Цитировать

    11.05.2010 в 09:12 # 17182
    Аватар (Anna)
    Anna
    Подписчик
    По опыту анализа требований в нашей компании люди сходятся во мнении о том, что UI Prototype (сюда можно причислить что угодно, статические мокапы или динамический HTML прототип, кому что больше нравится и что в зависимости от ситуации наиболее удовлетворяет нуждам проекта), описание Use Cases и Domain Model покрывают 85% всех требований к продукту. Все остальные вещи типа GUI, NF-requirements, Business Rules и проч. зависят опять же от кокретного проекта.
    На мой взгляд в данной ситуации под Use Cases нужно понимать скорее не те классические сценарии Вигерса, а прецеденты, или варианты использования. Ими удается очень подробно и наглядно описать требования (не только пользовательские, но и функциональные зачастую).
    Так что в ответ на вопрос, можно ли обойтись одними юз кейсами, мой ответ: нет :) Ну или если аналитик молодец сам все еще и закодит, то ему и юз кейсы не понадобятся :)
    Поделиться:

    Цитировать

    11.05.2010 в 20:54 # 17183
    Анна, а можно в двух словах про отличие классических сценариев Вигерса от вариантов использования?
    Поделиться:

    Цитировать

    09.07.2010 в 11:12 # 17184
    Аватар (Николай Киреев)
    Николай Киреев
    Участник
    Можно ли обойтись одними Use Case´ами?

    Смотря для чего… и не понятно, что в данной поставновке вопроса подразумевается под Use Case´ами? Если подразумевается просто одна или даже несколько Use Case Diagram, где Use Case это овал, отражающий некую функциональность программной системы (без детализации потоков событий) то это одно, а если под ними подразумевается не только набор диаграмм, но и подробно описанные потоки событий (типовые, альтернативные, ошибочные, начальные и конечные состояния системы, точки ветвления) + экранные формы, то это уже другое.
    Просто набор Use Case-диаграмм должен однозначно отображать всю функциональную бизнес-логику программной системы и каждое пожелание заказчика, связанное с функциональностью системы, должно иметь однозначное отражение в одном или нескольких Use Case´ах.
    А набор из: Use Case-диаграмм + подробные сценарии + экранные формы = это уже первая действующая модель функционирования системы в рамках ее желаемой бизнес-логики, которую, можно и нужно обсуждать с заказчиком. У нас не написано ни строчки кода и даже нет никакой разработанной архитектуры системы, а мы уже показываем заказчику ее функционирование!!!

    Поделиться:

    Цитировать

    16.07.2010 в 18:30 # 17185
    А имеем ли мы право считать, допустим, экранные формы частью юз кейса? Я бы сказал, что юз кейс — это в максимальной интерпретации диаграмма + формальное текстовое описание. Скриншоты, мокапы и т.д. вроде бы причислять к контенту юз кейса не особо то и правильно.
    Поделиться:

    Цитировать

    16.07.2010 в 21:40 # 17186
    Так, стояночка (:
    Под юз-кейсами тут не подразумевается только

    одна или даже несколько Use Case Diagram, где Use Case это овал, отражающий некую функциональность программной системы (без детализации потоков событий)

    но под юз-кейсами тут не подразумевается и

    не только набор диаграмм, но и подробно описанные потоки событий (типовые, альтернативные, ошибочные, начальные и конечные состояния системы, точки ветвления) + экранные формы

    В частности, экранные формы однозначно не являются частью юз-кейсов.

    Вот так будет вернее
    "набор диаграмм и подробно описанные потоки событий (типовые, альтернативные, ошибочные, начальные и конечные состояния системы, точки ветвления)"

    Разобравшись в терминологии, каков будет ответ теперь?

    Поделиться:

    Цитировать

    19.07.2010 в 08:26 # 17187
    Аватар (Aliaksei Rudzko)
    Aliaksei Rudzko
    Подписчик
    5 коп. Всё зависит от детализации. Можно систему детально описать, используя только Use Cases. Но зачем? Для понятности каждой части спецификации есть свои методы. Например, детальное описание данных лучше иметь в Data Dictionary, UI — лучше увидеть [скрины], чем прочитать о них в UC. Etc, etc…
    Поделиться:

    Цитировать

    31.08.2010 в 22:49 # 17188
    Аватар (Vitrimak)
    Vitrimak
    Подписчик
    UC — это способ моделирования / документирования поведенческого требования. Use case use cas’у рознь. Можно и процесс описать, и выполнение какой-либо пользовательской задачи.Считаю, что моделирование того, как пользователь работает с пользовательским интерфейсом UC’ом называть не стоит. Я использую термин Usage Scenario вместо UC в таких случаях. Рекомендую глянуть Effective Use Cases книгу (Юра, могу дать почитать, у мну бумажная есть). Ну а ответ на вопрос "Да, можно, если хочеться / нужно / будет профит". Например, у нас в конторе пару лет назад так все и описывалось: Use cas’ы (с привязкой к UI) + mockup’ы и куча проектов успешно реализовано :) Но мы отошли от этого в пользу разделения требований на Business requirements->User requirements->Software requirements.
    Поделиться:

    Цитировать

    22.09.2010 в 12:22 # 17189
    Аватар (Snowball)
    Snowball
    Подписчик
    Здравствуйте.
    И все-таки каков правильный ответ на этот вопрос? Или его не существует?
    Поделиться:

    Цитировать

    22.09.2010 в 12:36 # 17190
    Имхо правильный ответ уже несколько раз звучал, может и завуалировано — все зависит от сложности проекта, доступных ресурсов и методологии разработки.
    Поделиться:

    Цитировать

    23.09.2010 в 03:55 # 17191
    Аватар (Snowball)
    Snowball
    Подписчик
    Понятно.
    А как по вашему, в каком разделе SRS (спецификации требований) можно поместить скрины и таблицы данных?
    Сейчас мы действуем по общепринятому стандарту IEEE 830-1998, но в нем, как мне кажется, очень большая свобода для маневров, в отличие от ГОСТов на создание ТЗ или ТП.
    И поэтому мне хотелось бы знать, как действует большинство, ну так сказать быть в мейнстриме.
    С уважением.
    Поделиться:

    Цитировать

Показано 15 ответов - от 1 до 15 (всего 18)

Вы должны авторизироваться для ответа в этой теме.