Поговорим о великом труде Карла Вигерса и Джой Битти — “Software Requirements, Third Edition” (”Разработка требований к программному обеспечению”). На схожую тему уже было выступление Дениса Бескова (тут), но там был авторский взгляд на типы требований и то, какую альтернативную методику Денис с коллегами предлагают. Был также полушуточный пост о том, как концепции мистера Карла (не)применимы на практике: https://t.me/systemswing/496.
Я бы хотел в ином ключе подойти: я искренне люблю эту книгу, ее теоретическую базу и очень уважаю авторов — считаю, что это все еще обязательная к изучению библия для IT-аналитиков, которые работают с требованиями к ПО. Однако за годы изучения у меня скопился ряд вопросов. В основном — по типологии требований и артефактам. Причем вопросов, что логично, было в разы больше ко второй версии книги, а потому вполне себе вероятно, что ряд моментов маэстро пофиксит в 4-й версии, если мы когда-нибудь ее увидим.
Учитывая, что для многих эта книга — начало пути в профессию и то, что формирует начальную теоретическую базу (а многие также берут шаблоны документации требований оттуда) мне видится полезным подсветить точки улучшения. В целом, посыл таков: я однозначно рекомендую сей труд к изучению (особенно для тех, кто начинает свой путь в IT бизнес-анализе), но если, как и я, вы видите эти нестыковки, держите их в голове при формировании своей картины знаний и применении на практике. Конечно, я допускаю, что где-то попросту не понял замысел, поэтому если кто-то поправит и укажет на косяки в интерпретации, буду только рад. Также я буду сразу приводить оригинальный текст и его официальный перевод — рекомендую, конечно, изучать оригинал, если посильно (чтобы местами не сломать мозг).
Итак, поехали.
Начнем с того, что в модели есть System requirements (Системные требования).
Что смущает: вся приведенная классификация отталкивается от смыслового содержания требований. Бизнес-требования — о том, зачем нужна система, требования пользователей — о том, что юзерам нужно от системы, и т. п. По итогу из этой картины эти самые системные требования как будто резко выпадают:
A top-level requirement for a product that contains multiple subsystems, which could be all software or software and hardware.
Требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО или совокупность ПО и оборудования.
Т. е. тут мы переходим в классификацию по уровню взгляда на систему. Зачем мы на одной картине пытаемся объединить теплое с мягким? Бизнес-требования, требования уровня пользователей и пр. актуальны и к комплексному решению, и к отдельному ПО, и к не-программным решениям. Требование не может быть либо бизнес-требованием, либо системным требованием в рамках этой модели — тут смешиваются разные взгляды: (а) по содержанию требования, б) по тому, чем является наш целевой solution, к которому мы формируем требования.
В итоговой картине, которой я пользуюсь и которую мы продвигаем в массы, мы это убрали. Иерархия отлично работает без этого вида требований, плюс становится проще для восприятия.
Тут же можно упомянуть, что business rules (бизнес-правила) — не требования (авторы и сами это не раз подчеркивают), а потому это вопрос, стоит ли иметь их в этой модели никак не обособляя — читающие по диагонали новички часто трактуют их как требования и неверно понимают.
User requirements (Требования пользователей). Если попытаться сопоставить с BABOK (а общего между моделями много), то эту точку BABOK зовет Stakeholder requirements. И я тут согласен. Не только у пользователей могут быть требования к системе на этом уровне. И авторы поясняют это:
Some people use the broader term “stakeholder requirements,” to acknowledge the reality that various stakeholders other than direct users will provide requirements. That is certainly true, but we focus the attention at this level on understanding what actual users need to achieve with the help of the product.
Некоторые люди используют более широкий термин «требования заинтересованных лиц» для обозначения того факта, что требования будут предоставляться различными заинтересованными лицами, отличными от прямых пользователей системы. Это конечно же верно, но на данном уровне нам нужно понять, что реальные пользователи хотят достичь с помощью продукта.
Проблема в том, что если мы применяем эту модель на практике, то формулировкой user requirements мы ограничиваем свою работу и упускаем требования. Т. е. мы не подумаем о команде разработки (которая также может иметь требования — о чем авторы говорят дальше, когда затрагивают тему внутренних атрибутов качества), о спонсоре (который, к примеру, не-пользователь, но может иметь свои требования вида “Впихните мне мое лого на домашнюю страницу”), о регуляторах (которые предъявляют требования через бизнес-правила) и т. п. Я бы рекомендовал оставить именно Stakeholder requirements и так в практике к этому и относиться (предварительно сделав, конечно, грамотный анализ этих стейкхолдеров, чтобы понять к кому и с какой целью за требованиями лезть).
Data requirements (Требования к данным). Отсутствуют в модели в принципе. Авторы пишут следующее касательное своей иерархии требований:
Data requirements are not shown explicitly in this diagram. Functions manipulate data, so data requirements can appear throughout the three levels.
На этой схеме не показаны требования к данным. Функции манипулируют данными, поэтому требования к данным могут присутствовать на всех трех уровнях.
Я не понимаю, как требования к данным могут фигурировать на трех уровнях требований. Что такое, например, требования к данным на уровне бизнес-требований, которые бизнес-цели заказчика? На мой взгляд, требования к данным не могут лежать нигде, кроме уровня требований к решению (solution requirements — об этом ниже), т. к. это именно то, чем будет оперировать решение, работающее с информацией. И именно в SRS или аналогичных артефактах с требованиями к решению они и будут присутствовать.
BABOK (3): functional requirements: describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage.
IREB: Functional requirements concern a result or behavior that shall be provided by a function of a system. This includes requirements for data or the interaction of a system with its environment.
Я согласен с последними двумя источниками, ибо функции программных систем оперируют информацией, а потому два ключевых вида функциональных требований рекомендую иметь такие:
- Требования к поведению
- Требования к данным
Solution requirements (требования к решению). Такого термина в модели нет, при этом в BABOK именно они являются третьим уровнем. Не то, чтобы принципиально отсутствие этого термина, но в целом мне видится путаница с этим уровнем. Что пишут авторы, поясняя свою модель:
Software requirements include three distinct levels: business requirements, user requirements, and functional requirements. In addition, every system has an assortment of nonfunctional requirements.
Требования к ПО состоят из трех уровней — бизнес-требования, пользовательские и функциональные требования. Вдобавок в каждой системе есть свои нефункциональные требования.
Почему три уровня формируются именно так, как очерчено?
Чем принципиально отличаются нефункциональные требования (NFR) от функциональных (FR) в плане уровня и почему они не на третьем уровне под названием Solution Requirements вместе с FR?
Не путает ли аналитика то, что business rules — на одном “уровне” с business requirements (хотя они могут являться источником для всех видов требований), атрибуты качества — на уровне с user requirements (хотя, как и FR, их надо закладывать в систему), а внешние интерфейсы и ограничения — уже на уровне FR (хотя это те же самые NFR, как и атрибуты качества)?
Мне тут однозначно ближе модель BABOK, в которой есть третий уровень Solution Requirements, состоящий из FR и NFR. Так модель проще понимать и не путать с BABOK и рядом иных классификаций, плюс разграничивать артефакты, предназначенные для разных целей (SRS или аналогичные артефакты — это именно совокупность требований к решению, FR + NFR).
Чем принципиально отличаются нефункциональные требования (NFR) от функциональных (FR) в плане уровня и почему они не на третьем уровне под названием Solution Requirements вместе с FR?
Не путает ли аналитика то, что business rules — на одном “уровне” с business requirements (хотя они могут являться источником для всех видов требований), атрибуты качества — на уровне с user requirements (хотя, как и FR, их надо закладывать в систему), а внешние интерфейсы и ограничения — уже на уровне FR (хотя это те же самые NFR, как и атрибуты качества)?
Мне тут однозначно ближе модель BABOK, в которой есть третий уровень Solution Requirements, состоящий из FR и NFR. Так модель проще понимать и не путать с BABOK и рядом иных классификаций, плюс разграничивать артефакты, предназначенные для разных целей (SRS или аналогичные артефакты — это именно совокупность требований к решению, FR + NFR).
По поводу Business Requirements (бизнес-требований) в книге, как по мне, встречаются противоречия. Вот ряд отрывков:
Business requirements describe why the organization is implementing the system — the business benefits the organization hopes to achieve.
Бизнес-требования (business requirements) описывают, почему организации нужна такая система, то есть цели, которые организация намерена достичь с ее помощью.
Ок, возьмем это за базу (тем более это в ногу с большинством иных источников). Но далее:
“Business requirements” refers to a set of information that, in the aggregate, describes a need that leads to one or more projects to deliver a solution and the desired ultimate business outcomes. Business opportunities, business objectives, success metrics, and a vision statement make up the business requirements.
Термин бизнес-требования (business requirements) относится к информации, которая в совокупности описывает потребность, которая инициирует один или больше проектов, призванных предоставить решение и получить требуемый конечный бизнес-результат. В основе бизнес-требований лежат бизнес-возможности, бизнес-цели, критерии успеха и положение о концепции.
Как сюда относится vision statement? Формулировка конечного решения не отвечает на вопрос “зачем организации нужно решение”. Это ответ на вопрос "чем будет решение".
Two core elements of the business requirements are the vision and the scope.
Концепция и границы — два базовых элемента бизнес-требований.
Теперь сюда каким-то образом скоуп добавился. Скоуп — это наполнение решения (в терминах фич — функциональных единиц, характеристик — нефункциональных свойств или use cases/user stories — требований уровня пользователя). На вопрос “зачем организации нужно решение” единицы скоупа точно так же не отвечают.
Что я рекомендую: оставить за бизнес-требования то, что фигурировало в начальных постулатах выше: business opportunities, business objectives, success metrics. Видение решения — это не требования в принципе, т. к. все требования из иерархии направлены на решение. А что у нас вообще за решение — очерчиваем, если нужно, через vision statement.
Т. е. не лишним тут будет понимать, что не весь контент документа V&S — это бизнес-требования. В частности, не бизнес-требования (но важная контекстная информация) — background (описание ситуации AS IS), vision statement, business risks, assumptions and dependencies, scope and limitations, stakeholder profiles, project priorities.
И тут мы подходим к следующему пункту:
Project priorities (Приоритеты проекта) как раздел документа Vision and Scope. Вот, что авторы упоминают в другом месте:
So far we have been discussing requirements that describe properties of a software system to be built. Let’s call those product requirements. Projects certainly do have other expectations and deliverables that are not a part of the software the team implements, but that are necessary to the successful completion of the project as a whole. These are project requirements but not product requirements.
До этого момента мы обсуждали требования, описывающие свойства программной системы, которую планируется построить. Назовем их требованиями к продукту. Для проекта, как правило, создаются требования других типов: документ, где описана среда разработки, ограничения бюджета, руководство пользователя или требования для выпуска продукта и продвижения его в поддерживаемую среду. Это требования к проекту, но не к продукту.
В целом, я, хоть и понимаю концепцию совместной работы и пересекающихся областей, все же предпочитаю упрощение как минимум теории, чтобы начальные границы были более чисты (впоследствии уже участники могут между собой договориться). И по этим границам аналитик — он про решение, проектный менеджер — про проект по разработке решения. И тут внезапно в документ, очерчивающий требования, направленные на решение, проникают приоритеты проекта:
…five dimensions of features, quality, schedule, cost, and staff.
…пяти измерений: функции (или объем), качество, график, затраты и кадры
Не считая features (самого решения), это все проектные параметры. Оперировать ими уверенно требует знаний и понимания проектноуправленческих аспектов, т. е. по всей логике — это область работы проектного менеджера. Зачем аналитику сюда лезть? Аналитику нужно понять и отвечать за решение. Я за то, чтобы убрать это из фокуса работы и артефактов аналитика, т. к. не понимаю, в каком ключе аналитик будет вырабатывать информацию подобного плана с имеющимися у него знаниями и навыками:
До 15% перерасхода по бюджету возможны без пересмотра куратором проекта.
Планируемый состав команды: работающий на полставки менеджер проекта, 2 разработчика, тестировщик, работающий на полставки; при необходимости могут быть дополнительно привлечены разработчик и тестировщик, работающие на полставки.
Transition requirements (Переходные требования). Мне импонирует концепция таких требований, и я вижу необходимость в работе с ними. К сожалению, авторы упоминают Transition requirements только мельком в некоторых разделах, например в разделе SRS “Other requirements”:
Transition requirements that are necessary for migrating from a previous system to a new one could be included here if they involve software being written (as for data conversion programs), or in the project management plan if they do not (as for training development or delivery).
В этот раздел можно включить требования к переходу, которые необходимы для миграции с предыдущей системы на новую, если они относятся к создаваемому ПО (например, программы преобразования данных), в противном случае их можно включить в план управления проектом (например, разработка обучающих материалов или поставка).
В этом плане мне нравится то, что в модели BABOK этот вид требований вынесли в отдельную явную категорию, чем я и рекомендую дополнить модель авторов. Не задуматься о них, идя по чеклисту видов требований, может оказаться весьма рискованным.
Пока мы в теме Transition Requirements, поговорим об еще одном разделе документа Vision and Scope — Deployment Considerations (Особенности развертывания). Вот, как авторы подают суть этого раздела:
Summarize the information and activities that are needed to ensure an effective deployment of the solution into its operating environment.
Перечислите информацию и действия, необходимые для обеспечения эффективного развертывания решения в рабочую среду.
И это слегка внезапно. В том же самом пассаже про project requirements (см. выше) авторы приводят следующие примеры, плюс поясняют этот пласт информации так:
Project requirements include...environment, configuring it, and testing the installation.
- Infrastructure changes needed in the operating environment.
- Requirements and procedures for releasing the product, installing it in the operating
...
This book does not address these sorts of project requirements further. That doesn’t mean that they aren’t important, just that they are out of scope for our focus on software product requirements development and management.
К требованиям проекта относятся......
- инфраструктурные изменения, которые необходимо внести в рабочую среду;
- требования и процедуры для выпуска продукта, установки в рабочей среде, конфигурирования и тестирования;
Эти требования к проекту не будут рассмотрены в этой книге. Это не значит, что они не важны, — просто они находятся за рамками нашей тематики, посвященной разработке и управлению требованиям к программному продукту.
Мне не очень понятно, как сочетаются эти два отрывка: только, если допустить, что Vision and Scope — это смесь информации как по решению, так и по проекту по его разработке.
При этом, комбинируя этот и предыдущий пункты — а как насчет переименовать это в Transition requirements и указать их тут? Мы ведь в документе с высоты птичьего полета перечислили функции (FR) и характеристики (NFR) в разделе Scope, но забыли про переходные требования (как минимум те, которые видимы уже на этапе работы с бизнес-требованиями).
При этом я рекомендую все же хотя бы пытаться разделять Transition requirements и проектные работы по поставке решения (deployment considerations). Грань может быть туманной, но вот, как вижу ее для себя я. Переходные требования — это дополнительные активности или меры, дабы решение в очерченном нами FR+NFR скоупе стало нести ценность бизнесу и пользователям. Т. е. наша команда разработала и поставила решение, обладающее набором FR и NFR. Оно уже интегрировано в рабочие процессы компании и несет ценность "как есть"? Или нужно (причем далеко не факт, что именно нам как исполнителям):
Проектные работы по разработке и поставке решения — это то, что включено в процесс разработки и поставки решения. Проект по разработке и внедрении решения может включать для нас:
И если о первом списке как аналитик я могу (и должен бы) подумать, т. к. тут я думаю о бизнесе и пользователях, то о втором — едва ли, т. к. эти аспекты — на плечах моей команды разработки.
- Обучить пользователей
- Сделать миграцию данных из старого решения
- Разослать уведомления пользователям
- Создать аккаунты для пользователей и т. п.
Проектные работы по разработке и поставке решения — это то, что включено в процесс разработки и поставки решения. Проект по разработке и внедрении решения может включать для нас:
- Написать код, настроить сборки, протестировать и т. п.
- Настроить серверы, сеть и прочие параметры окружения
- Развернуть систему в продакшне и проверить там ее работоспособность и т. п.
И если о первом списке как аналитик я могу (и должен бы) подумать, т. к. тут я думаю о бизнесе и пользователях, то о втором — едва ли, т. к. эти аспекты — на плечах моей команды разработки.
Следующая (не особо существенная на самом деле) деталь касательно документа Vision and Scope: Background и Business opportunity (Исходные данные и Возможности бизнеса). Это подано как два разных раздела в документе. Вот, как описывают содержимое авторы:
Background: Summarize the rationale and context for the new product or for changes to be made to an existing one. Describe the history or situation that led to the decision to build this product.
Business Opportunity: ....describe the business problem that is being solved or the process
being improved...
...describe the business opportunity that exists and the market in which the product will be
competing...
Describe the problems that cannot currently be solved without the envisioned solution.
Исходные данные: Они суммируют обоснование и содержание нового продукта или изменения, которые нужно внести в существующий продукт. Здесь помещают общее описание предыстории или ситуации, в результате чего было принято решение о создании продукта.
Возможности бизнеса: ...описывают бизнес-задачу, которая решается посредством этого продукта, или бизнес-процессы, для улучшения которых требуется продукт.
...существующие рыночные возможности и рынок, на котором продукту придется конкурировать с другими продуктами...
Опишите задачи, которые не удается разрешить без предлагаемого решения.
Честно говоря, мне неясна разница. В то же время, мне нравится концепция из BABOK — выделять понятие Business Need (бизнес-потребность), которая может быть проблемой (problem) или возможностью (opportunity). Бизнес-потребности порождают бизнес-требования — последние формулируются на базе первых. Бизнес-потребности — это часть описания ситуации AS IS (задача Analyze Current State из BABOK). Они описывают, что сейчас не так или какие улучшения хотелось бы иметь. А потому зачем нам иметь два раздела, описывающие одни и те же вещи, только чуть разным языком, если все, что нам нужно сделать — это сформулировать бизнес-потребности (проблемы либо возможности) и описать контекст вокруг них в одном месте?
Нехватка видов требований в модели. Несмотря на то, что модель видов требований, в целом, отлична, когда я как читатель начинаю изучать артефакты с требованиями, у меня возникает небольшой диссонанс. Например, поговорим про требования к решению, а именно про SRS (Software Requirements Specification). Плюс примерно в таком же виде мы можем вести речь и о требованиях в рамках Agile-документации.
В SRS у авторов есть раздел Operating environment (Операционная среда). Очень важная и нужная информация, но а что это за вид требований?
Модель видов требований у меня не мэтчится с содержимым документа. Или это не считается требованиями? Но как же тогда формулировки вида "The COS shall operate correctly with the following web browsers: Windows Internet Explorer versions 7, 8, and 9; Firefox versions 12 through 26; Google Chrome (all versions); and Apple Safari versions 4.0 through 8.0". Не звучит ли это как требование?
Модель видов требований у меня не мэтчится с содержимым документа. Или это не считается требованиями? Но как же тогда формулировки вида "The COS shall operate correctly with the following web browsers: Windows Internet Explorer versions 7, 8, and 9; Firefox versions 12 through 26; Google Chrome (all versions); and Apple Safari versions 4.0 through 8.0". Не звучит ли это как требование?
Что предлагаю: иметь категорию "Прочие" для NFR (помимо Атрибутов качества, Требований к внешним интерфейсам и Ограничений), куда будут входить различные "обрезки", которые относятся к нефункциональным аспектам решения и могут быть разными в зависимости от того, что у нас за решение по своей сути. В том числе, туда будут входить и требования к операционной среде.
По аналогии: Internationalization and localization requirements (Требования по интернационализации и локализации). Раздел есть, зовутся требованиями, а с моделью видов требований не стыкуется. Еще один замечательный кандидат в раздел "Прочие NFR".
Авторы также упоминают в документе заглушку [Other requirements] — для разных иных требований:
Define any other requirements that are not covered elsewhere in the SRS. Examples are legal, regulatory, or financial compliance and standards requirements; requirements for product installation, configuration, startup, and shutdown; and logging, monitoring, and audit trail requirements.
Определите все другие требования, которые еще не были описаны в спецификации требований к ПО. Примером могут служить юридические, законодательные или финансовые требования и требования стандартов, требования к установке, конфигурированию, запуску и остановке продукта, а также к журналированию, мониторингу...
И хоть я понимаю, что любая модель неидеальна по определению, но почему бы все же не оставить простор для таких требований под грифом "Прочие NFR"? У нас есть либо FR, либо NFR — этими видами наполнение ПО исчерпывается. И тогда не возникнут сложности с сопоставлением модели и артефактов, описанных выше.
И напоследок — про Characteristics of excellent requirements (Характеристики превосходных требований). Набор "качеств" — замечательный. Однако нет пояснений по ограниченности его применения в контексте разных видов требований. А они, как мне видятся, есть.
Давайте разбираться (а кому лениво вчитываться — можно прыгнуть сразу к зеленому маркеру).
Давайте разбираться (а кому лениво вчитываться — можно прыгнуть сразу к зеленому маркеру).
In an ideal world, every individual business, user, functional, and nonfunctional requirement would exhibit the qualities described in the following sections.
В идеальном мире каждый отдельный пользователь, компания или функциональные требования отвечают различным параметрам качества, которые и описаны в следующих разделах. Перевод — бомба 🤣
Complete (Полнота) — согласен, но: авторы фокусируются на представлении user requirements с помощью use cases, user stories и event-response tables. При этом, если мы вернемся к тому, что user requirements стоило бы расширить до stakeholder requirements (плюс, как мельком упоминают авторы, включают descriptions of product attributes or characteristics that are important to user satisfaction), возникают вопросы.
В моем понимании, user/stakeholder requirements — это исходные "хотелки" (зачастую — черновые), которые впоследствии перерабатываются аналитиком в solution requirements (FR и NFR). А само слово "черновые" подразумевает, что до анализа и переработки в solution requirements эти самые user requirements не будут качественными. Пример user requirement: Нужно иметь возможность заказать еду в рабочее время (для системы по заказу еды для сотрудников). На этапе переработки в FR/NFR это станет, например, вариантом использования"Заказать еду", детализированным внутри с помощью FR. Но само исходное user requirement — оно полное или нет? Мне сказать сложно.
Correct (Корректность — т. е. не искажен смысл) — согласен, что актуально для любого требования, да и в целом для любой информации, которую прорабатывает аналитик.
Feasible (Осуществимость — "возможность реализовать требование при известных возможностях и ограничениях системы и рабочей среды, а также в рамках временных, бюджетных и ресурсных ограничений проекта"). Применимо ли подобное для бизнес-требований? По красивому процессу "от проблем к решению" на этапе проработки бизнес-требований мы не уверены еще в том, каким будет наше решение. Как бизнес-цель может быть реализуема технически или нет, не понимая, что мы будем делать? Кстати, для целей есть такая штука, как SMART, в котором есть achievable — достижима для заказчика в текущем бизнес-контексте, что уже ближе к истине.
Теперь, как мы можем оценить feasibility user requirements? Например, "Хочу, чтобы система работала быстро". Лишь потом, будучи переработанным в NFR, это станет чем-то вида "Время загрузки страниц не должно превышать 2-х секунд при пропускной способности локальной сети >= 100 Mbps."
Теперь, как мы можем оценить feasibility user requirements? Например, "Хочу, чтобы система работала быстро". Лишь потом, будучи переработанным в NFR, это станет чем-то вида "Время загрузки страниц не должно превышать 2-х секунд при пропускной способности локальной сети >= 100 Mbps."
Necessary (Необходимость) — ок, применимо для любых требований. Бизнес-требования должны соответствовать решаемым бизнес-потребностям, stakeholder requirements — бизнес-требованиям и тому, что нужно стейкхолдерам, solution requirements — соответствовать stakeholder requirements.
Prioritized (Приоритизированность). Тут будет несколько иной вопрос . Несомненно, есть ценность в приоритизации бизнес-требований, ее можно найти в приоритизации stakeholder requirements, но едва ли кто-то занимается вот таким:
Assign an implementation priority to each functional requirement...
Каждый отдельный критерий приемки в user story или шаг системы в use cases (или когда вы в ином формате описываете поведение системы) — это функциональное требование. Кто будет заморачиваться приоритизацией каждого шага для всех вариантов использования и зачем? Зачем приоритизировать ограничения, если им надо просто следовать? Т. е. тут также стоит ввести оговорку: каждая команда сама решит, что в их контексте — единица работ (или бэклога, если в терминах agile), которую нужно приоритизировать (например, единицы скоупа: фичи, юз кейсы, юзер стори).
Unambiguous (Недвусмысленность) — также согласен, что это полезное качество для любого вида информации, но сошлюсь еще раз на user/stakeholder requirements — "хотелки", которые получат "качество" только тогда, когда будут переработаны аналитиком в solution requirements (FR и NFR).
Verifiable (Проверяемость — "Сможет ли тестировщик разработать тесты или применить другие приемы,
чтобы установить, действительно ли в продукте реализовано каждое требование"). Едва ли тестировщики будут проверять достижение бизнес-целей, да и проверка исходных "хотелок" уровня пользователей (Хочу, чтобы система работала быстро") — также под вопросом. Тестировщики будут проверять реализацию требований к решению.
чтобы установить, действительно ли в продукте реализовано каждое требование"). Едва ли тестировщики будут проверять достижение бизнес-целей, да и проверка исходных "хотелок" уровня пользователей (Хочу, чтобы система работала быстро") — также под вопросом. Тестировщики будут проверять реализацию требований к решению.
Как бы я подытожил:
Для бизнес-требований есть замечательная аббревиатура SMART — берем ее за "идеальный набор качеств" этого вида требований.
Для требований заинтересованных лиц (включая требования пользователей): с одной стороны, им не нужно качество, если мы трактуем их как сырой материал и источник для solution requirements. С другой стороны, ту их часть, которую мы оформим в виде use cases или user stories, можно проверить по собственным параметрам качества: для user stories есть INVEST; для вариантов использования красивой мнемоники не встречал, но есть рекомендации от "классиков" по тому, как выделять и описывать use cases.
Для требований к решению (FR и NFR) — чеклист выше, и он для них работает, но с оговорками. Берем приоритизацию как пример.
Что по итогу:
Надеюсь, что моменты, которые я перечислил выше, помогут уложить в голове теорию из этой замечательной книги и применять на практике, внеся небольшие поправки. Кого-то, вероятно, простимулируют указать мне на неверную интерпретацию и то, что в действительности вкладывали авторы.
В любом случае, Software Requirements — огромный и крутейший труд, и большое спасибо за него Карлу Вигерсу и Джой Битти.
Надеюсь, что моменты, которые я перечислил выше, помогут уложить в голове теорию из этой замечательной книги и применять на практике, внеся небольшие поправки. Кого-то, вероятно, простимулируют указать мне на неверную интерпретацию и то, что в действительности вкладывали авторы.
В любом случае, Software Requirements — огромный и крутейший труд, и большое спасибо за него Карлу Вигерсу и Джой Битти.
