Comparative analysis of requirements assessment techniques

Abstract

Subjects of research are methods for assessing characteristics of requirements. The aim of the study is to compare the existing developments in the field of requirements engineering, in order to later develop its own method that is most suitable for Russian-language requirements specifications. The problem of existing methods lies in their disunity, the lack of precise criteria for assessing whether the requirements have inherent characteristics, and the lack of adaptation of these methods to Russian-language texts. For comparison, publications were described in which different methods were used for evaluation, and trends in evaluation methods were highlighted. Based on the results obtained, a method was proposed for assessing the characteristics of requirements written in Russian.

Keywords

• requirements
• assessment of requirements
• quality requirements
• lexical indicators

-

Существует проблема плохо сформулированных требований, увеличивающих рост проектных рисков [1]. На основе таких требований проблематично провести валидацию разработанной системы [ 2 ]. В статье [ 2 ] также указывается, что требования также проходят верификацию и валидацию, что гарантирует их высокое качество. Однако, что такое «качество требования» не было определено в этой статье. Так как требования являются результатом человеческой деятельности, то они являются продуктом инженерии требований. Соответственно, у требований тоже есть качество, которым можно управлять. В соответствии с рекомендациями стандарта ГОСТ Р ИСО 9000 [3], качество это степень соответствия совокупности присущих характеристик объекта требованиям . Следовательно, раз требования являются продуктом инженерии требований, то их качество определяется на основе присущих требованиями характеристик. Имеется ряд публикаций, статьи различных авторов, документы, подготовленные общественными организациями, нормативные документы профессионального и корпоративного уровня, а также официальные документы, подготовленные международными организациями стандартизации, в которых авторы описывают характеристики, которыми, по их мнению, требования должны обладать. Такое количество документов подтверждает, что проблема есть, она весьма существенная, и люди пытаются её решить различными способами.

Основной причиной появления некачественных требования является то, что требования пишут на естественном языке. [ 4 ] Естественный язык является наиболее распространенной формой для формулирования требований. Качество спецификации требований зависит от способности автора сформулировать требования, сформулированные на основе нужд заинтересованных сторон: они отражают потребности клиентов, затем эти требования используются аналитиками, разработчиками и тестировщиками. Учитывая эту центральную роль требований как средство выражения нужд заинтересованных сторон, обеспечение их качества имеет важное значение для уменьшения недопонимания, которое ведет к потенциальной растрате.

Для того, чтобы определить хорошо ли сформулированы требования, специалисты в области инженерии требований стараются выделить строгие критерии, которыми отдельные требования и наборы требования должны соответствовать. Опираясь на международный стандарт ISO/IEC/IEEE 29148 [ 5 ] в силу его официального статуса, специалисты используют описанные в стандарте характеристики, делая вывод, что если у требований эти характеристики есть, значит они сформулированы хорошо насколько это возможно. У каждой характеристики есть признаки, показывающие - обладает требование данной характеристикой или нет. Авторы создают различные методы оценки характеристик, выделяя признаки характеристик. Некоторые методы похожи между собой, некоторые отличаются, но специалисты стараются автоматизировать процесс оценки, так как это весьма трудоемкий процесс, ведь количество требований может быть весьма значительным. Автоматизация также позволит снизить вероятность совершения ошибки, в виду исключения человеческого фактора.

В Отечественной практике в настоящий момент проблема некачественных требований рассматривается очень узким кругом специалистов. Следовательно, имеющиеся методы оценки характеристик требований не адаптированы для использования в русскоязычных текстах, не определены строгие критерии, какими должны быть требования. Соответственно, в данной работе будет представлен сравнительный анализ существующих методов оценки характеристик требований, для их дальнейшего изучения и построения на их основе собственных методов, применимых к русскоязычным документам. 2 Характеристики требований В различных литературных источниках используют свой набор характеристик требований, но часть из них ссылается на международный стандарт ISO/IEC/IEEE 29148 [ 5 ]. В данной работе также в центре внимания рассматриваются характеристики, которые приведённые в стандарте ISO/IEC/IEEE 29148. Их перечень, описание и комментарии автора приведены ниже. 2.1 Необходимость (Necessary) Требование должно определять существенную способность, характеристику, ограничение и/или показатель качества. Если требование будет проигнорировано или удалено, то при определении способности или характеристики возникнут недостатки, которые не смогут быть полностью устранены за счет реализации других требований.

Замечание: Необходимое требование применимо в настоящее время и в последующем отказ от него не предполагается. Требования с ограничениями по срокам применимости четко определены [ 5 ]

Характеристика «необходимость» имеет важное значение, так как согласно определению, исключение выбранного требования станет причиной возникновения проблемы, которая не сможет быть устранена за счёт реализации других требований. Использование термина «существенную» также дает понять, что требование должно быть уникальным, т.е. не пересекаться с другими требованиями, в противном случае разработчикам придется выполнять одно и тоже требование, увеличивая на это затраты ресурсов. Также, в случае реализации похожих требований разными командами, повышается риск возникновения путаницы, и неизвестно кто за это будет нести ответственность. Также данный термин требует дополнительного пояснения, так как понятие существенности поможет для определения, обладает ли оцениваемое требование данной характеристикой или нет. Синонимом «существенный» является термин «важный». По существу, важным требованием считается такое требование, которое отражает какуюлибо нужду заинтересованных сторон (Далее – ЗС) или накладывает ограничение, исходящее из нормативных документов. В данном случае имеется в виду, что при существовании множеств требований ЗС и требований к системе, приветствуются случаи, когда требование ЗС порождает одно или несколько требований к системе, а вот наоборот – одно требование к системе реализует ряд требований ЗС – сигнализирует о том, что требования ЗС требуют дополнительного уточнения. Соответственно, для того, чтобы определить является ли требование существенным, нужно иметь источник, в котором перечислены нужды и потребности ЗС. Также дано замечание о том, что при формулировании требований нужно учитывать, что они являются актуальными на протяжении всего жизненного цикла системы, если не указано обратное. В руководстве INCOSE [ 6 ] указано, что необходимость требования можно подтвердить в результате экспертизы. Для подтверждения, что требование является необходимым, требуется показать требование, которое выше его в иерархии, или предоставить потребность, на основе которой оно было разработано. 2.2 Соразмерность (Appropriate) Конкретная цель и степень детализации требования должны соответствовать уровню структуры объекта, к которому это требование предъявляется (уровню абстракции).

Замечание: Следует избегать ненужных ограничений на архитектуру или проектные решения, и добиваться при этом максимально возможной независимости от способов реализации. [ 5 ]

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

Авторы статьи [ 7 ] придерживаются тех же взглядов на характеристику «Абстракция», считая принципиально важным, что требование не должно содержать избыточных деталей об осуществлении. В руководстве [ 6 ] считается важным учитывать соразмерность требования к уровню, так как неверно расположенные требования или будут содержать информацию о методе реализации, или будут неверно проанализированы, следовательно, не будут созданы требования более низкого уровню, приводя к потере требований. Для того, чтобы проверить обладает ли требование характеристиков соразмерности к уровню, авторы предлагают применять адекватное уровню подлежащее и сказуемое, что означает, что необходимо указывать к какому уровню детализации подлежащее принадлежит. Например, не может требование к «Шасси» находится на одном уровне с «самолётом». Касаемо сказуемых, предлагается использовать на более высоких уровнях сказуемые функции, которые разбиваются на несколько подфункций на низких уровнях. Например, «телефон должен поддерживать функцию коротких сообщений», имеет в составе сказуемое «поддерживать», которая на более низких уровнях разбивается на «написание смс», «хранение», «приём» и «передача» и т.д. 2.3 Однозначность (Unambiguous) Формулировка требования должна полностью исключать возможность неоднозначного толкования. Требование должно быть изложено простым, легким для понимания языком. [ 5 ]

Учитывая то, что требования пишут на естественном языке, увеличивается вероятность использования терминов, которые разными людьми могут быть истолкованы по-разному. Поэтому очень важно, чтобы требование обладало однозначностью. Как подчёркивают авторы руководства [ 6 ], требование должно быть сформулировано таким образом, чтобы отсутствовала необходимость в выяснении сути требования. Автоматически возможно обнаружить является ли требование однозначным, так как для этого всего лишь нужен поиск слов-индикаторов, свидетельствующих о наличии неоднозначности. В разных работах словами-индикаторами являются различные термины, которые вносят неоднозначность в требования. 2.4 Полнота (Complete) Формулировка требования должна исчерпывающе, исключая необходимость в дополнительной информации, определять способности, характеристики, ограничения, показатели качества, необходимые для удовлетворения потребности. [ 5 ]

Для обладания характеристикой полнота, необходимо формулировать требование таким образом, чтобы после ознакомления с ним, у читающего не возникала потребность в поиске дополнительной информации. Учитывая, что требования используются для валидации разработанной системы – соответствует ли она нуждам и потребностям ЗС – так и у проверяющего не должно возникнуть потребности в уточнении деталей, при использовании требований. 2.5 Единственность (Singular) Требование должно определять единственное (уникальное) свойство, способность, характеристику, ограничение или показатель качества. [ 5 ]

Требование должно обладать признаком единственности, т.е. система, подсистема или элемент системы в текущем требовании должен выполнять только одну функцию. Это упрощает реализацию, а также верификацию. Если требование будет содержать более одной функции, специалистам потребуется проводить дополнительные исследования, что ведёт за собой увеличение траты на время разработки. 2.6 Реализуемость (Feasible) Требование должно быть реализуемым с учетом имеющихся ограничений на системные решения (например, стоимость, график работ, технические и технологические возможности, правовые и нормативные ограничения) и с приемлемым уровнем риска. [ 5 ]

Безусловно, нужно формулировать требования таким образом, чтобы на их основе возможно было реализовать решение. Также требовании должен быть указан график работ, необходимо продумывать решения с учетом действующих стандартов, не нарушая законодательств. Авторы книги [1] выделяют характеристику «реализуемость», где рассматриваются конкретно возможности технической реализации относительно выделенных средств и сроков, и а также характеристику «законность», в которой рассматривается проблематика создания решений с учетом действующих стандартов, не нарушая законодательств 2.7 Верифицируемость (Verifiable) Требование должно быть структурировано и сформулировано таким образом, чтобы можно было получить приемлемые для заказчика доказательства реализации требования (верифицировать требование) на уровне, предусмотренном для подобных требований. Замечание: Верифицируемость улучшается, если требование измеримо. [ 5 ] Каждое решение должно проходить верификацию. Для этого требование, на основе которого оно было создано, должно давать такую возможность. Как пример, авторы книги [1] предлагают формулировать требования таким образом, чтобы его пункты были пригодны для верификации. По словам Терри Бахилл [8], верификация требований гарантирует, что системные требования удовлетворены, а также проверены технические, производственные требования. определил верификацию требований как процесс, чтобы доказать, что каждое требование было выполнено. Проверка может быть выполнена с помощью логики, проверки, моделирования, моделирования, анализа, проверки, тестирования или демонстрации. То есть требование сформулировано так, что на его основе можно провести различные тесты, перечисленные ранее. 2.8 Правильность (Correct) Формулировка требования должна давать точное представление об исходной потребности. [ 5 ] Чтобы требование было правильным, необходимо сопоставить его с потребностями и нуждами ЗС, насколько корректно оно отражает потребности ЗС, если это требование находится на высоком уровне в иерархии требований. Если у проверяемого требования существует требование-родитель, следует проверить насколько детализировано требование-потомок. Например, не нарушена ли единственность, т.е. не создалось ли дублирование с родителем или с другими требованиями. Или же наоборот – возможна потеря некой потребности при дроблении требования на отдельные более узкоспециализированные требования. 2.9 Соответствие нормам (Conforming) Отдельные элементы формулировки требования должны, при необходимости, соответствовать принятым стандартам, шаблонам и стилистическим нормам написания требований. [ 5 ]

Требования необходимо писать согласно принятым стандартам. В отечественной практике нет правил по написанию спецификаций требований, закреплённых стандартами, однако, требования входят в состав технического задания, регламентированных в таких документах, как ГОСТ 34 и ГОСТ 15. Так как требования оформляют в виде документа, то необходимо также придерживаться норм документной лингвистики. Примером таких норм может стать употребление особых языковых норм. [9] 3 Обзор методов оценки характеристик требований На основе изученных источников был сделан вывод, что авторы методов не всегда оценивают все характеристики, перечисленные в стандарте ISO/IEC/IEEE 29148, даже если берут его за основу. В частности, это происходит из-за того, что не все характеристики можно оценить автоматически. В данной работе рассматриваются методы, прежде всего основанные на поиске лингвистических индикаторов, так как они наиболее распространенные и поддаются автоматизации, не требуют дополнительной консультации экспертной комиссии. А также их наиболее удобно адаптировать для русскоязычных текстов. В частности, в руководстве INCOSE [ 6 ] предлагают для проверки использовать шаблоны (паттены), то есть определённый порядок слов. Это также было бы актуально для проверки характеристики «Соответствие нормам» автоматически, однако, учитывая специфику русского языка, этот способ в текущий момент проблематично реализовать [10]. Ряд авторов не только разработали методы оценки характеристик или качества требований, а также создали инструменты, чтобы автоматизировать этот трудоемкий процесс. Ниже представлен краткий обзор таких разработок и их анализ. 3.1 Гонсало Женова , Хосе М. Фуэнтес, Хуан Льоренс, Омар Уртадо, Валентин Морено «Фреймворк для измерения и улучшения качества текстовых требований» В своей статье [ 7 ], авторы рассказывают о своем инструментарии RQA, предназначенном для оценки качества требований. Проанализировав публикации и стандарты, авторы выделили следующий список характеристик, которыми должны обладать требования. В своей работе они обозначат это термином «желаемые свойства». Были выделены следующие свойства:  валидируемость,  верифицируемость,  модифицируемость,  полнота,  солнасованность,  понятность,  однозначность,  прослеживаемость,  абстрация,  тончность,  единственность.

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

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

Так как авторам удалось определить показатели качества, с помощью которых возможно определить наличие желательных свойств, и были выведены соответствующие ступенчатые функции для оценки показателей, авторы разработали инструмент, выявляющий показатели, а также дающий рекомендации по улучшению требований. Авторы подчеркивают, что инструмент даёт минимальное значение среди всех показателей, что означает – если хотя бы один показатель имеет значение «Плохо», то даже при высоких значениях остальных показателей, требование является некачественным. Инструмент взаимодействует с системой DOORS и обрабатывает файлы в формате .xls. 3.2 Хеннинг Феммер, Даниэль Мендес и др. «Быстрые проверки требований с запахами требований: Два тематических исследования» В отличии от авторов предыдущей статьи, авторы работы [11] разрабатывали инструментарий для оценки качества требований, опираясь прежде всего на критерии из стандарта ISO/IEC/IEEE 29148: 2011 [ 5 ]. Основной причиной данного выбора является описание в стандарте различных качественных характеристик для набора требований и для отдельных требований. Стандарт также описывает использование требований на разных этапах проекта и описывает примерное содержание и структуру для технических требований. На основе стандарта и различных публикаций авторы данной статьи также разработали метод по оценке качества требований, заключающийся в поиске «запахов» требований, т.е. выделении языковых критериев, таких как:  Двусмысленные наречия и прилагательные,  Местоимения,  Субъективные термины,  Сравнительные фразы,  Относительная степень,  Отрицание,  Неявные, не поддающиеся проверке термины,  Лазейки,  Ссылки, по которым нельзя перейти Фактически, авторы также разработали инструмент, который только выискивает термины, влияющие на качество требований. Также, они указывают, что было проведено исследование вместе с экспертами, которые давали рекомендации по улучшению инструментария. Основным недостатком которого является отсутствие взаимодействия с контекстом. В сущности, инструмент выделял все слова, заложенные в словаре терминов для поиска, тогда как эксперты не всегда считали эти термины недостатками, учитывая контекст требований. Примером является условие, что требование должно быть положительным. Не всегда удается переформулировать требование таким образом, чтобы оно не содержало отрицаний, поэтому вопрос насколько оно влияет на качество остается открытым.

Авторы и эксперты подчеркивают, что этот инструментарий не дает возможности обойтись без экспертной комиссии полностью, однако, позволяет проверить на соответствие критериев стандарта ISO/IEC/IEEE 29148 быстрее, чем если бы это делал человек. Недостатком данного метода является также отсутствие оценки как таковой, эта тема не была полностью раскрыта. Актуальность работы заключается в проблеме требований плохого качества, но само качество не измеряется напрямую, просто выявляются дефекты, которые нужно убрать или скорректировать. Также не показывается четкая прослеживаемость влияния «запахов» на характеристики из стандарта, то есть неизвестно все ли характеристики требования оцениваются или нет. Однозначно можно сказать, что они точно учитывают языковые критерии из стандарта ISO/IEC/IEEE 29148.

Хеммер в своей статье от 2018 года [12] рассказывает об успехах в создании инструментария, который создавался, основываясь на разработках прошлых инструментов. Теперь это встроенное в Microsoft Word приложение, которое позволяет находить «запахи» в режиме реального времени. Отдельным достоинством этого нововведения является обучаемость специалистов, так как свои ошибки они видят сразу после написания требования. Также, безусловно, это сокращает время на обработку текста. В этом приложении «запахи» делятся на четыре категории:  Лексические запахи – дефект требования заключается в отдельных словах;  Грамматические запахи – дефект требования относится к грамматике текста;  Структурные запахи – дефект требования относится к структуре текста;  Семантические запахи - дефект требования относится к семантике текста; Прогресс ярко выражен, так как в предыдущей статье указывалось, что поиск заключался только в поиске слов, то в новом инструментарии дефекты выявляются четко и в структуре и грамматике требований. Хотя по словам автора, семантические запахи определять проблематично для автоматизированной системы. Также была выявлена проблема актуальности – для каждых новых клиентов необходимо настраивать инструмент индивидуально, то есть систему нужно разрабатывать таким образом, чтобы она адаптировалась к различным контекстам. Но явно не указывается, на чем основан выбор этих «запахов», что может поставить под сомнение насколько верны выбранные критерии. Основная проблема этой неизвестности заключается в том, что языковые критерии стандарта ISO/IEC/IEEE 29148 не обеспечивают наличие всех характеристик, присущих требованиям, согласно этому стандарту. По существу, все они так или иначе влияют, например, на однозначность, полноту и верифицируемость, но каким образом достигается прослеживаемость, единственность, необходимость и абстракция? Если эти оценка этих характеристик предоставляется экспертной комиссии, то явно это никак не отражено. 3.3 Сравнительный анализ методов оценок характеристик требований Описанные выше публикации являются примерами двух направлений развития методов оценки характеристик требований. Женова и его коллеги стараются идти по пути получения качества требований на основе характеристик, указанных в стандарте ISO/IEC/IEEE 29148, такие же методы наблюдаются в ряде работ, таких как [13], [14]. Феммер и его коллеги опираются в основном на языковые критерии, указанные в стандарте ISO/IEC/IEEE 29148, в последствии же пользуются литературными источниками, в которых авторы трудятся в области оценки качества требований. Эти работы можно объединить в категорию, в которой инструментарии нацелены на поиск дефектов или «запахов». Эти же методы наблюдаются и в работах [15], [16], [17], [18], [19]. Объединяет их также тот факт, что эти методы, даже если это не указано явно, оценивают только несколько характеристик требований. Объясняется это тем, что авторы стараются автоматизировать деятельность по оценке качества требований, а такие характеристики как «необходимость» весьма проблематично оценивать без экспертной комиссии, используя только поиск терминов, для чего часто применяют весьма эффективные методы NLP [20]. Дополнительно, такой подход облегчает саму оценку, так как отпадает необходимость подсчитывать меры, продумывать шкалу, ведь для того, чтобы улучшить требования в соответствии с данным методом, необходимо либо убрать ненужные термины, либо добавить. Это удобно, так как для получения значений диапазонов, в которых требования можно было бы оценить, как «Хорошо, средне, плохо», необходимо составить статистику. Например, признак «Размер» в статье [ 7 ] не имеет четкого диапазона, в котором было бы известно, какое количество слов/символов/параграфов оптимально, выведено только то, что для измерения стоит использовать выпуклую функцию. В методах таких работ как [12], [15], [16], [17], [18], [19], это не требуется.

Чтобы проверить, как полученные знания можно применить к требованиям, написанными на русском языке, автор работы постаралась разработать метод оценки характеристик требований для русскоязычных текстов. За основу был также выбран метод, основанный на поиске лексических индикаторов в тексте с требованиями. На базе полученных рекомендаций была составлена таблица 1, с помощью которых было бы возможно определить – обладает ли требование рядом вышеперечисленных характеристик. Для этого был взят стандарт ISO/IEC/IEEE 29148:2018 для получения перечня характеристик, затем, после анализа публикаций, книг и руководства INCOSE [ 6 ], были выведены лексические индикаторы и их влияние на оценку характеристик. Проанализировав получившуюся Таблицу 1, автором был сделан вывод, что ряд свойств можно определить с помощью программного обеспечения наиболее точно, а другие, например, «соразмерность» и «реализуемость» определяются хуже. Поэтому, используя опыт Феммера, для оценки были выбраны не все характеристики, а только однозначность, полнота, единственность и верифицируемость, ведь для них было выявлено наибольшее количество разновидностей лексических индикаторов. Полученный результат даёт возможность автоматизировать процесс оценки характеристик требований. Таблица 1 - Лексические индикаторы для оценки характеристик требований Соразмерность Однозначность Полнота Единственность Реализуемость Верифицируемость + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Категория лексических индикаторов Подчинительные союзы Личные и неопределённые местоимения Неточные термины Субъективные термины Проблемные части речи Пассивный залог Единицы измерений Устойчивые термины Инфинитив Размер текста Акронимы и сокращения Наречия степени Соединительные союзы Модальный глагол Пунктуация Наречие времени Частицы «не» и «ни» Также был составлен базовый словарь, на основе которого программное обеспечение могло бы искать словаиндикаторы, сигнализирующие о том, что формулировка требования подлежит коррекции или уточнения, или наоборот – свидетельствовать о том, что требование обладает нужными признаками. Также было определено, как влияют слова-индикаторы на качество требования, поскольку некоторые индикаторы недопустимы при формулировании требования, некоторые обязательно должны присутствовать.

Был разработан прототип программного обеспечения для оценки характеристик требований, представленный на Рисунке 1(а,б). На вход подаётся файл с требованиями в формате .xls, пользователь указывает координаты, в которых располагаются требованиями, затем программа ищет лексические индикаторы и, для наглядности, результат записывает в тот же файл с требованиями. В настоящий момент производится грубая оценка, так как при отсутствии необходимых лексических индикаторов или при наличии терминов, снижающих качество требования, требование считается негодным и рекомендуется к корректированию. Поэтому программное обеспечение можно считать прототипом, требующим доработки. Рисунок 1(б) – Словарь лексических индикаторов 4 Выводы Внедрение и развитие методов оценки характеристик требования позволяют улучшать качество требований, а значит, сокращать проектные риски, вызванные плохо сформулированными требованиями. В виду того, что к системам разной сложности могут предъявляться значительное количество требований, разработки автоматизированных систем оценка качества требований являются очень важными, так как проводить экспертные оценки вручную это трудоемкий процесс и недешевый. Инструментарии разработаны на основе методов, ориентированных на поиск различных показателей. Разные авторы используют наборы из лексических, морфологических, синтаксических и семантических показателей. В зависимости от вида метода, авторы опираются или на поиск дефектов, или на оценку качества требований. Второй вид даёт более полноценные рекомендации по улучшению требований, так как охватывает больше характеристик, нежели метод, построенный на поиске дефектов. Однако, не для каждой характеристики выявлены диапазоны оптимальных значений, даже для номинальной шкалы, состоящей из значений «Хорошо, средне, плохо».

На основе изученных источников, был предложен набор лексических индикаторов для оценки русскоязычных требований, а также представлен прототип программного обеспечения оценки характеристик требований для русскоязычных текстов. Список использованной литературы [8] Terry Bahill, Steven J. Henderson, «Requirements, Development, Verification, and Validation Exhibited in Famous

Failures,» Systems engineering, т. 8, № 1, pp. 1-14, 2005. [9] Р. Е.Н., Документная лингвистика: сборник учебно-методических, Томск: Томского политехнического университета, 2011. [10] Hasso H., et al, «Detection of Defective Requirements using Rule-based Scripts,» 2019. [11] H. Femmerm D. M. Fernández, M. Klose, I. Zimmer, J. Zimmer, «Rapid Requirements Checks with Requirements

Smells: Two Case Studies,» 2014. [12] F. H, « Requirements Quality Defect Detection with the Qualicen Requirements Scout,» REFSQ Workshops, 2018. [13] Kaiya H., Horai H., Saeki M, «AGORA: Attributed goal-oriented requirements analysis method,» Proceedings IEEE joint international conference on requirements engineering, pp. 13-22, 2002. [14] Kasser J. E., «The first requirements elucidator demonstration (FRED) tool,» Systems engineering, т. 7, № 3, pp.

243-256, 2004. [15] Rosadini B. et al, «Using NLP to detect requirements defects: An industrial experience in the railway domain,» International Working Conference on Requirements Engineering: Foundation for Software Quality, pp. 344-360, 2017. [16] Lucassen G. et al, « Improving agile requirements: the quality user story framework and tool,» Requirements

Engineering, т. 21, № 3, pp. 383-403, 2016. [17] Parra E. et al, «A methodology for the classification of quality of requirements using machine learning techniques,»

Information and Software Technology, т. 67, pp. 180-195, 2015. [18] Fabbrini, Fabrizio, et al, «The linguistic approach to the natural language requirements quality: benefit of the use of an automatic tool,» Proceedings 26th Annual NASA Goddard Software Engineering Workshop, pp. 97-105, 2001. [19] Kamalrudin M., Hosking J., Grundy J., «Improving requirements quality using essential use case interaction patterns,» /2011 33rd International Conference on Software Engineering (ICSE), pp. 531-540, 2011. [20] Falessi D., Cantone G., Canfora G, «A comprehensive characterization of NLP techniques for identifying equivalent requirements,» Proceedings of the 2010 ACM-IEEE international symposium on empirical software engineering and measurement., p. 18, 2010.

References

[2] Sourour Maalema , Nacereddine Zarour, «Challenge of validation in requirements, » Journal of Innovation in Digital Ecosystems, т. 3, № 1 , pp. 15 - 21 , 2016 .

[4] Unterkalmsteiner M. , Gorschek T. , « Requirements quality assurance in industry: why, what and how?,» International Working Conference on Requirements Engineering: Foundation for Software Quality . - Springer, pp. 77 - 84 , 2017 .

[5] ISO/IEC/IEEE 29148 « Системная и программная инженерия. Управление жизненным циклом . Инженерия требований».

[6] М. с. п. с. и. (INCOSE), « Руководство по написанию требований ,» 2017 .

[7] G. Genova , J. M. Fuentes , J. Llorens , O. Hurtado , V. Moreno, « A framework to measure and improve the quality of textual requirements ,» Springer-Verlag, 2011 .