Присвоение уникальных идентификаторов всем требованиям.
Выработайте соглашение о присвоении уникальных идентификаторов
требованиям, зафиксированным в спецификации требований к ПО.
Соглашение должно быть устойчивым к дополнению, удалению
элементов и изменениям, вносимым в требования. Присвоение
идентификаторов позволяет отслеживать требования и фиксировать
вносимые изменения.
Указание
атрибутов
качества.
Выявляя
качественные
характеристики,
удовлетворяющие
потребности
клиента,
не
ограничивайтесь только обсуждением функциональности. Выясните
ожидаемые производительность, эффективность, надежность, удобство в
использовании др. Информация от клиентов об относительной важности
тех или иных качественных характеристиках позволит разработчику
принять правильные решения, касающиеся архитектуры приложения.
Документирование бизнес-правил.
К бизнес-правилам относятся
корпоративные политики, правительственные распоряжения и
алгоритмы вычислений. Ведите список бизнес-правил отдельно от
спецификации требований к ПО, поскольку правила обычно существуют
вне рамок конкретного проекта. Для выполнения некоторых приходится
создавать реализующие их функциональные требования, и поэтом
необходимо определить связь между этими требованиями и
соответствующими правилами [12, 25].
5.7.
Проверка требований
Изучение документов с требованиями.
Официальная проверка
документирования требований – один из наиболее ценных способов
проверки качества ПО. Соберите небольшую команду, члены которой
представляют различные направления (например, аналитик, клиент,
разработчик и специалист по тестированию}, и тщательно изучите
спецификацию требований к ПО, модель анализа и соответствующую
информацию на предмет недостатков. Также полезно провести в ходе
формулирования требований их неофициальный предварительный
просмотр. И хотя реализовать это на практике непросто, данный прием –
один из самых ценных, так что начинайте внедрять проверку требований
в вашей организации прямо сейчас.
Достарыңызбен бөлісу: |