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

Вот где конец света то будет)))))))))))

Задавайте себе два вопроса:
1. Что делает система? - Функциональные
2. С каким качеством система это делает? (количественные показатели) - Нефункциональные

С каким качеством система это делает? (количественные показатели) - Нефункциональные

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

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

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

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

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

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

  Ну, что поделаешь. На ходу формулировал. Да, эта фраза в отдельности звучит не только сложно, но и не точно.

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

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

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

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

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

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

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

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

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

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

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

А что делать в случае фразы "Требований данного класса не предъявлено"? Это означает, что пользователю (или заказчику) не важны атрибуты качества и на них можно "забить"? Или же нужно обязательно допытываться у пользователя о конкретных измеримых значениях по каждому нефункциональному требованию - надёжность такая-то, быстродействие такое-то и т.д.? Может, он просто забыл о них упомянуть и считает как "само собой разумеющееся"?

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

Отделение прочих требований от функциональных служит в частности способом уменьшения объема.

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

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

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

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

Все это и определяет качество системы, качество, вытекающее из потребностей (интересов) участников. Как со стороны заказчика, но так и со стороны разработчика

А что делать в случае фразы "Требований данного класса не предъявлено"? Может, он просто забыл о них упомянуть и считает как "само собой разумеющееся"?

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

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

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

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

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

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

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

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

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

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

Да, с моей точки зрения, это наиболее полезная на практике причина выделения нефункциональных требований изо всех остальных: их перечни для различных систем очень близки друг к другу. Кстати, обсуждаемый в соседней ветке ГОСТ 34 может рассматриваться в частности, как перечень возможных нефункциональных требований.

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

Мне кажется, что эти три момента важны для любых требований, не только нефункциональных.

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

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

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

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

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

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

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