При рассмотрении спецификации требований к каким «смертным грехам» нужно обратиться?

Question

При рассмотрении спецификации требований (которая включает функциональные, нефункциональные требования, ограничения и т. Д.), Какими бы маленькими или большими они ни были, на какие «смертные грехи» авторы должны обратить внимание?

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

Answer 1

ОК, это больше 7, но у хороших требований есть следующие атрибуты:

• Unique . Есть ли другие требования, которые похожи?
• Идентифицируемый , Может ли Требование однозначно определить? Можно ли это отследить на протяжении всего процесса разработки?
• Complete . Что-то отсутствует или забыли? Это основательно? Является ли включите все необходимое, чтобы сделать это одиноко?
• Точная . Это правильно? Правильно ли определяется Цель? Есть ли ошибки?
• Однозначный . Является описание точное и не расплывчатое? Есть ли единая интерпретация? Является это легко читать и понимать?
• Последовательная . Это описание функция написана так, чтобы это не конфликтует с другими предметами в спецификация?
• Соответствующий . Требуется ли утверждение к функции? Это дополнительный информацию, которая должна быть опущена? Это прослеживается до первоначальная потребность клиента?
• реализуемое . Может ли так быть реализовано с доступным персонал, инструменты и ресурсы в пределах указанного бюджета и график?
• Код свободной . Есть ли спецификация придерживаться определения продукта и не основной дизайн программного обеспечения, архитектура и код?
• Testable . Можно ли это проверить? Достаточно информация при условии, что тестер Можно ли создать тесты для проверки выполнения требования?
• Приоритетность . Это больше или менее важно, чем другие требования?
• Использует активный голос . Ли спецификация использовать активный голос? Пассивный голос не всегда определяет кто или что выполняет действие.
• Категоризированный . Требование логически сгруппированы с похожими требования? Возможные категории являются: поведенческие, производительность, Интерфейс, Структуры данных / Элементы, Внедрение, соответствие / качество, Оперативность (Надежность, Безопасность, Безопасность), Производный / Разработанный.

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

Answer 2

Особенности, Время, Качество - выбирайте любые два. убедитесь, что требования не налагают все три на вашу команду.

Отодвиньте требования, которые пытаются контролировать ваш процесс.

Запросите четкую расстановку приоритетов с самого начала.

Настаивайте на четких критериях приемлемости для каждого требования.

Answer 3

Отсутствующие требования - намного сложнее поймать. Разделение требований на четкие разделы (например, безопасность, производительность, стиль и т. Д.) Может облегчить выявление этого.

Answer 4

Более строгий - если возможно, укажите соответствующие допуски.

Answer 5

Создание предположений - дважды проверьте, что все, что выглядит как предположение, действительно проверено.

Answer 6

Требование не указывает, кто / что делает вещь.

"The invoice is reconciled to the purchase order."

Означает ли это, что система что-то делает или пользователь?

Answer 7

Требования, которые нелегко проверить как выполненные - измените форму, которую легче пометить как выполненную или нет при просмотре.

Answer 8

Плохо сформулированные отправления, содержащие более одного требования. Разделяйте их где-нибудь, чтобы сделать их более четкими и удобными для галочки, как сделано.

Answer 9

Двусмысленные требования плохие.

Не поддающиеся проверке и не поддающиеся количественному определению требования удваиваются.

Answer 10

Худший, который я видел в проекте, для которого я кодировал: -

The system shall interface to SAP as required.

Во-первых, требование «как требуется» в нем глупо. Эта одна строка должна стоить 400 тысяч долларов. Клиент продолжал указывать на это и говорить, что там говорится, что вы собираетесь делать бла, бла, бла.