Варианты использования (use cases)
Варианты использования (use cases) определяют взаимодействие между пользователем рассматриваемой системы (часто называемым действующим лицом или действующим субъектом (actor)) и собственно системой. На контекстных диаграммах и диаграммах потоков данных они показаны в виде окружностей или эллипсов, обозначающих процессы. На диаграмме вариантов использования (use case diagram) отображаются действующие субъекты и варианты использования, а также показываются связи между ними. Каждый вариант использования определяет функциональные требования к системе. Несмотря на то что действующий субъект схематично обозначен человеческой фигурой, он не обязательно является человеком, скорее, это определённая роль (role). Каждый действующий субъект должен быть связан как минимум с одним вариантом использования. Кроме того, на диаграмме вариантов использования граница системы обозначается прямоугольником, внутри которого указывается наименование данной системы. Обычно каждая диаграмма вариантов использования сопровождается текстовым описанием наиболее важных и полезных характеристик системы.
На рис. 3.13 показан пример диаграммы вариантов использования для банковской системы.
15. Описание и проверка требований. Ключевые требования. Использование атрибутов. Обеспечение непротиворечивости требований.
Ключевые требования (KUR – Key User Requirements) или ключевые показатели эффективности (KPI – Key Performance Indicators), представляют собой небольшое подмножество требований, выделенных из общей совокупности требований, предъявленных к системе в целом. Принципиальная «философская» основа выбора ключевых требований похожа на ту, что описал Джером К. Джером в своём произведении «Трое в лодке», когда три джентльмена, планируя своё путешествие, приходят к пониманию того, что «...верховья Темзы недостаточно судоходны, и там не сможет пройти судно, достаточно большое для того, чтобы вместить всё, что мы сочли необходимым взять с собой в путешествие. Мы разорвали список и озадаченно посмотрели друг на друга. Джордж сказал: – Так ничего не выйдет. Нужно думать не о том, что нам может пригодиться, а только о том, без чего мы не сможем обойтись». Для каждого ключевого требования должен быть получен уверенный отрицательный ответ на следующий вопрос: «Если предлагаемое решение не предоставляет мне эту возможность, сохраняется ли моё намерение заплатить за него?» или на уровне системы: «Если система не выполняет эту функцию, сохраняется ли для меня необходимость в её приобретении?». При таком подходе ключевыми становятся только совершенно необходимые, обязательные требования. (Разумеется, договориться можно обо всём, но вопросу о ключевых требованиях всегда следует уделять особое внимание.) Насколько это возможно каждое ключевое требование должно быть выражено в количественной форме с помощью показателей, связанных с функциональными характеристиками системы. В таком случае ключевые требования могут быть использованы в качестве KPI для предварительной оценки альтернативных предложений по требованиям или в качестве сводки важнейших статистических показателей, характеризующих развитие проекта
Использование атрибутов
Обеспечение непротиворечивости требований
При управлении большим набором требований часто возникает необходимость в выявлении конфликтующих требований. Здесь сложность заключается в том, что противоречащие друг другу формулировки могут быть разделены множеством страниц. Какие методики можно применять для обнаружения подобных несоответствий? Во-первых, возможны классификация требований несколькими способами и использование методов выборки и сортировки для отбора небольшого количества требований, соответствующих заданному критерию. Многие требования касаются нескольких конкретных свойств системы. Например, требование, касающееся в первую очередь мощности двигателя, может включать составляющие, относящиеся к безопасности. Таким образом, подобный пункт требований должен рассматриваться как с точки зрения мощности двигателя, так и в контексте обеспечения безопасности. Ранее, в разделе 1.3, уже отмечалось, что для требований могут быть установлены основная (первичная) и вспомогательные (вторичные) классификации. Как правило, имеется одна основная классификация (например, на основе расположения пунктов в документе), а вспомогательных классификаций, например использующих ссылки и атрибуты, может быть несколько. Благодаря этому полноценный процесс проверки и контроля может включать систематические процедуры отбора пунктов требований по ключевым словам из основной и вспомогательных классификаций. Например, отбор всех требований с упоминанием безопасности можно будет объединять с выборками по различным ключевым словам основной классификации, что позволит более эффективно обнаруживать потенциально конфликтующие требования.