Этап 3. Спецификации требований
Суть спецификации требований заключается в документировании требований различных типов единообразным, доступным и поддающимся проверке способом так, чтобы они были понятными целевой аудитории. Зафиксировать бизнес-требования можно в положении о концепции и границах. Пользовательские требования обычно представляют в виде вариантов применения или пользовательских историй. Подробные функциональные и нефункциональные требования к ПО фиксируются в спецификации требований к ПО (SRS) или другом хранилище, таком как средство управления требованиями.
Внедрение шаблонов документов требований
Создайте стандартные шаблоны для документирования требований к ПО в вашей организации, такие как документ концепции и границ в главе 5, шаблон варианта использования в главе 8 и шаблон SRS в главе 10. Шаблон предоставляет согласованную структуру, позволяющую фиксировать описания разной информации, касающейся требований. Даже если вы не храните требования в традиционной документарной форме, шаблон напомнит вам о разных видах информации требований, которые нужно собрать и записать.
Определение источников требований
Чтобы гарантировать, что все заинтересованные лица понимают, зачем нужно то или иное требование, выявите источники всех требований. Это может быть вариант использования или другая информация от пользователей, системное требование высокого уровня или бизнес-правило. Указав всех лиц, заинтересованных в каждом требовании, вы будете знать, к кому обратиться при поступлении запроса на изменение. Источники требований устанавливают на основе связей или определяют для этой цели атрибут требования.
Присвоение уникальных идентификаторов всем требованиям
Выработайте соглашение о присвоении уникальных идентификаторов требованиям. Соглашение должно обеспечивать возможность дополнения, удаления и изменения требований. Присвоение идентификаторов позволяет отслеживать требования и фиксировать вносимые изменения.
Документирование бизнес-правил
К бизнес-правилам относятся корпоративные политики, правительственные распоряжения и алгоритмы вычислений. Ведите список бизнес-правил отдельно от требований проекта, поскольку правила обычно существуют вне рамок конкретного проекта. То есть бизнес-правила нужно рассматривать как актив уровня предприятия, а не проекта. Для выполнения некоторых приходится создавать реализующие их функциональные требования, и поэтому необходимо определить связь между этими требованиями и соответствующими правилами.
Определение нефункциональных требований
Можно реализовать решение, которое делает ровно то, что ожидается, но не реализует ожиданий пользователей в плане качестве. Чтобы избежать подобной проблемы, нужно выйти за рамки обсуждения функциональности, чтобы понять характеристики качества, которые важны для успеха проекта. К этим характеристикам относятся производительность, надежность, удобство использования, возможность внесения изменений и многое другое. Информация от клиента об относительной важности эти атрибутов качества позволяет разработчику принимать соответствующие проектные решения. Также нужно указать требования внешних интерфейсов, ограничения дизайна и реализации, проблемы интернационализации и другие нефункциональные требования
Внедрение шаблонов документов требований
Создайте стандартные шаблоны для документирования требований к ПО в вашей организации, такие как документ концепции и границ в главе 5, шаблон варианта использования в главе 8 и шаблон SRS в главе 10. Шаблон предоставляет согласованную структуру, позволяющую фиксировать описания разной информации, касающейся требований. Даже если вы не храните требования в традиционной документарной форме, шаблон напомнит вам о разных видах информации требований, которые нужно собрать и записать.
Определение источников требований
Чтобы гарантировать, что все заинтересованные лица понимают, зачем нужно то или иное требование, выявите источники всех требований. Это может быть вариант использования или другая информация от пользователей, системное требование высокого уровня или бизнес-правило. Указав всех лиц, заинтересованных в каждом требовании, вы будете знать, к кому обратиться при поступлении запроса на изменение. Источники требований устанавливают на основе связей или определяют для этой цели атрибут требования.
Присвоение уникальных идентификаторов всем требованиям
Выработайте соглашение о присвоении уникальных идентификаторов требованиям. Соглашение должно обеспечивать возможность дополнения, удаления и изменения требований. Присвоение идентификаторов позволяет отслеживать требования и фиксировать вносимые изменения.
Документирование бизнес-правил
К бизнес-правилам относятся корпоративные политики, правительственные распоряжения и алгоритмы вычислений. Ведите список бизнес-правил отдельно от требований проекта, поскольку правила обычно существуют вне рамок конкретного проекта. То есть бизнес-правила нужно рассматривать как актив уровня предприятия, а не проекта. Для выполнения некоторых приходится создавать реализующие их функциональные требования, и поэтому необходимо определить связь между этими требованиями и соответствующими правилами.
Определение нефункциональных требований
Можно реализовать решение, которое делает ровно то, что ожидается, но не реализует ожиданий пользователей в плане качестве. Чтобы избежать подобной проблемы, нужно выйти за рамки обсуждения функциональности, чтобы понять характеристики качества, которые важны для успеха проекта. К этим характеристикам относятся производительность, надежность, удобство использования, возможность внесения изменений и многое другое. Информация от клиента об относительной важности эти атрибутов качества позволяет разработчику принимать соответствующие проектные решения. Также нужно указать требования внешних интерфейсов, ограничения дизайна и реализации, проблемы интернационализации и другие нефункциональные требования