1

Варианты Использования (Use Case) / Re: Диаграмма использования при определении образа и границ системы

« : 15 Сентября 2011, 15:48:04 »

Ответ на вопрос, ради которого я создавала тему, я уже получила. Спасибо ответившим.  Не следовало упоминать в документе об образе и границах такие функции, как сохранение и удаление, а потому и в диаграмме их быть тоже не должно.

Что значит будет системный, а Вы какие рассматриваете?

Да, конечно, я неточно выразилась. Я имела в виду действия, совершаемые системой и пользователю малоинтересные, как те же удаление и сохранение данных. Но распознавание я пожалуй в диаграмму включила бы.

Вы фотографируете объект, потом система по вашей команде его распознает. Эти две операции могут быть совершенно самостоятельными и транзакционно завершенными:
сфотали сохранили в хранилище телефона
потом запустили распознавалку, извлекли фотку, распознали, сохранили

Согласна.

Какова основная задача или цель использования МУ?
Нечто вроде Занести расход на лицевой счет пользователя - это что за цель? цель пользователя. Зачем это делается - все за кадром. Это и есть системный ВИ, а не бизнес ВИ...

А если наше приложения для МУ будет частью некой системы учета личных расходов? Допустим, основной функционал уже работает, а этой доработкой для МУ мы его только расширяем. Оптимизируем операцию ввода данных. Ввод и передача данных – основные UC, для нашей доработки они будут уровня БВИ.

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

2

Варианты Использования (Use Case) / Re: Диаграмма использования при определении образа и границ системы

« : 14 Сентября 2011, 14:30:59 »

Распознать объект данных

Так это тоже будет системный ВИ. Пользователям то, что система распознает данные, так же интересно, как и то, что она их сохраняет, а после передачи удаляет.

Основная функция приложения на мобильном устройстве - ввод данных о расходах и передача их в основную БД на лицевой счет пользователя. Поэтому фотографирование и ввод с клавиатуры объединены общим UC. Фотографирование лишь способ быстрого ввода данных. А в первой версии диаграммы распознавание было упущено, да.)

3

Варианты Использования (Use Case) / Re: Диаграмма использования при определении образа и границ системы

« : 14 Сентября 2011, 12:26:12 »

Улучшенная версия.

4

Варианты Использования (Use Case) / Re: Диаграмма использования при определении образа и границ системы

« : 13 Сентября 2011, 19:35:38 »

На мой взгляд, диаграмма в корне не верная, т.к. здесь перемешаны и действия, выполняемые системой, и пользовательские цели.

Вот это и меня смущает.

А ВИ "Ввести данные" включает "Авторизацию".

По замыслу ввод данных и сохранение их в МТ возможно без авторизации. Авторизация нужна лишь для передачи данных в основную базу.

Убрать передачу данных как системную функцию с диаграммы верно только если она происходит автоматически, а не инициируется пользователем. Допустим, инициируется. Что вы можете тогда сказать о ВИ "удаление данных", корректно ли тогда его присутствие?

5

Варианты Использования (Use Case) / Re: Диаграмма использования при определении образа и границ системы

« : 13 Сентября 2011, 19:32:36 »

1. все кто пользуются пользователи.

А что с этим не так? Если предусмотрена единственная роль в системе.

2. из диаграамы я могу понять что система МобильнаяСуперПупер должна уметь(позволять) ручной ввод данных, ввод данных через фотографирование, сохранение данных в каком-то МТ, авторизацию в системе, передачу данных в некую БД, включая удаление сохраненных данных из МТ.

Я стремилась именно к тому, чтобы проиллюстрировать этой диаграммой предполагаемый функционал будущей системы.

Но это никак не сообщает мне о том ЗАЧЕМ ВСЕ ЭТО ДЕЛАЕТСЯ И ДЛЯ КОГО

Да, верно. "Зачем и для кого" описывается в прочих разделах документа. Или вы хотите сказать, что все это должно быть ясно из диаграммы? А первый отвечавший высказался, что ДВИ без описания сценариев не имеет смысла. )

6

Варианты Использования (Use Case) / Re: Диаграмма использования при определении образа и границ системы

« : 13 Сентября 2011, 16:24:25 »

Уже 100 раз говорили о том, что ДВИ не имеет смысла без описания сценариев. Все на ДВИ не отобразишь - будет каша.
Как вариант: ДВИ+описание каждого ВИ на несколько строк о его назначении.

А кто говорит о ДВИ без описания сценариев? Я написала, что

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

Для всех: если можно, прошу давать ответы не общетеоретические, а касательно конкретной приведенной диаграммы.

7

Варианты Использования (Use Case) / Диаграмма использования при определении образа и границ системы

« : 13 Сентября 2011, 16:15:55 »

Недавно я обдумывала документ об образе и границах системы и нашла, что сопроводить описание основных функций будущей системы диаграммой использования будет удобно и наглядно.  Смущает то, что в диаграмму попадают функции, которые будут присутствовать в системе, и это важно явно обозначить заранее, но при этом сами по себе эти функции чисто служебные, которые я обычно в отдельные UC не выделяю.

Пример. Допустим, мы описываем образ и границы некоего приложения на мобильном устройстве, которое будет позволять вводить данные двумя способами - фотографируя и распознавая значение,  и с клавиатуры. Затем эти данные будут передаваться в основную БД. Ниже приведена диаграмма использования.

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

8

Варианты Использования (Use Case) / Re: Именование вариантов использования

« : 30 Августа 2011, 14:10:45 »

Отношения между User Requirements и Functional Requirements могут любыми: один ко многим, многие ко многим (т.е. одно пользовательское требование реализуется разными функциональными требованиями, но при этом одно функциональное требование может реализовывать несколько пользовательских в том или ином объеме), многие к одному...

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

Декомпозиция по жизненному циклу. Признак выделения подсистем — изменение закона функционирования подсистем на разных этапах цикла существования системы «от рождения до гибели». Рекомендуется применять эту стратегию, когда целью системы является оптимизация процессов и когда можно определить последовательные стадии преобразования входов в выходы.

Декомпозиция по физическому процессу. Признак выделения подсистем — шаги выполнения алгоритма функционирования подсистемы, стадии смены состояний. Хотя эта стратегия полезна при описании существующих процессов, результатом ее часто может стать слишком последовательное описание системы, которое не будет в полной мере учитывать ограничения, диктуемые функциями друг другу. При этом может оказаться скрытой последовательность управления. Применять эту стратегию следует, только если целью модели является описание физического процесса как такового.

http://victor-safronov.narod.ru/systems-analysis/lectures/rodionov/07.html

9

Варианты Использования (Use Case) / Re: Именование вариантов использования

« : 30 Августа 2011, 09:29:56 »

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

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

Что такое высокоуровневые? А, бывают низкоуровневые? Как они выглядят, что описывают, в какой форме?

Бывают, конечно. Например, шаги сценария, входящего в UC и выполняемые пользователем, которые представить в виде самостоятельного UC нельзя никак. Хотя на некотором уровне функциональной декомпозиции они тоже являются целями пользователя.

10

Варианты Использования (Use Case) / Re: Именование вариантов использования

« : 29 Августа 2011, 16:12:08 »

Но это сразу приводит нас к тому, что ВИ=функция (feature)

В том смысле, что UC - функции, реализующие высокоуровневые пользовательские цели, можно согласиться. Имхо.
Но никак не обратное - ес-сно, не всякая функция есть UC.

11

Варианты Использования (Use Case) / Re: Именование вариантов использования

« : 29 Августа 2011, 15:38:23 »

Естественно мы пишим в требованиях нечто вроде: "Система должна Принимать заказы клиентов"

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

индийский коллега в ходе своего жизненного и профессионального опыта делает вывод, что ВИ следует именовать в терминах сервиса. Но это сразу приводит нас к тому, что ВИ=функция (feature)

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

12

Системный Анализ и Требования / Re: Бизнес-требования и бизнес-цели

« : 25 Августа 2011, 18:04:56 »

Про ITIL я уточнила для себя по ходу участия в теме. Про Вигерса честно сказала еще на прошлой странице, что запамятовала, есть ли там критерии формулировки требований. И тоже уточнила для себя этот вопрос по ходу участия в теме.

Надеюсь, мой исчерпывающий ответ вас удовлетворил.
Хотя, если с этим проблемы, вы, конечно же, можете продолжать свои оффтопные в этой теме изыскания по причинах моих высказываний и прочих скрытых мотивах. Никто, кроме модераторов, помешать не может.
А я даже причинами такого поведения интересоваться не буду.

13

Системный Анализ и Требования / Re: Бизнес-требования и бизнес-цели

« : 25 Августа 2011, 17:13:23 »

И что из этого следует? Что у Вигерса не такая уж и «исчерпывающая» классификация? Допустим

Просто уточнение.

14

Системный Анализ и Требования / Re: Бизнес-требования и бизнес-цели

« : 25 Августа 2011, 17:04:22 »

Глава 1. Особенности разработки требований к ПО 

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

1.Единичность — требование описывает одну и только одну вещь.
2.Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
3.Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
4.Атомарность — требование нельзя разделить на более мелкие.
5.Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
6.Актуальность — требование не стало устаревшим с течением времени.
7.Выполнимость — требование может быть реализовано в рамках проекта.
8.Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
9.Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
10.Проверяемость — реализованность требования может быть проверена.

Это ITIL.

15

Системный Анализ и Требования / Re: Бизнес-требования и бизнес-цели

« : 25 Августа 2011, 16:26:22 »

У папы нашего Вигерса есть исчерпывающая классификация требований с перечислением их характеристик.

Что-то не помню про критерии формулировок требований у Вигерса, по-моему, это из других источников.

ITIL.