Incose руководство по написанию требований

КНИГИ

Подписаться на новые статьи

REQUIREMENTS — INCOSE CMS

INCOSE SYSTEMS ENGINEERING HANDBOOK—VISUAL …

INCOSE GUIDE FOR WRITING REQUIREMENTS: REAL-TIME QUALITY

WebINCOSE, the International Council on Systems Engineering has done an excellent job in the dissemination of best practices and guides towards the Systems Engi…
From youtube.com

INCOSE GUIDE TO WRITING REQUIREMENTS UPDATES MADE AT IW 2015

WebJan 30, 2015 My time at International Council of Systems Engineering (INCOSE) International Workshop (IW) 2015 was well spent. The Requirement Working Group …
From argondigital.com

OVERTIME MEALS OR ALLOWANCES — CANADA.CA

WebIf you provide overtime meals, or an allowance for overtime meals, there is no taxable benefit if all of the following conditions apply: The allowance, or the cost of the meal, is …
From canada.ca

INCOSE GUIDE FOR WRITING REQUIREMENTS: REAL-TIME QUALITY …

WebINCOSE Guide for Writing Requirements: real-time quality assessment of the INCOSE rules A SMART set of quality rules for requirements INCOSE, the International Council …
From reusecompany.com

SE LIFE CYCLE MANAGEMENT, REQUIREMENTS QUALITY …

WebSE Life cycle Management, Requirements Quality Management
From reusecompany.com

INCOSE GUIDE FOR WRITING REQUIREMENTS IN A PRACTICAL WAY

WebA practical solution to an implementation towards quality assessment and requirements writing assistance. Description: Even though the INCOSE Guide for Writing Requirements (INCOSE GfWR – 3 rd edition of June 2019) is a broadly used and recognized reference for requirement engineers all over the world, the implementation of the INCOSE Guide for …
From reusecompany.com

AUTOMATING THE INCOSE GUIDE FOR WRITING REQUIREMENTS — QRA

WebThe INCOSE Guide for Writing Requirements is one of the most widely used and highly respected references in requirements engineering (RE). Systems engineers, …
From qracorp.com

REQUIREMENT (GLOSSARY) — SEBOK

WebOct 10, 2022 A requirement is “a statement that identifies a system, product or process characteristic or constraint, which is unambiguous, clear, unique, consistent, stand‐alone …
From sebokwiki.org

INCOSE GUIDE FOR WRITING REQUIREMENTS 2019

Web1.8 Guide Organization 2 Characteristics of Need and Requirement Statements 2.1 C1 — Necessary 2.2 C2 — Appropriate 2.3 C3 — Unambiguous 2.4 C4 — Complete 2.5 C5 — …
From dokumen.pub

DEFINITIONS — INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING

WebINCOSE Guide to Writing Requirements v3.1 – Summary Sheet INCOSE-TP-2010-006-03.1 | April 2022 Page 3 of 7 Requirements Working Group Rules for Need and …
From incose.org

QUESTIONS ON REQUIREMENTS DEVELOPMENT AND …

WebAug 10, 2021 INCOSE Requirements Working Group (Tami Katz, chair) –Guide being developed as part of RWG –Will be aligned with existing product, “Guide to Writing Requirements” –Lou Wheatcraft, Co-chair 2 Two guides and one manual are currently …
From incose.org

INCOSE GUIDE TO NEEDS AND REQUIREMENTS. — YOUTUBE

WebBrewve repaso a la nueva guía #INCOSE de #needs (#necesidades) y #requirements (#requisitos).Ponentes: José Fuentes y Luis Andés.Dentro de los diferentes equ…
From youtube.com

5 INCOSE GUIDELINES THAT EVERY REQUIREMENT ENGINEER SHOULD KNOW

WebApr 13, 2020 Below are 5 of the 44 INCOSE guidelines that every requirement engineer should know prior to starting their project. For more information on INCOSE best …
From requirements.com

SE HANDBOOK — INCOSE CMS

WebYou will be required to «purchase» the item. Once the order has been processed, you will receive a link via email to download the PDF. This link will also be available from your …
From incose.org

TECHNICAL PUBLICATIONS — INCOSE CMS

WebTechnical Publications Technical Publications include Handbooks and Guidebooks that provide formal INCOSE technical information relative to topics within Systems …
From incose.org

GUIDE FOR WRITING GOOD REQUIREMENTS — LINKEDIN

WebApr 7, 2020 The INCOSE Guide for Writing Requirements defines the characteristics for individual and set of requirements, rules and attributes that need to be fulfilled by any …
From linkedin.com

INCOSE REQUIREMENTS GUIDE KNOWLEDGE LIBRARY — REUSE COMPANY

WebThe International Council on Systems Engineering Requirements Working Group (INCOSE RGW) in line with the first INCOSE goal: “ Be a focal point for dissemination of systems …
From reusecompany.com

MEALS AND LODGING (INCLUDING SHOWERS) — CANADA.CA

WebMeals To calculate your meal expenses, you can use either the simplified or detailed method, or in certain situations, the batching method.. The most you can deduct for …
From canada.ca

THE GUIDE FOR WRITING REQUIREMENTS TUTORIAL WEBINAR — INCOSE.ORG

WebOct 1, 2014 SE Handbook Guide for Writing Requirements Leadership Skills for SEs Audio and video recordings of past sessions will be available for downloading. …
From incose.org

INCOSE GUIDE FOR WRITING REQUIREMENTS – 2017 UPDATE

WebJul 15, 2017 The main focus of this Guide is on how to express requirements clearly and precisely once they have been discovered, and in a form convenient for further analysis …
From argondigital.com

INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING WEBSITE

WebINCOSE’s Impact Leading the future of Systems Engineering. Discover how INCOSE is leading the transformation of the discipline through thought leadership and collaboration. …
From incose.org

Юрий Куприянов

Стоп-слова как маркер проблем в требованиях

10 возможностей для улучшения требований

Эта статья будет полезна начинающим аналитикам, которые хотят научиться лучше описывать требования, а также их руководителям, желающим качественно проверять выдаваемый подчиненными продукт. Впрочем, и опытные аналитики найдут для себя идеи для улучшения своих требований (даже тех, которые, казалось бы, в порядке).

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

Что производит аналитик в процессе работы

Системный аналитик разрабатывает требования к программному обеспечению, и эти требования представляют из себя текст. Существует много попыток фиксировать требования исключительно в виде диаграмм, но ни одна из них не стала на 100% успешной. Аналитик всегда производит именно тексты. Это могут быть длинные документы, карточки user story или подписи на диаграммах, но всё это тексты.

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

Схематично этот поток текстов может выглядеть так:

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

Обратите внимание, что на каждом из этих шагов происходит 2 процесса: валидация (мы сделали то, что нужно было) и верификация (мы сделали то, что было запрошено, зафиксировано в документах предыдущего этапа, и соответствует внутренним правилам и критериям качества).

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

Что мы знаем про написание текстов?

Написано довольно много книг о том, как работать с текстами: есть книги о том, как писать тексты в журналистике, тексты для SMM и SEO, есть книги для писателей, рекомендации по написанию научных работ. Но нет ни одной книги о том, как аналитикам писать требования — не выявлять, не управлять, а именно писать словами тексты на естественном языке, понятном всем согласующим людям.

Конечно, существует несколько стандартов, регламентирующих работу с требованиями. Но давайте посмотрим, насколько они информативны.

Например, российские стандарты регламентируют только оформление документов: шрифт, разделение на абзацы, межстрочные расстояния и т.п. Всё это описано в ГОСТ Р 7.0.97-2016, ГОСТ Р 2.105-2019. В комплексе ГОСТов 34-й серии был руководящий документ РД 50-34.698-90, ныне недействующий, но и он регламентировал только содержание документов, оставляя за рамками рассмотрение формулировок и языка, которым должно быть изложено это содержание.

Единственный стандарт, в котором есть некоторые рекомендации по текстам требований — это международный ISO 29148:2018, однако он не переведён на русский язык и не принят в РФ, а значит ссылаться на него нельзя.

У совета по системной инженерии INCOSE есть «Руководство по написанию требований» INCOSE-TP-2010-006-02.1. Руководство переведено на русский и включает в себя порядка 100 страниц, тогда как в международном ISO 29148:2018 о тексте и требованиях приведён довольно скромный список рекомендаций. Пожалуй, именно это Руководство является на текущий момент лучшим документом по текстам требований.

Ниже представлен полный перечень рекомендаций из ISO 29148:2018, переведённый на русский язык и его оригинальная версия.

Также в стандарте ISO 29148:2018 представлено два шаблона формулировки требований, на которые стоит обратить внимание.

Этих рекомендаций, как правило, на практике оказывается недостаточно, потому что в процессе работы люди совершают множество ошибок. Хорошая новость заключается в том, что можно научиться выявлять эти ошибки, отслеживая определённые слова.

Характеристики качества требований

Перед принятием проектных решений аналитики должны убедиться, что требования обладают достаточным качеством, иначе на более поздних этапах проекта неизбежно появятся ошибки реализации и проектирования. Характеристики качества требований в литературе и стандартах описаны, но как именно проводить анализ на соответствие этим критериям, обычно остаётся за скобками.

То есть всем известно, что требования должны быть атомарными, отслеживаемыми и так далее. Но как это верифицировать, мало кто знает.

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

Сейчас мы попробуем восполнить этот пробел и попробуем выявить проблемы в качестве требований с помощью слов-маркеров. Для начала мне хотелось бы напомнить вам характеристики одиночного требования.

Бывает так, что каждое требование в отдельности обладает всеми атрибутами качества, а вот весь набор требований не полон или противоречив. Поэтому выделяют ещё и критерии качества для набора требований.

Типовые проблемы в текстах требований

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

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

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

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

Рассмотрим пример (здесь и далее приведены примеры формулировки требований из реальных проектов).
Требования со страдательным залогом:

1. Идентификатор учётной записи социальной сети, при помощи которой пользователь впервые вошёл на Портал, присоединяется к профилю пользователя.

2. Актуальная программа курса должна быть размещена на Портале.

Как можно обратить внимание, эти требования не соответствуют характеристике «Завершённости». Требование 1 не полностью определено, ведь мы не знаем, как именно идентификатор присоединяется к профилю? Что это вообще значит? Кто это делает? В какой момент? Те же вопросы можно задать в отношении требования 2.

Как требования должны звучать (представим, что мы получили ответы на свои вопросы):

1. После входа на портал через учётную запись социальной сети, модуль авторизации должен сохранить идентификатор и email пользователя, полученный от социальной сети, в профиле пользователя.

2. При изменении (добавлении, удалении, переименовании) тем курса в LMS, LMS должна автоматически передавать изменения на Портал, для раздела «программа курса» в опубликованном описании курса, публикация полученных изменений происходит автоматически.

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

Бывает так, что в тексте требования вообще нет подлежащего, то есть из требования невозможно понять для кого или где оно должно быть реализовано.

Рассмотрим пример
Требование с безличным предложением:

Иметь возможность просмотреть все полученные сертификаты на одной странице.

Такое требование также не соответствует характеристике «Завершённость». В требовании недостаёт данных, отсутствие которых приведёт к неполноценности решения. Кто должен иметь возможность просмотреть? Также нарушается характеристика «Проверяемость», так как в требовании не указано, для каких ролей нужно проверять возможность.

Как требование должно звучать:

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

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

Отглагольные существительные

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

Рассмотрим пример
Требование с отглагольными существительными:

Система должна обеспечивать возможность хранения информации о местоположении вагонов.

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

Как требование должно звучать:

Система должна сохранять местоположение вагона.

И тут сразу возникает резонный вопрос — когда, в какой момент она должна сохранять местоположение? И как, всё-таки, описывается местоположение? Надеюсь, это понятие также описано в глоссарии.

Общее слово вместо конкретного

Ещё одна частая проблема в требованиях — общие слова. Дело в том, что общие слова не несут никакого конкретного смысла. Во избежание неопределённости необходимо совсем отказаться от общих слов или использовать их в ограниченном количестве, например, при описании высокоуровневых требований.

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

Существуют следующие уровни требований:

• Цели менеджмента (бизнес-требования)
• Цели стейкхолдеров (уровень операций)
• Требования к системе
• Требования к элементу системы

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

Чтобы проверить, является ли конкретное слово общим, можно подставить местоимение «какой-то» и посмотреть, что из этого получится. Если требование с местоимением благозвучно, то перед вами общее слово, если что-то не вяжется, то всё в порядке.

Рассмотрим пример
Предположим, что перед сдачей руководителю, мы решили перепроверить написанные ранее требования. Сейчас мы имеем требования:

1. Система должна обрабатывать информацию о заказах клиентов.

2. Администратору должен предоставляться отчет о действиях пользователя.

Как вы могли заметить, такие требования не соответствуют характеристике «Адекватность уровню». В требованиях отсутствует конкретика.

Чтобы проверить требования на общие слова добавляем местоимение «какой-то», получаем следующие требования:

1. Система должна обрабатывать информацию о каких-то заказах клиентов.

2. Администратору должен предоставляться отчёт о каких-то действиях пользователя.

Получившиеся требования звучат хорошо, всё как будто на своем месте, но как раз это и должно нас насторожить. Если требование с проверочным местоимением благозвучно, то мы имеем дело с общим словом, а его в требованиях быть не должно. Попробуем исправить первоначальные требования, конкретизировав их:

1. Система должна обрабатывать информацию о текущих заказах клиентов.

2. Администратору должен предоставляться отчёт об успешных входах пользователя в систему.

Мы добавили по одному уточняющему слову к каждому требованию. Теперь попробуем подставить местоимение «какой-то» для проверки:

1. Система должна обрабатывать информацию о каких-то текущих заказах клиентов.

2. Администратору должен предоставляться отчёт об каких-то успешных входах пользователя в систему.

Вы уже заметили? Местоимение здесь явно лишнее, а значит, перед нами качественное требование.

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

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

Указание способа реализации

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

Рассмотрим пример
Указание в требовании способа реализации:

1. Для отправки сообщения пользователь должен нажать на кнопку, расположенную в правом нижнем углу экрана.

2. Система должна формировать рекомендации курсов для пользователя с использованием средств машинного обучения.

В приведенных примерах требования не соответствуют атрибуту качества «Адекватность уровню», поскольку есть указание на способ реализации. А может быть, кнопка должна быть не в нижнем углу? Или это вовсе не кнопка, а, например, движение-свайп? И рекомендации формируются не средствами машинного обучения, а классическим алгоритмом?

“

Обратите внимание, что стоп-слова — это индикатор возможных проблем, они не для того, чтобы их сразу вычёркивать, они призывают остановиться и задуматься почему эти слова появилось в требованиях и что мы хотим с помощью них сказать.

Субъективный, относительный язык

Начнём с того, что всё субъективное не имеет чётких параметров объекта, процесса или явления, а значит использование субъективного языка в требованиях неминуемо приведёт к разночтению.

Рассмотрим пример
Требование с использованием субъективного языка:

Система радара должна отображать информацию для отслеживания актуальных воздушных судов.

Обращаем ваше внимание, что данное требование не соответствует характеристике «Недвусмысленность». Актуальные — это какие?

Как требование должно звучать:

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

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

Это происходит потому, что никто не любит лишней работы. Аналитик пишет требования «насколько это возможно» потому что он не знает, насколько на самом деле возможно. Он не провел работу, разъясняющую детали и передаёт требования дальше — пусть разработчик сам решает.

А разработчик тоже не хочет разбираться, ему реализовывать надо. Либо он отправит требование назад, либо (что проще) проигнорирует непонятный момент. Разумеется, это означает, что мы либо отложим реализацию, либо реализуем что-то на свой страх и риск, «заложим бомбу», которая рванёт на демонстрации заказчику или при эксплуатации системы.

Если требование действительно необходимо реализовать, то оно должно быть сформулировано соответствующим образом.

Рассмотрим пример
Снятие ответственности:

Интерфейс системы должен соответствовать рекомендациям WCAG 2.1 как минимум на уровне A, по возможности — на уровне AA.

В примере не учтена характеристика «Обязательность». Из требования не понятно, заинтересован ли стейкхолдер в реализации интерфейса системы на уровне АА или нет. Решение предлагается принять разработчикам, а они всегда выбирают то, что проще.

Несколько требований в одном

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

Рассмотрим пример
Несколько требований в одном:

Система управления задвижками должна закрывать входной клапан при температуре выше 80 градусов по Цельсию, когда температура падает, она должна вновь открывать его.

Как вы можете видеть, в этом требовании не соблюдена характеристика «Единичности», то есть требование описывает сразу две функции системы управления задвижками. Опасность здесь заключается в том, что каждое из требований может детализироваться и обрастать своими дополнительными требованиями, а иногда может быть выбрано для реализации в разных итерациях!

Как требования должны выглядеть:

1. Система управления задвижками должна закрывать входной клапан при температуре выше 80 градусов по Цельсию.

2. Система управления задвижками должна открывать входной клапан при температуре ниже 80 градусов по Цельсию.

Неоднозначная логика высказывания

Когда в требованиях перечисляется какое-то множество, из текста не всегда понятно, имеется ли в виду, что все элементы должны удовлетворять требованию или только один. Поэтому при употреблении логических элементов следует придерживаться правил:

• Избегайте частицы «не», двойного отрицания и знака «/»
• Однозначно выделяйте элементы множества и группировки
• При указании порядка используйте уточнения, не должно быть двусмысленности.

Рассмотрим пример
Неоднозначная логика высказывания:

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

2. Допускается отправка индивидуальных сообщений, рассылка на группу пользователей, рассылка всем пользователям проекта / площадки / платформы.

Требования выше противоречат характеристике «Недвусмысленность», поскольку содержат символы и нечеткие формулировки, которые можно интерпретировать по разному. Косая черта в данном случае — это «И» или «ИЛИ»? Отправка рассылки осуществляется по всем пользователям и проекта и площадки? Или быть может автор имел в виду, что рассылка осуществляется только пользователям проекта или только пользователям площадки? А как интерпретировать во времени одно И другое условие в первом требовании?

Как требование должно выглядеть:

1. Система управления двигателем должна отключать блок круиз-контроля, когда включена система курсовой устойчивости и, одновременно с этим, водитель нажимает педаль газа.
2. Допускается отправка индивидуальных сообщений; рассылка на группу пользователей; рассылка всем пользователям одного проекта; всем пользователям одной площадки (включая все проекты на указанной площадке); всем пользователям платформы (включая все площадки и проекты).

Неоднозначность указания времени

При указании времени в требованиях велик риск неопределённых формулировок. Даже если события в системе должны произойти практически одновременно, то корректнее будет указать, что событие Б должно произойти через 3 секунды после того, как произошло событие А.

Рассмотрим пример
Примеры неоднозначного времени:

1. Система должна оповещать пользователя об окончании времени выполнения теста заблаговременно.

2. Система должна перекрыть вентиль одновременно с получением сигнала датчика о переполнении резервуара.

Требования в примере выше не соответствуют характеристике «Недвусмысленность». Первое требование не отвечает нам на вопрос «насколько заблаговременно?». А второе не сообщает ни о каких ограничениях, которые могут привести к дальнейшим проблемам. Ведь перекрытие вентиля, после получения сигнала, не может произойти мгновенно, а значит нужно понимание сколько у нас есть времени до того, как содержимое резервуара начнёт выливаться через край.

Как требования должны выглядеть:

1. Система должна оповещать пользователя об окончании времени выполнения теста за 5 мин до истечения отведённого времени.

2. Система должна перекрыть вентиль за 5 секунд от момента получения сигнала датчика о переполнении резервуара.

Необязательная информация в требовании

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

Рассмотрим пример
Требование с лишним обоснованием:

Система должна позволять перемещаться между полями формы ввода сделки при помощи стрелок на клавиатуре,

т.к. трейдеру это сделать быстрее, чем двигать мышью

.

Требование с лишним дополнением:

В Системе должна быть реализована возможность при добавлении пользовательского контента выполнять проверку текста на соответствие заданному пополняемому словарю

(нецензурные, матерные слова, ключевые слова с точки зрения безопасности)

.

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

Пример общих верхнеуровневых требований к пользовательскому интерфейсу:

1.Требуется обеспечить возможность работы с пользовательским интерфейсом системы без использования указателей и прикосновений.

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

Содержимое же словаря должно быть вынесено в отдельное приложение, в тексте требования явно не удастся перечислить их все, да и не нужно.

Сам текст должен быть хорошо отформатирован, поскольку это упрощает восприятие требований. Нам хотелось бы обратить ваше внимание ещё на несколько рекомендаций:

• Структурированные тексты
• Отсутствие опечаток, пропущенных слов
• Правильная орфография (не путаем -тся и -ться!)
• Правильная пунктуация
• Используем термины и аббревиатуру из контролируемого глоссария
• Указываем единицы измерения величин и шкал
• Только полные перечисления (никаких «и т.д.», «и т.п.»)
• Не используем сокращения
• Не используем указательные местоимения: оно, это, то, он, она, они, им, его

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

Мы собрали краткую памятку по замене стоп-слов и сгруппировали его по видам требований. Вы можете использовать эту памятку при написании и проверке требований на качество.

Информация, данные, параметры, настройки, статистика — приводим конкретные данные и параметры (напр., «личная информация» -> «ФИО и реквизиты паспорта», «данные о продажах» -> «объём продаж за выбранный период в рублях» и т.п.)
Управление — означает, что с объектом производятся какие-то действия, раскрываем — какие. Обычно это CRUD: создание, просмотр, изменение, удаление.
Обработка — указываем конкретные действия, скорее всего это проверка условий, сохранение, преобразование и передача.
Проверка — указываем конкретный список условий, требующих проверки; ещё лучше — «система убеждается, что <условие 1 соблюдено> и <условие 2 соблюдено> и т.д.»
Согласование — указываем конкретные действия, которые осуществляют акторы.
Союзы, скобки и составные предложения — разделяем на несколько требований.
Элементы решения — задаем вопрос «Зачем?»
Субъективные высказывания — приводим к измеримым значениям.

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

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

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

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

Юрий Куприянов

Системный аналитик, архитектор программных систем, менеджер продукта

Рисунок 1. Процесс Управления решениями (INCOSE DAWG 2013)

Рисунок 3. Примеры оценочной функции (INCOSE DAWG 2013)

Рисунок 3. Примеры оценочной функции (INCOSE DAWG 2013).

Рисунок 4. Матрица колебания весов (INCOSE DAWG 2013)

Рисунок 5. Описание альтернатив (INCOSE DAWG 2013).

Рисунок 6. Измерение альтернатив (INCOSE DAWG 2013)

Рисунок 7. Значения показателей с цветовой карты (INCOSE DAWG 2013)

Рисунок 8. Диаграмма значений по компонентам (INCOSE DAWG 2013)

Рисунок 9. Пример диаграммы разброса ценностей стейкхолдеров (INCOSE DAWG 2013).

Рисунок 10. Неопределенность по функциональности на основе метода Монте-Карло (INCOSE DAWG 2013).