Замечание о наименовании требований.

В былые времена, когда примитивные инженеры долбили бинарные деревья каменными топорами, существовал только один путь написания требований. Это был путь, по которому требования писали их праотцы, а до этого писали праотцы праотцов, и так до самых истоков цивилизации. Этот священный метод наименования требований был таков.

ТРЕБОВАНИЯ:

1. Система должна делать X.

2. Система должна делать Y.

3. Система должна делать Z, если происходит событие A...

Это было довольно просто для маленьких проектов. Но по мере того, как проект становился всё больше и больше, в этой схеме начинали возникать проблемы. Например, что произойдет, если требование станет нерелевантным? Тогда возникнут "пропавшие" требования; в списке требований могут быть разделы 1, 2, 5, 7, 12 и т. д. Наоборот, что если нужно добавить требования к программе? Если нумерация списка требований возрастает линейно, эти новые требования должны быть размещены в конце или втиснуты между существующими (требование 1.5).

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

Было разработано несколько способов для разрешения этой проблемы. Один из них заключался в группировке всех требований по различным секциям (например, "DATABASE-1", "DATABASE-2") и продолжении в них традиционной нумерации. По крайней мере, в такой схеме новое требование для базы данных DATABASE не понадобится размещать в конце общего списка требований, зато можно будет поместить его вместе с аналогичными требованиями. Также из названия можно догадаться, о чем говорит это требование.

Другой способ - использовать соответствующие аббревиатуры в названиях требований. Префиксы и суффиксы вроде "FUN-" для функциональных и "NF-" для нефункциональных являются довольно обычными.

При этом следует отметить, что еще более важно использовать одинаковый подход к наименованиям требований внутри команды!