12.2. Анализ требований

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

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

1

1ццеи. Система должна быть совместима с уже имеющимися си-^стемами, а также согласовываться с имеющимися организацион-•ными требованиями.

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

Случаи, предполагающие безошибочную работу, представ­ляют собой лишь весьма малую часть всех возможных вариантов поведения программы, поэтому весьма важно рассмотреть и опи­сать поведение программы при наличии ошибок. Этой частью анализа никогда не следует пренебрегать или недооценивать ее. Аналитик должен попытаться обнаружить все возможные ошибки, которые могут произойти, и разработать соответствующие реакции программы во всех таких случаях. Ошибки исходят из двух источ­ников: пользователей, работающих с программой, и программных и аппаратных сбоев. Для изучения ошибок пользователя очень удобно использовать сценарии, поскольку они позволяют нам выделить места внесения пользователями ошибок. Иногда гра­мотное проектирование интерфейса позволяет избежать ошибок пользователя, например предоставляя работающему в интерактив­ном режиме пользователю меню, содержащее только разрешенные команды. Другая возможность предполагает распознавание си­стемой ошибочных вводов и отбрасывание их. Разумеется, всех ошибок избежать невозможно. Например, если банковский слу­жащий сделает ошибку при введении номера счета вкладчика, то это будет обнаружено только при анализе вкладчиком ежемесяч­ного отчета. Аналитик должен учитывать ситуации 'подобного рода и принять решение о том, что делать в подобном случае. Очень часто для принятия подобных решений необходимо консуль­тироваться с заказчиком, поскольку в данной ситуации привле­каются методы ведения дел (например, принятие решения о том, как компенсировать вкладчику неприятности, связанные с тем, что его чек не был оплачен вследствие ошибки служащего банка).

До тех пор пока речь идет о программных ошибках, аналитик должен принять решение об объеме работы, который на этапе раз­работки программы необходимо затратить на локализацию, исклю­чение и ограничение возможной сферы возникновения ошибок. Например, часто при необходимости ограничения области возник-9*

250 Глава 12

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

Помимо функциональных требований программа также должна удовлетворять требованиям эффективности. Фактор времени вы­полнения и фактор объема используемой памяти должны рас­сматриваться вместе, поскольку обычно необходимо прийти к не­которому соглашению между этими критериями. В первую очередь должно быть установлено, не имеется ли жестких ограничений по первому или второму пункту. Например, программа может ра­ботать на микроЭВМ с объемом памяти в 128кбайт и одним гиб­ким диском. Альтернативно, может иметься требование времен­ного ограничения при работе в реальном масштабе времени (на­пример, вычисление текущего уровня поверхности каждую деся­тую секунды). При рассмотрении временной эффективности важно различатьпроизводительностьивремя отклика.Под производи­тельностью понимается объем данных, обрабатываемый системой за некоторый интервал времени. Время отклика характеризует время между двумя взаимодействиями с системой. Очень часто оптимизация одной из этих характеристик приводит к ухудшению другой. Например, для сети из ЭВМ увеличение производитель­ности приводит к увеличению времени отклика за счет постановки сообщений в очередь.

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

Рассмотренные аспекты непосредственно влияют на требования спецификации. Имеется ряд других соображений, которые должны

^Предварительные замечания о процессе разработки программ

1быть рассмотрены на этапе анализа требований не потому, что1они влияют на спецификацию, а поскольку они обеспечивают раз-«работчика ценной информацией. К этим аспектам относятсямодифицируемостьиповторная используемость.Обычно имеется ряд областей, которые не изменяются, и ряд, в которых весьма вероятны возможные изменения. Информация о возможных изме--„,.T,ovп fivnvnieMочень полезна, поскольку в этом случае проек-

нениях в будущем очень

чтобы максимально

нениял " uj^j^— .. -

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

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

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

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

262 Глава 12

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