Пользовательские Сценарии или как уйти от ВИ и перейти к иерархии ПТ(Прочитано 46989 раз)
1. Столкнулся с такой ситуацией, что трудно\не_нужно применение ВИ для описания Пользовательских Требований (ПТ). А ситуация такая, что Система не будет иметь четко разделенных ролей. Т.е. будет один пользователь и у него будут набираться права из ф-ций Системы. Т.е. классическая ERP\CRM система без четко разделенных ролей. Т.е. даже если разделить все на ВИ, то получится бред с точки зрения Д, т.к. будет один пользователь и куча ВИ к нему.

2. Пришли к такому мнению, что Описывать ВИ не надо, а описать ПТ в виде иерархии и разбития по модулям. Шаблон для описания ПТ был выбран - шаблон для ВИ.

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

Что скажите?
« Последнее редактирование: 20 Марта 2008, 16:06:31 от bas »
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Саша, немного сумбурно и не понятно.

Хотя в целом вопрос ясен. Итак, ты полагешь или констатируешь, что

1. есть некое не пустое множество функций в системе

2. есть некое непустое множество пользователей такой системе без четко выраженной роли

3. роль пользователя представляет собой абстракцию, определяемую текущим набором прав.

4. классификация ролей возможна, но не имеет смысла. Т.е. действительно некая группа пользователей может иметь одинаковый набор функций, но эта группа случайна и никак не определяет специфику роли

5. Одно из главных различий между вариантом использования и алгоритмом (функцией) заключается в том, что алгоритм (функция), который может содержать некоторую последовательность шагов, не будет (не должен) отображать диалог между пользователем и системой. Т.е. если функция системы (ERP-CRM) не отражает диалог пользователя с системой, то очевидно использовать ВИ не следует, в противном случае нужно писать вариант использования.

6. Поскольку функций в системе может быть много, они так или иначе могут быть классифицированы по типу и следовательно распределены по пакетам, так что большое количество ВИ на одной диаграмме не такая уж проблема. С другой стороны совершенно необязательно строить такую диаграмму, если она не целесообразна

7. ВИ не единственный инструмент описания требований пользователя. Для этого можно испрользовать пользовательские истории.

8. Для более детального анализа сказанного Сашей, хотелось бы увидеть все-таки некоторые примеры, поскольку пункт 3 неясен и не новичку (какую технику? почему автор полагает что такая техника возможна, как понять не ошибается ли автор в своих суждениях по данной теме?)



Эд,

Все верно. Это что-то среднее между Пользовательской Историей (ПИ) и ВИ. Как я представляю ПИ все-таки не структурируются, не живут долго и пишутся без особого шаблона и взаимосвязей. Мы же предполагаем опираться на эти ПТ как на одни из основных требований на данный момент и в будущем, и если же надо будет их детализировать, то будет это делать с помощью функц. треб. (ФТ).

Пример, ну самый простой - Справочники:
* Редактировать справочник
Сценарии:
- Просмотреть
- Добавить
- Удалить
- Редактировать
- Копировать
** Редактировать Категорию товара
** Редактировать свойства Товара
** ....

* - означает корневое ПТ
** - означает детализацию ПТ (в частности тут наследие используется)
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Саша, я думаю ты находишься под впечатлением RUP или другой методологии. Вариант использования - это и есть пользовательская история. Разница лишь в акцентах.

ВИ допускает любую форму описания и неформальную и формальную - способ записи зависит от процесса или стратегии разработки.

Однако спорить не буду.

Перечисленные тобой функции - совершенно не ВИ, а лишь части ВИ. Например ВИ : Управления справочниками - типичный CRUD ВИ и ничего более. Есть даже целый проработанный шаблон где указывается пользователь и два ВИ: CRUD и X information




Пользовательские требования рассматривают систему с перспективы самого пользователя и тех бенефитов\целей которые он имеет по отношению к системе. Если возможных вариантов использования очень много и нельзя выделить конкретный ВИ,  думаю имеет смысл сосредоточится на функциональных требованиях.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Перечисленные тобой функции - совершенно не ВИ, а лишь части ВИ. Например ВИ : Управления справочниками - типичный CRUD ВИ и ничего более. Есть даже целый проработанный шаблон где указывается пользователь и два ВИ: CRUD и X information

Эдуард, а как же описывать такой вариант использования?
Например, есть вариант использование "Управление справочниками", который, по вашему, включает в себя функции (шаги) создание, удаление, редактирование справочника. Это очень громоздкий ВИ с кучей альтернативных потоков. Имхо, каждая операция CRUD -  это отдельные ВИ, потому, что она содержит в себе различные действия, вызываются различные формы пользовательского интерфейса.

Может я и не прав, но в проекте, в котором я участвую,  ситуация аналогична той, что у Александра.
Система (аналог ECM) не имеет как такового пользователя (отдельного актора), а имеются лишь наборы прав (роли), которые позволяют пользователю использовать различные услуги системы.
Получается, что основные варианты использования такой системы это управление каталогами, управление таксономией, управление контентом, управление правами пользователя и др. Мы же сделала описанное выше пакетами ВИ, каждый из которых состоит из ВИ создать, удалить, отредактировать и т.д. Получается такой подход не правильный?
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



Виталий,

Это будет уже не ВИ, ВИ - это в первую очередь цель пользователя, ну какая цель в удалении Справочника, если его даже еще нет?
В том то и дело, что это уже не ВИ, это больше ПИ, но описанные в виде шаблона ВИ, что мне показалось очень удобно.

Юра,
А чем тебе не нравится подход, кот. я предложил?
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Эдуард, а как же описывать такой вариант использования?
Получается, что основные варианты использования такой системы это управление каталогами, управление таксономией, управление контентом, управление правами пользователя и др. Мы же сделала описанное выше пакетами ВИ, каждый из которых состоит из ВИ создать, удалить, отредактировать и т.д. Получается такой подход не правильный?
Виталий, во-первых, ВИ - это некое удобное средство, возникшее в результате практики. Это не математическая концепция или физический закон. Потому, естественно, Вы используете это так, кк считаете нужным. Но следует прислушаться к мнению специалистов, которые пришли к такому решению

Вот описание CRUD Ви из книги Gunnar Övergaard, Karin Palmkvist. Use Cases Patterns and Blueprints

Intent
Merge short, simple use casessuch as Creating, Reading, Updating, and Deleting pieces of information into a single use case forming a conceptual unit.

Keywords: Create data, delete data, information handling, merge use cases, read data, short flow, short use case, simple operation, update data.
 
Patterns
CRUD: Complete  (см. ris1)

Description
The CRUD: Complete pattern consists of one use case, called CRUD Information (or Manage Information), modeling all the different operations that can be performed on a piece of information of a certain kind, such as creating, reading, updating, and deleting it.

Applicability
This pattern should be used when all flows contribute to the same business value and are all short and simple.

Type
Structure pattern.

CRUD: Partial
Model (см. ris2)

Description
An alternative pattern models one of the alternatives of the use case as a separate use case.

Applicability
This pattern is preferable when one of the alternatives of the use case is more significant, longer, or much more complex than the other alternatives.

Type
Structure pattern.

Discussion
Quite often systems handle information that, from the system's viewpoint, is very easily created in the system. After a simple syntax or type check, and perhaps some trivial calculation or business-rule check (see Chapter 16, "Business Rules"), the information is simply stored in the system. No advanced calculations, verifications, or information retrieval will have to be performed. The description of the flow is only a few sentences long, and there are probably not more than one or two minor alternative paths in the flow. Reading, updating, or deleting the information are equally simple operations. Each of them can be described in a few sentences.

Should such operations be modeled as use cases and, if so, must they be included in the use-case model? The answer to both questions is yes. They are indeed use cases because something is to be performed in the system; someone is to use the system to create (read, delete, update) some piece of information in the system. Moreover, they must be included in the use-case model, or the model will not be complete. If these use cases are not included in the model, some stakeholder will probably miss them; otherwise, the functionality should not have been included in the system in the first place.

Luckily, this does not necessarily mean that this kind of functionality should be expressed as separate use cases. Instead, according to the CRUD: Complete pattern, we group them together in so-called CRUD use cases, including all four types of operations on some kind of informationcreation, reading, updating, and deletion of any such information.

This procedure has a few obvious advantages. First, the size of the model will be reduced, which will make it easier to grasp because the number of use cases will be reduced. Second, nobody will be interested in a system containing only a subset of these use cases (for example, read and delete, but not create and update). Grouping these flows together in a single use case called something like CRUD X ensures that all four are included in the model, and makes it clear to every reader of the model that this is the use case where all this functionality is captured. Third, the value of each of the separate use cases is very small (if any) for the stakeholders; it is the whole collection of them that gives a value to the stakeholders. Together these use cases form one conceptual unit (see Figure 20.1).

Note that if only some of the four operations are simple while others are complex, you can group the simple operations into one use case and let the other ones be modeled as separate use cases, according to the CRUD: Partial pattern.

Note also that this is a typical situation where a use case does not have only one basic flow. None of them can be said to be more "basic," or "normal," than the others. Therefore, a CRUD use case will typically have four basic flows, and possibly a few alternative flows, as is shown in the following example.

An instance of a CRUD use case will perform either a creation, a reading, an updating, or a deletion, and after that it will cease to exist. This instance will not continue to live and wait for the next operation to be performed. That operation will be performed by another instance of the same use case.

A so-called CRUD use case may of course include other (basic) flows than the four common ones, such as searching for an item, or performing some simple calculation based on an item.

It is important not to merge advanced or complex operations into one use case. They should remain separate use cases instead, because they will probably be developed, reviewed, designed, and implemented separately.

As a general rule, when not sure whether to merge the different usages into one use case or to keep them as separate use cases, they should no doubt be kept apart. This decision will not affect the functionality of the system, only the model structure and hence its maintenance.

Example
This section provides an example of the CRUD: Complete pattern. It models the registration of a new task to be performed sometime in the future, the modification of a registered but not performed task, the cancellation of such a task, and the presentation of tasks that either failed during their execution or have not yet been performed (see Figure 20.2). As you can see, the four different alternatives are quite simple and short, and they are expressed as four basic flows, because none of them can be said to be superior to the others. Therefore, this is an application of the CRUD: Complete pattern even if some of the four basic flows in this case are different from the standard ones.

см ri3. The CRUD Task use case models the creation, modification, presentation, and cancellation of a task.

Error handling and exceptional flows are expressed as alternative flows of the use case.

The Item Look-Up and the Future Task blueprints are also useful in this example.

Use Case: CRUD Task
Brief Description

The use case registers, modifies, or cancels the information about a task to be performed as stated in information received from the Task Definer.

Basic Flow

The use case has four different basic flows:

Register Task

Modify Existing Task

Cancel Task

View Tasks That Failed

REGISTER TASK

The use case starts when the Task Definer chooses to register a new task. The use case presents a list of possible kinds of tasks to the Task Definer, and asks what kind of task is to be registered, what name it is to be assigned, and when it is to be performed.

The Task Definer enters the required information. The use case checks whether the specified time is in the future and whether the name of the task is unique.

The use case registers a new task in the system and marks the task as enabled.

The use case ends.

MODIFY EXISTING TASK

The use case starts when the Task Definer chooses to modify an already registered task. The use case retrieves the names of all the tasks not marked as active and presents them to the Task Definer.

The Task Definer selects one of the tasks. The use case retrieves the information about the task and presents it to the Task Definer.

The Task Definer modifies any of the presented information except the name of the task.

The Task Definer accepts the information. The use case checks whether the specified time is in the future and, if so, stores the modified information.

The use case ends.

CANCEL TASK

The use case starts when the Task Definer chooses to cancel a task. The use case retrieves all the tasks not marked as active.

The Task Definer selects one of the tasks. The use case retrieves the information about the task and presents it to the Task Definer.

If the Task Definer confirms the cancellation, the use case removes the task; otherwise, no modifications are made.

The use case ends.

VIEW TASKS THAT FAILED

The use case starts when the Task Definer chooses to view a list of all the tasks that have failed. The use case collects all the tasks with the status failed and presents their names to the Task Definer.

The use case ends.

Alternative Flows

CANCEL OPERATION

The Task Definer may choose to cancel the operation at any time during the use case, in which case any gathered information is discarded, and the use case ends.

INCORRECT NAME OR TIME

If the name of the task is performed not unique or the time is not in the future, the Task Definer is notified that the information is incorrect and is requested to re-enter the incorrect information.

The Task Definer re-enters the information. The flow resumes where the check of the information is performed.
 
Analysis Model
The analysis model of a CRUD use case is based on all the flows of the use case. It must include the realization of all the basic flows as well as the realization of the alternative flows.

However, because the flows are quite simple in this case, the model usually contains one boundary class for presentation and modification of the information, one control class to handle any checks, and one entity class (or perhaps a few) to store the information (see Figure 20.3). The flow starts in the System Form when the Information User requests to create, read, update, or delete the information. An instance of the Information Handler is created, which opens an instance of the Information Form to the Information User.

см. ris4. An analysis model of a CRUD use case.

Depending on the chosen operation, the actor enters information about a new piece of information, or the Information Handler retrieves existing information and asks the Information User via the Information Form to select one item. The Information Form sends the new information or the identity of the selected item, respectively, to the Information Handler which performs the chosen operation. Finally, the Information Form and the Information Handler are removed and the use case ends.




Мы же предполагаем опираться на эти ПТ как на одни из основных требований на данный момент и в будущем, и если же надо будет их детализировать, то будет это делать с помощью функц. треб. (ФТ).

Виталий,
Это будет уже не ВИ, ВИ - это в первую очередь цель пользователя, ну какая цель в удалении Справочника, если его даже еще нет?
В том то и дело, что это уже не ВИ, это больше ПИ, но описанные в виде шаблона ВИ, что мне показалось очень удобно.

Александр, действительно хорошая идея.
Проводя аналогию с тем, что делаю в своем проекте, прихожу к выводу, что мы с Вами столкнулись с одной и той же проблемой. А именно, как описывать пользовательские требования для "инфраструктурных" систем, т.е. систем которые не несут как таковую бизнес-логику для пользователя, а предоставляют некоторый функционал, который пользователь будет использовать для построения необходимой для него логики.
Например, из различных функций (создать каталог, добавить файл, послать сообщение) будет выстраиваться некий процесс, который уже имеет смысл для пользователя, т.е. ЦЕЛЬ.

Тогда получается, что в данном случае от варианта использования остается лишь каркас, для удобного описания и представления этих так называемых ПТ?
У нас следующий подход:
1. Мы описываем функционал (можно наверное назвать его ПТ) используя ДВИ (см. файл)
2. Далее каждую функцию описываем в виде сценария и/или диаграммы деятельности (ДД)
3. Анализируя, получаем классы анализа
4. Действия из ДД дробятся на более детальные функции системы (мы называем их системными функциями)
5. Создаем диаграммы последовательности используя полученные системные функции
6. Распределяем системные функции по компонентам системной архитектуры (трехслойная по Фаулеру). Многие системные функции как у нас получилось используются в нескольких ПТ.
Если я правильно понял, Александр, Вы предлагаете именно такой подход, только называя это другими именами.
Мы тоже называем их не ВИ, а функциональными узлами (operational nodes), т.к. используем MODAF.

Эдуард, спасибо за подсказку. Теперь понимаю свою ошибку. :)
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



Виталий и Саша, а чем Вас не устраивает обычная техника описания функциональных требований, например, которая приведена у Вигерса?

Кстати, у Ливенгуэлла приведены достаточно понятные аргументы когда имеет смысл, а когда нет использовать варианты использования.

Хотя, мне кажется, неважно что и как Вы используете, главное, если внутри команды есть понимание, то значит все окей.



Виталий,
Мы предполагаем использовать примерно такой подход как Вы описываете. Только не надо их называть ВИ и делать ДВИ, в последней ИМХО нет смысла, да и не правильно это. Возможно надо посмотреть SysML, мне кажется там можно делать Д из требований.

Эд,
Ну то, что мы описываем, есть именно ПТ, не ф-ые. Т.е. это некий сценарий между Пользователем и Системой, это не только то что делает Система.
Вообще у меня есть идея как-то оформить этот подход и назвать это как - Пользовательский Сценарий.
Мне хотелось проверить, что я не изобретаю велосипед ...
« Последнее редактирование: 10 Февраля 2008, 00:44:54 от bas »
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Наткнулся в интернете на книжку по управлению требованиями
(http://www.ibmpressbooks.com/bookstore/product.asp?isbn=0321383001).
Так как книга новая, я не смог ее найти в электронном виде (может плохо искал :)).
Дак вот, автор предлагает добавить в пирамиде иерархии требований, ниже ВИ, еще и сценарии. Это конечно, обычный РУПовский подход, но мне показалось, что можно прикрутить его к текущей ситуации, т.е. под вариантом использования понимать, например, управление справочником, а под сценариями - создание, удаление, копирование и др.
Вобщем почитайте, если интересно (см. аттач)
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



Виталий, на мой взгляд в книге нет ничего принципиально нового.

Что такое ВИ. Это некоторая спецификация целевого использования пользователем системы. Т.е. ВИ определяет цель использования системы. Реализация такого использования в рамках одной цели может приводить по сути к разным результатм: успешное достижение цели или неуспешное, либо частичное.
 
ВИ описывает некоторое множество возможных сценариев, путей протекания ВИ. ВИ как минимум состоит из основного потока(сценария) и альтернативных  потоков(сценариев). Метафора штанов у Коберна.

Каждый сценарий (будучи реализованный) естественно требует тестирования его реализации



Предлагаю продолжить дискуссию, п.ч. о чем я говорю, многим кажется спорным.
Прикладываю свой доклад на РИТ для этого.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Предлагаю продолжить дискуссию, п.ч. о чем я говорю, многим кажется спорным.
Прикладываю свой доклад на РИТ для этого.
Александр, если можно опишите кратко по пунктам основные отличия ПС от ВИ, а то я немного запутался 8)
Если различие только в том, что для описания ПС мы не используем диаграммы, то это еще не говорит о том, что это не ВИ
Вигерс, кстати называет ВИ - именно пользовательскими требованиями, мне кажется что ВИ - это нечто среднее между пользовательскими требованиями и функц. требованиями, так как из них прослеживаются как те, так и другие.
Посмотрев сценарий описанного вами ПС, не увидел разницы с ВИ -> действие пользователя - ответ системы, как реакция на действие пользователя.
Единственное отличие в том, что в альтернативные сценарии представляют собой отдельный функционал, который является неким расширением основного функционала и под одним ПС собраны все функции, оперирующие конкретным объектом управления, например справочником
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19