1-software_engineering_requirements (1133541), страница 7
Текст из файла (страница 7)
Стандарт IEEE 830 является классическимпримером стандарта на содержание структурирование и методы описания программных требований– “Recommended Practice for Software Requirements Specifications”.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru15Основы программной инженерии (по SWEBOK)Программная инженерия.
Программные требования.По мнению авторов, в документацию на требования не следует вносить элементы дизайна системы(скажем, логическую модель базы данных). А вот сценарии использования Use Case часто включаютв спецификацию требований наравне с трассировкой (traces) к соответствующим моделям в формедиаграмм, например, к UML Use Case, UML Activity, BPMN и т.п. . Говоря о написании спецификацийтребований, то есть одно серьезное заблуждение, которое делают обычно неопытные аналитики –это фактическая подмена требований как таковых, моделями графического пользовательскогоинтерфейса, т.е. когда в документы-спецификации требований просто включаются «картинки»пользовательского интерфейса с небольшими пояснениям. Это отнюдь не означает, что сзаинтересованными лицами и в частности с пользователями, не следует вообще обсуждать дизайнGUI, часто это имеет смысл делать, но для этого существует, например, прототипирование.
Мнедовелось изучить многие документы требований в разных организациях и практически все они имелиодни и те же проблемы:1.Терминологическая неопределенность. Часто используются термины, которые обладаютмногозначностью, и такие термины не определены в глоссариях, чтобы можно было четкопонять, что конкретно автор имеет в виду в данном случае (это не всегда бывает понятно изконтекста). Как пример можно привести собственно использование (и, что немаловажно,понимания!) термина «требования». Под этим ѐмким термином можно понимать как требования кбизнес процессам, так и функциональные или нефункциональные требования к ПО вообще.Интересно, что на уровне многих стандартов (к сожалению, в основном, англоязычных)прописано использование тех или иных глаголов, форм и структурирование предложений,описывающих требования – например использование глаголов (will, shall, should, may, can –перечислены в порядке “убывания директивности”).
Действительно, “программный модуль Xотсылает уведомление на e-mail адрес пользователя...” несет, мягко говоря, иную смысловуюнагрузку, чем “отсылается сообщение”.2.Отсутствие представления о классификации требований. Подмена одних категорийтребований – другими и смешение требований (например, такое часто случается сфункциональными требованиями, бизнес-требованиями и бизнес-правилами). Как результат –создаваемые документы тяжело читать и извлекать полезную для разработки ПО информацию.Зачастую в одном абзаце, можно встретить перемешанные как описания необходимойфункциональности и тут же элементы предполагаемого пользовательского интерфейса, которыйдолжен воплотить разработчик.
Или проектные решения, например, использование таблиц базданных или полей. И помимо этого, содержится несистематизированная и фрагментарнаяинформация о бизнес-процессах организации. Все это скрывает истинные требования кразрабатываемому ПО, что в свою очередь затрудняет как разработку, так и согласованиетребований. Корректная и однозначная интерпретация требований и анализ влияний становятсяпрактически неосуществимыми, что напрямую сказывается на адекватности удовлетворенияпотребностей заказчика/пользователей.3.Фокусировка на деталях пользовательского интерфейса.
В документах встречаетсяакцентирование не на необходимой функциональности, а на деталях пользовательскогоинтерфейса.4.Излишнее акцентирование внимания на деталях реализации. Попытка отразить в документе стребованиями к создаваемому ПО не ЧТО должна делать система, а то КАК она это будетделать. Это одна из ключевых проблем. Во многом, поэтому, часто выделяют внутренниетехнические требования к системе, которые не проходят аттестации со стороны пользователей иразрабатываются не аналитиками, а архитектором и ведущими разработчиками уже на этапепроектирования – software design (см.
следующую область знаний SWEBOK).5.Слабая формализация бизнес-процессов. В документах перемешивается описание бизнеса итребования к ПО, что приводит сложностям в понимании сути и общему пониманию как должнабыть спроектирована система.6. Проверка требований (Requirements Validation)Определение требований напрямую связано с процедурами проверки (verification) и утверждения(аттестации - validation, как это сформулировано в ГОСТ Р и ISO/IEC 12207). Вообще говоря, принятоCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru16Основы программной инженерии (по SWEBOK)Программная инженерия. Программные требования.считать, что требования описаны не полностью, если для них не заданы правила V&V(verification&validation – проверка и аттестация), то есть не определены способы проверки иутверждения.
Процедуры проверки являются отправной точкой для инженеров-тестировщиков испециалистов по качеству, непосредственно отвечающих за соответствие получаемогопрограммного продукта предъявляемым к нему требованиям.К сожалению, как уже комментировалось выше, часто, в крупных организациях вместо полноценнойпроверки сути и содержания документов, все сводиться к так называемому "нормоконтролю" -- когдапроверка документов требований заключается в проверке на соблюдение принятых стандартоввнешнего оформления документа (отступы и размеры поля, подписи таблиц/рисунков и т.п.), ноникак ни оценки качества требований.
И совершенно неверно считать такой "нормоконтроль"полноценной проверкой требований.Если стандарты жизненного цикла описывают как правильно создавать продукт, то стандарты (в томчисле, внутрикорпоративные) отвечают за создание правильного продукта, то есть того продукта,который соответствует ожиданиям пользователей и других заинтересованных лиц.Для достижения этой цели применяется ряд практик, в том числе, представленных ниже.6.1 Обзор требований (Requirements Review)Один из распространенных методов проверки требований - инспекция или обзор требований.
Сутьего заключается в том, что ряд лиц, вовлеченных в проект (для крупных проектов – специальновыделенные специалисты), “вычитывают” требования в поисках необоснованных предположений,описаний требований, допускающих множественные интерпретации, противоречий,несогласованности, недостаточной степени детализации, отклонений от принятых стандартов и т.п.Вопросы обзора требований, вообще говоря, имеют непосредственное отношение к теме качества,поэтому они также описываются в области знаний SWEBOK “Качество программного обеспечения”(Software Quality) в теме 2.3 “Обзор и аудит” (Review and Audit).6.2 Прототипирование (Prototyping)В общем случае, прототипирование подразумевает проверку инженерной интерпретациипрограммных требований и извлечение новых требований, неопределенных или неясных на раннихитерациях сбора требований.
Существует множество подходов к прототипированию, как с точкизрения детализации, так и того, чему уделяется внимание при прототипировании. Наиболее частопрототипы создаются для оценки способа реализации пользовательского интерфейса и проверкиархитектурных подходов и решений.При всей безусловной полезности прототипирования для обеспечения проверки требований ирешений, необходимо понимать, что с прототипированием связан ряд вопросов способных привестик негативным последствиям или, как минимум, работам, требующим дополнительного времени исредств.
Среди возможных негативных последствий прототипирования стоит выделить следующие: Смещение внимания с целевых функций прототипа и, как следствие, неудовлетворенностьпользователей огрехами прототипа, отсутствием стоящей за ним реальнойфункциональности (для прототипов пользовательского интерфейса), ошибками в прототипе ит.п. Превращение прототипа в реальную систему за счет постоянного добавления новых свойстви функциональности “для проверки” – часто бывает нарушена архитектурная целостность,необеспечена необходимая масштабируемость и качество получаемого программногопродукта;Здесь, авторы хотели бы добавить и еще одну типичную проблему - переключение вниманиязаинтересованных лиц на эргономику и детали дизайна графического пользовательскогоинтерфейса, при начальной цели построения прототипа для выявления функциональных и иныхтребований и наоборот.
Проблема не во внимании пользовательскому интерфейсу, проблема вподмене, если так можно выразиться, функциональной составляющей пользовательскиминтерфейсом (вспомните, как часто вы сами говорили или слышали – “я не о „кнопочках‟ и „окошках‟,я о задаче ...”).Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru17Основы программной инженерии (по SWEBOK)Программная инженерия. Программные требования.Конечно, ясно, что эти факторы можно превратить и в положительные стороны прототипа. Крометого, не стоит считать что прототип это всегда нечто, воплощенное в код. Прототипомпользовательского интерфейса может быть, например, просто “прорисованный” на бумаге или вэлектронной форме набор переходов между экранами/диалоговыми окнами системы (кстати, этоподход, часто используемый в Agile-практиках, но отнюдь не заменяющий требований к системе).Так или иначе, выбор того или иного метода прототипирования, да и самого факта такого способапроверки требований или технологических идей, должен основываться на временных и другихимеющихся ресурсах, опыте в прототипировании и, конечно, степени сложности создаваемойпрограммной системы.6.3 Утверждение модели (Model Validation)Утверждение или аттестация модели связана с вопросами обеспечения приемлемого качествапродукта.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
