Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Разработка требований к программному продукту. Учебное пособие
.pdf
становится руководством для подробного дизайна пользовательского
интерфейса.
1. Состояние (прямоугольник) на карте
Правила составления карт
диалоговых окон
диалоговых окон определяет каждый элемент
окна.
2. Переход (стрелка) показывает возмож-
ные перемещения между элементами. Подоб-
ным образом используют и диаграммы перехода состояния.
3. Текстовое описание на стрелке перехода задает условие перемещения по пользовательскому интерфейсу. Ниже приведены типы усло
вий перехода:
действие пользователя, например, нажатие функциональной кла-
виши;
ошибочное значение данных, что приводит к выводу сообщения
об ошибке;
системное условие, например отсутствие бумаги в принтере;
некоторые комбинации вышеперечисленных элементов, например
ввод номера элемента меню и нажатие клавиши Enter.
2. Входная точка (черный кружок с точкой) с исходящей линией пе-
рехода при отсутствии входящих линий определяет переход из другой
части пользовательского интерфейса в эту часть интерфейса. Подобным
образом определяются выходные точки перехода в другие части пользовательского интерфейса: это входящие линии перехода в черный кружок с точкой без исходящих линий
В приложении 7 приведен пример карты диалоговых окон для варианта использования «Заказ химиката» (описание системы заказа химикатов см. в приложении 3).
Карты диалоговых окон напоминают диаграммы потоков данных,
но создаются для разработки пользовательского интерфейса. Диаграммы потока показывают этапы процесса и точки решений, но не
пользовательский интерфейс. Они ценны
ональных требований.
Способы упрощения карт
диалоговых окон
пример нажатие клавиши вызова справки F1
для каждого элемента диалогового окна.
В разделе спецификации требований к про-
перехода.
для формулирования функци-
Пропустить глобальные функции, на-
-
31
граммному обеспечению по пользовательскому интерфейсу должно
быть указано требование о доступности этой функциональности.
Пропустить в случае веб-сайта стандартные для каждой страницы
ссылки перемещения, а также переходы по щелчку кнопки «Назад»
браузера.
25. Как представить сложную логику управления
исследуемой системой, чтобы ничего не пропустить
в функциональных требованиях?
Действия разрабатываемого продукта
иногда зависят от выполнения
или невыполнения целого ряда условий (от сложной логики). В таких
случаях в функциональных требованиях должны быть указаны все допустимые варианты действий и определены соответствующие условия
для каждого действия. Полное представление обо всех возможных вариантах выполнения условий и действий можно получить, используя такие модели
анализа, как таблица решений и дерево решений.
В таблице решений указывают все допустимые значения для всех
условий, определяющих действия продукта, и сами действия продукта
в случае выполнения нужных условий. Часто условия формулируются
как утверждения, истинность которых нужно проверить. Одно условие
в зависимости от формулировки может вызывать несколько различных
действий, и
тогда определяют такое же количество пограничных значе-
ний для условия.
В приложении 8 приведены примеры таблицы решений и дерева решений (описание системы заказа химикатов см. в приложении 3).
26. Как связаны между собой бизнес-правила
и требования к создаваемому продукту?
Бизнес-правила определяют большую часть функциональных тре-
бований к продукту и
не зависят от информационных систем организа-
ций или предприятий.
Многие профессиональные виды деятель-
Примеры
ности в организациях и на предприятиях тре-
буют выполнения правил техники безопасности. Соответственно имеется система подготовки, которая включает
в себя периодические занятия для сотрудников и получение ими допуска к работе после успешного выполнения ряда заданий на
знание
32
правил техники безопасности и их применение в конкретных ситуациях.
Такой порядок существует независимо от степени развития информационных систем организаций и существовал до их внедрения. Следование
ему обязательно для выполнения многих производственных процессов,
а значит, при разработке требований к информационной системе организации или предприятия нужно сформулировать требования, связанные
с обеспечением правил техники безопасности.
Атрибутом качества в этом случае являются требования государственных регулирующих органов. Например, необходим допуск к определенным видам деятельности, в которых используется разрабатываемый программный продукт, при наличии у пользователя удостоверения
о соответствующей подготовке – как, например, в системе заказа химикатов. Бизнес-требованием является утилизация химикатов
в системе
заказов химикатов в соответствии с федеральным и местным законодательством.
Пользовательским требованием является распределение видов дея-
тельности по ролям в программном продукте.
Бизнес-требования определяют желае-
Определение
бизнес-правила
мые результаты работы сотрудников организации или организации в целом, которые
могут быть достигнуты с помощью разрабатываемого продукта.
Возможны ситуации неоднозначного
понимания сотрудниками бизнес-правил, что приводит к разным способам выполнения и результатам
применения одних и тех же бизнес-правил. Сотрудники даже могут вообще не выполнять бизнес-правило. Существуют правила, которые выработаны опытным путем, они выполняются сотрудниками, но не зафиксированы как бизнес-правила в установленном порядке. В этом
случае невозможность для сотрудников выполнять свои обязанности может
привести к потере таких правил. Разработчикам нужно учитывать эти
ситуации при определении требований к продукту.
Для формулирования однозначных требований лучше создавать
единое хранилище бизнес-правил.
33
27. Есть классификация бизнес-правил,
помогающая в работе с ними?
Классификация бизнес-правил указывает на возможные типы правил, что облегчает поиск бизнес-правил и уменьшает вероятность их
пропуска.
Бизнес-правила можно разделить на группы в зависимости от способа использования в продукте: факты, вычисления, активаторы операций, ограничения, выводы.
Факты
– это верные утверждения о бизнесе на
определенный момент. Они описывают связи и от-
Факты
ношения между важными бизнес-терминами.
Примеры фактов:
во время шторма корабли не могут покинуть порт;
если за 30 секунд ни один из операторов не освободился, то звонок
прерывается;
если станок занят, то деталь помещается в
буфер до окончания об-
работки предыдущей детали;
за каждым экскаватором закрепляются для погрузки определен-
ные самосвалы.
В каждой организации можно собрать большое количество фактов.
Очевидно, что нужно выделить факты, имеющие отношение к разрабатываемому продукту. Каждый выделенный факт должен иметь связь
с входными и выходными данными контекстной диаграммы, а
также
с событиями системы, известными объектами данных или конкретными
пользовательскими требованиями.
Преобразование имеющихся данных в но-
Вычисления
вую информацию с помощью математических
формул и алгоритмов является классом бизнесправил «вычисления».
Многие вычисления выполняются по внешним для организации или
предприятия правилам, в частности в соответствии с федеральным или
местным законодательством.
Например, цена единицы
товара снижается на 10 % при покупке
от 3 до 5 единиц, на 20 % – при покупке от 6 до 8 единиц и на 30 % –
при покупке более 8 единиц. Представление вычислений в виде формул
или таблиц вычислений делает этот материал понятнее в отличие от текстовой формы записи правил вычислений (табл. 5).
34
Таблица 5
Пример представления вычислений в виде таблицы
Количество приобретаемых товаров Скидка, %
1–2 0
3–5 10
6–8 20
9 и более 30
При документировании таких правил важно отследить, что границы
диапазонов не перекрываются, иначе возникает неопределенность в вычислениях.
В работе [10] рассмотрен проиллюстрированный примерами подход
определения требований к качеству программного обеспечения.
Активатором действий называют правило,
Активаторы
действий
которое в зависимости от выполненного условия определяет выполняемое действие.
Для реализации нужного поведения про-
граммного продукта
используют активаторы действий. Для представления возможных вариантов условий в активаторе действий используют
таблицы.
В качестве примера приведем табл. 4: таким образом можно обеспечить учет всех возможных вариантов принятия решений активатором
действий в случае сложной логики. Варианты принятия решений можно
представить, используя шаблон вида «Если <некоторое условие верно
или наступило определенное
событие>, то <что-то произойдет>» для
представления активатора действий.
Примеры активаторов:
если в наличии имеются контейнеры с запрошенным химикатом,
то их следует предложить запросившему химикат лицу;
если обучающийся не имеет академических задолженностей по
учебным дисциплинам и практикам в соответствии с учебным планом
направления подготовки и профиля на момент
окончания обучения,
то издается приказ о его допуске к защите магистерской диссертации;
если факт болезни студента во время сессии подтвержден медицин-
ской справкой из государственного медицинского учреждения, то издается приказ о продлении сессии студенту на срок, указанный в медицинской справке.
35
Пример учета возможных вариантов принятия
решений активатором действий в сложной логике
Таблица 4
Матрица принятия
решений
Системные операции
Вход в информационную
систему
Ввод / корректировка за-
писи о преподавателе
Рабочие программы учебных дисциплин
Ввод/корректировка – – Да
Назначение преподава-
телю
Просмотр Да Да Да
Удаление Да – Да
Копирование Да Да Да
Перемещение – Да –
Зав. кафедрой
Да Да Да
– Да –
– Да –
Ученый
секретарь
Преподаватель
Ограничение определяет, какие операции
Ограничения
не может выполнять система и ее пользова-
тели.
Ограничения можно определить по фразам, которые часто используются при их описании: «должен», «не должен», «не может», и только
определенные люди или роли могут выполнять определенные действия.
Ниже приведены примеры ограничений различного вида.
1. Правила организации:
все сотрудники
организации должны использовать в служебных
целях только корпоративную почту;
обязательный список источников информации по учебной дисци-
плине должен содержать только доступные обучающимся источники
информации из научной библиотеки университета или из проверенных
источников в Интернете;
в соответствии с Положением о балльно-рейтинговой системе уни-
верситета максимальный балл за экзамен
по учебной дисциплине со-
ставляет 40 из 100 возможных баллов.
36
2. Государственные нормативы:
все сотрудники организации при приеме на работу должны прохо-
дить инструктаж по технике безопасности;
продолжительность учебного часа теоретических и практических
занятий в автошколах – один академический час (45 минут), при обучении вождению – один астрономический час (60 минут), включая время
на подведение итогов и оформление документации.
3. Ограничения в
проектах по разработке программного обеспе-
чения:
члены команды проекта должны выполнять задания в соответ-
ствии с графиком, с учетом лимитов по персоналу и бюджету;
разные роли или сотрудники организации, для которой разраба-
тывается продукт, могут выполнять разные функции и соответственно
имеют разные права доступа к возможностям продукта. Эту информа
цию для лучшего понимания и проверки полноты сведений рекомендуется помещать в таблицу, столбцы которой представляют собой
роли пользователей, а строки – функции проекта. Право роли выполнять ту или иную функцию отмечается определенным символом
в ячейке, находящейся на пересечении нужного столбца (роли) и нужной строки (функции). Дополнительно можно выделить
группы функ-
ций или ролей;
некоторые требования формулируют на основе ограничивающих
процессы работы системы бизнес-правил. Эта связь должна быть отражена в программной документации;
ограничивающие бизнес-правила могут создавать определенные
последствия для разработки ПО, даже если они непосредственно не выражаются в определенной функциональности. Например, некоторые
функции периодически
при определенных условиях могут выполнять
сотрудники сторонней организации, что косвенно влияет на функционал продукта.
Вывод создает новый факт на основе других
Вывод
фактов. Выводы зачастую записывают в формате
«Если…, то…». При записи бизнес-правил элемент
«то…» вывода заключает в себе факт, а не действие.
Примеры выводов:
если преподаватель
выставил оценку за присланный отчет по ла-
бораторной работе, то работа имеет статус «Принято»;
-
37
если сумма баллов обучающегося за все обязательные виды учеб-
ной деятельности по дисциплине больше 50 баллов, то он имеет статус
по данной дисциплине «Зачтено».
28. Как упростить сложные бизнес-правила?
Сложные бизнес-правила содержат несколько правил, что усложняет их понимание и проверку качества. Приведенный выше пример
определения скидки на покупку
товара представляет собой сложное
бизнес-правило, в соответствующей таблице оно разбито на четыре простых. Лучше записать несколько простых и коротких правил, разделив
сложное правило, – это упрощает понимание правила и проверку его
правильности, а также повторное использование. Если правило нельзя
разделить на еще более простые правила, то его называют атомарным.
Для записи предположительного знания и активирующих операций
бизнес-правил в атомарном виде не рекомендуется использовать связку
«или» в левой части шаблона «Если…, то…» и связку «и» – в правой.
Функциональные требования формулируют на основе различных
вариантов сочетаний атомарных правил, созданных при разделении
сложного бизнес-правила. Такой подход предполагает, что при изменении части правила нужно менять только четко определяемую часть
функциональных требований или программного кода.
29. Есть ли важные рекомендации
для документирования бизнес-правил?
При документировании особенно важно правильное управление
требованиями и соблюдение правил, относящихся к безопасности, защите, финансам, а также выполнению требований законодательства и
регулирующих органов.
За хранилище бизнес-правил
должны отвечать соответствующие
подразделения, а не команда проекта.
Лучше употреблять простые формы записи правил, что обеспечивает их эффективное использование разработчиками.
По мере накопления опыта можно разработать и использовать шаблоны для документирования разных типов правил. В простом случае
шаблон требования может включать в себя следующие характеристики:
идентификатор, формулировку, тип правила
, свойство изменчивости
(статическое или динамическое) и источник.
38
Введение идентификатора правил дает возможность отслеживать
р
происхождение функциональных требований от бизнес-правил. Каждый такой идентификатор является указателем на единственный экземпляр бизнес-правила в базе данных, что исключает использование неактуальной формулировки правила.
Характеристика «тип правила» указывает, чем является правило:
фактом, ограничением, активатором операции, выводом или вычислением.
Свойство
изменчивости правила (статичное или динамическое) может помочь разработчикам в обеспечении атрибута качества модифицируемости продукта. Если правило будет меняться в процессе использования продукта, то должна быть обеспечена простота внесения нужных
изменений в функционал или данные продукта. Например, число рабочих дней в месяце изменяется каждый год, следовательно, для начисле
ния заработной платы нужно ежегодно изменять соответствующие данные. Это легко сделать в базе данных или таблице без привлечения программного кода продукта.
Источниками правил могут быть управленцы, специалисты предметной области и другие лица, а также нормативные документы и законы. Знание источника помогает понять, куда обращаться, если нужна
дополнительная информация о правиле или нужно подробнее узнать об
изменениях.
Если пользователям задавать вопросы из ряда «Каковы ваши бизнесправила?» или «Чего вы хотите?», то такие действия практически не
приводят разработчиков к нужному результату, т. е. получению полезных сведений о требованиях.
Давно работающие в компании спе-
Стандартные
места и способы
выявления
бизнес-п
авил
циалисты могут предоставить
все сведе-
ния об особенностях работы компании
«как есть» в отличие от регламентов раз-
личного типа, которые определяют «как
надо». Разработка и внедрение новой ин-
формационной системы может привести к изменению порядка работы
организации. Важно взять по согласованию с заинтересованными лицами все полезное и эффективное для компании с целью
формулирова-
ния требований из источников «как есть» и «как надо».
Наиболее полное знание о бизнес-правилах организации можно
получить, проведя анализ кода информационной системы, которую организация хочет заменить новой системой.
-
39
Правила принятия решений, ограничения, вычисления и факты
продуктивно определять, моделируя бизнес-процессы. Моделирование
приводит к необходимости определения всех типов требований.
Вариант организации бизнес-процессов «как надо» можно опреде-
лить при анализе нормативной документации различного вида: федеральных и местных законов, документации на предыдущую версию продукта, нормативных документов
организации.
Анализ состояний источников данных и условий, при которых
пользователь или системное событие может изменить состояние объекта, является важным источником разработки качественных требований.
Любое выделенное в ходе работы с различными источниками информации бизнес-правило, факт, формула для вычислений или вывод
должны быть проверены на актуальность для нового
проекта.
30. Как на основе бизнес-правил можно сформулировать
требования к разрабатываемому программному продукту?
После документирования бизнес-правил нужно определить правила,
которые будут реализованы в продукте.
Несмотря на то что некоторые бизнес-правила и соответствующие
им требования просто будут повторять друг друга, именно бизнес-правила определяют функционал продукта, а функция
продукта определяет
способ реализации бизнес-правила. Лучше делать ссылку на хранилище
бизнес-правил как источник требований, чем повторять его в спецификации требований.
Для определения источника требований можно использовать следу-
ющие способы:
составить матрицу требований, в которой определить связи между
функциональными требованиями и правилами-родителями, если требования и
правила размещены в одном хранилище;
создать гиперссылки в требованиях на правила, если требования и
правила хранятся в текстовых файлах или электронных таблицах. При
этом нужно учесть, что при перемещении таких файлов ссылки не работают;
создать атрибут «Источник требования» и указать правила, опре-
деляющие это функциональное требование, если в
проекте для управления требованиями используется специализированное программное
средство.
40
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]