Вопрос: Почему предприятия, занимающиеся разработкой систем / программного обеспечения, предпочитают требования варианта использования, а не системные требования?
Сравнение:
Функциональные требования системы, как правило, определяются с помощью:
1-традиционных требований к системным требованиям
2 варианта использования (текст или схема)
Оба этих подхода пытаются использовать таким образом, чтобы обеспечить системные требования, относящиеся к системе как к «черному ящику», то есть требования не должны определять детали подсистемы.
Мне кажется, традиционные заявления должны быть отброшены,Однако я также думаю, что они хорошо подходят для системы.Я не нахожу варианты использования по своей природе как способ написания SMART или хороших требований.Они либо не атомарны, не тестируемы, не определяют или не зависят от поведения другой системы, переопределяют систему или определяют поведение подсистемы для определения взаимодействия системы.Я думаю, традиционные требования к заявлению лучше по своей атомарной природе для управления требованиями.Тем не менее, я видел, что он также подвергается критике как сложный для завершения, когда завершенный трудно приспособиться к изменениям.Я утверждаю иначе.Их может быть сложно завершить, но вы должны иметь полные требования.Вы можете не начинать с полного набора, но вы можете завершить, как вы идете.Я тоже не думаю, что им сложно адаптировать изменения.Я думаю, что в случае использования одно изменение более подвержено влиянию других частей требований.Но требования к доброму утверждению должны быть атомарными.С отслеживаемым управлением требованиями, например, любым изменением интерфейсов, можно легко указать, какие требования изменить / удалить / добавить.Вы даже можете абстрагировать свои требования от деталей интерфейса, используя символы для элементов интерфейса, чтобы повысить свою способность адаптировать изменения в интерфейсах.
ПРИМЕР:
Я хочу более подробно остановиться на следующем примере.Для простоты функциональное определение будет небольшим.
Допустим, у меня есть система, состоящая из 4 подсистем.Система1 контролирует систему2.Система2 управляет системой3 и системой4.System2 имеет возможность включения и выключения System3 и System4.Система1 отправляет сообщение1 системе2 для управления системой3.Система1 отправляет сообщение2 системе2 для управления системой4.Система, которую мне нужно определить, это system2.
Подход с использованием варианта использования:
MAIN FLOW
- system2 получает сообщение «message1» от «system1» (Альтернативное утверждение: отправка system1 »message1 "для system2.)
- system2 получает" power on system3 ".
- system2 включает" system3 "
- system2 получает сообщение" message2 "от" system1 "(Альтернативаоператор: system1 отправляет «message2» в system2.)
- system2 получает «power on system4».
- system2 включает «system4».
Alternative Flow1 (MF.2): 1. system2 получает «power off system3».2. system2 отключает «system3»
Альтернативный поток 2 (MF.4): 1. system2 получает «power off system4».2. system2 выключает «system4»
Требования оператора Shall:
REQ1: «System2» включает питание «system3», если «system1» подала «питание» включеноsystem3 "с сообщением" message1 ".
REQ2:" System2 "должна выключить" system3 ", если" system1 "применила" power3 system "с сообщением" message1 ".
REQ3:«System2» должен включить «system4», если «system1» применил «power on system4» с сообщением «message2».
REQ4: «System2» должен выключить «system4», если «system1» применен »Выключите system4 "с сообщением" message2 ".
Примечание. Я бы даже объединил REQ1 и REQ2 как одно требование, а REQ3 и REQ4 - как одно требование, поскольку они представляют собой два различных набора требований, объединение которых определяет каждыйусловие, применяемое пользовательской системой («system1»).
Я думаю, что требование должно быть четким, выполнимым, проверяемым, не противоречащим другим требованиям, ограниченным во времени, если необходимо, не определяющим поведение подсистемы, не переопределяющим, не определяющим поведение других взаимодействующих систем,определение, в каком состоянии оно выполняется.Я думаю, что требования к заявлению достаточно хороши.Вы можете просто реализовать их и просто написать простые тестовые случаи и проверить систему.
Для операторов вариантов использования, я думаю, мы должны определить, является ли каждый из шагов в основном потоке требованием, илиесли весь сценарий является одним единственным требованием.
Если каждый из шагов является требованием, то я думаю, что шаг 1,2 определяет другое поведение системы, если оно написано альтернативным способом, и они не тестируемы, так какЕдинственный способ проверить это - спросить систему, получило ли оно сообщение.шаг 3. может быть в порядке, но мы хотим, чтобы это требование было выполнено, если бы шаги 1 и 2 происходили раньше.Поскольку шаг 3 не ссылается на шаги 1 и 2, шаг 3 не может быть отдельным требованием.
Я думаю, что мы должны рассматривать все из них как одно единственное требование.Я считаю, что эта точка зрения более осуществима, но, тем не менее, я думаю, что эта точка зрения тоже имеет свои недостатки.
Тем не менее шаг 1. определяет другое поведение системы или зависит от него.Вы можете возразить иначе, сказав, что это является предварительным условием всего сценария, но в этом случае шаг 4. также определяет другое поведение системы.Я думаю, что требования не должны зависеть от того, что должны делать другие системы, а скорее определять все случаи, не зависящие от других систем.
Кроме того, поскольку вариант использования является последовательностью, теперь мы также определяем операции «power system3» перед операциями «power system4».Но в роли системного инженера это не то, что я хочу определить для system2.Система2 должна обработать, в каком порядке поступили заказы.Последовательность этих операций - чрезмерное определение и поведение подсистемы, для меня.
Я попытался сделать пример простым.Но в обширных реальных сценариях случаи использования, как правило, длинные, они должны определять ненужное поведение подсистемы, чтобы иметь возможность определять системные взаимодействия, а не атомарные, не тестируемые или генерирующие тестовые примеры не так естественны, как стребования к заявлению, которые являются атомными.Поскольку варианты использования являются длинными, они состоят из множества атомарных требований к заявлению.Если весь длинный сценарий сценария использования множества атомарных требований рассматривается как одно единственное требование, то при сбое соответствующего контрольного примера выясняется, как определить и задокументировать проблему.