В теме 23 ответа, и 6 участников, последнее обновление сделано пользователем 
Андрей В. 13 г, 8 мес. назад.
-
Сообщения
-
Заинтересованные стороны не понимают этого.
Как им просто и наглядно объяснить, что я от них хочу. Хочу получить различные варианты использования будущего продукта.Попробуйте внедрить в использование Case Complete. Имхо система вам неплохо подойдет — она позволит вам и грамотно поддерживать требования в виде атомарных структурированных единиц, и может генерировать спеки автоматом на основе вашей иерархии требований.
Case Complete, помимо прочего, еще и предоставляет обучающую презентацию для заказчика на предмет того, зачем вообще на проекте юз кейсы (мы же о юз кейсах говорим или я ошибаюсь?)
Сама презентаха в аттаче. Сам с ее помощью заказчика не обучал, поэтому за результат не ручаюсь.
Если честно, не понимаю, зачем вообще заказчику объяснять что такое ВИ? Они должны видеть только описанные ВИ, а вот читаются ли, и понимаются ли эти ВИ правильно, это зависит от аналитика. Разве не так? Прошу прощения, если что-то не так понял.Или вы хотите, чтобы заказчик сам писал ВИ?
Не уверена, в каком значении вы используете "пользовательские сценарии": как варианты использования (Use Cases) или как популярный инструмент юзабилистов. Но в любом случае для того, чтобы объяснить, зачем это нужно, я бы сказала, что успех продукта у пользователей зависит от того, позволяет ли он пользователям достигать своих целей с высокой эффективностью и соответствует ли их ожиданиям. А для того, чтобы продукт все это умел, необходимо понимать, что нужно пользователю, к чему он привык, какие действия в его работе можно упростить/автоматизировать и тому подобное. Понимание потребностей пользователя необходимо для того, чтобы система в итоге оказалась востребованной. А пользовательские сценарии — как раз мощный инструмент для этого.
Одна из самых модных и, как показывает практика, успешных тенденций сегодня — это проектирование не отдельных фич, а целых сценариев или workflows, при которых продумывается огромное количество нюансов, вплоть до контекста использования. Такое представление — в виде сценария — позволяет четко определить цели (а это значит, что продукт не обрастет ненужными функциями, которым не соответствуют реальные цели реальных пользователей), условия, влияющие на процесс (а здесь часто всплывают забытые или пропущенные требования) и другие особенности. Именно сценарии позволяют спроектировать взаимодействие. Самый крутой графический интерфейс с шикарным дизайном не спасет систему, если взаимодействия не продуманы.
И еще, советую не тешить себя надеждой, что заказчик сам предоставит вам годные сценарии или ВИ. Всякое бывает, конечно, но готовьтесь к тому, что продумывать их придется вам. Поэтому я бы ставила вопрос не прямо "раскройте, пожалуйста, основные пользовательские сценарии в проектируемом продукте", а иначе, постепенно проясняя для себя непонятные моменты, например, "Какую информацию должен получить пользователь до, после и во время выполнения задачи? Что он делает с ней?" и т.д. и т.п.Благодарностей: 1 Цитировать
Прошу прощения за долгое молчание. Благодарю всех за ответы! Вы мне очень помогаете! После обеда отпишусь подробней, а пока время обеда
([u]мы же о юз кейсах говорим или я ошибаюсь[/u]?)
Если это действительно варианты использования (ВИ, Use Cases, UC)
Если это user stories
Не уверена, в каком значении вы используете "пользовательские сценарии": как варианты использования (Use Cases) или как популярный инструмент юзабилистов.
Мои знания основываются на двух книгах и нескольких статьях (буду благодарен за наводки. По идеи здесь уже должна быть такая тема).
Вот что я понимаю под «Пользовательские сценарии»1) «Варианты использования – это последовательность взаимодействий пользователя и программы в типичной ситуации.»
Книга «Технология разработки программного обеспечения» Эрик Дж. Брауде, 2004. – 655 с.: ил.
2) «Давно было подмечено, что сценарии использования – это очень хороший способ
моделирования того, что люди делают, или того, что они хотели бы иметь возможность делать. Сценарии во многом соответствует тому, как люди думают о своей работе и о своих проблемах. Сценарий может быть разработан совместно с заинтересованной стороной и в дальнейшем использоваться как основа для обсуждения требуемых возможностей.»«Сценарии стимулируют человека (представителя заинтересованной стороны)
задумываться не только о том, как он в данный момент выполняет свою работу, но и о том, как бы он хотел ее делать в будущем. Это ведет к тому, что люди многократно «проигрывают» (репетируют) в уме разные сценарии того, как они хотели бы это делать.»Книга «Разработка и управление требованиями. Практическое руководство пользователя (Второе издание)» , Telelogic 2005
Пользовательские сценарии, варианты использования, сценарии использования – это одно и тоже или разные вещи?
Заметил, что постоянно используются аглицкие термины и не только в этой теме. Для этого есть какие то причины? Я думаю, что это вводит только дополнительную путаницу ибо на русском ясно и понятно. Возможно, я чего то не понимаю ибо начинающий, так что просьба не пинать сильно
Вот аглицкие словечки «юз кейсы, Use Cases, UC, user stories, инструмент юзабилистов.» что под ними вы понимаете? Это одно и тоже?
Привет,Отпишусь за себя. Книгу эту не читал, но судя по описанию вроде бы это и есть варианты использования.
Насчет английской терминологии — 3 причины:
1) Большинство присутствующих здесь аналитиков работают на иноязычных заказчиков. Английские термины как-то сами собой влазят в мозг .
2) Количество доступных для обучения материалов (книги, статьи, форумы и т.д.) на английском в сотни раз превышает то, что есть на русском. Поэтому вместо того, чтобы искать, а что есть на русском, лучше искать то, что достойно изучения (и скорее всего найдено оно будет только на английском).
3) Я лично принципиально читаю все материалы только на английском, потому что это несет value для пункта 1 выше (тренируется восприятие англ. языка).Пользовательские сценарии, варианты использования, сценарии использования – это одно и тоже или разные вещи?
Вот, что говорит Википедия о пользовательских историях (user stories) и сценариях (вариантах) использования:
Хотя пользовательские истории и сценарии использования служат единой цели документирования пользовательских требований с точки зрения взаимодействия между пользователем и системой, между ними есть различия.
Пользовательские истории это небольшое и удобное в работе представление информации. Они сформулированы на ежедневном языке пользователя и содержат небольшие детали, таким образом оставаясь открытыми для интерпретации. Они помогают читателю понимать что должна делать система.
Сценарии использования, в отличие от пользовательских историй, описывают процесс и его шаги подробно, и могут быть сформулированы с точки зрения формальной модели. Сценарий самодостаточен. Он обеспечивает всю необходимую информацию и детали для понимания. Сценарий описывается как «обобщенное описание ряда взаимодействий между системой и одним или более агентами, где агент — пользователь или другая система».От себя я бы добавила, что у пользовательских историй, вариантов использования и пользовательских сценариев в общем и целом одни цели: понять, как пользователи будут работать с продуктом и как они хотели бы это делать. А вот форма у всех методов разная. Пользовательские истории (User Stories) связаны, если я не ошибаюсь, с такой методологией разработки ПО как Scrum, чем обусловлен их формат: Каждая пользовательская история ограничена в размере и сложности. Часто история пишется на маленькой бумажной карточке.
Варианты использования (или сценарии использования — это синонимы) растут из UML, из Use Case диаграммы. Это наиболее формализованный способ описания того, как пользователи будут взаимодействовать с системой (вот здесь можно найти даже готовые шаблоны). Как правило сначала рисуется диаграмма, а потом готовится подробное описание каждого варианта использования. Описания вариантов использования похожи на алгоритмы, в них практически полностью отсутствуют "лирические отступления".
Что касается сценариев, которые используются юзабилистами (user scenario): в них акцент зачастую ставится на контекст использования, они менее формальны, в них допускаются лирические отступления. Ни в User Stories, ни в Use Case-ах, как правило, мысль не идет по пути: "Судя по всему, продукт будет использоваться с мобильных устройств в дороге, следовательно, необходимо предусмотреть следующее…". Это уже не описание в духе:
1. Пользователь нажимает на кнопку
2. Система отображает форму
А скорее: "Пользователь находится в шумном месте, держит мобильный телефон одной рукой и хочет попасть на такой-то сайт. Вокруг многолюдно, пользователь не хочет, чтобы окружающие видели, что это за сайт" и т.п.Заметил, что постоянно используются аглицкие термины и не только в этой теме. Для этого есть какие то причины? Я думаю, что это вводит только дополнительную путаницу ибо на русском ясно и понятно.
Причина в том, что большинство форумчан работают на англоязычных проектах, и эти термины настолько привычны, что их использование перестаешь замечать. Ну и мое мнение: многие русские аналоги английских терминов просто ужасны.
Попробуйте внедрить в использование Case Complete. Имхо система вам неплохо подойдет — она позволит вам и грамотно поддерживать требования в виде атомарных структурированных единиц, и может генерировать спеки автоматом на основе вашей иерархии требований.
Case Complete, помимо прочего, еще и предоставляет обучающую презентацию для заказчика на предмет того, зачем вообще на проекте юз кейсы ([u]мы же о юз кейсах говорим или я ошибаюсь[/u]?)
Сама презентаха в аттаче. Сам с ее помощью заказчика не обучал, поэтому за результат не ручаюсь.Благодарю! Интересная программа.
Для установки она требует установки всех версий Microsoft.NET Framework!? Я в замешательствеПопробую её поставить сегодня.
Если честно, не понимаю, зачем вообще заказчику объяснять что такое ВИ?
Я должен понять, как заказчик предполагает использовать будущий продукт ибо
«Сценарии стимулируют человека (представителя заинтересованной стороны)
задумываться не только о том, как он в данный момент выполняет свою работу, но и о том, как бы он хотел ее делать в будущем. Это ведет к тому, что люди многократно «проигрывают» (репетируют) в уме разные сценарии того, как они хотели бы это делать.»Они должны видеть только описанные ВИ, а вот читаются ли, и понимаются ли эти ВИ правильно, это зависит от аналитика. Разве не так? Прошу прощения, если что-то не так понял.
Грамотно оформленный варианты использования это уже моя забота (и это кстати тянет на отдельную тему
). Здесь же и будут уточняющие вопросы.Или вы хотите, чтобы заказчик сам писал ВИ?
Я хочу чтобы заказчик показал/объяснил/ написал как он предполагает использовать будущий продукт. Личного контакта нет, только почта.
Если честно, не понимаю, зачем вообще заказчику объяснять что такое ВИ?
Я должен понять, как заказчик предполагает использовать будущий продукт ибо
«Сценарии стимулируют человека (представителя заинтересованной стороны)
задумываться не только о том, как он в данный момент выполняет свою работу, но и о том, как бы он хотел ее делать в будущем. Это ведет к тому, что люди многократно «проигрывают» (репетируют) в уме разные сценарии того, как они хотели бы это делать.» (см. выше)Они должны видеть только описанные ВИ, а вот читаются ли, и понимаются ли эти ВИ правильно, это зависит от аналитика. Разве не так? Прошу прощения, если что-то не так понял.
Грамотно оформленный варианты использования это уже моя забота (и это кстати тянет на отдельную тему
). Здесь же и будут уточняющие вопросы.Или вы хотите, чтобы заказчик сам писал ВИ?
Я хочу чтобы заказчик показал/объяснил/написал как он предполагает использовать будущий продукт. Личного контакта нет, только почта поэтому вероятнее что он напишет.
Не уверена, в каком значении вы используете "пользовательские сценарии": как варианты использования (Use Cases)
Ответил выше.
или как популярный инструмент юзабилистов.
Что сие такое?
Вроде нашел. Ответ дан выше то бишь здесь.Но в любом случае для того, чтобы объяснить, [b]зачем[/b] это нужно, я бы сказала, что успех продукта у пользователей зависит от того, позволяет ли он пользователям достигать своих целей с высокой эффективностью и соответствует ли их ожиданиям. А для того, чтобы продукт все это умел, необходимо понимать, что нужно пользователю, к чему он привык, какие действия в его работе можно упростить/автоматизировать и тому подобное. Понимание потребностей пользователя необходимо для того, чтобы система в итоге оказалась востребованной. А пользовательские сценарии — как раз мощный инструмент для этого.
Понятно. Это важно конечно, но вопрос «зачем» не стоит. Скорее всего как они хотят им пользоваться…
Одна из самых модных и, как показывает практика, успешных тенденций сегодня — это проектирование не отдельных фич, а целых сценариев или workflows, при которых продумывается огромное количество нюансов, вплоть до контекста использования. Такое представление — в виде сценария — позволяет четко определить цели (а это значит, что продукт не обрастет ненужными функциями, которым не соответствуют реальные цели реальных пользователей), условия, влияющие на процесс (а здесь часто всплывают забытые или пропущенные требования) и другие особенности. Именно сценарии позволяют спроектировать [i]взаимодействие[/i]. Самый крутой графический интерфейс с шикарным дизайном не спасет систему, если взаимодействия не продуманы.
Да. Сценарии нужны.
И еще, советую не тешить себя надеждой, что заказчик сам предоставит вам годные сценарии или ВИ.
Окончательная обработка и анализ с уточнениями за мной.
Всякое бывает, конечно, но готовьтесь к тому, что продумывать их придется вам. Поэтому я бы ставила вопрос не прямо "раскройте, пожалуйста, основные пользовательские сценарии в проектируемом продукте", а иначе, постепенно проясняя для себя непонятные моменты, например,
Готовое ВИ от заказчика никто не требует, но видение его мне надо получить.
Я думаю, что без заказчика и информации о продукте мне одному не придумать сценарии. Или можно?"Какую информацию должен получить пользователь до, после и во время выполнения задачи? Что он делает с ней?" и т.д. и т.п.
Хорошие вопросы! Запишем в вопросник
Привет,
Привет
Понятно. У нас все местные заказчики.
Читать и понимать книги на английском мне пока не светит. С SVN, Bugzilla и JIRA разбирался на английском. Очень долго это. У меня пока нет время на это. Предполагаю, что книги по требования будут сложнее чем эти продукты.[quote="Belle Morte"]
или как популярный инструмент юзабилистов.Что сие такое?
[/quote]
Если вкратце, то usability (дословно — "удобство использования", но чаще на русском так и говорят — "юзабилити") при разработке пользовательских интерфейсов обозначает обеспечение удобства программного обеспечения для пользователя. Юзабилист, соответственно, это специалист по юзабилити. А пользовательские сценарии — это один из методов, которые они используют в своей работе.[quote="Belle Morte"]
Но в любом случае для того, чтобы объяснить, [b]зачем[/b] это нужно, я бы сказала, что успех продукта у пользователей зависит от того, позволяет ли он пользователям достигать своих целей с высокой эффективностью и соответствует ли их ожиданиям. А для того, чтобы продукт все это умел, необходимо понимать, что нужно пользователю, к чему он привык, какие действия в его работе можно упростить/автоматизировать и тому подобное. Понимание потребностей пользователя необходимо для того, чтобы система в итоге оказалась востребованной. А пользовательские сценарии — как раз мощный инструмент для этого.Понятно. Это важно конечно, но вопрос «зачем» не стоит. Скорее всего как они хотят им пользоваться… [/quote]
Вопрос "зачем" очень важен, и, как ни странно, не стоит он очень часто, а зря. Я знаю людей, которые используют MS Excel для того, чтобы в нем рисовать макеты интерфейсов. Выглядит это ужасно. Это неудобно, ненаглядно, неэффективно. Такого рода пользователи скажут вам: "Нам нужен Excel", не конкретизируя, зачем он им нужен. А возможно есть лучшее решение, вот только увидеть его можно лишь зная, в чем конечная цель пользователей, зачем им вообще нужна какая-либо система.Belle Morte, благодарю за ответ.Я знаю людей, которые используют MS Excel для того, чтобы в нем рисовать макеты интерфейсов. Выглядит это ужасно. Это неудобно, ненаглядно, неэффективно. Такого рода пользователи скажут вам: "Нам нужен Excel", не конкретизируя, зачем он им нужен. А возможно есть лучшее решение, вот только увидеть его можно лишь зная, в чем конечная цель пользователей, зачем им вообще нужна какая-либо система.
Хм… возможно я не так вас понял, но лучше спросить-уточнить чем промолчать.
Я думал, что цель в начале определяется, а в конец пользовательский интерфейс. Вроде и в книгах так пишут. После оценки пользовательского интерфейса может измениться цель?Хм… возможно я не так вас понял, но лучше спросить-уточнить чем промолчать.
Я думал, что цель в начале определяется, а в конец пользовательский интерфейс. Вроде и в книгах так пишут. После оценки пользовательского интерфейса может измениться цель?Разумеется, прежде всего определяется цель, все остальное, в том числе и пользовательский интерфейс, создается уже с учетом известной цели. Наверное я не очень понятно описала пример, поясню: представьте, что вы проектируете систему. Заказчик говорит, что ему нужно "что-то вроде Excel-а, только чтобы меню было не сверху, а слева". Что сделает хороший аналитик: опишет то, чего хочет клиент, и в итоге по его спецификации создадут второй Excel. Он будет соответствовать требованиям клиента, но станет ли работа в нем эффективнее?
Что сделает отличный аналитик: прежде всего, он спросит, зачем заказчик использует Excel. И если узнает, что заказчик использует его для рисования макетов, посоветует 10+ других инструментов, в которых этот процесс лучше, проще и эффективнее, и на их основании предложит, если нужно, новое решение, заточенное под нужды заказчика. Заказчик может никогда и не слышать об этих инструментах — задача отличного аналитика придумать, как можно улучшить процесс.
Зная цель, всегда можно определить оптимальные средства для ее достижения. Если же заказчик начинает со средств, не говоря о целях, невозможно оценить, насколько они эффективны.
Вы должны авторизироваться для ответа в этой теме.
