Определение требований к продукту

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

Дело осложняется тем, что заказчик программного продукта часто не может полностью сформулировать то, что он хочет получить. Его требования огра­ничиваются общими фразами вроде: "Сделайте мне систему, такую же, как CoolProduct, но рассчитанную на наши правила товарооборота и отчетно­сти". Получив же такую систему, заказчик чаще всего восклицает: "Но я со­всем не это имел в виду!" Поэтому требования к программному продукту вырабатываются в результате долгих обсуждений и уточнений. Зачастую они изменяются уже в ходе разработки, хотя этого надо всячески избегать.

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

Требования к функционированию продукта

Самое главное требование к программному продукту заключается в том, чтобы он решал поставленную задачу в максимальном объеме и с макси­мально возможной точностью. Потребителя продукта редко интересует ал­горитм решения задачи. Ему просто нужно получить результаты как можно точнее и быстрее. Более того, потребитель хочет, чтобы управление про­граммой было простым и привычным для него. Ему надо сразу сесть и на­чать работу с программой, у него нет времени на обучение и нет желания долго вникать в особенности продукта и изучать новые команды для работы с ним.

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

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

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

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

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

Плодотворный метод определения функциональных требований разработал Айвар Якобсон (Ivar Jacobson). Этот метод входит в так называемый унифи­цированный процесс разработки (RUP, Rational Unified Process), предлагае­мый фирмой Rational Software Corporation. Якобсон предложил начинать определение требований с составления всех возможных действий (actions) некоторого действующего лица (actor) с программным продуктом, с начала сеанса его работы до окончания сеанса. Действующим лицом может быть не только пользователь, но и какой-то алгоритм, выполняющийся в программ­ном продукте, и какая-то внешняя программа.

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

Набор всех сценариев, приводящих к одному результату, называется use case. На русский язык этот термин переводят по-разному: прецедент, сцена­рий использования, вариант использования. Сценарии, образующие преце­дент, называются экземплярами (instances) прецедента. Вначале в прецеден­ты вносятся все сценарии, в том числе и неудачные. Затем сценарии каждого прецедента анализируются, обобщаются и собираются в один-два наилучших сценария.

Например, пользователь Интернета может создать экземпляр прецедента "Загрузить файл с сайта", набирая адрес этого сайта в строке адреса браузе­ра. Другой экземпляр прецедента будет создан щелчком кнопки мыши по ссылке в окне браузера. Как видите, в браузере реализовано несколько сце­нариев прецедента "Загрузить файл с сайта". Набор другого адреса — это другой сценарий того же прецедента. Если адрес верен и загрузка файла до­пустима, то сценарий завершится успешно, в противном случае сценарий завершится неудачей.

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