Дорогие форумчане!
Мне необходимо описать функциональные и нефункциональные требования к клиент-серверной программе. Клиент программы аналогичен программе "блокнот". То есть - это редактор  текстового файла, с функциями поиска, поиска далее, редактирования шрифта, сохранения файлов на удаленном сервере, информации о программе. Информация о сервере настраивается в клиентской версии.

С функциональными требованиями мне, в целом, все понятно.

А что с нефункциональными? Какие тут могут быть бизнес-правила или ограничения? Какие вообще тут могут быть нефункциональные требования?

Бизнес-правила - то, что должно выполняться вне зависимости от существования ИС. Что-то т па: блокнтомо может пользоваться только человек, достигший 16 лет.
Ограничения на технологии, стоимость, время выходы продукта на рынок (срок выпуска) и т.п.

Согласно стандарту 9126-4 выделяют:
Эффективность - Способность ПО предоставлять пользователям возможность решать их задачи с необходимой точностью при  использовании в данном контексте
Продуктивность - Способность ПО предоставлять пользователям определенный результаты в рамках ожидаемых затрат ресурсов
Безопасность - Способность ПО обеспечивать необходимый низкий уровень риска нанесения ущерба жизни и здоровью людей, бизнесу, собственности и окружающей среде
Удовлетворение пользователей - Способность ПО приносить удовлетворение пользователям при использовании в заданном контексте

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

А что с нефункциональными? Какие тут могут быть бизнес-правила или ограничения? Какие вообще тут могут быть нефункциональные требования?

К нефункциональным требованиям можно относить:
1. Бизнес-правила
2. Атрибуты качества
3. Ограничения

1. Бизнес-правил в блокноте может не быть никаких. Обычно это ограничения на количественные и качественные характеристики бизнес-фукнций.

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

3. Атрибутов качества последние стандарты семейства ISO 250XX, пришедшие на смену 9126, выделяют десятки, я предлагаю взять хотя бы базовые 4-6:
http://www.slideshare.net/maieutic/ss-35127562

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

Вот что у меня получилось:

Нефункциональные требования
Бизнес-правила
Системой могут пользоваться только сотрудники организации.
Ограничения:
Система работает только с файлами с расширением *.txt
Клиент системы может работать только с файлами, расположенными на сервере.
Данные между клиентом и сервером передаются по протоколу FTP

Атрибуты качества продукта
Производительность:
1. Максимальное количество одновременно работающих клиентов не меньше 100
2. Максимальная частота запросов от пользователя (в минуту) не больше 10
3. Количество исполняемых транзакций (в минуту) не меньше 50
4. Длительность типовых транзакций (операций) не больше 10 секунд
Доступность:
Коэффициент доступности серверной части не менее 96%
Допустимое время простоя (в час) не более 3 минут
Безопасность:
Вероятность утечки данных в результате сбоя не должна превышать 0.1%
Масштабируемость:
Стоимость десятикратного увеличения мощности системы не должна превышать 400%

Атрибуты качества использования
Скорость обучения пользованию программой должна быть менее 10 минут
Удовлетворенность пользователей и средняя оценка продукта должны быть на уровне ожиданий.

А в функциональных требованиях я записал системные требования и сценарии использования.

Прошу Вас, укажите на мои ошибки.

Бизнес-правила
Системой могут пользоваться только сотрудники организации.

А при чем тут бизнес? Это правило про ограничение доступа.

Система работает только с файлами с расширением *.txt

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

Клиент системы может работать только с файлами, расположенными на сервере.
Данные между клиентом и сервером передаются по протоколу FTP

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

Атрибуты качества продукта
Производительность:
1. Максимальное количество одновременно работающих клиентов не меньше 100

Очень плохо. Попрошу продемонстрировать работу для 1.000.000 пользователей. Как покажете?
Рекомендую применять формулировку "до Х..." (в смысле не "дох...", а "до х единиц").

2. Максимальная частота запросов от пользователя (в минуту) не больше 10

Это требование к пользователю?

3. Количество исполняемых транзакций (в минуту) не меньше 50

Что такое "транзакция" в данном случае? "Не меньше 50" - это на всю систему или на пользователя? Или на экземпляр клиента? А то ж транзацией может быть и реакция сервера на нажатие очередной кнопки в поисковой строке.

4. Длительность типовых транзакций (операций) не больше 10 секунд

Аналогично. Понятно, что пример утрирован - но если и в реальности будете так писать, посеете ветер. Много ветра.

Доступность:
Коэффициент доступности серверной части не менее 96%
Допустимое время простоя (в час) не более 3 минут
Безопасность:
Вероятность утечки данных в результате сбоя не должна превышать 0.1%
Масштабируемость:
Стоимость десятикратного увеличения мощности системы не должна превышать 400%

Круто. Будьте готовы все это доказать.

Атрибуты качества использования
Скорость обучения пользованию программой должна быть менее 10 минут

Оно как бы не только от вас зависит. А потому - плохое требование.

Удовлетворенность пользователей и средняя оценка продукта должны быть на уровне ожиданий.

Гм... В чем измерять будете? В количестве постсессионных сигарет?

Очень плохо. Попрошу продемонстрировать работу для 1.000.000 пользователей. Как покажете?
Рекомендую применять формулировку "до Х..." (в смысле не "дох...", а "до х единиц").

А можно поподробнее?
Чем с точки зрения нынешних методик нагрузочного тестирования формулировака

Максимальное количество одновременно работающих клиентов до  100 пользователей

отличается  от

Максимальное количество одновременно работающих клиентов не меньше 100

Так и так стенд собирать, роботов запускать...

Гм... В чем измерять будете? В количестве постсессионных сигарет?

Я в восхищении

А можно поподробнее?
Чем с точки зрения нынешних методик нагрузочного тестирования...отличается  от

Это вопрос не тестирования. В первом случае задается верхняя планка допустимого количества, во втором нижняя. Второй легким движением руки можно превратить в "Максимальное количество одновременно работающих клиентов больше 99". Звучит.

Как полностью проверить выполнение требования "не меньше 100"? 1.000 - это не меньше 100. 1.000.000 - это не меньше 100. Тут можно разве что договориться с заказчиком и прописать документально, что тестировать будем на конкретно стольки-то пользователях. Которых не меньше 100, разумеется (например, 147). И то это вряд ли спасет от вопросов ревизоров.

Это вопрос не тестирования. В первом случае задается верхняя планка допустимого количества, во втором нижняя. Второй легким движением руки можно превратить в "Максимальное количество одновременно работающих клиентов больше 99". Звучит.

Это даже круче, чем с постсессионными сигаретами:)

По атрибутам качества можно найти много примеров в шаблоне от Atlantic Guild:
http://www.volere.co.uk/template.htm

Сотни вопросов, которые помогают выявить требования к атрибутам качества, можно найти в книге Roxanne E Miller:
http://requirementsquest.com/books-and-software/