Другие подходы к формулированию требований

Рассмотренный подход к формулированию функциональных требований не является единственным. Например, Алистер Коберн предлагает другой подход, основанный на следующих основных понятиях [43, с. 2—3]:

• • действующее лицо — кто-то (или что-то), обладающее поведением;
• • участник — кто-то (или что-то), проявляющий интерес к поведению проектируемой системы;
• • основное действующее лицо — участник, который может инициировать взаимодействие с системой для достижения некоторых целей;
• • вариант использования — «…описывает поведение системы при ее ответах на запрос одного из участников» [43, с. 1]. По сути, представляет собой сценарий взаимодействия пользователя с системой;
• • область действия — проектируемая система;
• • предусловия и гарантии — то, что должно быть истинным до и после реализации варианта использования;
• • основной сценарий — стандартный вариант решения (основной вычислительный процесс), при котором не возникает никаких ошибок;
• • расширения — возможные отклонения решения (возможные разветвления основного вычислительного процесса), возникающие в зависимости от выполнения определенных условий в ходе решения, которые «нарушают» стандартный вариант его исполнения и поэтому должны предусматривать нестандартные процедуры обработки.

На рис. 2.11 показан пример описания варианта использования с применением перечисленных понятий.

Дин Леффингуэлл и Дон Уидриг, рассматривая вопросы, касающиеся принципов работы с требованиями к ПО, используют следующие понятия [50].

«Требование — возможность, которую должна обеспечивать система» [50, с. 41].

«Управление требованиями — это систематический подход к выявлению, организации и проектированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющей проект группе по поводу меняющихся требований к системе» [50, с. 42].

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

Рис. 2.11. Пример описания варианта использования [43, с. 6].

«Функция — это предоставляемое системой обслуживание для удовлетворения одной или нескольких потребностей заинтересованных лиц» [50, с. 41]. После определения совокупности функций, согласованных с клиентом, появляется возможность конкретизации требований, которые будут и интегрированы в проектные решения, и доведены до программной реализации.

«Прецедент (вариант использования, use case) описывает последовательность выполняемых системой действий, дающих клиенту некий полезный результат» [50, с. 41].

Графически данные понятия можно представить в виде пирамиды (рис. 2.12).

В работе [86] рассматриваются такие особенности требований, как:

• • ключевые требования;
• • атрибуты требований;
• • связанность и согласованность требований;

• • важность требований;
• • непротиворечивость требований;
• • стилистика изложения требований;
• • шаблоны требований;
• • детализация требований.

Рис. 2.12. Зависимость потребностей пользователя к проектируемой систем, функций системы и программных требований [50, с. 47]

В той же работе [86] приводится схема описания требований (примеры приведены на рис. 2.13) и пример шаблона для написания требований (рис. 2.14). По мнению авторов, шаблон «…является хорошим способом стандартизации языка, применяемого для разработки требований. При этом для того, чтобы иметь возможность писать стандартным способом требования различных типов, необходимо просто собрать определенный набор таких шаблонов. В процессе применения этого набора на практике он может уточняться, расширяться и корректироваться с тем, чтобы получить более полный набор шаблонов, который в дальнейшем может даже использоваться и в других проектах» [86, с. 95].

Рис. 2.13. Примеры схем для формулирования требований [86, с. 92—93].

Рис. 2.14. Глобальные шаблоны [86, с. 95].

Карл Вигерс и Джой Битти [6] в главе «Как понять требования пользователей» рассматривают такие понятия, как:

• • варианты использования;
• • сценарии использования;
• • предварительные и выходные условия;
• • функциональные требования;
• • пользовательские истории.

На рис. 2.15, 2.16 приведены примеры, иллюстрирующие понятия «варианты использования» и «пользовательские истории».

Другие примеры вариантов использования можно посмотреть в работе [6, с. 685—690].

При выявлении требований возможны различные проблемы, например, [6, с. 659—664]:

• • недостаточно активное участие представителей заказчика;
• • недостаток исходной информации, который «провоцирует» разработчиков делать большое количество допущений о реализуемых функциях, что может «идти вразрез» с реальными требованиями;
• • недостаточная компетентность представителей от заказчика;
• • невозможность для заказчика сформулировать требования даже в упрощенном виде. Это приводит к тому, что требования могут быть ограничены, вообще отсутствовать или не соответствовать действительности;
• • менеджер проекта или бизнес-аналитик не знают, кто является пользователем будущей системы, т. е. кому будет предназначен конечный программный продукт;
• • слишком много людей от разных подразделений вовлечено в выявление требований, что может приводить к противоречивости требований и большому объему информации, трудно поддающейся упорядочению и структуризации.

Рис. 2.15. Примеры вариантов использования в различных приложениях

[6, с. 167—168].

Рис. 2.16. Примеры вариантов использования и соответствующих пользовательских историй [6, с. 168—169].

Также могут появиться проблемы, связанные с анализом требований [6, с. 664—668]:

• • указаны ненужные требования;
• • не все реализуемые функции будут использоваться в действительности;
• • проявление «самодеятельности» разработчиком, который добавляет функциональность, не согласованную с заказчиком;
• • изменение приоритетов в требованиях и неумение их правильно ранжировать;
• • некорректная формулировка требований, не позволяющая составить тесты для их проверки;
• • невозможность для бизнес-аналитиков сопоставить новые требования с теми, которые уже были сформулированы ранее;
• • неверное толкование требований разработчиком и др.

Кроме этих двух типов проблем процесс формулирования требований может сопровождаться еще и проблемами, которые связаны:

• • со спецификацией требований [6, с. 669—670];
• • с утверждением требований [6, с. 670—671];
• • с управлением требованиями [6, с. 672];
• • с управлением изменениями [6, с. 672—677].

Обобщая различные подходы к формулированию требований к проектируемой АСОИУ, можно заключить, что все они похожи по сути и отражают пользовательские роли, алгоритм преобразования входной информации в выходную и совокупность особенностей, обусловливающих программную реализацию такого преобразования.

Процесс разработки требований должен заканчиваться процедурой их утверждения, суть которой заключается в том, чтобы удостовериться в следующем [6, с. 392]:

• • в спецификации требований описаны все предполагаемые функциональные возможности системы с точки зрения всех потенциальных пользователей;
• • требования точно отражают: бизнес-требования, системные требования, бизнес-правила и другие особенности, которые должны быть учтены в разрабатываемом ПО;
• • все требования должны быть полными по сути, реализуемыми и проверяемыми;
• • объем требований должен быть необходимым и достаточным для достижения целей функционирования проектируемой системы;
• • все логически зависимые требования должны быть согласованы друг с другом.

В случае возникновения спорных вопросов возможно проведение экспертизы требований с участием специалистов соответствующей предметной области. Для упрощения и оптимизации их работы предлагается перечень дефектов, которые могут быть выявлены в процессе экспертизы [6, с. 400].