Процесс разработки требований один из самых важных и сложных этапов при создании любого программного продукта. Очень часто успех проекта зависит от того, насколько качественно и точно составлена документация.
К сожалению, не существует выверенного способа написания идеальных требований. Хорошую документацию можно определить по техническому стилю изложения и используемой терминологии, а не по компьютерному сленгу. Она достаточно точно описывает ожидания заказчика от проекта, и является понятной для всех, кто принимает участие в разработке.
Причины возникновения двусмысленности
Согласно К. Вигерсу [1], одним из критериев хорошего требования является его «недвусмысленность». Это значит, что требование читается и понимается заказчиком и всеми участниками команды разработки одинаково.
В моей практике требования «из-под руки» аналитика, попадают прямиком к заказчику, а от заказчика через аналитика к разработчику. К сожалению, среди разработчиков больше любителей писать код, чем участвовать в дискуссиях, поэтому совместное обсуждение требований иногда носит воинственный характер и выходит весьма затратным по времени.
Одной из причин возникновения двусмысленности в требованиях является незнание контекста. Каждый, кто читает требования, должен быть в контексте описанного. Если в документации есть какие-то специфические термины, тонкости применения которых знает, например, только заказчик, то они должны быть описаны в глоссарии.
К примеру, мой заказчик активно использовал термин «счёт»(invoice), говоря о пост оплате, где задействован баланс денежных средств, для одного типа заказов, и тот же термин использовал, говоря о предоплате, но уже для другого типа заказов. Разработчик в свою очередь, опираясь не только на документацию, но и на свой опыт, принял оба случая за один и тот же тип оплаты, и подразумевал, что заказ будет предоставлен только после оплаты «счёта».
В данном случае, использование глоссария, позволило бы устранить неоднозначность и избежать ошибки при реализации функционала системы.
Вторая причина двусмысленности — это то, что требования пишутся на естественном языке (natural language), в отличии от формального языка (formal language) [2], в котором двусмысленность исключена.
Формальный язык – это язык, который характеризуется точными правилами построения выражений и их понимания. Он строится в соответствии с четкими правилами, обеспечивая непротиворечивое, точное и компактное отображение свойств и отношений изучаемой предметной области. К формальным языкам относятся формулы, блок-схемы, алгоритмы и т.д.
Естественный язык — это язык, который используется в повседневной жизни прежде всего для общения, и имеет целый ряд особенностей, к примеру, слова могут иметь более одного значения, иметь синонимы или быть омонимами, а иногда значения отдельных слов и выражений зависят не только от них самих, но и от контекста, в котором они употребляются.
Все это в совокупности приводит к тому, что причиной возникновения двусмысленности как раз и является естественный язык.
Слова, которые приводят к двусмысленности
К словам, которые могут приводить к двусмысленности, относятся:
- соединительный союз «и»;
- разделительный союз «или»;
- пояснительные союзы «также» и «только»;
- слова «по возможности», «при необходимости».
Это далеко не весь список. Однако мне бы хотелось рассмотреть именно его, поскольку без этих слов иногда не обойтись, но применять их нужно очень осторожно.
Соединительный союз «и»
Этот союз может означать, что:
- одно действие или объект в хронологическом порядке следует за другим действием или объектом;
- одно действие является результатом другого действия;
- действие или объект зависит от предыдущего действия или объекта.
На одном из проектов аналитиком было прописано требование: R1. «Все пользователи для входа в систему используют логин и пароль». При этом, подразумевалось, что «У каждого пользователя для входа в систему есть свой уникальный логин и пароль». Но при прочтении требований разработчик интерпретировал это требование как «Все пользователи используют один логин и пароль для входа в систему».
Разделительный союз «или»
Данный союз также может быть источником потенциальной двусмысленности. В случае, если речь идет про два и более объекта или действия, то смысл может быть такой:
- «или то, или то» (исключающее «или»);
- либо «оба сразу» (включающее «или»).
К примеру, требование R2. «Координатор или администратор могут мониторить заказы в системе» может трактоваться следующим образом:
- координатор или администратор, но не вместе, могут мониторить каждый заказы в системе;
- координатор и администратор могут вместе мониторить все заказы в системе;
- координатор может мониторить все заказы в системе;
- администратор может мониторить все заказы в системе.
Соответственно, первоначальная формулировка требования не дает точного понимания, как должен быть реализован данный функционал, а неточные или размытые формулировки дают разработчикам больше свободы для их интерпретации.
Пояснительные союзы «также» и «только»
Могут вносить неоднозначность в сочетании с «и» и «или», образуя сочетания:
- только…или;
- также…и.
Например, R3. «Только администратор или координатор могут заблокировать пользователя». Возможные трактовки данного требования:
- один администратор и любой координатор вместе могут заблокировать пользователя;
- каждый администратор может заблокировать пользователя;
- каждый координатор может заблокировать пользователя.
Слова «по возможности», «при необходимости»
Использование этих слов вносит не только двусмысленность в написанное, но еще делают требования не тестируемым, поскольку неясно, в какой момент эта «возможность» или «необходимость» должна появиться.
R4. «При необходимости пользователь может распечатать счет». Данное требования не дает точной информации, когда должна быть доступна эта функция.
Способы борьбы с двусмысленностью в требованиях
Для того, чтобы двусмысленность не стала проблемой в требованиях, необходимо:
- Использовать глоссарий терминов. Он поможет команде разработки понять специфику терминологии, которую использует заказчик, а заказчику в свою очередь – терминологию разработки.
- Проводить семинары, встречи или совещания по обсуждению требований. Работа с требованиями сложный и кропотливый процесс, и вовлеченность в него заказчика и команды разработки прямо пропорциональна вероятности успешной реализации ожиданий заказчика.
- Избегать сложных предложений. Сложные предложения, в которых используются соединительные, разделительные, пояснительные союзы, усложняют понимание написанного, и могут привести к неоднозначности, поэтому лучше использовать простые предложения. Если, все такие, не удается избежать применение союзов, убедитесь, что написанное имеет только один вариант трактовки.
- Проводить тестирование требований. Если для проверки требования невозможно составить сценарий тестирования, это значит, что требование не четко сформулировано или не полное, и его необходимо исправить.
Заключение
В заключение, хочу сказать, что ошибки, которые были допущены в приведенных примерах, взяты из реальных проектов, и они могли бы остаться неисправленными, и как результат заказчик был бы не удовлетворен, если бы не совместные обсуждения требований и проработка вариантов тестирования с командой и заказчиком.
Я надеюсь, что мои примеры и рекомендации будут полезны молодым аналитикам минимизировать вероятность появления двусмысленности, поскольку цена ошибки в требованиях может быть очень высока для всего проекта.
Литература:
[1] Название, Разработка требований к программному обеспечению. Автор, Вигерс Карл Битти Джой. Издательство, БХВ-Петербург. Год, 2014.
[2] Avoiding Ambiguity in Requirements Specifications, Sri Fatimah Tjong, B.Sc. University of Nottingham, 2008.
Автор:
Екатерина Ли
Бизнес аналитик, руководитель отдела
