Разделы презентаций

ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ CASE- технологии

Содержание

Ключевые вопросы программной инженерииОхватывает 10 областей знаний SWEBOK:Software requirements – программные требованияSoftware design – дизайн (архитектура) Software construction – конструирование программного обеспечения Software testing – тестирование Software maintenance – эксплуатация (поддержка)

Слайды и текст этой презентации

Слайд 1ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ CASE-технологии
Лекция _3_4
Ключевые дисциплины программной инженерии.
Дисциплина Требования (Software Requirements).
Управление требованиями

(Requirements management).
Виды требований и их определение (Definition of a Software

Requirement).
Процессы работы с требованиями (Requirements Process).
Спецификация требований (Requirements Specification).
Извлечение требований (Requirements Elicitation).
Пирамида Требований.
Анализ требований (Requirements Analysis). Характеристики «хорошего» Требования.
Техники извлечение требований.
Инженерия требований.




ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ CASE-технологииЛекция _3_4Ключевые дисциплины программной инженерии.Дисциплина Требования (Software Requirements).Управление требованиями (Requirements management).Виды требований и их определение

Слайд 2Ключевые вопросы программной инженерии
Охватывает 10 областей знаний SWEBOK:
Software requirements –

программные требования
Software design – дизайн (архитектура)
Software construction – конструирование

программного обеспечения
Software testing – тестирование
Software maintenance – эксплуатация (поддержка) программного обеспечения
Software configuration management – конфигурационное управление
Software engineering management – управление в программной инженерии
Software engineering process – процессы программной инженерии
Software engineering tools and methods – инструменты и методы
Software quality – качество программного обеспечения

3

Ключевые вопросы программной инженерииОхватывает 10 областей знаний SWEBOK:Software requirements – программные требованияSoftware design – дизайн (архитектура) Software

Слайд 3Ключевые вопросы программной инженерии
4

Ключевые вопросы программной инженерии4

Слайд 4Дисциплина Требования (Software Requirements)
5

Дисциплина Требования (Software Requirements) 5

Слайд 5Стоимость внесения изменений в разрабатываемое ПО в зависимости от фазы

ЖЦ
http://cmcons.com/articles/upravlenie_trebovanijami_instrument_ibm_rational_r/rol_protsessa_upravlenija_trebovanijami_pri_razrabotke_slozhnykh_programmnykh_sistem_praktika_primenenija_metodologii_ibm_rup_i_instrumenta_ibm_rational_requisitepro/
Дисциплина Требования
6

Стоимость внесения изменений в разрабатываемое ПО в зависимости от фазы ЖЦhttp://cmcons.com/articles/upravlenie_trebovanijami_instrument_ibm_rational_r/rol_protsessa_upravlenija_trebovanijami_pri_razrabotke_slozhnykh_programmnykh_sistem_praktika_primenenija_metodologii_ibm_rup_i_instrumenta_ibm_rational_requisitepro/Дисциплина Требования6

Слайд 6Вспомним определения объекта к которому предъявляются требования:

информационно-вычислительная система (программно-технический комплекс):

совокупность данных (баз данных) и программ, функционирующих на вычислительных средствах

как единое целое для решения определенных задач [ГОСТ Р 53622-2009].
программный продукт (software product): набор компьютерных программ, процедур и возможно связанной документации и данных. [ИСО/МЭК 90003:2004. Техника программного обеспечения. Рекомендации по применению ИСО 9001:2000 к компьютерному программному обеспечению, стадия пересмотра 90.20]

7

Дисциплина Требования

Вспомним определения объекта к которому предъявляются требования:информационно-вычислительная система (программно-технический комплекс): совокупность данных (баз данных) и программ, функционирующих

Слайд 7Дисциплина Требования
8

Дисциплина Требования8

Слайд 8Откуда берутся ошибки в требованиях:
Требования связаны между собой и с

другими артефактами проекта – их нельзя анализировать по одному, а

приходится анализировать сразу группу взаимосвязанных требований.
Требования часто относятся к нескольким функциональным областям сразу – их трудно группировать.
Требования разнообразны по значимости (обязательность, риск, важность, стабильность); традиционная группировка по функциям оказывается неоднозначной.
Трудно отслеживать влияние изменившихся требований на другие.
Требования изменяются в процессе жизненного цикла создания ПО.

Снизить трудоемкость процесса и повысить качество управления требованиями позволяют ПП (IBM Rational RequisitePro).

Управление требованиями

9

Откуда берутся ошибки в требованиях:Требования связаны между собой и с другими артефактами проекта – их нельзя анализировать

Слайд 910
ПП, поддерживающие процессы управления требованиями позволяют:
Управлять сложностью за счет подробных

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

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

Управление требованиями

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

Слайд 10Вспомним, что мы:
разработчик (developer): Организация, которая выполняет разработку задач (в

том числе анализ требований, проектирование, приемочные испытания) в процессе жизненного

цикла [ГОСТ ISO 9000-2011].
Работаем в рамках:
проект (project): Попытка действий с определенными начальными и конечными сроками, предпринимаемая для создания продукта или услуги в соответствии с заданными ресурсами и требованиями [ГОСТ Р ИСО/МЭК 12207-2010].
проект (project): Уникальный процесс, состоящий из совокупности скоординированных и управляемых видов деятельности с начальной и конечной датами, предпринятый для достижения цели, соответствующей конкретным требованиям, включающий ограничения по срокам, стоимости и ресурсам [ГОСТ ISO 9000-2011].

11

Вспомним, что мы:разработчик (developer): Организация, которая выполняет разработку задач (в том числе анализ требований, проектирование, приемочные испытания)

Слайд 11Проект организован согласно ЖЦ:

жизненный цикл (life cycle): Развитие системы, продукта,

услуги, проекта или других изготовленных человеком объектов, начиная со стадии

разработки концепции и заканчивая прекращением применения [ГОСТ ISO 9000-2011].
модель жизненного цикла (life cycle model): Структура процессов и действий, связанных с жизненным циклом, организуемых в стадии, которые также служат в качестве общей ссылки для установления связей и взаимопонимания сторон [ГОСТ ISO 9000-2011].

12

Проект организован согласно ЖЦ:жизненный цикл (life cycle): Развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов,

Слайд 12Виды требований и их определение (Definition of a Software Requirement)
Стандарт ISO

дает наиболее общее и полное определение:
требование: установленная или типично

предполагаемая потребность или ожидание [ГОСТ ISO 9000-2011Системы менеджмента качества. Основные положения и словарь].
определенное требование: Установленная потребность или ожидание [ГОСТ ISO 9000-2011].

IEEE Standard Glossary of Software Engineering Terminology (1990) определяет требования как:
1. условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам
3. документированное представление условий или возможностей для п. 1 и 2

13

Виды требований и их определение (Definition of a Software Requirement)Стандарт ISO дает наиболее общее и полное определение:

Слайд 13требования могут выражаться в форме потребностей, пожеланий, требований, ожиданий и

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

терминах модели (текстовой или формализованной), ориентированной на цели и поведение системы и описывающей ее в контексте среды и условий функционирования [ГОСТ Р ИСО/МЭК 12207-2010].

проектирование: процесс, который преобразовывает требования в набор характеристик продукта [ГОСТ Р ИСО/МЭК 12207-2010].

14

Виды требований и их определение

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

Слайд 1415
Виды требований и их определение

15Виды требований и их определение

Слайд 1516
Виды требований и их определение

16Виды требований и их определение

Слайд 16Требования к продукту охватывают требования как пользователей (внешнее поведение системы),

так и разработчиков (некоторые скрытые параметры). Термин пользователи относится ко

всем заинтересованным лицам в создании системы.
Требования к продукту и процессу (Product and Process Requirements) – проводится разграничение соответствующих требований как свойств продукта, который необходимо получить, и процесса, с помощью которого продукт будет создаваться.

Например, ряд требований может быть заложен неявно и программные требования могут порождать требования к процессу, например: выбор платформы J2EE (Java 2 Enterprise Edition) и ее реализации в виде конкретного сервера приложений практически наверняка потребует применения модульного тестирования (Unit testing) как практики процесса разработки и JUnit, как инструмента реализации этой практики.

17

Виды требований и их определение

Требования к продукту охватывают требования как пользователей (внешнее поведение системы), так и разработчиков (некоторые скрытые параметры). Термин

Слайд 17Чаще всего, для описания комплексных проектов (в части требований) используется

три основных документа (спецификации):
определение системы (system definition);
системные требования

(system requirements)
программные требования (software requirements).
Системные требования и программные требования (System Requirements and Software Requirements) следует различать, основываясь на определении информационной системы:

18

информационная система – это «комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы.
Таким образом, подразумевается, что информационная система является более ёмким понятием, чем программное обеспечения и включает окружение, в котором функционирует ПО, как таковое; отсюда, естественным образом, вытекают требования к системе в целом и программному обеспечению (или программной системе), в частности.

Виды требований и их определение

Чаще всего, для описания комплексных проектов (в части требований) используется три основных документа (спецификации): определение системы (system

Слайд 1819
1 уровень:
1. Системные требования (System Requirements) – иногда классифицируются

как составная часть группы функциональных требований.
Описывают высокоуровневые требования к

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

2 уровень:
2. Программные требования (Software Requirements) – это «свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач».

Виды требований и их определение

191 уровень: 1. Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований. Описывают

Слайд 193 уровень:
1. Группа функциональных требований состоит из следующих видов:
потребности

(needs) – отражают проблемы бизнеса, персоналии или процесса, которые должны

быть соотнесены с использованием или приобретением системы;
бизнес требования (business requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемой ПС. Бизнес требования формулируют в документе об образе и границах проекта — уставе проекта (project charter), или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами расползания границ.
пользовательские требования (user requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой ПС. Эти требования часто представляют в виде вариантов использования (Use Cases);
функциональные требования (Functional Requirements) – определяют функциональность (поведение) системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.

20

3 уровень:1. Группа функциональных требований состоит из следующих видов: потребности (needs) – отражают проблемы бизнеса, персоналии или

Слайд 203 уровень:
2. Группа нефункциональных требований (non-functional requirements) включает в

себя:
бизнес-правила (business rules) – включают или связаны с корпоративными регламентами,

политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. Бизнес правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности.

Business Rules Group дает понимание бизнес-правила, как «положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса».
Бизнес правила определяют распределение ответственности в системе, отвечая на вопрос «кто будет осуществлять конкретный вариант, сценарий использования» или диктуют появление некоторых функциональных требований. В контексте дисциплины управления проектами такие правила обладают высокой значимостью и, именно они, часто определяют ограничения проектов, для автоматизации которых создается соответствующая ПС;

21

3 уровень: 2. Группа нефункциональных требований (non-functional requirements) включает в себя:бизнес-правила (business rules) – включают или связаны

Слайд 21внешние интерфейсы (external interfaces) – конкретизация аспектов взаимодействия с другими

системами, операционной средой (например, запись в журнал событий операционной системы),

возможности мониторинга при эксплуатации – все это не столько функциональные требования к которым ошибочно приписывают иногда такие характеристики, сколько вопросы интерфейсов;
атрибуты качества (quality attributes) – описывают дополнительные характеристики продукта в различных «измерениях», важных для пользователей и/или разработчиков. Атрибуты касаются например вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности или устойчивости;
ограничения (constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных) которые, в свою очередь, могут относиться, например, к внешним интерфейсам.

22

Виды требований и их определение

внешние интерфейсы (external interfaces) – конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал

Слайд 22Классификация требований (Requirements Classification)
Уровни требований по Вигерсу
23
Виды требований и

их определение

Классификация требований (Requirements Classification)Уровни требований по Вигерсу 23Виды требований и их определение

Слайд 23Дополнительно требования следует определить как:
квалификационное требование (qualification requirement): Совокупность критериев

или условий, которые должны быть удовлетворены для того, чтобы квалифицировать

программный продукт как соответствующий спецификациям и готовый для применения в заданном окружении или интеграции с системой, для которой он предназначен [ГОСТ Р ИСО/МЭК 12207-2010];

квалификация (qualification): Процесс демонстрации, определяющий, способен ли какой-либо объект полностью удовлетворять заданным требованиям [ГОСТ Р ИСО/МЭК 12207-2010];

гарантия качества (quality assurance): Все запланированные и систематические действия, выполняемые в рамках системы качества и продемонстрированные надлежащим образом для обеспечения соответствующей уверенности в том, что объект полностью удовлетворяет требованиям к качеству [ГОСТ Р ИСО/МЭК 12207-2010].

24

Виды требований и их определение

Дополнительно требования следует определить как:квалификационное требование (qualification requirement): Совокупность критериев или условий, которые должны быть удовлетворены для

Слайд 24Цель процесса определения требований правообладателей состоит в выявлении требований к

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

и иным заинтересованным лицам в заданной эксплуатационной среде [ИСО/МЭК 15288:2007] .

Разработка требований – процесс выявления, формулирования, анализа, документирования и верификации требований, подлежащих выполнению в продукте [ИСО/МЭК 15288:2007].
В ходе разработки требований системный аналитик формирует реестр требований, который ложится в документ или автоматизированную систему управления требованиями.

Процессы работы с требованиями
(Requirements Process)

23

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

Слайд 25Процессы работы с требованиями
Начальным этапом разработки ПО ИС является технический

процесс определения требований правообладателей цель которого состоит в выявлении требований

к системе, выполнение которых может обеспечивать предоставление услуг, необходимых пользователям и другим правообладателям в заданной среде применения [ГОСТ Р ИСО/МЭК 12207-2010].

Результаты процесса определения требований правообладателей:
требуемые характеристики и условия использования услуг;
ограничения для системных решений;
возможность прослеживания от требований правообладателей к правообладателям и их потребностям; основа для определения системных требований;
основа для валидации соответствия услуг;
основа для ведения переговоров и заключения соглашений о поставке услуги или продукции [ГОСТ Р ИСО/МЭК 12207-2010].

26

Процессы работы с требованиямиНачальным этапом разработки ПО ИС является технический процесс определения требований правообладателей цель которого состоит

Слайд 26Процессы работы с требованиями
Цель анализа системных требований состоит в

преобразовании определенных требований правообладателей в совокупность необходимых системных технических требований,

которыми будут руководствоваться в проекте системы [ГОСТ Р ИСО/МЭК 12207-2010].

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

27

Процессы работы с требованиями Цель анализа системных требований состоит в преобразовании определенных требований правообладателей в совокупность необходимых

Слайд 27На начальном этапе можно считать, что:
требование (requirement): потребность или ожидание,

которое установлено, обычно предполагается или является обязательным [ГОСТ ISO 9000-2011],

а также:
требование (requirement): документально изложенный критерий, который должен быть выполнен, если требуется соответствие документу, и по которому не разрешены отклонения [ГОСТ ISO 9000-2011].
И следует помнить, что:
качество (quality): степень соответствия совокупности присущих характеристик требованиям [ГОСТ ISO 9000-2011].

Процессы работы с требованиями

28

На начальном этапе можно считать, что:требование (requirement): потребность или ожидание, которое установлено, обычно предполагается или является обязательным

Слайд 28Определимся, что:
заинтересованная сторона (interested party): лицо или группа лиц, заинтересованных

в деятельности или успехе организации [ГОСТ ISO 9000-2011].
правообладатель (stakeholder): лицо

или организация, имеющие право, долю, требование или интерес в системе или в обладании ее характеристиками, удовлетворяющими ее потребности и ожидания [ГОСТ Р ИСО 12207-2010].
анализ (review): деятельность, предпринимаемая для установления пригодности, адекватности и результативности рассматриваемого объекта для достижения установленных целей [ГОСТ ISO 9000-2011].
проектирование и разработка (design and development): совокупность процессов, переводящих требования в установленные характеристики или спецификации на продукцию, процесс или систему [ГОСТ ISO 9000-2011].

Процессы работы с требованиями

29

Определимся, что:заинтересованная сторона (interested party): лицо или группа лиц, заинтересованных в деятельности или успехе организации [ГОСТ ISO

Слайд 29Документирование требований (Requirements Elicitation) в соответствии с:
спецификация (specification): документ ,

устанавливающий требования [ГОСТ ISO 9000-2011].
конструкторский документ: документ, описывающий состав, структуру,

алгоритмы обработки данных и методы их реализации, правила функционирования и применения информационно-вычислительной системы и ее составных частей, предназначенный для разработчика на всех стадиях жизненного цикла [ГОСТ Р 53622-2009].
задание на выполнение работы (statement of work): документ, используемый приобретающей стороной как средство для описания и конкретизации задач, которые должны быть выполнены по условиям контракта [ГОСТ 12207-2010].
техническое задание: Организационно-распорядительный документ, содержащий технические требования к информационно-вычислительной системе и порядку ее создания [ГОСТ Р 53622-2009].

Процессы работы с требованиями

30

Документирование требований (Requirements Elicitation) в соответствии с:спецификация (specification): документ , устанавливающий требования [ГОСТ ISO 9000-2011].конструкторский документ: документ,

Слайд 30Документирование требований (Requirements Elicitation) в соответствии со спецификацией требований (Requirements

Specification):
Определение системы (System Definition Document)
Спецификация системных требований (System Requirements

Specification)
Спецификация программных требований (Software Requirements Specification - SRS)

Процессы работы с требованиями

31

Документирование требований (Requirements Elicitation) в соответствии со спецификацией требований (Requirements Specification):Определение системы (System Definition Document) Спецификация системных

Слайд 31Главная парадигма:
ориентация на потребителя: Организации зависят от своих потребителей, и

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

требования и стремиться превзойти их ожидания [ГОСТ ISO 9000-2011 Системы менеджмента качества. Основные положения и словарь].

удовлетворенность потребителей (customer satisfaction): Восприятие потребителями степени выполнения их требований [ГОСТ ISO 9000-2011].

Извлечение требований (Requirements Elicitation)

32

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

Слайд 32Таким образом на первом этапе определяющими являются:


идентификация заинтересованных лиц, их

взаимодействия, выполняемые ими бизнес-процессов.
вопросы сбора требований как с точки зрения

организации процесса, так и определения источников, откуда поступают требования.

Извлечение требований

33

Таким образом на первом этапе определяющими являются:идентификация заинтересованных лиц, их взаимодействия, выполняемые ими бизнес-процессов.вопросы сбора требований как

Слайд 33Пирамида Требований
В зависимости от формата, источника и общих характеристик, требования

могут быть разделены на различные типы.

Несколько типов требований, наиболее часто

использующихся в проектах:
Потребность заинтересованного лица: требование от заинтересованного лица.
Функциональная особенность: предоставляемая системой функциональность, обычно формулируемая бизнес-аналитиком; назначение особенности – удовлетворить потребности заказчика.
Сценарий (использования (Use Case)): описание поведения системы в терминах последовательности действий.
Дополнительное требование: другое требование, обычно нефункциональное, которое не может быть охвачено сценариями использования.
Тестовые сценарии (Test Cases): спецификация тестовых исходных данных, условий выполнения и ожидаемых результатов.
Сценарий (Scenario): особая последовательность действий – алгоритм, «определенный путь» реализации сценария использования.

Адаптация методики IEEE 830-1998

34

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

Слайд 34Пирамида Требований
35

Пирамида Требований35

Слайд 35Потребности заинтересованного лица (Регистратура) – требование от заинтересованного лица:
запись

на прием;
обслуживание пациентов в ЛПУ;
ведение нормативно-справочной информации в регистратурах ЛПУ;
планирование

работы кабинетов и врачей;
поиск и регистрация пациентов;
закрепление пациента за участком;
подготовка выходных отчетных форм.

Пирамида Требований

Потребности заинтересованного лица (ЛПУ) – требование от заинтересованного лица:
создание, редактирование и прочие виды обработки информации;
регистрацию и ведение учета записи пациентов на прием;
выработку оптимальных технологических маршрутных схем движения документов;
организацию хранения информации;
обмен информацией между подразделениями ЛПУ;
формирование отчетов.

36

Потребности заинтересованного лица (Регистратура) – требование от заинтересованного лица: запись на прием;обслуживание пациентов в ЛПУ;ведение нормативно-справочной информации

Слайд 36Пирамида Требований
Функциональная особенность – предоставляемая системой функциональность (Регистратура):
Для «Ведение нормативно-справочной

информации в регистратурах ЛПУ» :
ведение справочника врачей (медицинского персонала ЛПУ);
календарное

планирование расписание работы врачей ЛПУ (с возможностью создания резервных зон);
оперативное планирование расписание работы врачей ЛПУ;
кабинеты ЛПУ.

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

37

Пирамида ТребованийФункциональная особенность – предоставляемая системой функциональность (Регистратура):Для «Ведение нормативно-справочной информации в регистратурах ЛПУ» :ведение справочника врачей

Слайд 37Пирамида Требований
38

Пирамида Требований38

Слайд 38Сценарий реализации для Предоставления доступа пользователя (пациента) к подсистеме записи

на прием к врачу в случае успешной авторизации на web-сайте:
после

подтверждения пользователем введенных данных автоматически выполняется запрос в БД ФОМС на проверку полиса ОМС по параметрам «серия, номер, срок действия полиса ОМС + ФИО», ответ на запрос поступает в режиме реального времени;
если проверка полиса ОМС не пройдена, пользователь получает сообщение электронной почты о невозможности записи на прием с указанием причины отказа и предложением посещения регистратуры ЛПУ с документами, удостоверяющими личность пациента.

Дополнительные требования для Регистрации пациентов:
Список льготных категорий формируется в рамках ПК «Льготные рецепты» при загрузке реестра льготников и может отображаться в составе социально-паспортных данных пациента. Должна быть предусмотрена возможность ручного ввода льготной категории.

Пирамида Требований

39

Сценарий реализации для Предоставления доступа пользователя (пациента) к подсистеме записи на прием к врачу в случае успешной

Слайд 39Пирамида Требований
Адаптация методики IEEE 830-1998
40

Пирамида ТребованийАдаптация методики IEEE 830-199840

Слайд 40Пирамида Требований
Примечание: На верхнем уровне располагаются потребности заинтересованного лица.
На

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


Достаточно часто на разных уровнях этих требований могут быть выяснены детали различного уровня.
Чем ниже уровень, тем более детально описывается требование. Например, потребность может быть следующей: «Данные должны быть неизменными».
Функциональная особенность этого требования будет: «Система должна использовать реляционную базу данных».
На уровне дополнительных требований, требование еще более точное: «Система должна использовать базу данных Oracle».
Чем дальше вниз, тем более детальным становится требование.
Один из лучших способов управления требованиями – обобщать требования, по крайней мере, на двух различных уровнях.
Например, документ Концепция («Vision») содержит высокоуровневые требования (особенности), а низшие уровни пирамиды представляют требования на более детальном уровне.

41

Пирамида ТребованийПримечание: На верхнем уровне располагаются потребности заинтересованного лица. На последующих уровнях находятся функциональные особенности, сценарии использования

Слайд 41Анализ требований (Requirements Analysis). Характеристики «хорошего» Требования
Корректность [IEEE 830-1998], правдоподобность (реальность,

выполнимость);
Однозначность [IEEE 830-1998], недвусмысленность;
Полнота, завершенность [IEEE 830-1998];
Непротиворечивость [IEEE 830-1998];
Упорядочивание по

значимости и/или устойчивости (необходимость и устойчивость) [IEEE 830-1998];
Проверяемость (тестируемость) [IEEE 830-1998];
Модифицируемость [IEEE 830-1998];
Отслеживаемость [IEEE 830-1998];
В дополнение к методике:
Понятность;
Независимость;
Элементарность;
Независимость от реализации (абстрактность).

Адаптация методики IEEE 830-1998

42

Анализ требований (Requirements Analysis). Характеристики «хорошего» ТребованияКорректность [IEEE 830-1998], правдоподобность (реальность, выполнимость);Однозначность [IEEE 830-1998], недвусмысленность;Полнота, завершенность [IEEE

Слайд 42Корректность - каждое требование является требованием, которому должно удовлетворять программное

обеспечение [IEEE 830-1998].
Если требование содержит факты, эти факты должны быть

достоверны.
 
Треб. для подготовки выходных отчетных форм:
а) амбулаторная карта должна быть в соответствии с установленной учетной формой № 25/у-04;
б) контрольная карта диспансерного больного по диагнозам учета должна быть в соответствии с установленной учетной формой № 30/у -04;
в) талон амбулаторного пациента должен быть в соответствии с установленной учетной формой № 025-12/у.

Характеристики «хорошего» Требования

Адаптация методики IEEE 830-1998

43

Корректность - каждое требование является требованием, которому должно удовлетворять программное обеспечение [IEEE 830-1998].Если требование содержит факты, эти

Слайд 43Однозначноcть – если и только, если каждое изложенное требование может

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

характеристика конечного продукта была описана с использованием одного уникального термина [IEEE 830-1998].
Недвусмысленность – должен существовать только один путь интерпретации требования.

В тех случаях, когда термин, используемый в специфическом контексте, может иметь множественные значения, этот термин должен быть включен в глоссарий, в котором его значение описывается более конкретно.
Примечание* «Ловушки» естественного языка: Требования часто пишутся на естественном языке. Естественный язык по существу является неоднозначным. Естественный язык SRS должен анализироваться независимой стороной с целью идентификации неоднозначного использование так, чтобы эту неоднозначность можно было скорректировать.

Характеристики «хорошего» Требования

Адаптация методики IEEE 830-1998

44

Однозначноcть – если и только, если каждое изложенное требование может интерпретироваться только однозначно. Как минимум, для этого

Слайд 44Характеристики «хорошего» Требования
Адаптация методики IEEE 830-1998
Треб.1: Система не должна принимать

пароли более 15-ти символов.

Не совсем ясно, что система должна делать.
Система

не должна позволять пользователю вводить более чем 15 символов.
Система должна отсекать введенную строку до 15-ти символов.
Система не должна отображать сообщение об ошибке, если пользователь вводит более чем 15 символов.

Исправленное требование содержит пояснение:

Треб.1: Система не должна принимать пароли более 15-ти символов. Если пользователь вводит более 15-ти символов при выборе пароля, сообщение об ошибке должно информировать пользователя о необходимом исправлении пароля.

45

Характеристики «хорошего» ТребованияАдаптация методики IEEE 830-1998Треб.1: Система не должна принимать пароли более 15-ти символов.Не совсем ясно, что

Слайд 45Характеристики «хорошего» Требования
Адаптация методики IEEE 830-1998
Однозначность: ясность (Краткость, Сжатость, Простота,

Точность)

Требования не должны содержать ненужных выражений или информации. Они должны

быть изложены кратко и просто:
 
Треб.1: Иногда пользователь будет вводить Специальность врача которую система будет распознавать.
Это предложение может быть заменено на более простое:
 
Треб.1: Система должна идентифицировать Специальность врача.

46

Характеристики «хорошего» ТребованияАдаптация методики IEEE 830-1998Однозначность: ясность (Краткость, Сжатость, Простота, Точность)Требования не должны содержать ненужных выражений или

Слайд 4647
Завершенность, полнота – если и только, если определены все следующие

элементы:
а) Все существенные требования, независимо от того, относятся ли они

к функциональным возможностям, рабочим характеристикам, проектным ограничениям, атрибутам или внешним интерфейсам. В частности, должны быть подтверждены и обработаны любые внешние требования, налагаемые спецификацией системы.
б)Определение откликов ПО на все классы входных данных, которые могут быть реализованы, во всех возможных ситуациях. Следует заметить, что важно определить отклики, как на допустимые, так и недопустимые входные значения.
в)Полные обозначения и ссылки на все рисунки, таблицы и схемы в SRS и определение всех терминов и единиц измерения [IEEE 830-1998].
Примечание* Условия TBD – «должно быть определено»:
Требования к характеристикам взаимосвязей со смежными системами:
Треб. Должно обеспечиваться взаимодействие АИС с внешними системами в рамках:
а) получения:
1) данных о полисах ОМС пациентов в БД ФОМС;
2) данных о льготах пациентов в БД Управления социальной защиты.
б) передачи в БД ЛПУ информации о реестре талонов пациентов.
Смежные системы:
а) ФОМС (БД);
б) Управление социальной защиты (БД).

Характеристики «хорошего» Требования

Адаптация методики IEEE 830-1998

47Завершенность, полнота – если и только, если определены все следующие элементы:а) Все существенные требования, независимо от того,

Слайд 47Непротиворечивость: внутренняя непротиворечивость и внешняя
Характеристики «хорошего» Требования
Адаптация методики IEEE 830-1998
48
Закрепление

пациента за участком должно осуществляться в двух режимах:
а) в автоматическом

- участок пациента определяется автоматически по адресу проживания;
б) в ручном - регистратор имеет возможность закрепить пациента за любым участком, выбрав его из справочника.
Непротиворечивость: внутренняя непротиворечивость и внешняяХарактеристики «хорошего» ТребованияАдаптация методики IEEE 830-199848Закрепление пациента за участком должно осуществляться в двух

Слайд 48Упорядочивание по значимости и/или устойчивости
Характеристики «хорошего» Требования
Адаптация методики IEEE 830-1998
Каждое

требование в SRS должно быть идентифицировано, чтобы сделать эти различия

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

49

Упорядочивание по значимости и/или устойчивостиХарактеристики «хорошего» ТребованияАдаптация методики IEEE 830-1998Каждое требование в SRS должно быть идентифицировано, чтобы

Слайд 49Степень устойчивости
Характеристики «хорошего» Требования
Адаптация методики IEEE 830-1998
Один метод идентификации требований

использует величину устойчивости. Устойчивость может быть выражена с точки зрения

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

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

50

Степень устойчивостиХарактеристики «хорошего» ТребованияАдаптация методики IEEE 830-1998Один метод идентификации требований использует величину устойчивости. Устойчивость может быть выражена

Слайд 50Тестируемость (Возможность Проверки)
Тестеры должны иметь возможность проверить, было ли требование

реализовано корректно.
Использование некоторых слов может сделать требование невозможным для

тестирования:
Некоторые прилагательные: устойчивый, безопасный, точный, эффективный, целесообразный, гибкий, настраиваемый, надежный, дружелюбный, адекватный.
Некоторые наречия и фразы с ними: быстро, безопасно, своевременно.
Неспецифичные слова или акронимы: и т.д., и/или, TBD (to be determined).

Треб.1: Функция поиска должна позволять пользователю искать врача на основе Фамилии, Имени, Специальности, и т.д.
В этом требовании все критерии поиска должны быть детально перечислены. Дизайнер и разработчик не могут догадаться, что пользователь имел в виду под сокращением «и т.д.».

Треб.1: Система должна препятствовать одновременному доступу большого числа пользователей.
Какое количество здесь имеется в виду под «большим числом» - 10, 100 или 1000?

Характеристики «хорошего» Требования

51

Тестируемость (Возможность Проверки)Тестеры должны иметь возможность проверить, было ли требование реализовано корректно. Использование некоторых слов может сделать

Слайд 51Понятность
Требования должны быть грамматически правильные, написаны в соответствующем стиле. Должны

быть использованы стандартные соглашения. Слово «должен» должно быть использовано вместо

«будет», «обязан» или «может».


Правдоподобность (Реальность, Выполнимость)
Требование должно быть выполнимо в рамках существующих ограничений, таких как время, деньги и доступные ресурсы.
 

Характеристики «хорошего» Требования

52

ПонятностьТребования должны быть грамматически правильные, написаны в соответствующем стиле. Должны быть использованы стандартные соглашения. Слово «должен» должно

Слайд 52Независимость
Чтобы понять требование, не нужно знать какое-либо другое требование.


Треб.1: Список доступных специалистов должен включать номер кабинета, время ФИО.
Треб.2:

Он должен быть отсортирован по времени.
Слово «Он» во втором предложении относится к предыдущему требованию. И если порядок требований изменить, это требование будет непонятно.

Характеристики «хорошего» Требования

53

Элементарность
Требование должно содержать отдельный трассируемый элемент для которого возможно отслеживание связи):
 
Треб.1: Система должна предоставлять возможность выбрать врача по участку, выбрать дату приема, забронировать талон, а также предоставлять информацию об альтернативных специалистах .
Это требование содержит несколько элементарных требований, которые затрудняют трассировку.

НезависимостьЧтобы понять требование, не нужно знать какое-либо другое требование. Треб.1: Список доступных специалистов должен включать номер кабинета,

Слайд 53Необходимость
В требовании нет необходимости, если: Ни одному заинтересованному лицу требование

не нужно. Или Удаление требования не повлияет на систему.

Пример

требования, которое не нужно заинтересованному лицу – это требование, которое добавили разработчики или дизайнеры, т.к. полагали, что оно необходимо пользователям или заказчикам. Пример требования, которое может быть удалено, т.к. оно не предоставляет никакой новой информации:
 
Треб.1: Все требования, указанные в документе Концепции должны быть реализованы и протестированы.

Характеристики «хорошего» Требования

54

НеобходимостьВ требовании нет необходимости, если: Ни одному заинтересованному лицу требование не нужно. Или Удаление требования не повлияет

Слайд 54Независимость от Реализации (Абстрактность)
Требования не должны содержать ненужной информации о

дизайне и реализации системы:

Треб.1: Информация должна храниться в текстовом

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

Характеристики «хорошего» Требования

55

Независимость от Реализации (Абстрактность)Требования не должны содержать ненужной информации о дизайне и реализации системы: Треб.1: Информация должна

Слайд 55Постоянство
Не должно существовать конфликтов между требованиями. Конфликты могут быть прямые

и косвенные. Прямые конфликты возникают, когда ожидается различное поведение системы

в одной и той же ситуации:
 
Треб.1: Дата должна отображаться в формате дд/мм/гггг.

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

В итоге это приведет к следующему требованию:
 Треб.2: Даты должны отображаться в формате, принятом в веб-браузере пользователя.

Характеристики «хорошего» Требования

56

ПостоянствоНе должно существовать конфликтов между требованиями. Конфликты могут быть прямые и косвенные. Прямые конфликты возникают, когда ожидается

Слайд 56Немногословность
Каждое требование должно быть обозначено только один раз, и не

должно перекрываться другим требованием:
 
Треб.1: Для удобства ввода даты приема в

системе должен быть доступен календарь.
Треб.2: Система должна отображать всплывающее окно с календарем при вводе любой даты.
 
Первое требование (относящееся только к дате приема) является частью второго требования (относящееся к любой дате, вводимой пользователем).

Характеристики «хорошего» Требования

57

НемногословностьКаждое требование должно быть обозначено только один раз, и не должно перекрываться другим требованием: Треб.1: Для удобства ввода

Слайд 57Завершенность
Требование должно быть описано для всех возможных условий:
 
Должно обеспечиваться взаимодействие

АИС с внешними системами в рамках:
а) получения:
1) данных о полисах

ОМС пациентов в БД ФОМС;
2) данных о льготах пациентов в БД Управления социальной защиты.
б) передачи в БД ЛПУ информации о реестре талонов пациентов.
 
Однако требования могут быть выражены в виде комбинации критериев:
Изменяемый: Если требование элементарное и немногословное, то оно обычно изменяемое.
Трассируемое: Если оно краткое и имеет уникальный идентификатор (ID), то оно обычно трассируемое (способное к отслеживанию связи).

Характеристики «хорошего» Требования

58

ЗавершенностьТребование должно быть описано для всех возможных условий: Должно обеспечиваться взаимодействие АИС с внешними системами в рамках:а) получения:1)

Слайд 58Извлечение требований
Управление требованиями – это интерактивный процесс. На типичной итерации

предполагается полное прохождение по пирамиде.
59

Извлечение требованийУправление требованиями – это интерактивный процесс. На типичной итерации предполагается полное прохождение по пирамиде. 59

Слайд 5960
ПОТРЕБНОСТИ
Определение заинтересованных лиц.
заинтересованная сторона (interested party): лицо или группа лиц,

заинтересованных в деятельности или успехе организации [ГОСТ ISO 9000-2011].
заинтересованное лицо

(stakeholder): лицо, на которое результат работы системы оказывает непосредственное влияние [Словарь RUP].
правообладатель (stakeholder): лицо или организация, имеющие право, долю, требование или интерес в системе или в обладании ее характеристиками, удовлетворяющими ее потребности и ожидания [ГОСТ Р ИСО 12207-2010].

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

Разница: пользователи приложения центра обработки вызовов (call-центра), принимающие звонки, могут предпочитать изощренный пользовательский интерфейс, даже если он требует большого времени загрузки. Заказчик (директор call-центра) может запросить простой пользовательский интерфейс, который будет быстро загружаться и позволять 60бслуживать больше звонков в минуту.

Извлечение требований

60ПОТРЕБНОСТИОпределение заинтересованных лиц.заинтересованная сторона (interested party): лицо или группа лиц, заинтересованных в деятельности или успехе организации [ГОСТ

Слайд 60Например, Заинтересованные лица для разработки АИС для ЛПУ.


Выявленные заинтересованные лица:


Заказчики: руководство ЛПУ; Пользователи: Работник регистратуры 1, Работник регистратуры 2,

Пациент, старшей возрастной группы, Пациент средней возрастной группы), представитель ИТ отдела.
Разработчики: директор ИТ компании, бизнес аналитики, системные аналитики, кодировщики, графические дизайнеры, тестеры, менеджеры проектов, менеджеры по внедрению.
Сторонние компании, вовлеченные в процесс: лица, вовлеченные в управление, настройку и сопровождение системы
«Поставщики» стандартов и регламентов.

Извлечение требований

61

Например, Заинтересованные лица для разработки АИС для ЛПУ.Выявленные заинтересованные лица: Заказчики: руководство ЛПУ; Пользователи: Работник регистратуры 1,

Слайд 61Техники извлечения требований
Интервью (индивидуальный диалог).
Анкеты (набор вопросов, отправленный большому количеству

заинтересованных лиц).
Семинары (заинтересованные лица собираются на определенный период для интенсивных,

насыщенных дискуссий).
Сценарии приложения (использование визуальных/графических инструментов для демонстрирования поведения системы).
Ролевые игры (каждому члену группы назначается определенная роль, обычно роль одного из пользователей).
Сессии с применением метода «мозгового штурма» (Мозговой штурм – групповой метод решения вопросов путем изложения идей в течение непродолжительных, интенсивных сессий).

62

Техники извлечения требованийИнтервью (индивидуальный диалог).Анкеты (набор вопросов, отправленный большому количеству заинтересованных лиц).Семинары (заинтересованные лица собираются на определенный

Слайд 62Использование прототипов (разработка прототипов).
Сценарии использования (Use Cases – взаимодействие между

пользователем и системой).
Анализ существующих документов (извлечение информации из используемых документов,

электронной почты, записей).
Наблюдение и демонстрирование задач (наблюдение за пользователями, выполняющими определенную задачу).
Анализ существующих систем (сбор требований от морально устаревших заменяемых систем или от систем, разработанных в ходе конкуренции).

Техники извлечения требований

63

Использование прототипов (разработка прототипов).Сценарии использования (Use Cases – взаимодействие между пользователем и системой).Анализ существующих документов (извлечение информации

Слайд 63Техники извлечения требований
64

Техники извлечения требований64

Слайд 6465
Техники извлечения требований

65Техники извлечения требований

Слайд 65Техники извлечения требований
66

Техники извлечения требований66

Слайд 66*Термины «потребности заинтересованного лица» и «запросы заинтересованного лица» - синонимы.


Потребности

отражают требования высшего уровня.
Например:
создание, редактирование и прочие виды обработки информации;
регистрацию

и ведение учета записи пациентов на прием;
выработку оптимальных технологических маршрутных схем движения документов;
организацию хранения информации;
обмен информацией между подразделениями ЛПУ;
формирование отчетов.

Потребностей такого уровня должно быть не более пяти от одного ЗЛ, и не более пятнадцати согласно проекту.

Техники извлечения требований

67

*Термины «потребности заинтересованного лица» и «запросы заинтересованного лица» - синонимы.Потребности отражают требования высшего уровня.Например:создание, редактирование и прочие

Слайд 67Разработка Концепции: документ Видение
Извлечение функциональных особенностей системы из потребностей

заинтересованного лица.
Концепция должна содержать главную информацию о разрабатываемой системе, как

о программном продукте:
Видение (Vision document):
Образ продукта (Product vision)
Границы (проекта) (Project scope)


*Помимо перечисления всех функциональных особенностей, этот документ должен содержать обзор системы, описание пользователей, обзор всех возможностей системы и другую информацию, которая может понадобиться для понимания назначения системы. Он также может содержать список всех потребностей ЗЛ, в случае если они не были зафиксированы в отдельных документах.

ФУНКЦИОНАЛЬНЫЕ ОСОБЕННОСТИ

68

Техники извлечения требований

ПОТРЕБНОСТИ

Разработка Концепции: документ Видение Извлечение функциональных особенностей системы из потребностей заинтересованного лица.Концепция должна содержать главную информацию о

Слайд 68Образ продукта (Product vision) выстраивает работу всех ЗЛ в одном

направлении, содержит концепцию ИС, в процессе изменяется медленно в зависимости

от изменения стратегии системы или развития бизнес целей.

Документ О1. Образ продукта (Product vision)

69

Техники извлечения требований

Задачи Заказчика:

Задачи Разработчика – бизнес цели проекта

Образ продукта (Product vision) выстраивает работу всех ЗЛ в одном направлении, содержит концепцию ИС, в процессе изменяется

Слайд 69Образ продукта (Product vision):

потребности (бизнеса) (Needs) – учитывают, прежде всего,

интересы Заказчика и определяют цель и подцели проекта (реализация социальных

проектов в рамках ПП «Электронная Россия»);
потребности (Needs) включает в себя любые проблемы, возможности и ограничения, которые имеют потенциальную ценность для заинтересованных сторон [BABOK v3].
бизнес требования (Business Requirements) – основаны на выявленных Потребностях (Needs) бизнеса, составляют высший уровень абстракции в цепи требований: определяют образ и границы всего продукта (повысить качество обслуживания пациентов);
бизнес цели проекта – учитывают, прежде всего, интересы Разработчика и заключаются в том, чтобы получить признание в качестве наиболее защищенного продукта на рынке (разработать проект АИС ЛПУ с учетом возможного тиражирования);

70

Техники извлечения требований

Образ продукта (Product vision):потребности (бизнеса) (Needs) – учитывают, прежде всего, интересы Заказчика и определяют цель и подцели

Слайд 70Документ О.1 Г1. Границы проекта. Продукт
Документ О.1 Г. 2 Границы

проекта. Масштабы и ограничения
71
Техники извлечения требований

Документ О.1 Г1. Границы проекта. ПродуктДокумент О.1 Г. 2 Границы проекта. Масштабы и ограничения71Техники извлечения требований

Слайд 711. Introduction
1.1 Business purpose
1.2 Business scope
1.3 Business overview
1.4 Definitions
1.5 Stakeholders

2.

References

3.Business management requirements
3.1 Business environment
3.2 Goal and objective
3.3 Business model
3.4

Information environment

4. Business operational requirements
4.1 Business processes
4.2 Business operational policies and rules
4.3 Business operational constraints
4.4 Business operational modes
4.5 Business operational quality
4.6 Business structure

5. User requirements

6. Concept of proposed system
6.1 Operational concept
6.2 Operational scenario

7. Project Constraints

8. Appendix
8.1 Acronyms and abbreviations

Структура документа требований [ISO/IEC/IEEE 29148:2011 Системная и программная инженерия. Процессы жизненного цикла. Разработка требований]

72

Техники извлечения требований

Введение
1.1 Бизнес-цель
1.2 Объем работы
1.3 Обзор бизнеса
1.4 Определения
1.5 Заинтересованные стороны

2. Примечания

3.Бизнес требования
3.1 Бизнес-среда
3.2 Цель и задачи
3.3 Бизнес-модель
3.4 Информационная среда

4. Операционные бизнес требования
4.1 Бизнес-процессы
4.2 Политики и правила бизнес операций
4.3 Эксплуатационные бизнес ограничения
4.4 Режимы работы
4.5 Качество бизнес операций
4.6 Структура бизнеса

5. Требования пользователей

6. Концепция системы
6.1 Требования к системе
6.2 Сценарии использования

7. Ограничения

8. Приложения
8.1 Сокращения и аббревиатура

1. Introduction1.1 Business purpose1.2 Business scope1.3 Business overview1.4 Definitions1.5 Stakeholders2. References3.Business management requirements3.1 Business environment3.2 Goal and

Слайд 72Сценарии Использования/Варианты использования (Use Cases) – отклик системы на воздействие

пользователя.
Соглашению между разработчиками, заказчиками и пользователями что именно система должна

делать - «контракт» между разработчиками и заказчиками.
Дополнительная спецификация содержит нефункциональные требования (удобство использования, надежность, производительность, способность к сопровождению).
А также некоторые функциональные требования, распространяющиеся за пределы системы, и вследствие этого, сложные для отображения в сценариях использования. Эти требования называют дополнительными требованиями. Они извлекаются из функциональных особенностей.

73

Техники извлечения требований

ДЛ: Пациент.
ВИ: Выбрать специальность врача.
Отклик: Система предоставляет список «Специальность врачей» в алфавитном порядке.

Сценарии Использования/Варианты использования (Use Cases) – отклик системы на воздействие пользователя.Соглашению между разработчиками, заказчиками и пользователями что

Слайд 731.Поток событий для ВИ .
1.1. Предусловия.
1.2. Главный поток.
1.З. Под-потоки (если

применимы).
1.4. Альтернативные потоки.
1.5. Доп. требования
Создание Тестовых Сценариев (Test Cases) (из

Сценариев Использования)

Как только все требования собраны, следует разработать способ проверить, правильно ли они реализованы в конечном продукте.
Тестовые сценарии (test cases) показывают тестерам, какие шаги должны быть сделаны для того, чтобы протестировать все требования.

Тестовые сценарии находятся на низшем уровне пирамиды.



Создание Тестовых Сценариев (Test Cases) (из Дополнительной Спецификации)

74

Техники извлечения требований

1.Поток событий для ВИ .1.1. Предусловия.1.2. Главный поток.1.З. Под-потоки (если применимы).1.4. Альтернативные потоки.1.5. Доп. требованияСоздание Тестовых Сценариев

Слайд 74Требования являются основой для проектирования системы


75

Техники извлечения требований

Требования являются основой для проектирования системы

Слайд 75Модель бизнес прецедентов
Модель вариантов использования
Модель требований
Техническое задание
SRS
Анализ требований
Тестирование
Определение требований

правообладателей
76
АНАЛИЗ и ПРОЕКТИРОВАНИЕ

Модель бизнес прецедентовМодель вариантов использованияМодель требованийТехническое заданиеSRSАнализ требований ТестированиеОпределение требований правообладателей76АНАЛИЗ и ПРОЕКТИРОВАНИЕ

Слайд 76 Техники извлечения требований
Интервью – один из наиболее распространенных методов

сбора требований.

Преимущества:
интерактивность, предоставляющая возможность внесения дополнений или доработки вопросов

в зависимости от полученных ответов;
хороший способ собрать требования по удобству использования системы, надежности, производительности и удобству сопровождения.

Недостаток:
плохо выявляются нефункциональные требования.

77

Техники извлечения требований Интервью – один из наиболее распространенных методов сбора требований.Преимущества: интерактивность, предоставляющая возможность внесения

Слайд 7778
Рекомендаций для проведения интервью:
Формирование фокус-группы (При выборе ЗЛ для интервью

убедитесь, что Вы понимаете, какую именно группу ЗЛ они представляют).
Формирование

первоначального списка вопросов.
Проговорите ответы своими словами, чтобы убедиться, что Вы понимаете смысл. Вы не должны предлагать ответ на Ваш вопрос. Например: Какое время реакции системы Вы ожидаете? Три секунды? Не соединяйте несколько вопросов в один. Например: Необходимо ли Вам печатать талон, сохранять на электронной почте или вовсе предпочитаете не иметь «на руках» талон?
На первом этапе, не спрашивайте о деталях реализации.
Не используйте слишком длинные и сложные вопросы.
Не задавайте следующий вопрос, если еще не получен ответ на предыдущий.

Техники извлечения требований

78Рекомендаций для проведения интервью:Формирование фокус-группы (При выборе ЗЛ для интервью убедитесь, что Вы понимаете, какую именно группу

Слайд 78Рекомендаций для проведения интервью:
Если ответ непонятен, задайте дополнительные вопросы, даже

если их нет в сценарии интервью.
Когда пользователи отклоняются от темы

при ответе на заданный вопрос, не перебивайте их. Позвольте им высказать свои мысли, на какую бы тему они не размышляли. Затем, если Вы не получили ответа на изначальный вопрос, задайте его снова.
Фиксируйте каждое упомянутое пользователем требование, даже если в настоящий момент оно кажется неуместным.
Спросите пользователей о дополнительной информации (экранные формы системы).
При разговоре с заказчиками не говорите о том, будет ли их требование выполнено или нет. Это будет решено позже.
В конце разговора спросите вопрос для получения дополнительной информации, например «Что еще я должен знать?».
Выясните у заинтересованного лица приоритет для каждого требования.
Делайте примечания или используйте записывающее устройство.

69

Техники извлечения требований

Рекомендаций для проведения интервью:Если ответ непонятен, задайте дополнительные вопросы, даже если их нет в сценарии интервью.Когда пользователи

Слайд 79Рекомендуемый порядок для интервьюирования:
Официальное Представление.
2. Заполнение Профиля Заинтересованного Лица

или Пользователя
Имя: Иванова Галина Петровна
Компания: ЛПУ
Должность: Работник регистратуры
Интервью:
Каковы Ваши

основные должностные обязанности?
Какие услуги Вы предоставляете? Для кого?
Каким образом определяется качество Вашей работы?
Какие проблемы препятствуют выполнению работы?
Что сделает Вашу работу легче или сложнее? …….
3. Определение Проблемы
Каие проблемы, по Вашему мнению решит автоматизация большей части работы?
Для каждой проблемы, задайте следующие вопросы:
Почему существует данная проблема?
Как Вы решаете ее сейчас?
Как бы Вы хотели решить ее?


80

Техники извлечения требований:

Рекомендуемый порядок для интервьюирования:Официальное Представление.2. Заполнение Профиля Заинтересованного Лица или ПользователяИмя: Иванова Галина ПетровнаКомпания: ЛПУДолжность: Работник

Слайд 804. Понимание Среды Пользователя
Кто является пользователем системы?
Какое у них

компьютерное образование?
Есть ли у пользователей опыт работы с приложением

данного типа?
С какими дополнительными приложениями, которые Вы используете, система может взаимодействовать?
Каковы Ваши ожидания в плане удобства использования АИС?
Какие печатные копии и он-лайн документация Вам необходимы? …

81

Техники извлечения требований

5. Обобщение для Понимания
Вы сказали мне….(перечислите своими словами список проблем, обозначенных заинтересованным лицом). Отражает ли это Ваши текущие проблемы с существующими решениями?
6. Взгляд Аналитика на Проблемы Заинтересованного Лица (утверждение или аннулирование требований)
Какие (если есть) проблемы, связанные с …. (список любых недостатков или дополнительных проблем которые, по Вашему мнению, могут беспокоить ЗЛ или пользователя). Для каждой предложенной проблемы, задайте следующие вопросы: Это реальная проблема? Каковы причины данной проблемы?
Каким образом Вы решаете эту проблему? Как бы Вы хотели решить проблему?
Каким образом Вы бы распределили по приоритету решение данных проблем по сравнению с остальными, Вами обозначенными?

4. Понимание Среды ПользователяКто является пользователем системы? Какое у них компьютерное образование? Есть ли у пользователей опыт

Слайд 817. Оценка Вашего Решения
Что если бы Вы могли….(суммирование главных возможностей

предложенного Вами решения).
Как бы Вы оценили значимость этого?
8. Оценка Возможности.
Кому

необходимо данное приложение в Вашей организации?
Насколько много пользователей данного типа будут пользоваться приложением?
Как бы Вы оценили успешное решение?
9. Определение Надежности, Производительности и Требований Сопровождения
Каковы Ваши ожидания в плане надежности?
Каковы Ваши ожидания в плане производительности?
Будете ли Вы сами осуществлять сопровождение продукта или ее будет осуществлять иные лица?
Есть ли у Вас какие-либо специальные требования к сопровождению?
Каковы требования к безопасности?
Каковы требования к установке и конфигурированию системы?
Есть ли специальные требования по лицензиям?
Каким образом будет осуществляться распространение системы?
Каковы требования к маркировке и оформлению пакета требований?
Каковы (если есть) Ваши требования к инструкциям или среде?
Должна ли осуществляться поддержка стандартов?

82

Техники извлечения требований

7. Оценка Вашего РешенияЧто если бы Вы могли….(суммирование главных возможностей предложенного Вами решения).Как бы Вы оценили значимость

Слайд 82 10. Подведение итогов.
Есть ли какие-либо другие вопросы, которые я

должен задать Вам?
Если я должен задать сопутствующие вопросы, я

могу звонить Вам?
Хотели бы Вы участвовать в обзоре требований?

11. Резюме Аналитика.
Система должна предоставлять возможность ……
Пользователь должен иметь возможность ……
Система должна следовать инструкциям по разработке установленных …..
Система должна быть доступной … в сутки с уровнем надежности, соответствующим …… приложениям.
Система должна быть разработана в течение …...
Система должна .…...

83

Техники извлечения требований

компромисс (trade-off): действия по принятию решений, в ходе которых производится выбор из различных требований и альтернативных решений на основе конечной выгоды правообладателей [ГОСТ ИСО/МЭК 15288:2007].

10. Подведение итогов.Есть ли какие-либо другие вопросы, которые я должен задать Вам? Если я должен задать

Слайд 83Анкеты наиболее полезны в случае, если у Вас есть возможность

задать одни и те же вопросы многим заинтересованным лицам, и

Вы не собираетесь задавать дополнительные вопросы в процессе беседы.

84

Техники извлечения требований

Анкеты наиболее полезны в случае, если у Вас есть возможность задать одни и те же вопросы многим

Слайд 84Техники извлечения требований
Семинары
В процессе семинара по требованиям выбранная фокус группа

ЗЛ с проектной командой. Системный аналитик выступает в качестве организатора

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

Задачи организатора
1. Перед семинаром:
Пригласите участников.
Распространите план и предварительный материал, чтобы участники могли подготовиться к встрече.
Подготовьте комнату для совещаний и необходимое оборудование (например, проектор).
2. В процессе семинара
Поручите кому-нибудь делать записи.
Ведите дискуссию в соответствии с планом.
Стимулируйте к участию в беседе всех заинтересованных лиц.
Подведите итоги семинара.
3. После семинара
Проанализируйте полученные сведения и документально оформите информацию в презентабельном виде.
Распространите результаты среди участников.
Если необходимо, назначьте дополнительные семинары по результатам.

85

Результаты семинара по требованиям должны быть документально оформлены – запросы Заинтересованных Лиц (Stakeholder Requests).

Техники извлечения требованийСеминарыВ процессе семинара по требованиям выбранная фокус группа ЗЛ с проектной командой. Системный аналитик выступает

Слайд 85Инженерия требований. Управление требованиями
Спецификация требований используется при разработке, тестировании, гарантии

качества продукта, управлении проектом и его функциями. В дополнение к

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

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

86

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

Слайд 86Инженерия требований
Управление требованиями заключается в планировании и контроле выполнения требований

и проектных ресурсов в процессе разработки компонентов системы на этапах

ЖЦ.

Качество и процесс улучшения требований – это процесс формулировки характеристик и атрибутов качества (надежность, реактивность и др.), которыми должна обладать система и ПО, методы их достижения на этапах ЖЦ и адекватности процессов работы с требованиями.

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


87

Инженерия требованийУправление требованиями заключается в планировании и контроле выполнения требований и проектных ресурсов в процессе разработки компонентов

Слайд 87Инженерия требований
Трассирование требований
Трассировку можно описать исходя из следующего:
требования изменяются

во время функционирования системы;
возникновение требований и их расположение зависит от

деталей практической ситуации и контекста их возникновения (требования можно изменить, изменяя эти детали);
трассировка требований должна поддерживаться и изменятся на протяжении всего ЖЦ программного продукта (т.к. изменяются сами требования, необходимо проводить изменение и промежуточных результатов, полученных при анализе, спецификации, кодировке и т.д.);
для удобства трассировки использовать иерархическую структуру связей между требованиями, основу которой составляет информация об атрибутах требований.
Механизмы трассировки требований:
вместо простых связей вводить более сложные отношения (например, транзитивное отношение для выделения цепочек связей) или вводить специфические отношения;
использовать сложные и гибкие пути трассировки;
поддержать базы данных объектов трассировки и отношений между ними.

88

Инженерия требований Трассирование требованийТрассировку можно описать исходя из следующего:требования изменяются во время функционирования системы;возникновение требований и

Слайд 88Лучше один раз увидеть, чем сто раз услышать, тем паче

тысячу раз прочитать пересказ.

Лучше один раз увидеть, чем сто раз услышать, тем паче тысячу раз прочитать пересказ.

Слайд 89СПАСИБО ЗА ВНИМАНИЕ !!!



Ваши вопросы………



Темы следующей лекции:
Документирование требований (Requirements Elicitation)
Техническое

задание. Определение;
Развитие нормативно-правовой базы;
Разработка Технического задания:
Требования к содержанию и оформлению

[ГОСТ 34.601-90]


Техническое задание. Требования к содержанию и оформлению [ГОСТ Р ИСО/МЭК 12207-2010];
Отношения между системами и программными средствами [ГОСТ Р ИСО/МЭК 12207-2010];
Технические процессы [ГОСТ Р ИСО/МЭК 12207-2010];
Спецификация требований к программному обеспечению (SRS);
Гармонизация типов требований (по Вигерсу) и требований в соответствии ГОСТ 34.601-90.
СПАСИБО ЗА ВНИМАНИЕ !!!Ваши вопросы………Темы следующей лекции:Документирование требований (Requirements Elicitation)Техническое задание. Определение;Развитие нормативно-правовой базы;Разработка Технического задания:Требования к

Похожие презентации

ЧИСЛИТЕЛЬНЫЕ ЧИСЛИТЕЛЬНЫЕ 222
2 слайд 2 слайд 284
Он большого солнца маленький портрет… Он большого солнца маленький портрет… 306
ПОЛОВАЯ СИСТЕМА ПОЛОВАЯ СИСТЕМА 291
Дети войны Дети войны 345
Спектри. Спектральний анал із Спектри. Спектральний анал із 280
АСУ-Ш-2 АСУ-Ш-2 1108
Культ личности И.В. Сталина и массовые репрессии в СССР Культ личности И.В. Сталина и массовые репрессии в СССР 1208
лекция : Бронхиальная астма. ХОБЛ. Лекция для 3 курса 4 факультета Лектор- лекция : Бронхиальная астма. ХОБЛ. Лекция для 3 курса 4 факультета Лектор- 693
Основные функции при управлении адаптацией и их распределение Основные функции при управлении адаптацией и их распределение 272
Здоровый образ жизни Здоровый образ жизни 256
ОТЧЕТ МБОУ Кугесьская СОШ №1 об ОНЛАЙН-МЕРОПРИЯТИЯХ, посвященных ОТЧЕТ МБОУ Кугесьская СОШ №1 об ОНЛАЙН-МЕРОПРИЯТИЯХ, посвященных 217
Лес и человек Лес и человек 505
Прямоугольные треугольники Прямоугольные треугольники 407
молочка ТПП молочка ТПП 265
Викторина Олимпийские игры Викторина Олимпийские игры 254
Компьютерная графика Компьютерная графика 252
Слова-названия предметов и явлений, слова-названия признаков предметов и Слова-названия предметов и явлений, слова-названия признаков предметов и 284
( 1870 – 1958 гг.) Заслуженный художник Автономной Республики немцев Поволжья ( 1870 – 1958 гг.) Заслуженный художник Автономной Республики немцев Поволжья 278

Обратная связь

Если не удалось найти и скачать доклад-презентацию, Вы можете заказать его на нашем сайте. Мы постараемся найти нужный Вам материал и отправим по электронной почте. Не стесняйтесь обращаться к нам, если у вас возникли вопросы или пожелания:

Email: Нажмите что бы посмотреть 

Что такое TheSlide.ru?

Это сайт презентации, докладов, проектов в PowerPoint. Здесь удобно  хранить и делиться своими презентациями с другими пользователями.

Для правообладателей

Яндекс.Метрика