CC BY
46
часть работы организаторов, что будет способствовать повышению качества проводимых мероприятий.
Использованные источники:
1. Маторин С.И. Теория систем и системный анализ: Учебное пособие / С.И. Маторин., О.А. Зимовец. - Белгород: Изд-во НИУ «БелГУ», 2012. - 288 с.
2. Михелев В.М. Базы данных и СУБД: учебное пособие - Белгород: Изд-во Белгородского гос. ун-та, 2007. - 199 с.
УДК 004.42
Жуйкова А.А. студент магистратуры Поволжский государственный университет телекоммуникаций и информатики
Россия, г. Самара
ИНЖЕНЕРИЯ ТРЕБОВАНИЙ
Аннотация:
Статья посвящена подразделу системной инженерии - инженерии требований. В статье рассматриваются две группы требований: требования заказчика и требования разработчика. Описывается спецификация анализ и формирование требований.
Ключевые слова: инженерия требований, трассировка требований, спецификация требований, анализ требований, функциональные требования, нефункциональные требования.
Zhuykova A.A., Master Povolzhsky State University of Telecommunications and Informatics.
Russia, Samara
TECHNICAL REQUIREMENTS
Annotation:
The article is devoted to the subsection of system engineering - engineering requirements. The article considers two groups of requirements: customer requirements and developer requirements. The specification of analysis and requirements formation is described.
Keywords: requirements engineering, requirements traceability, specification of requirements, requirements analysis, functional requirements, non-functional requirements.
Инженерия требований - это раздел дисциплины системной инженерии, в котором изучается разработка требований с использованием итерационного кооперативного процесса исследования проблемы, документирование результатов наблюдений и проверки точности полученного понимания.
Инженерия требований является неким междисциплинарным
подходом, который связывает стороны поставщика и заказчика для определения и поддержки требований, которым должна отвечать целевая система, продукт или услуга.
Инженерия требований должна начинаться с управления требованиями. Требование - это некое утверждение, относящееся к части системы. Контрольная точка - это достижение этого требования к какому-то моменту.
Существует две группы требований: требования заказчика и требования разработчика. Отличаются они друг от друга степенью проработки описаний. Первичные требования документируют желания и потребности заказчика и пишутся на языке, понятном заказчику. Детальные требования документируют требования в специальной, структурированной форме, они детализированы по отношению к первичным требованиям.
Рис. 1. Интеграция требований разработчика и заказчика в единую спецификацию требований Требования, которые описывают поведение системы и сервисы, которые она должна выполнять, называются функциональными требованиями. Они задают работу, которую должна выполнять программная система.
Требования, которые относятся к характеристикам системы и ее внешнего окружения, называются нефункциональными. Дополнительно могут перечисляться ограничения, накладываемые на действия и функции системы, а также на условия разработки. Такие требования не связанны непосредственно с функциями системы. Многие нефункциональные требования относятся к системе в целом, а не к отдельным ее элементам. Это означает, что они могут быть более критичными, чем единичные функциональные требования. Ошибка в функциональном требовании может понизить функциональные возможности системы, а ошибка в нефункциональном требовании может привести к отказу всей системы.
Формы записи требований могут быть самыми разными. Однако требования должны быть:
• ясными (не допускать двоякого толкования, приводящего к
искажению смысла пожеланий заказчика);
• согласованными (не содержать противоречивых и взаимоисключающих утверждений);
• полными (определять всю требуемую функциональность системы).
Формирование требований. Требования заказчика представляются в
такой форме, что они понятны любому пользователю, не владеющему специальными техническими знаниями. Первичные требования должны определять только внешнее поведение программного обеспечения, без детализации структурной организации системы. Они записываются на естественном языке с использованием простых таблиц, а также наглядных диаграмм, рисунков.
Формирование требований является лишь начальной фазой работы с требованиями. Анализ требований рассматривает требования заказчика как исходные данные, на выходе анализа — требования разработчика, которые справедливо называют детальными требованиями. Анализ требований служит мостом между подготовкой-планированием и проектированием программного обеспечения.
Различается два аспекта инженерии требований. Формулировка необходимых требований и их анализ. В процессе выявления необходимых требований компания-разработчик выясняет, что необходимо и почему. Этот процесс относится к дисциплине извлечения необходимых знаний и требует применения многих методов, относящихся к этой дисциплине. Анализ требований, с другой стороны, представляет собой процесс понимания существующих или выявленных требований. Здесь разработчик требований задается вопросами о полноте и структуре полученной информации. Это различие позволяет разделить огромный труд по разработке технических требований на две довольно различные части. Одна часть концентрирует внимание на методах получения знаний и основывается на теории влияния человеческого фактора, гуманитарных системных методах и эргономике. Вторая часть акцентирует внимание на формальных методах системного анализа. В контексте объектно-ориентированных разработок существовало несколько попыток распространить формальные теории на объектно-ориентированный анализ.
Спецификация требований — это документ, являющийся официальным предписанием для разработчиков Программного обеспечения. Он содержит описание требований заказчика (первичных требований) и разработчика (детальных требований). Первичные требования документируются при формировании требований, а детальные требования -при выполнении анализа требований.
Трассировка требований, поступающих в ходе разработки итерации. Поступление требования, когда работы итерации начались, прерывает последовательный процесс выполнения итераций - необходима немедленная реакция на новые требования, после которой (а во многих случаях и
параллельно) прерванный процесс выполнения итераций возобновляется. Выполняется мини-цикл обработки требований, который нужно изобразить в качестве дополнительного элемента модели, описывающей объектно-ориентированное развитие проекта с учетом трассировки. При этом в модели, как и в первом варианте, следует отразить возможные результаты анализа требования:
• требование отклоняется — работа с требованием прекращается;
• требование принимается к реализации на текущей итерации;
• реализация требования откладывается до следующих итераций. Инженерия требований и реорганизация бизнес-процессов должны
начинаться с формирования четких требований, как со стороны заказчика, так и со стороны разработчика. Разработчик должен явно понимать спецификацию всех требований. Им должен быть проведен четкий анализ требований.
Использованные источники:
1. Пилон, Д. Управление разработкой ПО [Текст] / Д. Пилон, Р. Майлз. -СПб. : Питер, 2011. - 460 с
2. Скопин И. Н. Основы менеджмента программных проектов. Курс лекций [Text] : учеб. пособие для вузов / Скопин И. Н. - М. : ИНТУИТ. РУ, 2004. -336 с.
3. Грэхем, И. Объектно-ориентированные методы. Принципы и практика [Text] / И. Грэхем ; пер. с англ., ред. Н. Н. Куссуль. - 3-е изд. - М. : Вильямс, 2004. - 880 с.
4. Орлов, С. А. Технологии разработки программного обеспечения. Современный курс по программной инженерии [Текст] : учебник для вузов / С. А. Орлов, Б. Я. Цилькер. - 4-е изд. - СПб. : Питер, 2012. - 608 с.
