Comments | ailev: Стандарты представления требований

ailev

Стандарты представления требований

Jan 16, 2011 23:26

Еще раз об требования (интересно, сколько раз я уже обо всём этом тут писал?!). Традиционно требования понимаются как спецификация (т.е. точное формулирование) способности (capability) или условия (condition), которое должно или может быть удовлетворено (функция, которую нужно будет выполнить, или характеристика, которую нужно достигнуть и т.д ( Read more... )

Comments 35

slobin January 17 2011, 00:04:22 UTC

А "в следующем сезоне в моде будет розовое" -- это какая модальность?

... Деквалификация ведёт, как известно, к деквантификации доходов ...

ailev January 17 2011, 20:38:56 UTC

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

alextheraven January 17 2011, 10:44:36 UTC

Никакой неопределённости IMHO нет, мы на практике применяем следующие модальности ( ... )

Не сочтите за ярую критику, но за поддержание беседы iwwii January 17 2011, 18:35:50 UTC

Я прошу прощения заранее за "не до конца"-компетентность - я только учусь :) но так, в качестве варианта понимания Анатолия Игоревича ( ... )

Re: Не сочтите за ярую критику, но за поддержание беседы ailev January 17 2011, 20:47:30 UTC

Ваш вопрос очень хороший. Любые требования на железные системы содержат ссылки на конкретные стандарты, нормативные акты, законы, технические условия и другие документы. Даже если считать, что текст собственно "требований" 300 страниц, то при прохождении помянутых в них документов легко набирается 30000 этих страниц. И что делать: считать их все требованиями, или только начальные страницы? Это, конечно, не отменяет того, что в конце текста будет записано требование из вашего примера, а заодно и добавлено "и требования законодательство страны поставки".

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

Re: Не сочтите за ярую критику, но за поддержание беседы alextheraven January 18 2011, 09:50:27 UTC

В такой ситуации самое важное - как будут проверять соответствие законодательству. Для бухгалтерской системы будут проверять одно, для сервера - другое ( ... )

Thread 19

Доставило. buratino_69 January 17 2011, 15:05:18 UTC

Мудреные вещи Вы описываете Анатолий.

Текст ниасилил, увы, Ваш русский мне не по зубам.
Существует аглицкий вариант? И если - то где?
Однако диаграмки порадовали: примерно то же самое мы делаем со СмартПлантом. Отрадно видеть
:)

Re: Доставило. ailev January 17 2011, 20:12:30 UTC

Аглицкий вариант существует -- я почти на всё дал ссылки. Если речь идет о самом тексте, то я его сам написал сразу на русском. Ежели кто переведёт, то будет аглицкий вариант, не переведёт -- варианта не будет.

У вас в случае СмартПланта (фаундейшн, надо понимать? Ибо там много программных продуктов) на месте RIF на той диаграммке должна быть "схема СмартПлант Фаундейшн". А для этого эта схема должна стать стандартом, хотя бы стандартом предприятия ;)

Re: Доставило. buratino_69 January 18 2011, 10:37:24 UTC

В точку попали, SPF у нас заместо RIF. Написанием адаптеров "Engineering Tool <-> SPF" мы (интерграф) снижаем количество межаппликационных интерфейсов. Хотя до конца они еще не поумирали к сожалению. То тут то там клиент не хочет покупать/внедрять весь набор. Приходится дописывать и поддерживать всякую экзотику типа one-way SPI -> SAP или SPEL -> SAP. Что делать - деньги диктуют :(

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

В связи с чем вопрос к Вам - как объяснить что машиностроение, оптика, электроника - обходятся без нас?

Re: Доставило. vvagr January 18 2011, 14:36:16 UTC

Машиностроение обходится без вас в силу изначального выбора Интерграфа - это софт для проектировщиков. А софт для конструкторов писали другие фирмы.

Только Дассо Системс попыталась расшириться на оба сектора.

Thread 6

anonymous January 17 2011, 18:04:31 UTC

Анатолий, если Вы против ката, то, может быть, посмотрите в сторону якорной ссылки? Типа в начале текста ссылка skip, чтобы сразу перескочить через ваш текст?
Было бы удобно. Я с удовольствием читаю Ваши тексты, но когда возвращаешь во френдленту многократно проматывать тексты надоедает.

ailev January 17 2011, 20:17:06 UTC

Я не очень понимаю, как тут помогла бы якорная ссылка (да и не видел таких ссылок внутри постингов в ЖЖ, и не нашел таких кнопочек в Семажике). Мне кажется, что клавиша PgDn и инерционное колёсико на мыши много более полезны, чем целиться в такую ссылку.

netunika1 January 19 2011, 21:12:08 UTC

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

Спасибо за обзор maksiq January 19 2011, 08:17:17 UTC

Очень порадовал качественный и концентрированный обзор стандартов и подходов к представлению требований, таких материалов всегда не хватает ( ... )

Re: Спасибо за обзор ailev January 19 2011, 12:13:40 UTC

Вы абсолютно правильно понимаете. Более того, в не-айти-проектах тоже такая же ситуация. Я, собственно, и пишу эти обзоры для того, чтобы наметить какой-то путь к моделированию. Есть уточняемая модель, и вокруг неё суета с деонтической модальностью частей этой модели. Ну, и "будущие возможные миры" в количестве более чем одного.

Re: Спасибо за обзор maksiq January 20 2011, 10:55:02 UTC

При описании модели есть важный момент: ее надо уметь донести до заказчика, и не только для топов, но и для работников среднего звена. Чтобы общаться в ее терминах. А это - накладывает свои ограничения на сложность используемых средств, в том числе - стандартных нотаций для диаграмм. Обычно заказчики не согласны вкладывать свои силы в изучение сложного формализма. Мы это не сразу осознали, но теперь следим за сложностью, например, при использовании UML-диаграмм. Зато - добавляем цветовые и шрифтовые выделения, чтобы показать всякие дополнительные связи и группировки, это тоже помогает.

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

Re: Спасибо за обзор ailev January 20 2011, 12:03:46 UTC

Для описанной вами ситуации используется понятие viewpoint и соответствующего view (в ISO 42010). Каждый участник проекта/stakeholder (в том числе заказчик) получает артефакт "выписка-из-модели" той сложности и в той нотации, в которой ему наиболее удобно получить ответ на свои вопросы. Но сама общая для всех view модель поддерживается настолько сложной, насколько необходимо. Вы всегда сможете сделать черно-белую фотографию низкого разрешения из цветной 3D детальной голограммы ;)

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