Заранее извиняюсь за «многа букаф». Подход к описанию всех шагов разработки пока не оформился в моей голове, потому страдаю от некоторой размытости суждений
Давайте я лучше попробую с другой стороны подойти.
Рассмотрим два связанных между собой требования клиента.
Требования гласят, что, помимо прочего, клиент хочет иметь возможность в будущем добавлять в приложение функциональность (какую сам ещё не знает) не прибегая к перекомпиляции или изменению уже написанного кода. Также он хочет, чтобы была реализована возможность регулировать доступ к этой функциональности посредством групп пользователей. Т.е. чтобы, например, модуль аналитики был доступен только аналитикам и управленцам, а модуль работы данными был доступен всем, кроме аналитиков и т.д.
На основе этих требований я решаю, что приложение будет состоять (в упрощённом виде) из:
• исполняемого файла (exe) – загрузчика модулей
• и, собственно, модулей (dll), которые реализуют некий общий интерфейс для их поиска, загрузки и запуска на выполнение загрузчиком.
Также я принимаю решение, что приложение должно производить идентификацию пользователей с последующим определением их принадлежности к некми группам, чтобы при загрузке модуля можно было определить входит ли пользователь, от имени которого происходит загрузка, в группу для которой данный модуль является разрешённым. Так как «будущие» модули пока ничего не знают о тех группах, которые будут созданы пользователями системы, то необходимо жёстко прописать некоторые правила, которые помогут будущим модулям описать свою принадлежность (скажем посредством атрибутов). Таким образом, появляются следующие ограничения:
- в системе изначально предопределены три группы пользователей
- группа обычных пользователей
- группа управленцев
- группа аналитиков
- каждый пользователь системы должен придалежать хотябы одной из этих групп
Теперь для меня встаёт вопрос, как мне это всё ПРАВИЛЬНО описать.
Требование по добавлению функциональности в будущем не является функциональным или, точнее, это требование более высокого уровня, чем «обычное» требование, отвечающее на вопрос ЧТО система должна ДЕЛАТЬ. Соответственно это требование не может быть описано «диаграммой вариантов использования» с последующим раскрытыем конкретной ПОСЛЕДОВАТЕЛЬНОСТИ ДЕЙСТВИЙ в виде сценариев. Во всяком случае я не представляю как это сделать
Вопрос №1, где и в какой форме мне это (видимо нефункциональное) требование описать? В каком док-те?
Далее, требование регулировки доступа к функциональности посредством групп. Тут всё понятно, это «вариант использования» «Авторизация», со сценарием, в котором описан основной и альтернативные потоки процесса авторизации.
Вопрос №2, (пока писал кажется понял ответ
) был в том, где и в какой форме описать ограничения. Тут я понял что делать, как только назвал ограничения ограничениями (а не нефункциональными требованиями). Ограничения (видимо) можно описать в спецификации прецедента «Авторизация», в резделе ограничения
Хотя, с другой стороны, эти ограничения более высокого уровня, чем сам процесс авторизации пользователя.
В самом общем виде мой вопрос(ы) в следующем. Какие документы обычно используются (ведутся) в процессе разработки, при переходе от итерации к итерации и от фазы к фазе? Те же диаграммы и спецификации прецедентов оформляются потом в какой-то единый документ? Как и где (в какой форме) описываются нефункциональные требования? Я знаю о модели классификации требований FURPS, но это знание не отвечает на вопрос как, блин, всё это ГРАМОТНО оформить!?
UP: Документ с исходной архитектурой