Определение требований к программному обеспечению

Сергей Трофимов

22.01.2003

Вступление
Перечисление возможных требований
Осознание контекста системы
Модель предметной области
Бизнес-модель
Определение функциональных требований
Определение нефункциональных требований

Вступление

Любая программная система создается для решения одной или нескольких проблем будущих пользователей программной системы. Программа – это ни что иное, как некоторый алгоритм, заложенный в компьютер для решения определенного круга задач, работа которого должна принести пользователю ощутимый результат.

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

Традиционный подход решения этой проблемы – это поручение определения требования аналитикам, которые проводят с пользователями интервью, выявляя их реальные потребности. Но даже аналитикам трудно получить непротиворечивый и в дальнейшем мало изменяемый список требований, если не использовать систематизированный подход к определению требований.

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

Можно определить следующие шаги рабочего процесса определения требований*:

Перечисление возможных требований;

Осознание контекста системы;

Определение функциональных требований;

Определение нефункциональных требований.

Перечисление возможных требований

Первое, что нужно сделать – это начать собирать всевозможные требования и идеи насчет будущей системы. Это будет несистематизированный список, в который должно попасть все, что касается системы и приходит в голову разработчикам, аналитикам и пользователям. Эти идеи будут кандидатами на реализацию в будущих версиях системы и используются для планирования работ.

Каждое предложение в списке должно иметь короткое название и краткое описание, в чем оно состоит, также для дальнейшей работы необходима дополнительная информация для планирования и последующей реализации требований, в которые могут входить:

состояние предложения (например, предложено, одобрено, включено в план, утверждено);

трудоемкость в человеко-часах или стоимость реализации;

приоритет (например, критический, важный или вспомогательный);

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

Этот список в ходе работ может уменьшаться, когда требования преобразуются в другие артефакты, например – варианты использования или нефункциональные требования, и увеличиваться, когда выдвигаются новые предложения.

Осознание контекста системы

Для того чтобы верно определить требования разработчики системы должны понимать контекст (часть предметной области) в котором работает система. Существует по крайней мере два подхода к описанию контекста системы:

Моделирование предметной области;

Бизнес-моделирование.

Модель предметной области

Модель предметной области описывает важные понятия предметной области и их связи между собой. Нельзя путать модель предметной области с логической и физической моделями системы. Модель предметной области описывает только объекты предметной области, но не показывает, как программная система будет с ними работать. Данная модель также позволяет составить глоссарий системы для лучшего ее понимания пользователями и разработчиками.

Бизнес-модель

Бизнес-модель описывает процессы (существующие или будущие), которые должна поддерживать система. Бизнес-модель можно представить как подмножество модели предметной области. Кроме определения бизнес-объектов, вовлеченных в процесс, эта модель определяет работников, их обязанности, и действия, которые они должны выполнять.

Определение функциональных требований

Подход к выявлению системных требований основан на использования вариантов использования системы (Use Cases), которые охватывают как функциональные, так и нефункциональные требования, которые специфичны для конкретного варианта использования.

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

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

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

Определение нефункциональных требований

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

Требования по производительности – это скорость, пропускная способность, время отклика, используемая память. Многие требования, связанные с производительностью должны быть описаны в конкретных вариантах использования, а не в разделе относящейся ко всей системе.

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

*Согласно Rational Unified Process