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

Продолжение серии статей о требованиях. Часть 2.
Требования должны обладать следующими характеристиками:
1. Единичность. Это означает, что требование относится только к одному свойству. Например, система должна выполнять такое-то действие. Пример хорошего требования: система должна позволять регистрацию пользователей. Пример плохого требования: система должна позволять авторизацию пользователей по данным социальных сетей и запрашивать из социальных сетей и публиковать на стене пользователя в социальной сети определенную информацию. Почему это требование некорректное - не указаны социальные сети, а далеко не все разрешают сторонним приложения размещать информацию на стене пользователя, а, во-вторых, тут объединены два требования. 

2. Атомарность. Атомарность означает, что требования дальше нельзя разбить или уточнить. Например, пользователь может авторизоваться с помощью <конкретный список социальных сетей>. Плохое требование: пользователь может выбрать статью для чтения и прокомментировать ее. Это два требования, которые надо разбивать и конкретизировать дальше. 

3. Завершённость. Требование целиком приведено в одном месте документации. Не должно быть такого, чтобы в разных частях документа с требованиями шла речь об одном и том же функционале. 

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

5. Отслеживаемость (Трассируемость). Это означает, что требования зафиксировано в документации и можно понять откуда оно взялось. Например, требование подтверждения возраста это требование этического комитета заказчика. 

6. Актуальность. Это означает, что требование не устарело. Например, требование должно соответствовать современному законодательству. Или техническим реалиям. Вряд ли сейчас найдется много пользователей IE5 и Netscape Navigator. 

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

8. Понятность. Это означает, что нельзя использовать жаргон, фраза должна пониматься всеми одинаково. Т.е. фраза  "казнить нельзя помиловать" не должна использоваться.

9. Проверяемость. Это означает, что выполнение требования можно проверить. Пример плохого требования:  система должна работать быстро. Или сайт должен иметь понятную систему навигации. Или должен использовать интуитивно-понятный интерфейс. Кстати, на будущее, я напишу отдельную статью по поводу того, что не бывает интуитивного-понятного интерфейса. 

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

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

При фиксации требований очень важно не делать такую  ошибку, как формулировать требования в виде "как система должна работать". Надо использовать подход "что система должна делать". Пример плохих требований: Пользователь  нажимает красную кнопку в углу формы и переходит на следующий этап выбора товара в интернет-магазине. Пример хорошего требования: при выборе определенного товара пользователю предлагается перейти в корзину для оформления заказа или продолжить просмотр каталога. Дело в том, что вариантов реализации может быть множество и не надо заранее себя ограничивать. Более того, очень важно избегать субъективного подхода. Если что-то удобно именно вам, это не означает, что удобно всем.