Книга: Программист-прагматик. Путь от подмастерья к мастеру

В поисках требований

В поисках требований

Как распознать истинное требование, пробиваясь к нему сквозь толшу грязевых наносов? Ответ на этот вопрос и прост, и сложен одновременно.

Простой ответ состоит в том, что требование формулирует необходимость осуществления чего-либо. Грамотно составленное требование выглядит следующим образом:

• Доступ к личному делу сотрудника ограничен группой уполномоченных на то лиц.

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

• Редактор выделяет ключевые слова, выбор которых зависит от типа редактируемого файла.

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

Первая формулировка в списке, приведенном выше, вероятно, была составлена пользователями следующим образом: «Доступ к личному делу сотрудника ограничен его руководителями и работниками отдела кадров». Является ли эта формулировка требованием? Возможно, что сегодня и является, но она воплощает бизнес-политику в абсолютной формулировке. Политика же регулярно меняется, поэтому, скорее всего, мы не захотим жестко встраивать ее в наши требования. Мы рекомендуем документировать положения политики отдельно от требований и связывать их посредством гиперссылки. Сделайте требование общей формулировкой и снабдите разработчиков информацией о политике в качестве примера того, что им придется поддерживать в реализации. В конечном счете политика конечна, как и метаданные в приложении.

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

Различия между требованиями, политикой и реализацией могут быть весьма размытыми, если речь идет о пользовательских интерфейсах. Слова «Система должна давать возможность выбора срока предоставления ссуды» представляют собой формулировку требования. Выражение «Для выбора срока предоставления ссуды необходимо окно списка» может являться формулировкой, а может таковой и не являться. Если пользователям позарез нужно окно списка, то в этом случае речь идет о требовании. Если же вместо этого они описывают свою способность выбирать, используя окно списка лишь в качестве примера, то здесь говорится не о требовании. Врезка ниже «Когда интерфейс становится системой» описывает проект, который пошел совсем не в ту сторону, поскольку потребности пользователей в интерфейсе были проигнорированы.

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

Существует простая методика: чтобы взглянуть изнутри на требования (которые часто являются весьма недостаточными) ваших пользователей, нужно самому стать пользователем. Пишете систему для службы поддержки? Посидите пару дней на телефоне вместе с опытным сотрудником этой службы. Занимаетесь автоматизацией ручной системы управления складскими запасами? Поработайте на складе с неделю [41]. Вы получите представление о реальном использовании системы и вдобавок будете просто поражены тем, насколько просьба «Можно я посижу рядом с вами недельку и посмотрю, как вы работаете?» способствует доверию и закладывает основы ваших взаимоотношений с пользователями. Но не путайтесь у них под ногами!

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

Оглавление книги