Форум Сообщества Аналитиков

Дисциплины => Системный Анализ и Требования => Тема начата: NewBee от 01 Декабря 2009, 18:52:28

Название: Нефункциональные требования...
Отправлено: NewBee от 01 Декабря 2009, 18:52:28
Нефункциональные требования - как то плохо себе представляю.
Производительность системы, атрибуты качества...хм...

А насколько правильно будет, в параграфе нефункциональных требований к системе
прописывать требования о внесении изменений в структур БД ?
Название: Re: Нефункциональные требования...
Отправлено: ida - брэнд с 14-летней историей от 01 Декабря 2009, 19:40:34
Нефункциональные требования - это все, что невозможно описать в виде сценариев использования.
Так пожалуй будет проще.

А структура БД относится к области проектирования, а не анализа. Если вас интересуют именно требования, то ищите то, которое породило необходимость изменений в структуре БД. Там и выясните, функциональное оно или нет.
Название: Re: Нефункциональные требования...
Отправлено: NewBee от 02 Декабря 2009, 13:25:12
А структура БД относится к области проектирования, а не анализа. Если вас интересуют именно требования, то ищите то, которое породило необходимость изменений в структуре БД. Там и выясните, функциональное оно или нет.

Тоесть, пример:
создание справочника
- Функциональные требования:
  - Добавлять записи в справочник;
  - Редактировать записи;
  - Удалять записи;
- Нефункциональные требования;
  - должен хранить:
     1. ФИО;
     2. Должность;
     3. Стаж.
  - ФИО - только символы русского алфавита;
  - Стаж в дня.

Так ли я понял ?
Название: Re: Нефункциональные требования...
Отправлено: div от 02 Декабря 2009, 13:42:55
Не, неправильно.
У пользователя же нет задачи "добавить запись".
У него задача "Записать ФИО, должность, стаж в днях".
Они все функциональные.
Название: Re: Нефункциональные требования...
Отправлено: mouse от 02 Декабря 2009, 13:48:34
нет, не правильно.

Это Функциональные требования. Подробнее читаем FAQ (http://www.uml2.ru/forum/index.php?topic=341.0)
Цитировать
- Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
- Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта
и SWEBOK - перевод: Сергей Орлик и Юрий Булуй (http://www.sorlik.ru/swebok/3-1-software_engineering_requirements.pdf)
Цитировать
По мнению авторов, в определенной степени, систематизируя работы Вигерса, Лефингвелла и Видрига, Коберна, а также других экспертов, необходимо привести классификацию различных категорий (видов) требований и связанных с ними понятий, важнейших с точки зрения их понимания и дальнейшего практического применения:
...
Группа функциональных требований
...
Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.

Группа нефункциональных требований (Non-Functional Requirements)
Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований.

В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.
Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.
Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.
Ограничения (Constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, …), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.
Название: Re: Нефункциональные требования...
Отправлено: ida - брэнд с 14-летней историей от 02 Декабря 2009, 14:21:19
У пользователя же нет задачи "добавить запись".
У него задача "Записать ФИО, должность, стаж в днях".
Почему вы так решили?...
Следуя описанию, которое привел автор, мы можем выделить как минимум три действия:
1. Добавление записи
2. Редактирование записи
3. Удаление записи

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

И потом, я лично до сих пор не поняла, что такое "требование о внесении изменений в структуру БД".
Кому требуется вносить измнения? Зачем требуется? Когда требуется? Кто их вносит?
Название: Re: Нефункциональные требования...
Отправлено: NewBee от 02 Декабря 2009, 14:45:09
Цитата: ida
И потом, я лично до сих пор не поняла, что такое "требование о внесении изменений в структуру БД".
Кому требуется вносить измнения? Зачем требуется? Когда требуется? Кто их вносит?

Я вас запутал =(
Имел ввиду, что: требования к атрибутам объекта, на основе которого в модели БД появиться таблица, это требования нефункциональные.
Название: Re: Нефункциональные требования...
Отправлено: Бабихин Максим от 02 Декабря 2009, 14:59:44
Цитировать
- Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

При чем атрибуты объекта?  В определении четко сказано, что нефункц. треб. описывают цели и атрибуты качества.
Требования к атрибутам объекта на, мой взгляд, как раз функциональное требование.
Название: Re: Нефункциональные требования...
Отправлено: NewBee от 02 Декабря 2009, 15:11:11
При чем атрибуты объекта?  В определении четко сказано, что нефункц. треб. описывают цели и атрибуты качества.
Требования к атрибутам объекта на, мой взгляд, как раз функциональное требование.

Видимо я чего то непонимаю...
А могли бы вы привести пример нефункциональных требований ?
Название: Re: Нефункциональные требования...
Отправлено: Nikolay от 02 Декабря 2009, 15:25:32
Система должна обеспечивать безотказную работу в режиме 24*7
Время формирования ... отчета не должно превышать ... минут
Система должна позволять одновременное выполнение следующих процессов ...
etc
Название: Re: Нефункциональные требования...
Отправлено: Бабихин Максим от 02 Декабря 2009, 15:28:10
Видимо я чего то непонимаю...
А могли бы вы привести пример нефункциональных требований ?
система должна быть разработанная с использованием языка с++
Название: Re: Нефункциональные требования...
Отправлено: mouse от 02 Декабря 2009, 15:50:43
Вот пример... не факт что Best Practies, но хоть что-то
Название: Re: Нефункциональные требования...
Отправлено: NewBee от 03 Декабря 2009, 11:17:02
Спасибо, а то я тут чуть дров не наломал. :)
Название: Re: Нефункциональные требования...
Отправлено: tolldo от 07 Декабря 2009, 14:33:16
Как-то это странно...
С чего это вдруг такое требование
Цитировать
Система должна обеспечивать безотказную работу в режиме 24*7
                              обязательно должно быть нефункциональным?
Конечно, если речь идет о банке тушенки, то 24*7 -- нефункциональное требование. В том смысле, что без разницы, когда ее можно открыть и употребить, в среду или в пятницу, в 8 вечера или в 4 утра.

Но та же фраза 24*7 может звучать и иначе, когда речь идет, например, об атомном реакторе или круглосуточно работающей межбанковской или биржевой торговле. Когда система не может остановиться ни на секунду. А ведь требуется проводить разного рода регламентное обслуживание, подметать, продувать, чистить от мусора... А в это время все должно работать. Представьте себе проблему: запроектировать систему так, что ее нельзя остановить даже для ее же собственного обновления. Понимаете, 24*7 может означать, что даже апгрейд делается на работающей системе и как-то обновляются куски кода, задействованные в данный же момент. И все это без останова. И все с гарантией, что не хряпнется. Пользователи ничего не должны заметить. У них просто появятся новые фичи при следующем запросе к системе.

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

А тогда можно ли требование 24*7 называть нефункциональным?
Название: Re: Нефункциональные требования...
Отправлено: viking от 07 Декабря 2009, 15:28:41
Как-то это странно...
С чего это вдруг такое требование                              обязательно должно быть нефункциональным?
Конечно, если речь идет о банке тушенки, то 24*7 -- нефункциональное требование. В том смысле, что без разницы, когда ее можно открыть и употребить, в среду или в пятницу, в 8 вечера или в 4 утра.

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

А тогда можно ли требование 24*7 называть нефункциональным?
Можно и нужно, иначе мы дойдем до включения требований безопасности информации в функциональные
Название: Re: Нефункциональные требования...
Отправлено: kirillss от 07 Декабря 2009, 15:48:13
Можно и нужно, иначе мы дойдем до включения требований безопасности информации в функциональные

Вот где конец света то будет)))))))))))
Название: Re: Нефункциональные требования...
Отправлено: Виталий Григораш от 08 Декабря 2009, 08:04:57
Задавайте себе два вопроса:
1. Что делает система? - Функциональные
2. С каким качеством система это делает? (количественные показатели) - Нефункциональные


Название: Re: Нефункциональные требования...
Отправлено: tolldo от 08 Декабря 2009, 13:25:04
Цитировать
С каким качеством система это делает? (количественные показатели) - Нефункциональные

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

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

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

Название: Re: Нефункциональные требования...
Отправлено: Виталий Григораш от 08 Декабря 2009, 13:38:25
  • Функциональные требования -- это характеристики поведения системы, выделяющие ее из фона.
  • Нефункциональные требования -- это метрики границ фона, за которыми система начинает демонстрировать недопустимое поведение.
:) Клева.
Особенность умных людей объяснять простые вещи мега трудным языком. Сказал бы мне начальник, что надо требования поделить и вот тебе определения выше, я б точно ничего не смог поделить :)
Название: Re: Нефункциональные требования...
Отправлено: tolldo от 08 Декабря 2009, 14:44:14
 :) Ну, что поделаешь. На ходу формулировал. Да, эта фраза в отдельности звучит не только сложно, но и не точно.
Название: Re: Нефункциональные требования...
Отправлено: kirillss от 08 Декабря 2009, 14:48:04
Народ, сдается мне что это некоторая схоластика.
Что изменится от того что то или иное требование мы определим как функциональное, а на самом деле он нефункциональное?
Название: Re: Нефункциональные требования...
Отправлено: cintyao от 08 Декабря 2009, 15:17:33
Коллеги, я полагаю, что нефункциональные требования - это требования, которые можно предъявить ко всем без исключения информационным системам: надежность, быстродействие, пиковая нагрузка, необходимость миграции и т. д. Например, неважно, что мы разрабатываем - систему складского учета или текстовый редактор, но и там, и там для каждого вида нефункциональных требований мы должны указать значения или написать сакраментальную фразу "Требований данного класса не предъявлено".

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

Название: Re: Нефункциональные требования...
Отправлено: tolldo от 09 Декабря 2009, 16:05:54
Цитировать
Народ, сдается мне что это некоторая схоластика.
Что изменится от того что то или иное требование мы определим как функциональное, а на самом деле он нефункциональное?

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

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

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

Нефункциональные требования появляются совершенно по другому поводу. Предположим, что система создана, внедрена и успешно работает. Все хорошо? Не всегда. Бывает так, что решение проблемы в одном месте приводит к возникновению проблем в совершенно других местах. (Одно -- лечим, другое -- калечим.)

Новые проблемы могут возникнуть в тех местах, где сейчас все хорошо и никто не жаловался. Заказчик примет лекарство от боли в спине. Спина пройдет, а голова (которая не болела) -- заболит :( Нефункциональные требования -- это упреждение возможных негативных последствий работы системы, исключение появления у заказчика новых проблем.
Название: Re: Нефункциональные требования...
Отправлено: y0rk от 09 Декабря 2009, 16:29:33
Коллеги, я полагаю, что нефункциональные требования - это требования, которые можно предъявить ко всем без исключения информационным системам: надежность, быстродействие, пиковая нагрузка, необходимость миграции и т. д. Например, неважно, что мы разрабатываем - систему складского учета или текстовый редактор, но и там, и там для каждого вида нефункциональных требований мы должны указать значения или написать сакраментальную фразу "Требований данного класса не предъявлено".

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

А что делать в случае фразы "Требований данного класса не предъявлено"? Это означает, что пользователю (или заказчику) не важны атрибуты качества и на них можно "забить"? Или же нужно обязательно допытываться у пользователя о конкретных измеримых значениях по каждому нефункциональному требованию - надёжность такая-то, быстродействие такое-то и т.д.? Может, он просто забыл о них упомянуть и считает как "само собой разумеющееся"?
Название: Re: Нефункциональные требования...
Отправлено: SALar от 09 Декабря 2009, 18:34:31
Пролучается, что весь вопрос в том, в какой столбик записать требование, в правый или в левый? Если дело только в некоей правильности оформления бумаги и все, то и смысла делить нет.
Отделение прочих требований от функциональных служит в частности способом уменьшения объема.

Проще записать, что реакция системы при выполнении любой бизнесоперации не должна задерживать больше, чем на секунду, нежели повторять это требование десятки раз. Это неплохой критерий по отделению одного от другого.
Название: Re: Нефункциональные требования...
Отправлено: Galogen от 09 Декабря 2009, 20:27:48
Нефункциональные требования, к коим следует отнести атрибуты качества, в первую очередь важны для формирования архитектуры системы. Эти требования и определяют вид будущего продукта, а не функциональность сама по себе.

Функциональность, конечно, тоже влияет на качество. Однако предположим, что нам нужен некоторый набор функциональности: система должна делать что-то. Кто же нам мешает сделать некое монолитное решение в виде мегамодуля, в котором вся функциональность будет реализована и даже работать и возможно весьма шустро и стабильно.

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

Все это и определяет качество системы, качество, вытекающее из потребностей (интересов) участников. Как со стороны заказчика, но так и со стороны разработчика
Название: Re: Нефункциональные требования...
Отправлено: div от 10 Декабря 2009, 03:33:10
А что делать в случае фразы "Требований данного класса не предъявлено"? Может, он просто забыл о них упомянуть и считает как "само собой разумеющееся"?
Ну как же он забыл, если он написал русским по белому "Требований не предъявлено"? Для этого и пишут эту фразу, чтобы не говорил потом заказчик, что забыл упомянуть.
Название: Re: Нефункциональные требования...
Отправлено: cintyao от 10 Декабря 2009, 12:32:19
Формулировка "Требований данного класса не предъявляется" ни в коей мере не означает, что мы должны на "закрывать глаза" на что-либо существенное.

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

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

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

Я считаю, что для нас как для аналитиков очень важны три момента, связанные с нефункциональными требованиями:

- ни одно из нефункциональных требований не должно быть оставлено без внимания при разработке проектных спецификаций;

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

- если нефункциональное требование не предъявляется, можно в данном направлении ничего не предпринимать и не тестировать, но решение о том, что оно не предъявляется, должно приниматься осознанно и по взаимному соглашению заказчика и исполнителя.
Название: Re: Нефункциональные требования...
Отправлено: div от 10 Декабря 2009, 13:37:13
Все возможные нефункциональные требования к информационным системам целесообразно обобщить в одном документе-шаблоне, чтобы потом при разработке требований к конкретной системе ничего не забыть.
Да, с моей точки зрения, это наиболее полезная на практике причина выделения нефункциональных требований изо всех остальных: их перечни для различных систем очень близки друг к другу. Кстати, обсуждаемый в соседней ветке ГОСТ 34 может рассматриваться в частности, как перечень возможных нефункциональных требований.

Я считаю, что для нас как для аналитиков очень важны три момента, связанные с нефункциональными требованиями:
Мне кажется, что эти три момента важны для любых требований, не только нефункциональных.
Название: Re: Нефункциональные требования...
Отправлено: tolldo от 10 Декабря 2009, 13:37:25
Цитировать
Я считаю, что для нас как для аналитиков очень важны три момента, связанные с нефункциональными требованиями:

- ни одно из нефункциональных требований не должно быть оставлено без внимания при разработке проектных спецификаций;

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

- если нефункциональное требование не предъявляется, можно в данном направлении ничего не предпринимать и не тестировать, но решение о том, что оно не предъявляется, должно приниматься осознанно и по взаимному соглашению заказчика и исполнителя.

Согласен. Хочется добавить еще вот что.

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

Система же отличается от гвоздя тем, что управляет своими характеристиками. Т.е. как минимум сама умеет измерять свою собственную производительность, поддерживаемую нагрузку, время ответа на запрос и т.п. Кроме того, зная требования и их границы, должна уметь регулировать эти свои параметры. Уметь повысить производительность, уметь ускорить обработку сложного запроса и т.д. Хотя бы как-то реагировать на выход параметров за пределы требований. Тогда это будет система, а не гвоздь.
Название: Re: Нефункциональные требования...
Отправлено: div от 10 Декабря 2009, 13:41:29
Система же отличается от гвоздя тем, что управляет своими характеристиками. Т.е. как минимум сама умеет измерять свою собственную производительность, поддерживаемую нагрузку, время ответа на запрос и т.п. Кроме того, зная требования и их границы, должна уметь регулировать эти свои параметры. Уметь повысить производительность, уметь ускорить обработку сложного запроса и т.д.
Ну все, все системные админы дружными рядами пошли переквалифицироваться в управдомы ;)
Название: Re: Нефункциональные требования...
Отправлено: tolldo от 10 Декабря 2009, 15:00:36
Возможно во мне заговорил бывший сисадмин  :) переквалифицировавшийся в управдомы.

Ну, действительно, как можно гарантировать какое-либо качество, не умея его измерять?

Название: Re: Нефункциональные требования...
Отправлено: Бабихин Максим от 10 Декабря 2009, 15:25:21
Возможно во мне заговорил бывший сисадмин  :) переквалифицировавшийся в управдомы.

Ну, действительно, как можно гарантировать какое-либо качество, не умея его измерять?

Не факт, что система должна его измерять. Может пользователь с секундомером сидит перед компьютером и ждет ответ сервера :- ).
Название: Re: Нефункциональные требования...
Отправлено: tolldo от 10 Декабря 2009, 15:55:17
Цитировать
Может пользователь с секундомером сидит перед компьютером и ждет ответ сервера :- ).

Система точно так же может сидеть перед компьютером и с секундомером ждать ответ сервера  :)
Название: Re: Нефункциональные требования...
Отправлено: cintyao от 10 Декабря 2009, 15:58:12
На производстве для этих целей имеются ОТК, а у нас - подразделения тестирования...

На самом деле вопрос с оценкой нефункциональных параметров ИС достаточно сложный и острый.

В своем докладе на ReqLabs Григорий Печенкин обращал внимание на то, что требования, не подлежащие измерению, следует отбросить, чтобы не подписаться под невыполнимым проектом. Наверное, это будет правильно.

Хотя, полагаю, аналитику никогда не надо упускать шанс уточнить и переформулировать нефункциональные требования заказчика так, чтобы они, с одной стороны, были обоснованными с практической точки зрения, а с другой - измеряемыми в условиях тестовой и/или эксплуатационной среды. Тогда шансы на успех проекта возрастут.
Название: Re: Нефункциональные требования...
Отправлено: Григорий Печенкин от 10 Декабря 2009, 18:49:39
В своем докладе на ReqLabs Григорий Печенкин обращал внимание на то, что требования, не подлежащие измерению, следует отбросить, чтобы не подписаться под невыполнимым проектом.

Наверное, это всё-таки был не я. :) По крайней мере, так я это, вроде бы, не формулировал.
Название: Re: Нефункциональные требования...
Отправлено: cintyao от 16 Декабря 2009, 13:46:38
Григорий, вас трудно с кем-либо перепутать, но если со мной действительно такое произошло, приношу свои извинения...




Название: Re: Нефункциональные требования...
Отправлено: Григорий Печенкин от 16 Декабря 2009, 14:08:44
Григорий, вас трудно с кем-либо перепутать, но если со мной действительно такое произошло, приношу свои извинения...

Да что вы, какие извинения. Возможно, я сам не понял, что сказал. :) А скорее всего, мои общие фразы наложились на какой-то ваш конкретный опыт, и привели к таким выводам.

По сути: наверное, всё-таки, требования нельзя "отбрасывать". Лучше уж "отбросить" сам невыполнимый проект, если это возможно и если он действительно невыполнимый.

Переформулировать - конечно, с этим трудно не согласиться. Только нужно помнить, что каждая прописанная в требованиях цифра тянет за собой методику её получения, а реализация этой методики может обойтись дороже, чем собственно разработка.
Название: Re: Нефункциональные требования...
Отправлено: bustor от 21 Декабря 2009, 13:20:38
Вот что говорит по поводу классификации требований BABOK:

Цитата: BABOK
Functional Requirements describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations—specific information technology application actions or responses.

Non-functional Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as quality or supplementary requirements. These can include requirements related to capacity, speed, security, availability and the information architecture and presentation of the user interface.
Название: Re: Нефункциональные требования...
Отправлено: p_safin от 25 Июля 2011, 11:21:30
А я запомнил отличие ФТ от НФТ в следующем выражении, которое где-то вычитал: "ФТ определяют то, что делает Система, НФТ - при каких условиях она это делает".

Кстати, Наталья Желнова недавно опубликовала интересную статью про НФТ: http://softwarepeople.ru/blog/2011/07/11/non-functional-requirements01/