9. Взаимосвязь между пользовательскими историями (User Stories), вариантами и сценариями использования (uCs) и спецификацией требований.
Конечно, для разработки функциональных требований к системе мы пишем целый набор Use Case, учитывающих цели пользователей нескольких ролей. Этот набор позволяет обеспечить полноту требований пользователей к системе. Набор Use Case является набором требований более высокого уровня абстракции, чем набор отдельных функциональных требований, и в то же время полностью покрывает пользовательские требования к функциональности. Поэтому он более удобен в работе.
Пользовательские истории отличаются от вариантов использования и традиционных системных требований более повествовательным характером. Они предназначены для описания пожеланий пользователя в плане его возможностей. Кроме того, пользовательские истории фокусируют свое внимание скорее на ценности, полученной от использования системы, чем на детализированной спецификации ее возможностей.Пользовательские истории часто называют метафорой для работы, выполняемой системой. Целью является фиксация как можно большего количества информации
10. Методы выявления и ранжирования заинтересованных сторон. Выявление потребностей (нужд) заинтересованных сторон. Виды потребностей. Выявление требований заинтересованных сторон. Виды требований.
Матрица анализа заинтересованных лиц — это способ определить круг людей, так или иначе участвующих в проекте, а также воздействие, которое они могут на него оказывать, по двум ключевым факторам: влияние и заинтересованность. Матрица заинтересованных лиц поможет вам понять, кто и в какой степени влияет на проект, а также кто и насколько заинтересован в вашей работе. Это позволит эффективно обмениваться информацией со всеми заинтересованными лицами проекта самым подходящим способом.
11. Типовой процесс для инженерии требований. Разработка систем. Контекст типового процесса и его информационная модель. Типовой процесс инженерии требований
• Концепция процесса разработки систем начинается с обсуждения способа, которым разрабатываются системы. Это позволяет определить шаблон разработки, который может быть использован в самых разных ситуациях.
• Этот шаблон представлен в виде типового процесса и описан достаточно подробно. Далее будет показано, как можно применять этот типовой процесс для достижения конкретных целей.
Основные положения типовых процессов разработки требований
• Первоначально разрабатываются требования в идеальных условиях. Это позволяет согласовать требования с заказчиками. Также на данном этапе разрабатываются модели, благодаря которым возможно согласовать стратегии проверки соответствия для поставщиков
• Разработка требований в контексте изменений. После введения жестких ограничений, максимально стараются исключить изменения и дополнения по желанию ЗC без запроса на изменения.
Разработка системы
1. Получение потребностей ЗC
2. Разработка требований ЗC
3. Разработка требований к системе в целом
4. Разработка проектных решений по системе в целом
5. Разработка проектных решений по подсистемам
Процесс разработки системы
В контексте типового процесса ранее упоминались следующие типы информации:
исходные требования;
производные требования;
стратегия проверки соответствия для исходных требований;
стратегия проверки соответствия для производных требований;
запрос на внесение изменения.
Информационная модель тпрт
Соединительные линии между символами класса показывают отношения между классами, которые в UML называются ассоциациями (associations). Таким образом, исходное требование может быть связано с производным требованием отношением «удовлетворяется». Подобным образом производное требование может быть связано с исходным требованием отношением «удовлетворяет». (Эти метки в UML носят название «роли» (roles)). Звёздочка показывает, что данная ассоциация может содержать ноль или более экземпляров связываемого класса. Звёздочки на обоих концах линий означают, что данная ассоциация является отношением типа многие ко многим. Таким образом, для модели, показанной на рисунке, ноль или более исходных требований могут быть удовлетворены производным требованием, а некоторое исходное требование может быть удовлетворено нулевым или большим количеством производных требований. Здесь может возникнуть вопрос о целесообразности нулевого значения нижней границы, ведь оно предполагает отсутствие необходимости в какой-либо ассоциации. Но если установить значение нижней предельной границы равным 1, то это будет означать, что исходное требование не может существовать, если оно не связано, по крайней мере, с одним производным требованием. Очевидно, что это невозможная ситуация. Существенно то, что исходные требования могут существовать до определения производных требований. Следовательно, это корректная модель, поскольку иногда на протяжении проекта может иметь место отсутствие связей между исходными требованиями и производными требованиями, например на раннем этапе разработки, до установления каких-либо связей вообще. Но руководитель проекта должен стремиться к тому, чтобы эти связи были установлены как можно быстрее. Это наглядно демонстрирует прогресс в разработке, а также то, что все производные требования обоснованы, поскольку удовлетворяют исходному требованию, и наоборот, что все исходные требования были удовлетворены.
Каждый класс стратегии проверки соответствия предназначен для определенного типа требований, а стратегия проверки соответствия для производных требований может предоставить более подробную информацию о проверке соответствия исходных требований. Например, подобная ситуация возникает в системах с чрезвычайно высокими требованиями к безопасности, когда необходимо осуществлять детальный контроль на низких уровнях, чтобы обеспечить соответствие критериям проверки соответствия на более высоком уровне.