721

Системный Анализ и Требования / Re: Рекомендуемые формулировки требований

« : 17 Мая 2014, 23:35:43 »

Эдуард, вы не могли бы привести примеры для каждого класса сущностей? Без них сложно понять модель.

На самом деле это модель, выведенная из консультаций с Борисом Леонидовичем Новиковым - экспертом и, возможно, евангелистом RUP.
Заинтересованное лицо - лицо, имеющее определенный интерес в существовании системы.
Интерес - хотя и есть в модели, реально мною не используется. Concern - многозначное понятие. Чем оно отличается от проблемы, мне сказать, честно сложно.
Проблема - совпадает с Вашим пониманием.
Потребность (need) - высказанное или невысказанное пожелание то, что решает (по мнению ЗЛ) его проблемы.
Требование возможности (feature) - хотя Леонида передергивает, но RUP почему-то считает это требованиями. В практике RUP, в частности в ReqPro есть такой тип требования.
Требование прецедента - это не сам прецедент, но функциональное требование. Требование  - это условие, а прецедент - это договоренность об взаимодействии
Дополнительные требования - все что FURPS+
Функциональная область - уже часть решения - часть логической структуры или архитектуры

722

Системный Анализ и Требования / Re: Рекомендуемые формулировки требований

« : 17 Мая 2014, 22:23:03 »

Спасибо, интересное и похожее прочтение. Правда, что такое Opportunity

Моя (черновая диаграмма) во вложении (:

723

Системный Анализ и Требования / Re: Рекомендуемые формулировки требований

« : 16 Мая 2014, 20:53:00 »

Сергей, Леонид, спасибо.

Возможно вы и правы, считая возможности нетребованиями, но однако у Битнера и Спенсера в книге Use case modeling читаем:
"Возможность (Feature) – это высокоуровневая способность (услуги или качества) системы, необходимая для обеспечения нужного эффекта и помощи в реализации потребности заинтересованного лица и/или пользователя. Набор возможностей обеспечивает суммарное представление об объявленных свойствах продукта, который будет создан.

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

Впрочем мне скорее важно донести разницу до студентов, что бывает сложно. Ибо:

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

724

Системный Анализ и Требования / Re: Рекомендуемые формулировки требований

« : 16 Мая 2014, 09:45:32 »

Сергей, спасибо за ответ и интерес к теме.

Можно тогда дать определения бизнес-проблемы и бизнес-возможности? И нарисовать вашу модель трассировки?

725

Системный Анализ и Требования / Рекомендуемые формулировки требований

« : 15 Мая 2014, 22:21:12 »

Коллеги, друзья.

При формулировке и анализе требований в литературе часто приводят пирамиду: потребности (need) - возможности (feature) - требования (system requirement). Потребностям часто предшествуют интересы (concern) и проблемы (problem).

Когда это изложено в книге, каком-то примере все кажется вполне гладко, хотя тоже в тексте встречается масса оговорок. Если вы работаете по такой технологии, то используете ли какие-то формализмы при формулировке этих потребностей, возможностей и требований?

Очевидно, что в последнем случае можно потребовать формулы <система должна>.

Для случая потребностей, вероятно, можно начинать фразы с "желательно, нужно, хотелось бы"

Для случая возможностей не совсем ясно, но поскольку это по сути высокоуровневые требования, то <система должна предоставлять возможность>

Наверное есть и более приемлемые критерии и способы формулировок и различий?

Кроме того, хотелось бы узнать, какие типы связей вы предполагаете между этими понятиями?

Заинтересованные лица <имеют> потребности, которые <реализуются> через возможности, которые <детализируются, специфицируются> через системные требования ... ?

726

ПО Аналитика / Re: RequisitePro Evaluation

« : 29 Апреля 2014, 14:35:52 »

- Rational DOORS и Rational Requirements Composer скорее всего будут слиты в один продукт. Т.е., останется только DOORS.

И станет еще дороже:)

727

Задачи студентов / Re: Функции и описание их использования

« : 25 Апреля 2014, 17:22:24 »

Я разблокировал тему. Не совсем ясны причины ее блокировки. Прошу автора блокировки, заблокировать тему, если я сделал ошибку. Но просьба сообщить причину такого шага.
Спасибо.

728

ПО Аналитика / Re: Jama Contour. Инструмент для управления требованиями

« : 23 Апреля 2014, 18:01:01 »

Коллеги, ну как? Был опыт использования?
Данные по стоимости какие известны?

Нет, так и руки не дошли. Да и давно было, что-то уже не помню, что к чему.

729

ПО Аналитика / Re: RequisitePro Evaluation

« : 16 Апреля 2014, 16:52:47 »

Доброго  дня.

Повторил все ваши действия и все получилось. Правда, качать не стал - большое 1,2 Гигабайта. А канал чувствуется узковатый - оценку выдал как в 3 часа скачивания

730

Конференции Семинары и Тренинги / ЛАФ 2014 - 12-13 июня 2014 в Иванове

« : 15 Апреля 2014, 16:01:09 »

Друзья!

Рады сообщить вам, что регистрация на пятый Летний аналитический фестиваль открыта!

В этом году Фестиваль снова пройдёт в Иваново, в гостеприимном офисе НПО «Консультант».
Вечером первого дня можно будет обсудить поднятые темы с этими экспертами и другими коллегами за шашлычным столом на аналитических посиделках. Второй день — общение в свободном формате. Круглые столы на свежем воздухе, обсуждения, развлечения, культурный отдых.
Вечернее общение и второй день Фестиваля пройдут в Иваново, в гостиничном комплексе «Сосновый бор».

Стоимость участия в Фестивале зависит от того, насколько глубоко вы готовы погрузиться в его атмосферу:
1000 руб. — организационный взнос только на участие в конференции первого дня (включая обед и кофе-брейки).
3000 руб. + участие в аналитических посиделках и обсуждениях второго дня на базе отдыха «Сосновый бор» (без ночлега)
5000 руб. + плюс ночлег в «Сосновом бору»

Чтобы подтвердить своё участие, зайдите на сайт Фестиваля и укажите параметры своего участия на этой странице: http://conf.uml2.ru/my_options/

Фестиваль — это, в первую очередь, обмен практическим опытом. Если вам есть что рассказать о своём опыте общения с трудными заказчиками, о собственных приёмах работы с требованиями, об используемых вами методологиях, подходах и инструментах, то Фестиваль — самое подходящее для этого место! Подавайте свои заявки на выступления на сайте Фестиваля: http://conf.uml2.ru/my_speeches/

All you need is ЛАФ! Ждём вас!

Ищите нас на facebook: https://www.facebook.com/groups/let.an.fest/

731

Задачи студентов / Re: Проверка IDEF0-модели в 3SL Cradle

« : 09 Апреля 2014, 09:21:03 »

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

Переводе чего? С английского на английский? Нет, я понимаю - все придуманное людьми может содержать ошибки и соответственно улучшено. Но похоже это будет что-то свое.

P.S. На вопрос - действительно ли меня так волнует IDEF0, что я пишу о нем в пять утра, отвечаю: похоже, что да.  Размышляю о том, не начать ли обучение сантехников, которые делали этот чертов водопровод, прорыв которого докатился до нас через 7 этажей ....   Уже вижу баннер - "ТСЖ, защити свой дом, обучи своего сантехника IDEF0"
Пойдут?

Да, приятного мало. Не позавидуешь. Пару раз испытывал нечто подобное

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

732

Задачи студентов / Re: Проверка IDEF0-модели в 3SL Cradle

« : 08 Апреля 2014, 22:57:52 »

Юлия,
думаю тогда это не нотация или лучше сказать стандарт IDEF0. Возможно, это ваша особая технология, сильно похожая на стандарт?

Не знаю, в стандарте английским по белому написано

2.2 Arrow: A directed line, composed of one or more arrow segments, that models an open channel or conduit conveying data or objects from source (no arrowhead) to use (with arrowhead). There are 4 arrow classes: Input Arrow, Output Arrow, Control Arrow, and Mechanism Arrow (includes Call Arrow). See Arrow Segment, Boundary Arrow, Internal Arrow.

2.3 Arrow Label: A noun or noun phrase associated with an IDEF0 arrow or arrow segment, specifying its meaning.

733

Задачи студентов / Re: Проверка IDEF0-модели в 3SL Cradle

« : 08 Апреля 2014, 17:21:07 »

Юлия, спасибо.

Леонид меня опередил. По сути снял с моего языка вопросы. Для  меня оказалось неожиданностью, что управление формулируется глагольными фразами, хотя с учетом их формулировки принять можно, но не по фэншую как-то, у отца основателя такого я не видел Методология структурного анализа и проектирования SADT.

Каждая стрелка характеризует некоторое ограничение, которое Вы и интерпретируете как нефункциональное требование?

734

Задачи студентов / Re: Проверка IDEF0-модели в 3SL Cradle

« : 07 Апреля 2014, 21:32:25 »

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

Спасибо, Юлия. Нельзя ли чуть подробнее об этом тезисе. Не могли бы пояснить мысль на небольшом и понятном примере?

735

Задачи студентов / Re: Проверка IDEF0-модели в 3SL Cradle

« : 07 Апреля 2014, 20:44:46 »

Моя позиция ближе к Леониду, чем к Саше.

На самом деле IDEF0 довольно прост и строг. Мне он как раз нравится, причем больше BPMN, который преподавать явно сложнее. Понятно BPMN  и IDEF0 большие разницы, я бы нашел большее сходство между BPMN и IDEF3.

Есть правда eFFBD или process flow diagram. Просто, если нет инструментальной поддержки уровня BPWin, значит нет и спроса?