Коллеги, у нас тут возник неординарный вопрос.

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

А вы как думаете?

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

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

Интерсно было бы услышать обоснование того, почему данное требование является НЕФУНКЦИОНАЛЬНЫМ. Что по этому поводу говорят ваши коллеги?

Виталий, спасибо.

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

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

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

Как я уже написал выше, это немного разные типы классификации:
1. Фунциональные/нефункциональные - Вигерс:
 - что?(функциональное),
 - с каким качеством? (нефункциональное),
 - что ограничивает или нужно учесть? (бизнес-правило и ограничение)
2. Смысловое - деление требований по областям:
 - Служебные (журналирование, администрирование, вход в систему)
 - Предметная область

Если я не прав, то пусть меня коллеги поправят, я высказал свою точку зрения.
Если Вы работает по гостам, то в гостовских ТЗ немного намешано в разделах. Почитайте презентацию Юрия Булуя.
http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=135

Виталий, спасибо.

Я согласен с тем, что вы написали в предыдущем сообщении. Таким образом, вы (и мы ) относите данное требование к функциональным, в соотвествии с классификацией К.Вигерса?

Видимо, проблема стояла в некорректной постановке задачи более опытными коллегами. Хотя явного указания работать по ГОСТу нет, но он берется за основу. И тут же дается указание написать нефункциональные требования.

Тогда, надеюсь, последний вопрос. Куда все же надо отнести это требование в соответствии с ГОСТ 34.602-89?

2.6.2. В подразделе “Требование к функциям (задачам)”, выполняемым системой, приводят:

по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;

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

P.S. А презентация - да, очень интересная. Не раз уже обращался к ней. Юрию спасибо! Да и презентации по UC тоже очень интересные

Таким образом, вы (и мы ) относите данное требование к функциональным, в соотвествии с классификацией К.Вигерса?

Да. Я отношу его к функциональным. Считаю, что это функциональное требование уровня подсистемы.

Тогда, надеюсь, последний вопрос. Куда все же надо отнести это требование в соответствии с ГОСТ 34.602-89?

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

PS Гы.. Да мы с вами еще и коллеги по фирме
    Пишите мне в скайп vitaliy.grigorash

Администрирование и безопасность по своей сути пограничная вещь между технологиями и бизнес-процессами. С одной стороны разграничение\ограничение доступа к информации -- одно из ключевых требований бизнеса. Сильно сомневаюсь что бизнес-заказчик пожелает, чтобы к данным имел доступ кто угодно. С другой стороны -- решения по обеспечению безопасности стали достаточно стандартными, и рассматриваются часто как составня часть информационных технологий. В реальности все зависит от того, какую точку зрения принять в конкретном проекте. Лично я в данном случае сказал бы что это функциональное требование. Т.к. есть явный пользователь системы (например роль Администратор), пусть и "вспомогательный", но для которой система предоставляет какие-то свои возможности (вывод списка пользователей системы с доп. информацией).
По ГОСТ 34.602 это можно смело выносить в раздел требований к функциям (задачам), а в требованиях к безопасности перечислить требования более высокого уровня (например о том, что вообще должно быть разграничение доступа и т.п.)

Виталий, Юрий, спасибо!

Все, что мне надо было - я уяснил.

Коллеги, у нас тут возник неординарный вопрос.

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

А вы как думаете?

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

Дело в том, что список свойств вероятнее всего будет изменяться и уточняться (что такое уникальное имя? ФИО или логин? как хранить пароль - в хешах? может ли пользователь входить в несколько групп, и что в этом случае делать с его полномочиями? что если у нескольких пользователей одинаковые ФИО, и что если пользователь меняет ФИО? нужно ли хранить email, телефон, фото? и проч.).

Если в системе будет более 100 пользователей, управление их учётными записями тоже станет не такой тривиальной задачей (можно ли удалить единственного пользователя с полномочиями давать полномочия? а если он уволился, и никто не знает его логина с паролем? и проч.). Это тоже нужно серьёзно уточнять.

Совмещать две эти области знаний (требований? решений?) в одном требовании я бы не стал.