Составляем требования. Метод VORD.
Сегодня я попробую в общих чертах описать методологию составления требований к ПО под названием VORD. Расшифровывается это как Viewpoint-Oriented Requirements Definition (“Определение требований на основе точек зрения”).
Главным принципом, положенным в основу этого метода является то, что весь необходимый функционал структурируется в соответствии с группами пользователей системы.
План написания требований методом VORD выглядит так:
- Определение всех “точек зрения” на систему. Составление списка пользователей и внешних систем взаимодействующих с системой.
- Структурирование точек зрения. Построение иерархии точек зрения.
- Документирование точек зрения.
Первый этап обычно выполняет в стиле “мозговой атаки”. Вся система условно делится на сервисы и точки зрения (пользователи системы или внешние системы, взаимодействующие с ней). Результатом этой работы становится длинный список точек зрения и сервисов.
После сбора всей этой информации переходят ко второму этапу – структурированию точек зрения.
На этом этапе выстраивают иерархию всех выделенных точек зрения и соотносят с ними необходимые сервисы, которая должна предоставлять система (некоторые сервисы могут относиться сразу к нескольким точкам зрения при этом).
Например, если среди точек зрения были выделенны такие как “банк”, “отдел управления рисками”, “сотрудник банка”, то на верхнем уровне иерархии окажется банк. Под ним будет отдел управления рисками и на самом нижнем уровне – сотрудник банка. Я думаю тут все понятно.
После этого остается только более детально расписать все точки зрения и предоставляемые системой сервисы.
Для хранения всей получаемой в процессе информации, обычно используют элементарные диаграммы вроде таких:
А получение данных перед началом “мозговой атаки” реализуют обычным опросом служащих компании, для которой пишется ПО.
Принцип вполне логичен и прост, на мой взгляд.
Удачи!
А в чем удобство этого метода?
Какие плюсы и минусы по сравнению с другими методами?
Метод как по мне не очень. Например если проект сайт то там может быть всего три точки зрения (гости, пользователи и админы), если сайт уже очень крупный то может быть больше точек зрения, но обычно все решается с помощью управления доступом, т.е. реалиных точек зрения будет не много.
Этот метод мне напоминает ООП и другие подходы, которые требуют довольно высокого уровня абстракции.
2 adw0rd: Если рассматривать ситуации грубо, то есть два варианта:
1. Разрабатываемая система, строится на основе уже существующей + модернизируется и возможно добавляется функционал.
2. Система пишется полностью с нуля.
Во втором случае “опрос” всех пользователей системы провести не удастся, так как они еще и сами не знают какие функции они будут выполнять с использованием будущей системы; в отличие от первого случая, где они просто “вспоминают”, для чего они использовали предыдущую систему.
Поэтому можно предположить, что этот метод будет более адекватно работать для первого случая и позволит полностью “увидеть” систему в результате, ничего не упустив.
Насчет применимости этого метода для второго случая - вопрос спорный. Теоретически он тоже вполне подходит, но, возможно, есть и какие-то более эффективные методы. Я пока сам не знаю, поэтому точно сказать не могу Как только найду информацию про другие методики - обязательно напишу.
2 Igor: Согласен. Тут этот метод будет не особо эффективен. Кстати из этого можно сделать определенные выводы относительно использования этого метода. Например такой: метод VORD будет работать тем эффективней, чем ближе друг к другу будут находится кол-во точек зрения и кол-во возможных сервисов системы для каждой точки зрения.
Только в этом случае получится произвести более-менее нормальную декомпозицию системы как бы. От которой будет толк
2 kreditka.net: Сложные системы вообще сложно проектировать без использования ООП А степень абстракции на последующих этапах этого метода уменьшается, когда каждый сервис и точка зрения расписывается детально.