ЛК.0 4 – Формування прецедентів

проекту за рівнями цілей
Прецеденти узагальненого рівня
Інтереси зацікавлених сторін
Шаблони опису прецедентів


Перелік

питань

важливо не забувати про їх зв'язок із цілями, що ставлять

перед собою користувачі системи, у першу чергу основні актори.
Актор має цілі.
Ціль іменує прецедент.
Прецедент має сценарії.





Cockburn A. Writing Effective Use Cases, Addison-Wesley, Boston, MA, 2000. (Переклад на російську мову опублікований у видавництві "Лорі" М. 2002 р. під назвою "Современные методы описания функциональных требований к системам".
http://alistair.cockburn.us

функціональності (переліку функціональних рис чи вимог) системи, про яку часто

дуже турбуються програмісти. (Прецеденти суттєво відрізняються від списку функціональних характеристик: одна й та сама функціональна характеристика у вигляді текстового рядка може фігурувати одразу в декількох варіантах використання.) Разом з тим, щоб одержати задачі для розроблювачів, не важко "конвертувати" варіанти використання в список функціональних рис.
Прецедентами визначається, що саме повинна виконувати система, причому, як правило, нічого не говориться про те, як вона це має робити. (Програмісти мають усвідомлювати необхідність у специфікації поведінки системи у вигляді "чорного ящика".)

не завжди (не у кожному сценарії) відповідна ціль виявляється досяжною.

(Приклад: людина вводить невірний пароль при одержанні грошей з банкомата. А якщо карточка крадена! Система має переконатися, що людині можна спілкуватися з банкоматом.)
Отже, опис прецедента доцільно поділяти дві частини: опис послідовності дій, коли “усе йде, як треба” та опис того, як поводиться система, коли відбувається якийсь збій.
При цьому найбільшу практичну користь, яку можна отримати з варіанта використання, являє собою не основний сценарій, а опис саме альтернативної поведінки.
Практика свідчить, що основний сценарій може займати лише від чверті до однієї десятої всього обсягу опису.

опису прецедентів: короткий опис, звичайний опис і повний опис.
Короткий

опис містить від двох до чотирьох речень (його зручно представляти в окремій комірці електронної таблиці, в інших комірках можна зберігати пріоритетність, технічні особливості реалізації, порядковий номер версії та іншу інформацію, що стосується планування).
Звичайний опис складається вже з декількох абзаців тексту.
Повний опис – це місткий шаблон, у якому є поля для опису зацікавлених сторін, мінімальних гарантій, передумов, постумов, масштабу, рівня і т.д.

Навряд чи різні формати колись об'єднаються в єдине ціле. На те є дві причини. По-перше, проекти і люди, що їх розробляють, настільки різноманітні, що прецеденти завжди будуть створюватися на різних рівнях деталізації і формалізації. По-друге, щоб амбіційні люди могли робити собі ім'я, вони повинні запропонувати щось нове. Отже, навіть якщо якесь рішення стабілізується, знайдуться люди, що будуть шукати й просувати альтернативні підходи.

писати основний сценарій, у якому було б більше дев'яти кроків:

“ Справа не в тім, що дев'ятка - моє щасливе число, просто на той час, як я визначу другорядні цілі користувача на досить високому рівні абстракції і позбудуся від згадування елементів дизайну системи, у сценарії завжди виявляється менше дев'яти кроків.
Отже, якщо основний сценарій містить до дев'яти кроків, весь варіант використання буде займати максимум дві-три сторінки, що робить його читабельним.
Не рекомендується включати в опис прецедентів специфіку інтерфейсу користувача – це дозволить отримувати опис, який набагато легше читається.

не рекомендується?
По-перше, дизайн доцільно розробляти, коли вже відомо, що

і як повинна робити система.
По-друге, дизайн інтерфейсу – дуже непостійна річ, часто потребує змін. Якщо описувати інтерфейс за допомогою варіантів використання, то вийде, що цей опис потрібно буде дуже часто міняти.
На жаль, цю рекомендацію часто ігнорують. Новачки вважають своїм обов'язком описувати всі кнопки "ОК", поля введення, вікна і т.п. Цьому є тільки одне виправдання – люди люблять працювати з конкретними концепціями.
Краще витратити час і сили на те, щоб навчитися писати в нейтрально-технологічному стилі: "Система надає вибір таких-то можливостей. Користувач обирає визначену дію".
Результати виправдають зусилля – описи прецедентів стануть більш короткі і стабільні, їх можна буде легко прочитати і зрозуміти.

для застосування у діловій сфері. У багатьох випадках для аналізу

і вироблення управлінських рішень цілком достатньо опису бізнес-процесів у “прецедентному вигляді”: клієнт робить те-то; клерк робить те-то і передає документ (чи інший артефакт) у такий-то відділ; коли щось не так і відділ відмовляється прийняти деяку частину роботи, ця частина роботи передається в інший відділ і т.д.
Описи такого роду не потребують великих зусиль для більшості бізнесменів, а з іншого боку є цілком зрозумілими навіть непрофесіоналами предметної області, що розглядається. Саме тому ділові прецеденти відіграють усе зростаючу роль у реінженірингу бізнесів-процесів.
Профіль UML для ділового моделювання (стереотип для ділових прецедентів – <>).

важливо зв'язати їх з цілями, що ставлять перед собою користувачі

системи, у першу чергу основні актори.

(рівні абстракції), на яких ґрунтується опис прецедентів.

– цілей різного рівня.
Наприклад, можна вважати своєю основною ціллю

бажання одержати гарний контракт. Більш близька ціль (часовий проміжок звужується) – запросити роботодавця пообідати. Ще більш близька ціль (часовий проміжок ще вужче) – роздобути готівку, щоб заплатити за обід. Далі ще цілі – зняти гроші з картки в найближчому банкоматі і, нарешті, – уставити картку в банкомат і розпочати транзакцию. Усі згадані цілі співіснують одночасно, але мають різний рівень.
Якщо не вказувати, якого рівня ціль переслідується описом прецедента, у читача може виникнути перекручена картина того, що відбувається.
“При всій повазі” до банкоматів, не можна не відзначити, що в наведеному прикладі найважливішою (узагальненою) ціллю є отримання контракту.

цілі користувача;
рівень окремої функції.
У першій і третій групі виділяються

підгрупи. У першій – рівень хмари і рівень повітряного змія, у третій – підводний рівень і рівень дна. У назвах рівнів використовується характерна метафора – море, його поверхня, небо над морем. Ця метафора дозволяє ввести для прецедентів відповідні кольори: білий, блідо-блакитний, яскраво-блакитний, темно-синій і чорний.

функціональної поведінки найбільший інтерес являє рівень цілі користувача. Пошуку цих

цілей (а отже прецедентів) варто приділяти максимум уваги.
Як визначається цілі рівня користувача?
Ціль (прецедент) рівня користувача – це коли відрядна платня користувача як робітника залежить від того, скільки разів ним використовувався відповідний прецедент (використовувалась ціль).
Наприклад, “Реєстрація клієнта” є прецедентом рівня користувача, а от “Уведення пароля” – ні.
Корисно пам'ятати, що найпростіший список функцій системи (список функціональних вимог) – це список цілей користувачів системи. Такий список може бути основою для розподілу завдань між співробітниками, а також для визначення пріоритетів цих завдань.

цілі користувача легко шукати узагальнені прецеденти і прецеденти рівня окремої

функції.
Розгляньте будь-який прецедент “А” рівня цілі користувача. Поставте запитання: для чого (why) виконується прецедент “А” ?. Відповідь на це запитання дасть узагальнений прецедент.
Задайте інше питання: як (how) виконується прецедент “А” по кроках? Відповідь на це запитання дасть вам колекцію прецедентів рівня окремої функції.

Роль таких прецедентів:
визначають більш високий рівень опису системи (важливо для

спілкування зі спонсорами, важливо для відділів маркетингу, продажу тощо);
утворюють контекст для прецедентів рівня цілі користувача;
можуть визначати послідовність виконання прецедентів рівня цілі користувача;
можуть використовуватись для формування змісту документу "Вимоги до системи".

керівник)”.
Масштаб – кафедра (організація), білий ящик.

Рівень – узагальнений (повітряний змій).

Основний

сценарій.
1. Методист визначає мінімальну кількість тем для кожного викладача.
2. Викладачі пропонують назви тем.
3. Методист складає список запропонованих тем.
4. Студенти обирають теми робіт.
5. Методист складає таблицю з обраними студентами темами та керівниками тем.

компромісу між інтересами зацікавлених сторін.
Приклад. Іван підходить до автомату, що

продає напої. Насправді, він не хоче витрачати гроші - він хоче каву. У власника автомата зовсім інші інтереси. Він був би радий, якби люди просто клали в автомат гроші. Автомат діє на основі найпростішого контракту: Іван уводить в автомат гроші, а власник повинен гарантувати, що Івану автомат наллє каву. А ще й ПДВ.
Реальний приклад. Робоча група вирішила виписати всі інтереси зацікавлених сторін. Виявилось, що цей список практично збігається зі списком змін, які групі довелося зробити у зданій замовнику ПС протягом першого року її роботи. Іншими словами, зроби вони цю роботу на рік раніше, вони уникли б цілої маси помилок до того, як система була передана замовнику.
Резюме. Описувати стейкхолдерів і їх інтереси корисно завжди, навіть якщо це робиться дуже коротко і неформально.

TEMPLATE

active verb phrase>
Context of use:
Scope:
Level:
Primary Actor:
Stakeholders & Interests:
Precondition:
Minimal Guarantees:
Success Guarantees:
Trigger:

trigger to goal delivery, and any cleanup
after>

Extensions

here there extensions, one at a time, each referring to the step of the main scenario>
:
:
Technology and Data Variations List



Related Information

. . .

system / organization>
Performance Target:

use case should take>
Frequency:
Superordinate Use Case:
Subordinate Use Cases:
Channel to primary actor:
Secondary Actors:
Channel to Secondary Actors:

Buy Goods
CHARACTERISTIC INFORMATION
Goal in Context: Buyer issues request

directly to our company, expects goods shipped and to be billed.
Scope: Company
Level: Summary
Preconditions: We know Buyer, their address, etc.
Success End Condition: Buyer has goods, we have money for the goods.
Failed End Condition: We have not sent the goods, Buyer has not spent the money.
Primary Actor: Buyer, any agent (or computer) acting for the customer
Trigger: purchase request comes in.

purchase request.
2. Company captures buyer’s name, address, requested goods,

etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.
EXTENSIONS
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a1. Handle returned goods (use case 105)

use web order form,
electronic interchange
7. Buyer may pay

by
cash or money order
check
credit card

order, 45 days until paid
Frequency: 200/day
Superordinate Use Case:

Manage customer relationship (use case 2)
Subordinate Use Cases:
Create order (use case 15)
Take payment by credit card (use case 44)
Handle returned goods (use case 105)
Channel to primary actor: may be phone, file or interactice
Secondary Actors: credit card company, bank, shipping service
Channels to Secondary Actors:
OPEN ISSUES
What happens if we have part of the order?
What happens if credit card is stolen?
SCHEDULE
Due Date: release 1.0

the claimant
Goal: Get paid for car accident
1. Claimant submits claim

with substantiating data.
2. Insurance company verifies claimant owns a valid policy
3. Insurance company assigns agent to examine case
4. Agent verifies all details are within policy guidelines
5. Insurance company pays claimant
Extensions:
1a. Submitted data is incomplete:
1a1. Insurance company requests missing information
1a2. Claimant supplies missing information
2a. Claimant does not own a valid policy:
2a1. Insurance company declines claim, notifies claimant, records all this, terminates proceedings.
3a. No agents are available at this time
3a1. (What does the insurance company do here?)

basic policy guidelines:
4a1. Insurance company declines claim, notifies claimant, records

all this, terminates proceedings.
4b. Accident violates some minor policy guidelines:
4b1. Insurance company begins negotiation with claimant as to degree of payment to be made.
Variations:
1. Claimant is
a. a person
b. another insurance company
c. the government
5. Payment is
a. by check
b. by interbank transfer
c. by automatic prepayment of next installment
d. by creation and payment of another policy

and scope
1a. What is the overall scope and goal?
1b. Stakeholders

(who cares?)
1c. What is in scope, what is out of scope
Chapter 2. The terms used / Glossary
Chapter 3. The use cases
2a. The primary actors and their general goals
2b. The business use cases (operations concepts)
2c. The system use cases
Chapter 4. The technology to be used
4a. What technology requirements are there for this system?
4b. What systems will this system interface with, with what requirements?
Chapter 5. Other various requirements
5a. Development process
Q1. Who are the project participants?
Q2. What values will be reflected in the project (simple, soon, fast, or flexible)?

do the users and sponsors wish?
Q4. What can we buy,

what must we build, what is our competition to this system?
Q5. What other process requirements are there (testing, installation, etc.)?
Q6. What dependencies does the project operate under?
5b. Business rules
5c. Performance
5d. Operations, security, documentation
5e. Use and usability
5f. Maintenance and portability
5g. Unresolved or deferred
Chapter 6. Human backup, legal, political, organizational issues
Q1. What is the human backup to system operation?
Q2. What legal, what political requirements are there?
Q3. What are the human consequences of completing this system?
Q4. What are the training requirements?
Q5. What assumptions, dependencies are there on the human environment?

глагольного оборота или эквивалентного оборота с существительным и выражает основную

цель действующего лица>
Главное действующее лицо <Имя роли или краткое описание действующего лица, которое играет ключевую роль во взаимодействии с системой в рамках данного прецедента>
Внешний контекст <В этом пункте цель действующего лица раскрывается чуть более полно>
Масштаб <описание границ системы: что находится вне системы, которую на этом этапе мы можем представить себе в виде "черного ящика", с чьей точки точки зрения составлено описание>
Уровень <один из трех вариантов - Обобщенный, Цель пользователя, Отдельная функция>
Заинтересованные лица <список всех заинтересованных лиц и обзор их ключевых интересов, которые должны быть соблюдены при работе системы>
Исходные условия <Состояние мира (системы и ее окружения), которое всегда имеет место перед выполнением прецедента>
Минимальный результат <Какие цели будут достигнуты в наихудшем варианте из возможных>

достигнуты, если работа пройдет без малейших отклонений>
Триггер

которого стартует наш прецедент>
Основной успешный сценарий <В этом разделе шаблона перечисляются все шаги, начиная с события-триггера и заканчивая последним шагом, при котором достигается цель действующего лица. В этом же разделе можно описать процедуру освобождения ресурсов после достижения цели>
Формат описания <Шаг #> <Описание выполняемого действия>
Расширения <Описание возможных отклонений, если на том или ином шаге основного успешного сценария возникают проблемы>
Формат описания <Шаг # Отклонение # ...> <Описание выполняемого действия>
Варианты изменения технологий и данных <Описание возможных отклонений, которые при которых может меняться набор шагов основного успешного сценария и т.п.>
Формат описания<Отклонение #><Необходимые изменения>.
Дополнительная информация <Описание остальной полезной информации, которая может понадобиться разработчику. Здесь можно привести ссылки на документы, содержащие описания нефункциональных требований: дизайн, эргономичность, параметры базы данных, производительности etc>

Заинтересованные лица
1c. Что входит в систему, что выходит за ее

рамки?
Глава 2. Используемые термины (Глоссарий)
Глава 3. Прецеденты
2a. Основные действующие лица и их главные цели
2b. Бизнес-прецеденты
2c. Прецеденты-системы
Глава 4. Используемые технологии
4a. Требования к технологиям, которые будут использоваться в разрабатываемой системе?
4b. Будут ли другие системы взаимодействовать с разрабатываемой? Требования к форматам и протоколам взаимодействия?
Глава 5. Другие требования, непосредственно касающиеся проекта
5a. Организация процесса разработки
Q1. Кто является непосредственным участником проекта?
Q2. Сроки.
Q3. Желательный уровень обратной связи с заказчиком на разных этапах проекта.

приобрести, что нужно разработать самостоятельно?
Q5. Обзор конкурирующих

систем.
Q6. Требования к тестированию и к процедуре развертывания системы у заказчика.
5b. Бизнес-правила
5c. Производительность
5d. Организация операций, безопасность, требования к документации
5e. Простота обучения и использования
5f. Переносимость и администрирование
5g. Вопросы, решение которых неизвестно на данный момент, и возможности, которые будут реализованы в следующей версии
Глава 6. Организационные вопросы: взаимодействие с руководством заказчика, политические, законодательные, человеческий фактор.
Q1. Требования к квалификации персонала.
Q2. Законодательные требования, вопросы взаимодействия с властями.
Q3. Возможные влияния человеческого фактора на успех/неудачу проекта.
Q4. Требования к обучению персонала.
Q5. Прочие организационные вопросы.

Interests: the claimant - to get paid the most possible
MyInsCo

- to pay the smallest appropriate amount
the dept. of insurance - to see that all guidelines are followed.
Precondition: none
Minimal guarantees: MyInsCo logs the claim and all activities.
Success guarantees: Claimant and MyInsCo agree on amount to be paid, claimant gets paid that.
Trigger: Claimant submits a claim
Main success scenario:
1. Claimant submits claim with substantiating data.
2. Insurance company verifies claimant owns a valid policy
3. Insurance company assigns agent to examine case
4. Insurance company verifies all details are within policy guidelines
5. Insurance company pays claimant and closes file.

Claimant supplies missing information
2a. Claimant does not own a valid

policy:
2a1. Insurance company declines claim, notifies claimant, records all this, terminates proceedings.
3a. No agents are available at this time
3a1. (What does the insurance company do here?)
4a. Accident violates basic policy guidelines:
4a1. Insurance company declines claim, notifies claimant, records all this, terminates proceedings.
4b. Accident violates some minor policy guidelines:
4b1. Insurance company begins negotiation with claimant as to degree of payment to be made.

в целом
Уровень. Обобщенный, бизнес-процессы
Версия. Рабочий черновик
Исходные условия. Зафиксирован страховой случай
Триггер.

В страховую компанию поступило заявление о наступлении страхового случая
Основной успешный сценарий.
1. Клиент терпит убытки и обращается в страховую компанию с просьбой о возмещении убытков.
2. Клерк фиксирует запрос и направляет его одному из менеджеров.
3. Менеджер
проверяет страховой полис
оценивает сумму убытков
оценивает доступные резервы для страховых выплат
ведет переговоры с клиентом по его заявлению
принимает окончательное решение о выплате возмещения и закрывает заявление.

позднее
Минимальный результат.
Результат успешного завершения. Заявление о наступлении страхового случая

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

возмещения
Главное действующее лицо. Менеджер по выплатам страхового возмещения
Масштаб. Отдел выплат

страхового возмещения по полисам медицинского страхования
Уровень. Обобщенный
Контекст. Менеджер по выплатам страхового возмещения получает заявление клиента от клерка и анализирует процесс лечения, его результат и расходы клиента.
Исходные условия. Отсутствуют
Триггер.
Основной успешный сценарий.
1. Менеджер анализирует счета поликлиники, выписанные клиенту, размер суммы страхового возмещения по полису клиента и другие необходимые документы.
2. Менеджер определяет степень нетрудоспособности по законодательно определенным критериям.
3. Менеджер устанавливает окончательную сумму возмещения.
4. Менеджер проверяет возможность осуществления платежа (в соответствии с текущими резервами).

документов по заявлению.
6. Менеджер рассылает всем причастным лицам необходимые документы.
7.

Менеджер оформляет заключительный пакет документов.
Расширения. Будут описаны позднее
Частота использования. Несколько раз в день.
Минимальный результат. Определены необходимые процедуры (юридические, медицинские), требуемые для однозначного определения суммы страхового возмещения.
Результат успешного завершения. Определена сумма страхового возмещения по заявлению клиента.
Заинтересованные лица.
Клиент, он хочет получить максимальную сумму возмещения убытков.
Менеджер, хочет выплатить минимальную возможную сумму.
Страховая компания, то же самое.
Юридическая служба компании.
Бухгалтерия компании.
Контролирующие органы (им предоставляется отчетность по установленной форме).
Вопросы для размышления:Действующее законодательство и бизнес-правила.

со счета через банкомат
Главное действующее лицо. Клиент
Масштаб. Банкомат
Уровень. Цель пользователя
Основной

успешный сценарий.
1. Клиент вставляет карточку в банкомат.
2. Банкомат считывает с карточки код банка, номер счета, PIN-код и сверяет код банка и номер счета с данными в банке.
3. Клиент вставляет карточку и вводит PIN-код. Банкомат проверяет совпадение введенного кода и кода на карточке.
4. Клиент выбирает режим "Снять деньги наличными" и вводит сумму, кратную $5.
5. Банкомат соединяется с центральной системой в банке, передает данные о транзакции, получает подтверждение и новый остаток по счету.
6. Банкомат выдает деньги, возвращает карточку и печатает чек, на котором указан новый остаток по счету.
7. Банкомат записывает информацию о транзакции в журнал.

заказов
Уровень. Цель пользователя
Основной успешный сценарий.
1. Покупатель вводит ID и пароль.
2.

Система проверяет ID и пароль.
3. Покупатель вводит имя, адрес, номер телефона.
4. Система проверяет, является ли покупатель зарегистрированным клиентом.
5. Покупатель выбирает товары и вводит требуемое ему количество каждого товара.
6. Система проверяет, есть ли на складе достаточное количество выбранных покупателем товаров.