В теме 17 ответов, и 8 участников, последнее обновление сделано пользователем 
Юрий Веденин 14 г, 3 мес. назад.
-
Сообщения
-
Вот слышал такое мнение, что в системах, которые взаимодействуют с пользователями, для специфицирования функциональных требований можно обойтись одними юз-кейсами. Само собой, что можно добавить сюда еще макеты (mockups, wireframes, etc.) и маппинг одного на другое (например, на макетах будет обозначено, с помощью какого элемента можно вызвать какой юз-кейс).
Что скажете? Можно ли? Если нет, то почему или в каких случаях можно, а в каких — нет?Ну… При желании можно вообще одними словами обойтись — без написания спецификаций
. А можно сделать юз кейсы размером со слона и в них поместить всяко-разно требований (включая мокапы и т.д.). А можно скрам замутить и т.д… На мой взгляд — все зависит от ситуации — проекта, SDLC, имеющихся ресурсов и т.д. Но в одном я уверен исходя из опыта — для конечного приложения наилучший вариант (если условия позволяют) — это полноценная спецификация, детально и полностью описывающая требования к системе. Юз кейсы VS features? Юз кейсы не всегда описывают систему полностью, ведь кроме "сделать что-то с системой" есть функционал, который классическими юз кейсами не опишешь. Wireframes? Крутая штука, но допускает 90% девелоперского креатива при имплементации. здесь детальное описание каждого контрола незаменимо. В общем, я — за полноценный процесс разработки софта — с блэкджеком и SRS Соглашусь с Герычем, одними юз-кейсами не обойтись.
Допускаю такой вариант, что приложение очень простое, состоит не более чем из 10 страниц, наполнено статическим контентом и позволяет совершить 2-3 действия — здесь можно, конечно, ограничиться юз-кейсами да мокапами (хотя бы потому, что для такого маленького проекта не составит труда неочевидные моменты обговорить устно либо зафиксировать на салфетке). Но как быть, если приложение сложнее? Если присутствуют сложные вычисления, механизм roles and permissions, взаимодействия со сторонними системами? Где показать, к примеру, структуру xml запроса, отправляемого на сторонний сервис — в юз-кейсе или на мокапе? так что я считаю все зависит от специфики проекта. Часто можно пожертвовать теми или иными разделами спецификации, но выкинуть все, кроме юз-кейсов и мокапов — это чревато.Я так понял, что ответ Аси — в принципе можно.
Ответ Геры — всегда и везде полноценный SRS (:Действительно, ведь есть маааленькие, совсем не сложные с т. зрения бэкенд логики приложения.. У которых главная тема — это пользовательский интерфейс и какие-то простые функции… м? нет? не справимся юзкейсами и макетами?
Нее… Юра, не утрируй .
Я не имел в виду, что пипец только SRS и хоть вешайся — в противном случае не хочу работать…
Я согласен, что есть разные проекты и продукты.. да и не только — есть и разные методологии, и разный уровень аналитов, да и вообще наличие аналитов в команде не всегда есть реальность. Во всех этих случаях продукты получаются не хуже.
Так вот, отвечая на твой вопрос — да, можно. Но — если позволяют время и ресурсы, то лучше SRS (я не имею в виду полноценный шаблонный SRS здесь, скажем лучше спецификация в необходимом объеме).
Вот банальный пример — маааааалюсенькое приложение, состоящее из одного скрина с полями ввода данных. Нарисовал мокап, набабахал два юз кейса — сё гуд. Но ведь каждый контрол имеет свои особенности — обязателен ли для заполнения, автопостбэки с привязанной логикой, четкий формат и т.д. С помощью мокапов и юз кейсов этого не опишешь, ну то есть может и опишешь, если захочешь конечно, только смысл так над ними извращаться? А не имея всего этого — нужен либо постоянный контакт девелопера с аналитом, где аналит супервайзит девелопмент и тестирует сам перед сборкой, либо потом будет активный багофикс (вернее даже не багофикс, а доработка, ведь это не баги). Короч, как то так… Я надеюсь, что мысль свою донес.. По опыту анализа требований в нашей компании люди сходятся во мнении о том, что UI Prototype (сюда можно причислить что угодно, статические мокапы или динамический HTML прототип, кому что больше нравится и что в зависимости от ситуации наиболее удовлетворяет нуждам проекта), описание Use Cases и Domain Model покрывают 85% всех требований к продукту. Все остальные вещи типа GUI, NF-requirements, Business Rules и проч. зависят опять же от кокретного проекта.
На мой взгляд в данной ситуации под Use Cases нужно понимать скорее не те классические сценарии Вигерса, а прецеденты, или варианты использования. Ими удается очень подробно и наглядно описать требования (не только пользовательские, но и функциональные зачастую).
Так что в ответ на вопрос, можно ли обойтись одними юз кейсами, мой ответ: нет Ну или если аналитик молодец сам все еще и закодит, то ему и юз кейсы не понадобятся Анна, а можно в двух словах про отличие классических сценариев Вигерса от вариантов использования?Можно ли обойтись одними Use Case´ами?
Смотря для чего… и не понятно, что в данной поставновке вопроса подразумевается под Use Case´ами? Если подразумевается просто одна или даже несколько Use Case Diagram, где Use Case это овал, отражающий некую функциональность программной системы (без детализации потоков событий) то это одно, а если под ними подразумевается не только набор диаграмм, но и подробно описанные потоки событий (типовые, альтернативные, ошибочные, начальные и конечные состояния системы, точки ветвления) + экранные формы, то это уже другое.
Просто набор Use Case-диаграмм должен однозначно отображать всю функциональную бизнес-логику программной системы и каждое пожелание заказчика, связанное с функциональностью системы, должно иметь однозначное отражение в одном или нескольких Use Case´ах.
А набор из: Use Case-диаграмм + подробные сценарии + экранные формы = это уже первая действующая модель функционирования системы в рамках ее желаемой бизнес-логики, которую, можно и нужно обсуждать с заказчиком. У нас не написано ни строчки кода и даже нет никакой разработанной архитектуры системы, а мы уже показываем заказчику ее функционирование!!!А имеем ли мы право считать, допустим, экранные формы частью юз кейса? Я бы сказал, что юз кейс — это в максимальной интерпретации диаграмма + формальное текстовое описание. Скриншоты, мокапы и т.д. вроде бы причислять к контенту юз кейса не особо то и правильно.Так, стояночка (:
Под юз-кейсами тут не подразумевается толькоодна или даже несколько Use Case Diagram, где Use Case это овал, отражающий некую функциональность программной системы (без детализации потоков событий)
но под юз-кейсами тут не подразумевается и
не только набор диаграмм, но и подробно описанные потоки событий (типовые, альтернативные, ошибочные, начальные и конечные состояния системы, точки ветвления) + экранные формы
В частности, экранные формы однозначно не являются частью юз-кейсов.
Вот так будет вернее
"набор диаграмм и подробно описанные потоки событий (типовые, альтернативные, ошибочные, начальные и конечные состояния системы, точки ветвления)"Разобравшись в терминологии, каков будет ответ теперь?
5 коп. Всё зависит от детализации. Можно систему детально описать, используя только Use Cases. Но зачем? Для понятности каждой части спецификации есть свои методы. Например, детальное описание данных лучше иметь в Data Dictionary, UI — лучше увидеть [скрины], чем прочитать о них в UC. Etc, etc…UC — это способ моделирования / документирования поведенческого требования. Use case use cas’у рознь. Можно и процесс описать, и выполнение какой-либо пользовательской задачи.Считаю, что моделирование того, как пользователь работает с пользовательским интерфейсом UC’ом называть не стоит. Я использую термин Usage Scenario вместо UC в таких случаях. Рекомендую глянуть Effective Use Cases книгу (Юра, могу дать почитать, у мну бумажная есть). Ну а ответ на вопрос "Да, можно, если хочеться / нужно / будет профит". Например, у нас в конторе пару лет назад так все и описывалось: Use cas’ы (с привязкой к UI) + mockup’ы и куча проектов успешно реализовано Но мы отошли от этого в пользу разделения требований на Business requirements->User requirements->Software requirements.Здравствуйте.
И все-таки каков правильный ответ на этот вопрос? Или его не существует?Имхо правильный ответ уже несколько раз звучал, может и завуалировано — все зависит от сложности проекта, доступных ресурсов и методологии разработки.Понятно.
А как по вашему, в каком разделе SRS (спецификации требований) можно поместить скрины и таблицы данных?
Сейчас мы действуем по общепринятому стандарту IEEE 830-1998, но в нем, как мне кажется, очень большая свобода для маневров, в отличие от ГОСТов на создание ТЗ или ТП.
И поэтому мне хотелось бы знать, как действует большинство, ну так сказать быть в мейнстриме.
С уважением.
Вы должны авторизироваться для ответа в этой теме.
