Требования к информационной системе сети торговых точек

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

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

Хорошо сформулированное требование должно обладать следующими свойствами:

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

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

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

Для формирования требований к системе можно использовать описание предметной области, а также список основных функций системы из документа «Видение».

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

Можно выделить следующие рекомендации по оформлению требований:

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

· Нумеруйте требований через десяток. Это необходимо для того, что соблюсти свойство последовательности изложения требований. Ведь, если вам нужно вставить новое требование между требованиями 7 и 8, а всего требований у вас 99, то вам придется перенумеровать все требования начиная с восьмого. Если же вам необходимо вставить требование между требованиями 70 и 80, то необходимость в такой перенумерации отпадает. Выполнение этой рекомендации еще удобно и потому, что в тексте требований могут встречаться ссылки на другие требования и в случае изменения номера требования, на которое имеется ссылка, необходимо будет изменить и ее. В случае же нумерации требований через десяток вероятность того, что номер требования когда-либо изменится очень мала.

· Используйте только термины из глоссария. При описании запрещается использовать специальные термины, которых нет в глоссарии. Если вам необходимо употребить какой-либо термин, а его нет в глоссарии, то его необходимо туда внести, описать, и только потом употреблять (это вполне допустимо, ведь используется итеративный подход).

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

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

· Никакой реализации – только требования. Требование должно быть полностью абстрагированным от реализации. Недопустимым является употребление фраз типа «Система должны содержать таблицу Товары».

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