4.5. Валидация требований
Валидация – это процесс проверки истинности сформулированного списка требований, т.е. установление того, что выделенные требования – это действительно требования пользователей. Валидация - это один из наиболее сложных и трудно формализуемых этапов. На этапе валидации используют следующие основные технологии.
1. Рецензирование списка требований несколькими экспертами.
2. Разработка прототипа система. (Это может быть, например, модель экранных форм приложения).
3. Оценка возможности создания теста. Каждое требование должно быть тестируемым. Если не удается составить тест, который может проверить выполнение некоторого требования, то это может означать, что реализация этого требования может оказаться очень сложным, поэтому на это требование следует обратить особое внимание и, по возможности, реструктуризировать данное требование.
4.6. Документирование требований
Документирование или спецификация это процесс, в результате которого в качестве артефакта появляется документ, в котором описывается то, что должны сделать разработчики ИС. В нем детально описываются как пользовательские, так и системные требования. Иногда они интегрируются в единое описание, иногда сначала излагаются пользовательские требования, а затем подробно описываются системные требования.
Обычно требования документируются до начала проектирования, однако, не всегда. При использовании процесса проектирования, известного как экстремальное программирование [64] пользовательские требования собираются в процессе проектирования и постоянно уточняются. Пользователи могут назначать приоритеты отдельным требованиям. Подобный подход достаточно хорошо проявляет себя применительно к проектированию относительно небольших по размеру систем с постоянно меняющимися требованиями.
Спецификация требований выполняется в интересах нескольких категорий заинтересованных сторон (stakeholders). В табл. 4.1 приведен список основных заинтересованных лиц и их интересы применительно к списку требований.
Таблица 4.1.
Основные заинтересованные лица и их интересы
|
Заинтересованное лицо |
Интерес |
1 |
Покупатель, пользователь |
Проверка степени соответствия потребностям |
2 |
Менеджер проекта |
Планирование процесса разработки |
3 |
Программист |
Понимание того, какую систему требуется разработать |
4 |
Специалист по тестированию |
Разработка тестов |
5 |
Системный администратор |
Понимание структуры системы и того как она должна функционировать |
Документ, описывающий требования к системе, должен быть написан таким образом, чтобы он был понятен всем перечисленным категориям пользователей и отвечал ни их вопросы. Это не всегда просто сделать надлежащим образом.
В соответствии со стандартом [59] спецификация требований включает в себя следующие разделы.
Преамбула, в которой приводится самая общая информация о системе, описывается история версий документа и указываются основные отличия текущей версии от предыдущих версий.
Введение, в котором описывается назначение системы, ее основная функциональность, возможные варианты взаимодействия с другими системами и возможные варианты использования.
Глоссарий, в котором приводятся определения основных терминов.
Пользовательские требования, описывающие сервисы, предоставляемые пользователю системой, здесь также описываются нефункциональные требования. Описание пользовательских требований обычно выполняется на естественном языке, понятном конечному пользователю. Здесь же перечисляются стандарты, которым должна соответствовать разрабатываемая система.
Описание системной архитектуры, содержащее высокоуровневое описание системы в терминах основных подсистем и способов их взаимодействия.
Системные требования – подробно описываются функциональные и нефункциональные требования, определяются интерфейсы с внешними системами.
Системные модели, описывающие функционирование системы и ее взаимодействие с внешним миром. Эти описания ориентированы на тех, кто должен разрабатывать систему. Они должны быть максимально точны и подробны. Для описания системных моделей могут использоваться объектные модели, модели потоков данных, семантические модели.
Возможные направления эволюции системы – рассматриваются возможны варианты развития системы, обусловленные развитием элементной базы, изменениями потребностей пользователей и т. п. Фактически речь идет о формировании требований к следующим поколения систем данного класса. Основная цель данного раздела – помочь разработчикам избежать решений, которые будут ограничивать возможности системы в плане модернизации.
Приложения – в частности, при проектировании крупных систем могут содержать описания требований к подсистемам второго уровня.
Индексы – чаще всего это алфавитный указатель используемых в описании терминов.