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

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

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

А структура БД относится к области проектирования, а не анализа. Если вас интересуют именно требования, то ищите то, которое породило необходимость изменений в структуре БД. Там и выясните, функциональное оно или нет.

А структура БД относится к области проектирования, а не анализа. Если вас интересуют именно требования, то ищите то, которое породило необходимость изменений в структуре БД. Там и выясните, функциональное оно или нет.

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

Так ли я понял ?

Не, неправильно.
У пользователя же нет задачи "добавить запись".
У него задача "Записать ФИО, должность, стаж в днях".
Они все функциональные.

нет, не правильно.

Это Функциональные требования. Подробнее читаем FAQ

- Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
- Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

и SWEBOK - перевод: Сергей Орлик и Юрий Булуй

По мнению авторов, в определенной степени, систематизируя работы Вигерса, Лефингвелла и Видрига, Коберна, а также других экспертов, необходимо привести классификацию различных категорий (видов) требований и связанных с ними понятий, важнейших с точки зрения их понимания и дальнейшего практического применения:
...
Группа функциональных требований
...
Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.

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

В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.
Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.
Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.
Ограничения (Constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, …), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.

У пользователя же нет задачи "добавить запись".
У него задача "Записать ФИО, должность, стаж в днях".

Почему вы так решили?...
Следуя описанию, которое привел автор, мы можем выделить как минимум три действия:
1. Добавление записи
2. Редактирование записи
3. Удаление записи

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

И потом, я лично до сих пор не поняла, что такое "требование о внесении изменений в структуру БД".
Кому требуется вносить измнения? Зачем требуется? Когда требуется? Кто их вносит?

И потом, я лично до сих пор не поняла, что такое "требование о внесении изменений в структуру БД".
Кому требуется вносить измнения? Зачем требуется? Когда требуется? Кто их вносит?

Я вас запутал =(
Имел ввиду, что: требования к атрибутам объекта, на основе которого в модели БД появиться таблица, это требования нефункциональные.

- Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

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

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

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

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

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

система должна быть разработанная с использованием языка с++

Вот пример... не факт что Best Practies, но хоть что-то

Спасибо, а то я тут чуть дров не наломал.

Как-то это странно...
С чего это вдруг такое требование

Система должна обеспечивать безотказную работу в режиме 24*7

                              обязательно должно быть нефункциональным?
Конечно, если речь идет о банке тушенки, то 24*7 -- нефункциональное требование. В том смысле, что без разницы, когда ее можно открыть и употребить, в среду или в пятницу, в 8 вечера или в 4 утра.

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

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

А тогда можно ли требование 24*7 называть нефункциональным?

Как-то это странно...
С чего это вдруг такое требование                              обязательно должно быть нефункциональным?
Конечно, если речь идет о банке тушенки, то 24*7 -- нефункциональное требование. В том смысле, что без разницы, когда ее можно открыть и употребить, в среду или в пятницу, в 8 вечера или в 4 утра.

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

А тогда можно ли требование 24*7 называть нефункциональным?

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