Нові прийоми керування вимогами за допомогою Rational RequisitePro: Частина 1, Комерція, Різне, статті

У даній серії статей Кумара Мані пропонуються нові прийоми, що допомагають виявити і простежити архітектурні вимоги, а також керувати ними.

Введення


У цій статті описуються нові архітектурні методи і прийоми, спрямовані на проектування вимог, на вміння їх збирати, аналізувати і управляти ними протягом усього життєвого циклу проекту. Хоча в даній статті для ілюстрації цих прийомів використовується набір інструментів Rational, вона не є навчальним посібником по використанню цих продуктів. Ваша мета – використовувати основні архітектурні методи і застосовувати їх у своїх проектах. Звичайно ж, IT-архітектори, знайомі з Rational, Зможуть без зусиль відтворити ці методи в своїх проектах.


Вимоги важливі, оскільки вони утворюють основу для розробки архітектур. На Малюнку 1 показаний метод розробки архітектури Open Group Architecture Framework Architecture Development Method (TOGAF ADM) і його вісім фаз.


Рисунок 1. Метод розробки архітектури TOGAF
Метод розробки архітектури TOGAF

Вимоги, як вираження необхідності, можливості або недоліку, приводять в рух інші фази в процесі. Однак управління вимогами часто не береться до уваги або не застосовується належним чином в проектах з різних причин. IT-архітектори часто задають такі питання:


IT-фахівці хотіли б, щоб їхні технічні вимоги були чітко виражені, щоб їм можна було почати кодування. Менеджери проектів і клієнти не зовсім уявляють собі переваги таких інструментів, як Rational RequisitePro і можливість їх використання з інструментами управління проектами, наприклад, Rational Portfolio Manager. (В деяких проектах використовується весь набір інструментів Rational, крім RequisitePro!) Відповідям на ці питання і присвячена ця стаття.

Такі інструменти, як Rational, при правильному використанні можуть дати значні переваги. Деякі менеджери проектів використовують такі інструменти (наприклад, RequisitePro) як репозиторії для вимог; тобто вимоги імпортуються в інструмент як є, і з нього публікуються звіти. Менеджерам проектів залишається дивуватися, чому вони не бачать ніяких відчутних переваг.


Ця стаття покликана усунути прогалину між літературою про продукти та літературою про процеси. Документація по інструментальним засобам Rational прекрасно описує їх функції і можливості; література про процеси містить опис різноманітних методів і передової практики. Однак IT-архітектори все ж не уявляють собі до кінця, як можна витягти максимальну користь з цього інструменту. У цій статті ви дізнаєтеся про бізнес-вимогах, варіантах використання і базової трассируемого, а потім про вимоги системного рівня, компонентізаціі і трассируемого під час тестування.


Корпорація Empire Systems


Щоб продемонструвати, як найкращим чином використовувати методи управління архітектурними вимогами, в цій серії статей я буду приводити гіпотетичні приклади з практики Empire Systems Corporation (ESC), вигаданого виробника і постачальника ПК, ноутбуків, комп’ютерних компонентів і супутнього устаткування, наприклад, Web-камер і мікрофонів. ESC вже представлена ​​в Web, і багато хто з її додатків доступні через Інтернет. Тепер керівництву компанії потрібно перевести підприємство на наступний рівень шляхом раціоналізації процесів, автоматизації ділової активності, впровадження корпоративної архітектури, і, в кінцевому рахунку, підвищення доходів і рентабельності.


Бізнес-вимоги


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



В центрі уваги має бути бізнес Бізнес-вимоги повинні базуватися на реальних вимогах бізнесу, їх слід відрізняти від інших понять бізнесу (таких, як бачення, програма, цілі та завдання). Поширена помилка – формулювати бізнес-мету (наприклад, “досягти 20% зниження витрат”) як бізнес-вимога.
 
Будьте розумні Вимоги повинні бути Specific (конкретними), Measurable (вимірними), Actionable (дієвими), Realistic (реалістичними) і Timebound (обмеженими в часі). Це складніше, ніж здається. Однак цього легко зробити домогтися, задаючи такі питання:

  • Чому це має бути зроблено таким чином?
  • Який результат ви отримаєте або зможете досягти, якщо ця проблема вирішиться?
  • Який саме процес страждає від цього недоліку?
  • Яка вигода (вимірна кількісно, ​​наскільки це можливо), досягається внесенням поправок в процес?
  • Що можна зробити, щоб змінити ситуацію?

    Відповісти зазвичай буває важко, і зацікавлені сторони часто повертаються до постановки завдання. Спеціаліст по вимогам може почати з кількох припущень типу “а що якщо”, щоб виявити деякі можливості. Однак важливо від них відступити, як тільки зацікавлені сторони повернуться до питань.


  • Коли, відповідно з тимчасовими рамками, тому необхідно досягти, беручи до уваги ситуацію і бізнес-середовище?

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

Визначте і дізнайтесь область дії Що на вході і що на виході? Що слід виконати або здійснити, і до якого часу? Визначте “підлягає” і “дієслово” Це дуже часто не береться до уваги і є основною причиною зміщення області дії. Якщо дієслово не один, а декілька, подумайте, не сформулювати його як окреме вимога. Це робить ситуацію більш зрозумілою і сприяє її кращому розумінню зацікавленими сторонами. Важливо що, а не як Бізнес-вимоги завжди висловлюють, що повинно бути зроблено, і слід уникати вказівок на те, як це можна зробити. Наприклад, підприємству можуть знадобитися суб’єктивні, цілісні уявлення їх ділової інформації. Тоді в центрі уваги має бути те, що потрібно зробити, а не те, що необхідно отримати (наприклад, сховище даних).

Приклад вимог


У ESC є кілька Web-додатків. Оскільки кожен додаток розроблялося самостійно, клієнти стикаються з такими проблемами, як необхідність реєструватися окремо в кожному додатку і працювати з різними уявленнями для кожної бізнес-функції, що викликає невдоволення. У відповідь на це бізнес-група ESC сформулювала наступну вимогу:


BR264: Клієнти повинні мати доступ до всіх програм ESC через єдиний інтерфейс і реєструватися тільки один раз. ESCWeb (основний комерційний Web-сайт) повинен мати однаковий вигляд і функції для всіх клієнтів. У результаті повинно скоротиться кількість помилок користувачів, а зручність роботи з сайтом – підвищитися. ESCWeb також повинен підтримувати мобільних і віддалених клієнтів.

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


BR264: В ESC5.0 клієнти зможуть одноразово зареєструватися для всіх додатків ESC, в тому числі ESCWeb, ESCOrderStatus, ESCVendor і ESCSupport.

BR265: В ESC5.0 у всіх додатках ESC реалізуються ESC Web Standard 273-1 і 273-2, що призведе до зменшення кількості помилок користувачів на 10%.



Прийом 1. Визначення бізнес-вимог в RequisitePro


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



  1. Визначте Requirement Type (Тип вимоги) для бізнес-вимог. Всі бізнес-вимоги отримають цей тип. BUS – Це звичайний префікс.
  2. Визначаючи тип вимог, використовуйте опцію Requirement Must Contain (Вимога повинно містити) для вказівки роздільника (наприклад “/”). Підмет і дієслово можуть міститися по яку сторону від роздільника. Це не обов’язково для дотримання; в керівництві RequisitePro є більш докладний опис. Ідея в тому, щоб обережно ввести порядок при визначенні підмета-дієслова для вимог.
  3. Створіть пакет для бізнес-вимог на вищому рівні. Ви відразу ж побачите, як це покращує послежіваемость.

Прийом 1 завершений. Ви записали зрозуміле і точне бізнес-вимога, і готові перейти до наступної фази. Цей прийом показаний на рисунку 2.


Рисунок 2. Використання прийому 1 для запису бізнес-вимоги
Зображення, що ілюструє прийом 1 


Варіанти використання


Прийом 2 (Зв’язок варіантів використання з вимогами) стосується наступної фази проекту. Як тільки бізнес-вимоги будуть визначені, бізнес-архітектор чи аналітик розробляє варіанти використання для більшої ясності. Бізнес-аналітики часто стикаються з двома проблемами, особливо у великих або складних проектах:


Як бізнес-вимоги пов’язані з варіантами використання? Варіанти використання охоплюють користувальницьке уявлення, вони визначають дії користувача і відповіді системи. Але бізнес-вимоги служать не тільки джерелом для створення варіантів використання. Коли їх визначають як функціональні вимоги, вони направляють зміст варіантів використання. Коли їх визначають як якості або обмеження, вони стають атрибутами (або альтернативними потоками) варіантів використання. Ми повинні вміти записувати природний зв’язок між бізнес-вимогою і варіантом використання та здійснювати з ним значимі операції, наприклад трасування або аналіз.


Існує велика кількість матеріалу з моделювання варіантів використання. Огляд варіантів використання виходить за рамки цієї статті, проте ми представимо угоду про імена, що застосовується в реалізації прийому.


Принцип іменування для варіантів використання


Чому має значення ім’я варіанти використання? Згадайте, для визначення вимог ми ввели структуру підмет-дієслово. Це поняття тут розширене. У моделі варіанту використання підмет представлено виконавцями (actors). Наш принцип іменування варіантів використання полягає в тому, що варіанти використання повинні бути названі за допомогою теперішнього часу або герундія (ing-форми) дієслова. В деяких випадках це допомагає включити ім’я об’єкта, модифікованого дієсловом.



Прийом 2. З’єднання варіантів використання з вимогами


Тепер пора визначити варіанти використання і з’єднати їх з вимогами. Цілі цього прийому – підтримувати ясність у визначенні варіантів використання та забезпечити їх зв’язок з вимогами (трассируемого), виконуючи наступні кроки.



  1. Якщо ваш проект RequisitePro не містить пакета для варіантів використання або типу вимог для варіантів використання, створіть їх.
  2. Зв’яжіть модель Rose з проектом RequisitePro, використовуючи діалогове вікно Associate Model to RequisitePro project (Зв’язати модель з проектом RequisitePro). Переконайтеся, що в якості Default Requirement Type (Типу вимоги за замовчуванням) встановлено Use Case (Варіант використання).
  3. Тепер можете починати створювати моделі в Rose. Для кожного варіанту використання спочатку створіть вимога RequisitePro типу Use Case з ім’ям, відповідним принципом іменування, як показано на Малюнку 3. Введіть ім’я в Requirement Text (Текст вимоги).

    Рисунок 3. Принцип іменування варіанту використання


  4. Тепер поновіть View. Ви побачите бізнес-вимоги, які не мають пов’язаних з ними варіантів використання. Ви можете створити повний звіт View, Пропустивши кроки 2 і 3.
  5. Подання Dangler створюються шляхом інверсії критеріїв Query в цьому прийомі. Ми починаємо з вимог типу в колонці (варіанти використання) і вибираємо вимога Traced-to BUS. Це подання відображає всі посилаються на неіснуючий об’єкт варіанти використання.

Цей прийом завершений. Ви трасували варіанти використання до початкового бізнес-вимоги і усунули випадкові (помилкові) варіанти використання і незавершені бізнес-вимоги. Ваш проект тепер може спокійно переходити в стадію рішення.



Висновки


У цій статті розглянуті основи вироблення вимог і представлені три нові прийому для управління архітектурними вимогами. У ній дано огляд основних принципів вимог і описані три прийоми для управління бізнес-вимогами, варіантами використання і трассируемого.


Тим не менш, ми все ще перебуваємо на етапі завдання. Налаштуйтеся на роботу до частини 2, яка познайомить вас з етапом рішення і різними стадіями розробки рішень (в плані архітектури), і розгляне нові прийоми з управління створенням рішень.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*