Методы и средства инженерии программного обеспечения

       

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


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

Анализ и сбор требований является довольно нетривиальной задачей, поскольку в реальных проектах приходится сталкиваться с такими общими  трудностями:

– требования не всегда очевидны и могут исходить из разных источников, их  не всегда удается ясно выразить словами;

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

–                    требования связаны друг с другом, а также с процессами разработки ПС  и постоянно меняются.

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

Аналитик  системы, который занимается анализом и составлением требований,  должен иметь определенные  знания ПрО и навыки, чтобы справиться с этими трудностями. Он должен  уметь:

– анализировать проблему,

– понимать  потребности заказчика и пользователей,

– определять функции системы и требования к ним,

– управлять контекстом проекта и изменением требований.

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

Здесь цена ошибок и нечетких неоднозначных  формулировок очень  высока,  поскольку  время и средства могут расходоваться на ненужную заказчику систему или программу. Для внесения изменений в  требования может потребоваться   повторное проектирование  и, соответственно, перепрограммирование всей системы или отдельных ее частей. Как утверждает статистика,  процент ошибок в постановке требований и в определении задач системы превышает процент ошибок кодирования.
Это  является следствием субъективного характера процесса формулирования требований и  отсутствия способов его формализации. К примеру, в США ежегодно расходуется до $ 82 млрд. на проекты, признанные после реализации не соответствующими требованиям заказчиков.

Существуют стандарты на разработку требований  на  систему и документы, в которых фиксируются результаты создания программного, технического, организационного и др. видов обеспечения автоматизированных систем (АС) на этапах жизненного цикла, включающие. В приложении 2, 3 дается краткое описание ГОСТ 34.601-90 «Стадии и этапы разработки АС» и ГОСТ 34.201-89 «Документация на разработку АС».



В процессе формулирования требований на систему принимают участие:

– представители  от  заказчика из нескольких профессиональных групп;

– операторы,  обслуживающие систему;

– разработчики системы.

Процесс формулирования   требований   состоит из нескольких подпроцессов? Сбор и анализ требований.

Сбор требований.  Источниками сведений о требованиях могут быть:

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

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

Таким образом, требования к  системе   формулируются  исходя из:

– знаний заказчика относительно проблемной области,  формулирующего  свои проблемы в терминах понятий этой области;

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



Методами сбора требований  являются:

– интервью с носителями интересов заказчика и операторами;

– наблюдение  за  работой  действующей системы с целью отделения ее  проблемных   свойств от  тех, которые обусловлены структурою кадров;

– сценарии (примеров) возможных случаев выполнении ее функций, ролей лиц,  запускающих эти сценарии или взаимодействующих  с системой во время ее функционирования.

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

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

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

Нефункциональные требования  определяют условия  и среду выполнения функций (например,  защита и доступ к БД, секретность, взаимодействие компонентов функций и др.).

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

 

Функциональные требования  отвечает   на вопрос "что делает система", а нефункциональные требования определяют характеристики ее работы (вероятность сбоя системы, защита данных и др.).


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

– конфиденциальность;

–  отказоустойчивость;

– несанкционированный доступ к системе;

–  безопасность и защита данных;

–  время ожидания ответа на обращение к системе;

– свойства    системы    (ограничение на память,  скорость реакции при обращении к системе и т. п.).

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

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

Следующий шаг анализа  требований - установление их приоритетов  и избежание конфликтов между ними.

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

К настоящему времени сложилось направление в инженерии программирования  – инженерия требования,  сущность которой достаточно подробно  рассмотрена в соответствующей области знаний ядра SWEBOK и приводится ниже.


Содержание раздела