Термины, которых следует избегать в спецификации требований
При записи требований следует избегать множества привычных и обыденных терминов, имеющих неоднозначный характер. Ловушка в использовании подобных терминов заключается в том, что в процессе обсуждения все формулировки кажутся понятными, но при последующем чтении этих формулировок вне контекста обсуждения возникает неоднозначность. В приведенной ниже таблице показаны распространенные термины, порождающие неоднозначность, и способы устранения неоднозначности.
Таблица 6‑1. Устранение неоднозначностей в формулировках требований
| Неоднозначный термин | Способы устранения неоднозначности |
| Приемлемый, адекватный | Определите, что понимается под приемлемостью и как система это может оценить |
| Практически выполнимо | Не заставляйте разработчиков определять, что под этим понимается. Поставьте пометку НО (необходимо определить) и определите дату, к которой эту проблему следует разрешить |
| По меньшей мере, как минимум, не более чем, не должно превышать | Укажите минимальное и максимальное допустимые значения |
| Между | Определите, указаны ли конечные точки |
| Зависит от | Определите природу зависимости. Обеспечивает ли другая система ввод данных в вашу систему, надо ли установить другое ПО до запуска вашей системы и зависит ли ваша система от другой при выполнении определенных расчетов или служб |
| Эффективный | Определите, насколько эффективно система использует ресурсы, насколько быстро она выполняет определенные операции и насколько она проста в обращении |
| Быстрый, моментальный | Укажите минимальную приемлемую скорость, при которой система выполняет определенное действие |
| Гибкий | Опишите способы изменения системы в ответ на изменения условий или бизнес-потребностей |
| Улучшенный, лучший, более быстрый, превосходный | Определите количественно, насколько лучше или быстрее стали показатели в определенной функциональной области |
| Включает; включает в себя, но не ограничен этим; и т.д., и т.п.; такой как | Список элементов должен включать все возможности. В противном случае его нельзя использовать при разработке или тестировании |
| Максимизируйте, минимизируйте, оптимизируйте | Укажите минимальное и максимальное допустимые значения определенного параметра |
| Обычно, в идеальном варианте | Также опишите поведение системы при нештатных или неидеальных условиях |
| Необязательно | Укажите, кто делает выбор: системы, пользователь или разработчик |
| Разумный, при необходимости, при соответствующих условиях | Объясните, как это выполнить |
| Устойчивый к сбоям | Определите, как система должны обрабатывать исключения и реагировать на неожиданные условия работы |
| Цельный, прозрачный, элегантный | Выразите ожидания пользователя, применяя характеристики продукта, которые можно наблюдать |
| Несколько | Укажите сколько или задайте минимальную и максимальную границы диапазона |
| Не следует | Старайтесь формулировать требования в позитивной форме, описывая, что именно система будет делать |
| Реальный | Поясните этот термин |
| Достаточный | Укажите, какая степень чего-либо свидетельствует о достаточности |
| Поддерживает, позволяет | Дайте точное определение, какие действия система будет выполнять, поддерживая конкретную возможность |
| Дружественный, простой, легкий | Опишите системные характеристики, которые будут отвечать потребностям пользователей и его ожиданиям, касающимся легкости и простоты применения продукта |
Контроль версий
Контроль версий – это важный аспект управления спецификациями требований и другими проектными документами. Каждой версии следует присвоить уникальный идентификатор. У каждого члена команды должен быть доступ к текущей версии требований, а изменения необходимо ясно документировать и передавать всем заинтересованным сторонам. Чтобы минимизировать путаницу, конфликты и непонимание, назначьте право обновления требований строго определенным лицам и убедитесь, что идентификатор версии изменяется при каждом изменении требования.
Каждая версия документа требований должна содержать историю переработки, где указываются внесенные изменения, дата каждого из них, лицо, внесшее изменение, а также причина. Текущая версия документа должна указываться в колонтитуле.
Простейший механизм управления версиями – именовать вручную каждую версию спецификации требований к программному обеспечению согласно соглашению. Попытка различать версии документов по дате изменения или дате печати часто приводит к ошибкам и неразберихе.
Дата добавления: 2016-06-13; просмотров: 991;