Не функциональные требования приложения пример
Разрабатывая новую информационную систему или внедряя уже существующую, вы неизбежно сталкиваетесь с необходимостью определить нефункциональные требования к вашей системе.
- какими бывают нефункциональные требования,
- как определять нефункциональные требования,
- откуда берутся численные значения для нефункциональных требований.
Нефункциональные требования: какие они бывают
Начнем с того, что требования к программным продуктам или информационным системам можно разделить на две большие группы. Это функциональные требования (описывающие, что необходимо реализовать в продукте или системе, в т.ч. какие действия должны выполнять пользователи при взаимодействии с ними) и нефункциональные требования (описывающие, как должна работать система или программный продукт, и какими свойствами или характеристиками она должна обладать).
Как правило, говоря о нефункциональных требованиях, чаще всего говорят об атрибутах качества (т.е. требованиях, определяющих качественные характеристики разрабатываемого программного обеспечения или системы, такие как производительность, надежность, масштабируемость), не обращая внимания на другие виды нефункциональных требований, а именно:
- Ограничения — условия, ограничивающие выбор возможных решений по реализации отдельных требований или их наборов. Они существенно ограничивают выбор средств, инструментов и стратегий при разработке внешнего вида и структуры (в т.ч. архитектуры) продукта или системы.
- Бизнес-правила — политика, руководящие принципы или положения, которые определяют или ограничивают некоторые аспекты бизнеса, в т.ч. правила, определяющие состав и правила выполнения определенных бизнес-процессов. К бизнес-правилам относятся корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы, которые используются при разработке продукта или системы либо непосредственно влияют на разработку.
- Внешние интерфейсы — описание аспектов взаимодействия с другими системами и операционной средой. К ним относятся требования к API продукта или системы, а также требования к API других систем, с которыми осуществляется интеграция.
- Предложения по реализации — предложения, оценивающие возможность использования определенных технологических и архитектурных решений.
- Предложения по тестированию разрабатываемого ПО — дополнения к требованиям, указывающие, каким образом то или иное требование должно быть протестировано.
- Юридические требования — требования к лицензированию, патентной чистоте, etc.
Все эти требования должны быть определены и зафиксированы, прежде чем вы приступите к реализации вашей системы или продукта.
Нефункциональные требования: как их определять
Теперь, когда мы познакомились с различными видами нефункциональными требований, неплохо понять, что нужно делать дальше.
- Книга Карла Вигерса "Разработка требований к программному обеспечению" — в разделе «Приложение Г» этой книги находятся примеры документации требований.
- Материалы ГОСТ 34 серии
Нефункциональные требования: работа над определением
Как для определения функциональных, так и для определения нефункциональных требований используются рабочие группы, члены которых определяют, проверяют и утверждают требования. Для групп по определению нефункциональных требований особенно важно привлечь к этой работе не только аналитиков и пользователей, но и архитекторов и ключевых разработчиков продукта или системы, а также группу тестирования. Архитектор воспринимает нефункциональные требования как входные данные для выбора и проектирования архитектуры приложения, а группа тестирования планирует те сценарии нагрузочного тестирования, которые будут использоваться для проверки выполнения нефункциональных требований (в основном это касается атрибутов качества).
Роли, которые при этом играют участники рабочей группы по определению нефункциональных требований, описаны далее.
- Пользователи — дают оценки значений параметров, которые используются для определения нефункциональных требований. Параметры, как правило, привязаны к сценариям — пользовательским сценариям, в которых должны выполняться определенные действия с определенными ограничениями за определенное время.
- Системный аналитик — собирает, анализирует и документирует и систематизирует нефункциональные требования.
- Системный архитектор, ключевые разработчики — участвуют в определении и анализе нефункциональных требований и проверяют их на реализуемость.
- Группа тестирования — участвует в определении и анализе нефункциональных требований и разрабатывает сценарии тестирования для проверки нефункциональных требований.
Пример сценария, используемого для определения требований к производительности модуля системы, рассылающего уведомления пользователям сайта по электронной почте:
Требования к времени оповещения о событии, инициирующем рассылку уведомлений: система должна получать оповещение не позднее чем через XX секунд после возникновения события.
Требования к времени отправки уведомлений: все уведомления должны быть отправлены не позднее YY минут после получения оповещения о событии
Требования к повторной отправке рассылки после неудачной попытки: число повторных попыток должно быть равным 10, с интервалом в 10 мин после каждой неудачной попытки отправки.
Какие вопросы при этом нужно задавать заказчику? В сущности, только один: через сколько времени после возникновения события все пользователи сайта должны гарантированно получить уведомление.
Критерии качественных нефункциональных требований
Как к функциональным, так и к нефункциональным требованиям применяются критерии качества требований — т.е. описание тех качеств, которым должны удовлетворять качественные требования.
- Полнота (отдельного требования и системы требований) — требование должно содержать всю необходимую информацию для его реализации. В него включается вся информация об описываемом параметре, известная на момент описания. Система требований также не должна содержать невыявленных и не определенных требований. Причины неполноты описания следует явно объявлять.
- Однозначность — требование должно быть внутренне непротиворечиво и все работающие с ним должны понимать его одинаково. Требования следует выражать просто, кратко и точно, используя известные термины. Обычно базовые знания читателей спецификации требований к ПО различаются. Поэтому в ее состав нужно включить раздел с определением понятий прикладной области, используемых при определении требований. Пример, неоднозначного требования. «Период обновления экрана должен быть не менее 20 сек.»
- Корректность отдельного требования и согласованность (непротиворечивость) системы требований — требование не должно содержать в себе неверной, неточной информации, а отдельные требования в системе требований не должны противоречить друг другу.
- Необходимость — требование должно отражать возможность или характеристику ПО, действительно необходимую пользователям, или вытекающую из других требований.
- Осуществимость — включаемое в спецификацию требование должно быть выполнимым при заданных ограничениях операционной среды. Осуществимость требований проверяется в процессе анализа осуществимости разработчиком. В частности, для нефункциональных требований проверяется возможность достижения указанных численных значений при существующих ограничениях.
- Проверяемость — проверяемость требования означает, что существует конечный и разумный по стоимости процесс ручной или машинной проверки того, что ПО удовлетворяет этому требованию. Каждое требование (особенно нефункциональное) должно содержать достаточно информации для однозначной проверки его реализации. Иначе, факт реализации будет основываться на мнении, а не на анализе, что приведет к проблемам при сдаче готового ПО. Для атрибутов качества (как мы помним, отдельной разновидности нефункциональных требований) критерием проверямости можно считать наличие численных значений характеристик качества продукта или системы
Качество нефункциональных требований непосредственно определяет качество разрабатываемого продукта или системы и достигается за счет итеративного процесса определения и анализа нефункциональных требований при слаженной работе всей группы, участвующей в их разработке.
Атрибуты качества
Этот раздел будет посвящен характеристикам качества продукта или системы.
Характеристики качества и модель качества ПО
Определение атрибутов качества тесно связано с выбранной для вашего продукта моделью качества. Разработкой модели качества занимается группа обеспечения качества (в которую входят тестировщики и которая ими, разумеется, не ограничивается).
В индустрии ПО есть несколько моделей качества, принятых в качестве стандарта. Эти модели были разработаны в 70-е-80-е годы прошлого века и продолжают совершенствоваться.
- ISO 9126
- ГОСТ 34
- Модель качества по МакКоллу (McCall’s Quality Model)
- Модель качества по Боэму (Boehm’s Quality Model)
- 1061-1998 IEEE Standard for Software Quality Metrics Methodology
- ISO 8402:1994 Quality management and quality assurance
Характеристики качества с точки зрения влияния на архитектуру системы
Все атрибуты качества с точки зрения архитектуры системы можно разделить на две большие группы: первая группа (runtime) – это атрибуты, относящиеся ко времени работы приложения или системы; вторая группа (design time) определяет ключевые аспекты проектирования приложения или системы. Многие из этих атрибутов взаимозависимы.
Рассмотрим более подробно каждую из этих групп.
Группа runtime
- Доступность — атрибут качества, определяющий время непрерывной работы приложения или системы. Чтобы определить этот параметр, обычно указывают максимально допустимое время простоя системы.
- Надежность — требование, описывающее поведение приложения или системы в нештатных ситуациях (примеры: автоматический перезапуск, восстановление работы, сохранение данных, дублирование важных данных, резервирование логики)
- Требования к времени хранения данных (например, использование БД в качестве постоянного хранилища данных, продолжительность хранения данных)
- Масштабируемость — требования к горизонтальному и/или вертикальному масштабированию приложения или системы. Говоря о вертикальной масштабируемости, мы определяем требования к вертикальной архитектуре системы или приложения. К требованиям вертикальной масштабируемости могут относиться, например, возможность переноса приложений на более мощные SMP-системы, поддержка большого объема памяти и файлов. Говоря о горизонтальной масштабируемости, мы определяем требования к горизонтальной архитектуре системы или приложения. К требованиям горизонтальной масштабируемости могут относиться, например, возможность использования технологий кластеризации. Следует особо заметить, что вертикальное масштабирование обычно направлено на повышение производительности системы. Горизонтальное масштабирование, помимо производительности, позволяет повысить отказоустойчивость системы. Более подробно о вертикальном и горизонтальном масштабировании можно прочитать, например, здесь.
- Требования к удобству использования системы/приложения (с точки зрения пользователя) и требования к удобству и простоте поддержки (Usability)
- Требования к безопасности, как правило, включают в себя три большие категории: требования, связанные с разграничением доступа, требования, связанные с работой с приватными данным, и требования, направленные на снижение рисков от внешних атак.
- Требования к конфигурируемости приложения, взаимодействия и расположения компонентов можно условно разделить на четыре уровня:
1. конфигурируемость на основе предопределенного набора параметров (predefined configurability), когда необходимый уровень модификации достигается путем изменения значений параметров из предопределенного набора;
2. конфигурируемость на основе предопределенного набора базовых объектов (framework constrained configurability), когда необходимый уровень модификации достигается путем перекомпоновки предопределенного набора процессов, сущностей и служебных процедур;
3. конфигурируемость путем реализации новых базовых объектов (basis reimplementation), когда обеспечивается расширение набора процессов и сущностей;
4. конфигурируемость путем новой реализации системы (system reimplementation), когда система должна устанавливаться и настраиваться с нуля. - Требования к производительности решения, определяемые в терминах количества одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, а также скорости и пропускной способности каналов связи
- Ограничения, накладываемые на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи
Группа design time
- Требования к повторному использованию реализации или компонентов приложения или системы (Reusability). О том, как это выражается в конкретной реализации, будет рассказываться далее. Пока ограничимся лишь тем, что чаще всего эти требования будут возникать там, где общие компоненты используются несколькими модулями разрабатываемой вами системы.
- Требования к расширяемости (Extensibility) приложения или системы в связи с появлением новых функциональных требований, тесно связанное с таким архитектурным атрибутом качества, как переносимость кода. Как правило, на начальном этапе сбора требований можно ограничиться указанием тех функциональных областей, которые в дальнейшем должны удовлетворять требованию расширяемости.
- Требования к переносимости (Portability) приложения или системы на другие платформы.
- Требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия (Interoperability). Например, к таким требованиям можно отнести возможность использования нескольких стандартных протоколов для обмена данными между одной из подсистем разрабатываемой системы и внешней системой-поставщиком данных (на примере ArcGIS)
- Требования к поддержке системы или приложения (Supportability). Среди этих параметров могут быть названы такие как, напрмер, дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе
- Требования к модульности приложения или системы (Modularity). Обычно такие требования указывают, каким образом система должна быть разделена на модули, или перечисляют список обязательных модулей, которые должны входить в состав системы.
- Требования к возможности тестирования (Testability) приложения или системы определяют объем требований к автоматическому и ручному тестированию, наличие необходимого инструментария
- Требования к возможности и простоте локализации (Localizability) приложения или системы определяют возможности и специфические архитектурные требования, накладываемые процессом локализации. Эти требования содержат также перечень языков, на которые предполагается выполнять локализацию приложения или системы
О том, как, где, когда и откуда нужно взять конкретные значения для всех этих параметров, я расскажу в продолжении этой статьи.
При разработке какой-либо новой информационной системы (либо при внедрении существующей) специалисты обязательно столкнутся в своей работе с необходимостью определения данного рода требований. Есть смысл подробно их рассмотреть. Что такое нефункциональные требования, какими они бывают, как их определяют профессионалы.
Две категории требований
Предписаний по характеристикам, качеству программных продуктов, информационных систем большое множество. Однако их можно разделить всего на две большие категории - это функциональные и нефункциональные требования. Важно в начале статьи обозначить между ними разницу.
- Функциональные требования. Описывают, что конкретно нужно реализовать в той или иной системе или продукте, какие действия должны производить пользователи в отношении данной разработки.
- Нефункциональные требования. Описывают, как именно работает создаваемая система или программный продукт, какими свойствами и характеристиками обладает конкретная разработка.
Пункт 1. Понятие о функциональных и нефункциональных требованиях мы сформировали. Переходим теперь ко второму пункту - рассмотрим, что конкретно возможно отнести к последним.
Что относится к категории?
По сути, к нефункциональным требованиям прежде всего причисляют различные атрибуты качества продукта. А именно - требования, определяющие качественные характеристики разработки (программного обеспечения, информационной системы). Это, конечно, надежность, масштабируемость, производительность продукта.
Однако большое значение имеют и такие нефункциональные требования:
- Ограничения. То есть условия, ограничивающие выбор каких-либо решений по воплощению в жизнь отдельных требований (или наборов требований). Они сужают разнообразие выбора инструментов, стратегий, средств при разработке как структуры (архитектуры), так и внешнего вида информационного либо программного продукта.
- Бизнес-правила. Сюда относятся руководящие правила, политика, принципы, положения, как-то ограничивающие определенные аспекты бизнеса. Например, они могут определять состав и правила выполнения каких-либо бизнес-проектов. Что можно отнести в данную категорию? Корпоративную политику, всевозможные правительственные постановления и указы, промышленные стандарты, вычислительные алгоритмы. Все правила, что как-то влияют на разработку системы, продукта, используются во время работы над проектом.
- Предложения по реализации. В группу входят конкретные предложения, оценивающие возможность применения определенных архитектурных и технологических решений.
- Внешние интерфейсы. Описание ключевых аспектов взаимодействия продукта с иными системами и операционной средой. Прежде всего, это требования к API системы или продукта, а также требования к API иных систем, с которыми планируется интеграция разрабатываемого продукта.
- Предложения по проверке, тестированию разрабатываемого программного обеспечения. Это ряд дополнений к требованиям, указывающий, как то или иное требование должно быть протестировано на практике.
- Юридические требования. К лицензированию продукта, наличию патента и проч.
Важно отметить, что нефункциональные требования к системе предварительно определяются и фиксируются. Только после этого специалист может приступить к разработке продукта.
Примеры требований
Чтобы иметь более ясное представление о нефункциональных требованиях к информационной системе, разберем ряд примеров:
Как определять данные требования?
Мы разобрали конкретные примеры нефункциональных требований. А теперь другой важный вопрос: : "Как их определять в отношении конкретного продукта?"
Первым делом специалисты составляют шаблон, в котором перечисляются главные типы нефункциональных требований к продукту. Прежде всего он нужен для того, чтобы не упустить какую-либо позицию из этого списка.
Источниками для составления подобных шаблонов разработчики обычно выбирают следующее:
- ГОСТ (государственный стандарт РФ) 34-й серии.
- Книга "Разработка требований к программному обеспечению" (автор - К. Вигерс). В частности, нужно обратить внимание на раздел "Приложение Г". В нем содержатся конкретные примеры документации с требованиями.
Давайте рассмотрим теперь, кто конкретно занимается этой работой.
Деятельность по определению требований к продукту
Разработкой функциональных и нефункциональных требований к системе занимаются специальные рабочие группы. Их члены не только определяют, но и проверяют, утверждают данные предписания.
А что касается нефункциональной категории, то для ее определения важно привлечь к работе не только пользователей и аналитиков, но и ключевых разработчиков продукта, архитекторов системы, а также группу тестировщиков. Чем это важно? Архитектор, скажем, будет воспринимать нефункциональные требования в качестве входных данных для выбора и проектирования архитектуры программы. А группа тестирования будет по ним планировать подходящие сценарии нагрузочного тестирования. Именно с помощью последних будет проверяться выполнение нефункциональных требований. По большему счету, это касается атрибутов качества.
Роли участников рабочей группы
Давайте теперь рассмотрим, какие роли распределяются между членами группы специалистов, определяющих и утверждающих нефункциональные требования к продукту:
- Пользователи. Эти участники дают оценку значениям тех параметров, которые и определяют нефункциональные требования.
- Системный аналитик. Данный участник собирает, анализирует, систематизирует и документирует нефункциональные требования.
- Ключевые разработчики и системный архитектор. Какую роль выполняет эта группа? Участвуют как в определении, анализе нефункциональных требований, так и проверяют их на степень воплощения в жизнь.
- Группа тестирования. Также участвует в определении, анализе перечня нефункциональных требований к программе. Дополнительно разрабатывает сценарии тестирования для данных предписаний.
Сценарий для определения требований
Тут мы приведем конкретный пример сценария, применяемого для определения нефункциональных требований к производительности модуля, призванного рассылать уведомления пользователям интернет-ресурса по электронной почте:
Формирование требований к продукту по сценарию
А теперь составим требования к сформированному в предыдущем подзаголовке сценарию:
Важные критерии требований
Сами нефункциональные требования должны строго соответствовать целому ряду качественных критериев к их содержанию:
- Полнота (как отдельного требования, так и полного их перечня). Что это значит? Требование должно содержать в себе всю необходимую информацию для его воплощения в жизнь.
- Однозначность. Требование не должно противоречить ни себе самому, ни другим пунктам из списка. Все работающие с ним специалисты должны понимать его одинаково.
- Корректность отдельного требования, обеспечивающая системную непротиворечивость.
- Необходимость. Реализация данного требования действительно нужна пользователям.
- Осуществимость. Воплотить это требование в жизнь реально.
- Проверяемость. Должно обеспечивать однозначную проверку его реализации.
Мы с вами познакомились с таким понятием, как нефункциональные требования к программному продукту, информационной системе. Также разобрали их конкретные примеры, отличие от функциональной категории, критерии качества категории. Вы знаете, какие группы специалистов каким образом создают и утверждают данные предписания.
Это условия, при которых продукт должен работать, и качества, которыми он должен обладать (например, производительность, надежность, масштабируемость).
Что относят к нефункциональным требованиям?
Технические ограничения, бизнес–требования, локализация, доступность, производительность и масштабируемость, надежность, доступность, безопасность, удобство использвания.
Какими должны быть нефункциональные требования?
Они должны быть измеримы. Их можно проверить и протестировать.
Нефункциональные требования
Представьте, что вы покупаете мотоцикл. Какие характеристики вам важны? Чтобы он мог ехать со скоростью 150 км в час и не развалиться на части? Или для вас важно, можно ли прикрепить к нему мотоколяску или прицеп? Наконец, он должен быть безопасным? Все эти требования не описывают напрямую основную функцию мотоцикла — доставку человека из пункта А в пункт Б. Это нефункциональные требования, но для водителей они тоже имеют значение.
К сайтам, ПО, приложениям люди тоже предъявляют нефункциональные требования. Это качества, которые удовлетворяют пользователей.
Что такое нефункциональные требования
Нефункциональные требования — это условия, при которых продукт должен работать, и качества, которыми он должен обладать (например, производительность, надежность, масштабируемость).
Если совсем просто, то к нефункциональным относят те требования, которые не вошли в функциональные.
Какие бывают нефункциональные требования
Нефункциональные требования описывают эксплуатационные качества к продукту. Например, ваш продукт собирает какие–либо данные пользователей и работает на территории ЕС. Значит, он должен по закону соответствовать правилам GDPR — Общий регламент по защите данных.
Технические ограничения. Операционные системы и их версии, сетевые особенности, браузеры и их версии, устройства и другие аппаратные требования. Например, разработка должна вестись на определенной платформе, пользователь входит по отпечаткам пальцев.
Бизнес–требования. Процессы и стандарты, принятые в компании. Продукт должен им следовать и разрабатываться в соответствии с ними.
Производительность и масштабируемость. Насколько быстро продукт реагирует на определенные действия пользователей при определенной рабочей нагрузке. Например, сколько пользователь должен ждать, чтобы прошла регистрация в личном кабинете, был обработан платеж с банковской карты. Требования к производительности могут описывать фоновые процессы, которые пользователь не видит. Например, резервное копирование. Масштабируемость оценивает самые высокие рабочие нагрузки, при которых система все еще будет справляться.
Надежность, доступность, ремонтопригодность. Как часто в системе происходят критические сбои. Как быстро их можно устранить. Пример требований к доступности: сайт должен быть доступна для пользователей из США 98% времени каждый месяц в рабочие часы.
Безопасность. Как система и ее данные защищены от атак или несанкционированного доступа. Но здесь есть одна загвоздка. Львиная доля нефункциональных требований безопасности может быть переведена в конкретные функциональные требования.
Локализация. Соответствие системы особенностям страны, в которой ее будут использовать: местные языки, законы, валюты, культура, орфография и так далее. Чем больше продукт вписывается в контекст, тем больший успех он должен иметь у местной целевой аудитории. Чтобы документально подтвердить это требование, вы должны опираться на предварительное исследование рынка. Пример требования к локализации: формат даты должен быть следующим: месяц.число.год.
Удобство использования. Удобно ли людям пользоваться продуктом. Nielsen Norman Group, предлагают оценивать юзабилити по пяти параметрам:
- Обучаемость. Насколько быстро пользователи могут выполнить целевые действия, как только увидят интерфейс?
- Эффективность. Как быстро пользователи могут достичь своих целей в продукте?
- Запоминаемость. Могут ли пользователи вернуться к интерфейсу через некоторое время и сразу же начать работать с ним?
- Ошибки. Как часто пользователи допускают ошибки при использовании продукта?
- Удовлетворенность. Приятен ли дизайн в использовании?
Как скорость загрузки влияет на отказы пользователей. Чем дольше загружается, тем чаще люди закрывают продукт
Следите за нашими новостями на Facebook! Всегда что-нибудь интересное ;) Анализ требований
к программному обеспечению
с примерами Требование к программному обеспечению – это функциональная или нефункциональная потребность, которая должна быть реализована в системе. Функциональная потребность подразумевает предоставление пользователю определенной услуги.
Например, в контексте банковского приложения функциональное требование будет заключаться в том, что когда клиент выбирает функцию «Просмотр баланса», он должен иметь возможность просматривать последний баланс своего счета.
Требование к программному обеспечению также может быть нефункциональным, это может быть требование к производительности. Например, нефункциональное требование заключается в том, что каждая страница системы должна быть видна пользователям в течение 5 секунд.
Итак, в основном требования к программному обеспечению – это
- Функциональные или
- Нефункциональный
- Типы требований
- Другие источники требований
- Как анализировать требования
- Атомный
- Однозначно идентифицировано
- Полный
- Последовательный и однозначный
- Прослеживаемый
- Приоритет
- Проверяемый
- Заключение
Бизнес-требования : это требования высокого уровня, взятые из бизнес-целей проекта. Например, система мобильного банкинга предоставляет банковские услуги. Бизнес-требование, которое решено, это – сводка счета и оплата счета решаются как бизнес-требование (конечная цель, чтобы пользователь совершил транзакцию).
Требования к архитектуре и дизайну : эти требования более подробны, чем бизнес-требования. Он определяет общий дизайн, необходимый для реализации бизнес-требований. Для образовательной организации сценариями использования архитектуры и дизайна будет вход в систему, детали курса и т. д. Требования будут такими, как показано ниже.
Иногда на проекте вы можете не получить никаких требований или документов для работы. Но все же есть и другие источники требований, на которых вы можете основывать свое программное обеспечение. Другими источниками требований, на которые вы можете положиться, являются.
Другие источники требований
- разговор о проекте с бизнес-аналитиком, менеджером по продукту, руководителем проекта и разработчиками уже работающими над этим проектом;
- анализ предыдущей версии системы, которая уже внедрена в систему;
- анализ старых документов требований проекта;
- просмотр предыдущих отчетов об ошибках, некоторые из отчетов об ошибках превращаются в запрос на улучшение, который может быть реализован в текущей версии;
- изучите руководство по установке, если оно доступно, чтобы узнать, какие установки требуются;
- проанализируйте знания в предметной области или отрасли, которые команда пытается внедрить.
Давайте изучим, как анализировать требования. Требования проявляются на разных уровнях:
- Атомный
- Однозначно идентифицированный
- Полный
- Последовательный и недвусмысленный
- Прослеживаемый
- Приоритет
- Проверяемый
- В первом столбце указан – «тип требования».
- Во втором столбце указано – «некачественно сформулированное требование».
- В третьем столбец указано – «требование из второго столбца в удобоваримом варианте».
Вывод : чем конкретнее требование, тем лучше.
Теперь давайте подробно разберемся с каждым из этих требований, начиная с уровня Atomic.
Атомный
Таким образом, каждое ваше требование должно быть атомарным, а это значит, что оно должно быть на очень низком уровне детализации, чтобы его нельзя было разделить на компоненты. Здесь мы увидим два примера требований: атомарный и однозначно идентифицированный уровень требований.
Итак, продолжим с примером построения системы для сферы образования. Здесь плохое требование: «Студенты смогут поступить на курсы бакалавриата и магистратуры». Это плохое требование, потому что оно не атомарно, потому что в нем говорится о двух разных сущностях: бакалавриате и аспирантуре. Таким образом, очевидно, что это плохое требование, поэтому хорошим требованием соответствия было бы разделение его на два требования. Итак, один говорит о зачислении на курсы бакалавриата, а другой говорит о зачислении в аспирантуру.
Последовательный и однозначный
Далее, каждое требование должно быть последовательным и недвусмысленным, поэтому здесь, например, у нас есть требования: «У студента будут либо курсы бакалавриата, либо курсы последипломного образования, но не оба сразу». Это одно требование, но есть еще одно требование, которое гласит: «Некоторые курсы будут быть открытыми как для студентов, так и для аспирантов».
Проблема в этом требовании заключается в том, что из первого требования кажется, что курсы разделены на две категории: курсы для аспирантов и курсы для аспирантов, и студент может выбрать любой из двух, но не оба. Но когда вы читаете другое требование, оно противоречит первому и говорит о том, что некоторые курсы открыты как для аспирантов, так и для студентов.
Таким образом, очевидно, что это плохое требование можно преобразовать в хорошее таким образом: «У студента будет либо курс бакалавриата, либо курсы последипломного образования, но не то и другое одновременно». Это означает, что каждый курс будет отмечен как курс бакалавриата или курс аспирантуры.
Прослеживаемый
Каждое требование должно быть отслеживаемым, потому что существуют разные уровни требований. Мы уже видели, что наверху у нас есть бизнес-требования, а затем у нас есть требования к архитектуре и дизайну, за которыми следуют требования системной интеграции.
Теперь, когда мы преобразуем бизнес-требования в требования к архитектуре и дизайну или преобразуем требования к архитектуре и дизайну в требования системной интеграции, необходима прослеживаемость. Это означает, что мы должны быть в состоянии взять все бизнес-требования и сопоставить их с одним или несколькими требованиями к архитектуре и дизайну программного обеспечения. Итак, вот пример неверного требования, в котором говорится: «Сохранять информацию о студенте - сопоставлена с идентификатором требования BRD?». Пример идентификатора требования здесь не приводится.
Таким образом, преобразовав его в хорошее требование, оно говорит то же самое, но отображает идентификатор требования 4.1. Так что отображение должно быть для каждого требования. Точно так же, как у нас есть требования к высокоуровневому и низкоуровневому сопоставлению, сопоставление также существует между требованиями системы и интеграцией с кодом, который реализует это требование, а также существует сопоставление между системой и требованиями интеграции с тестовым примером, который проверяет это конкретное требование .
Читайте также: