Лекція 8. Управління вимогами

ПЗ продовжує проникати у все нові і нові області людської діяльності, і сформулювати адекватні вимоги в цьому випадку взагалі виявляється суперважким завданням. Віді вимог: функціональні вимоги, нефункціональні вимоги. Властивості вимог: ясність і недвозначність, повнота і несуперечність, необхідний рівень деталізації, прослеживаемость, тестируемость і проверяемость, модифікується. Формалізація вимог. Цикл роботи з вимогами.

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

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

У результаті, далеко не очевидно, що ту систему, яку хоче замовник, взагалі можна зробити. Важко знайти чорну кішку в темній кімнаті, особливо якщо її там немає. Або те, як зрозуміли і утілили завдання розробники, виявиться зручним, затребуваним на ринку.

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

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

Тепер трохи докладніше про змінність ПЗ і її причинах.

• Міняється ситуація на ринку, для якого призначалася система або вимоги до системи повзуть із-за перспектив продажу ще неготової системи, що швидко змінялися.

• В ході розробки виникають проблеми і труднощі, через які підсумкова функціональність міняється (видозмінюється, урізується).

• Заказчик может менять свое собственное видение системы: то ли он лучше понимает, что же ему на самом деле надо, то ли выясняется, что он что-то упустил с самого начала, то ли выясняется, что разработчики его не так поняли. В общем, всякое бывает, важно лишь, что теперь заказчик определенно хочет иного.

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

Види і властивості вимог

Розділимо вимоги на дві великі групи – функціональні і нефункціональні.

Функціональні вимоги є детальним описом поведінки і сервісів системи, її функціонала. Вони визначають те, що система повинна уміти робити.

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

Сформулюємо ряд важливих властивостей вимог.

• Ясність, недвозначність — однозначність розуміння вимог замовником і розробниками. Часто цього важко досягти, оскільки кінцева формалізація вимог, виконана з погляду потреб подальшої розробки, важка для сприйняття замовником або фахівцем наочної області, які повинні проінспектувати правильність формалізації.

• Повнота і несуперечність.

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

• Прослежіваємість — важливо бачити те або інша вимога в різних моделях, документах, нарешті, в коді системи. А то часто виникають питання типу – "Хто знає, чому ми вирішили, що такий-то модуль повинен працювати таким чином ..?". Прослежіваємость функціональних вимог досягається шляхом їх дроблення на окремі, елементарні вимоги, привласнення ним ідентифікаторів і створення моделі трасування, яка в ідеалі повинна протягуватися до програмного коду. Хочеться наприклад, знати, де потрібно змінити код, якщо дана вимога змінилася. На практиці повна формальна прослеживаемость труднодостижима, оскільки логіка і структура реалізації системи можуть сильно не співпадати з такими для моделі вимог. У результаті одна вимога виявляється сильно "розмазало" за кодом, а та або інша ділянка коду може впливати на багато вимог. Але прагнути до прослеживаемости необхідно, розумно суміщаючи формальні і неформальні підходи.

• Тестіруємость і проверяемость — необхідно, щоб існували способи відтестувати і перевірити дану вимогу. Причому, важливо обидва аспекти, оскільки часто проверить-то замовник може, а ось тестувати дану вимогу дуже важко або неможливо з причини обмеженості доступу (наприклад, з міркувань безпеки) до оточення системи для команди розробника. Отже, необхідні процедури перевірки – выполнение тестів, проведення інспекцій, проведення формальної верифікації частини вимог і ін. Потрібно також визначати "планку" якості (чим вище якість, тим воно дорожче стоїть!), а також критерії повноти перевірок, щоб що виконують їх і керівники проекту чітко усвідомлювали, що саме перевірене, а що ще немає.

• Модифікується. Визначає процедури внесення змін у вимоги.

Варіанти формалізації вимог

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

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

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

2. Вимоги у вигляді документа – опис наочної області і її властивостей, технічне завдання як додаток до контракту, функціональна специфікація для розробників і так далі

3. Вимоги у вигляді графа із залежностями в одному із засобів підтримки вимог (IBM Rational RequisitePro, DOORS, Borland CALIBERRM і нек. ін.). Таке уявлення зручне при частій зміні вимог, при відстежуванні виконання вимог, при організації "прив'язки" до вимог завдань, людей, тестів, коду. Важливо також, щоб була можливість легко створювати такі графи з текстових документів, і навпаки, створювати презентаційні документи по таких графах.

4. Формальна модель вимог для верифікації, модельно-орієнтованого тестування і так далі

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

Деякі помилки при документуванні вимог. Перерахуємо ряд помилок, що зустрічаються при складанні технічних завдань і інших документів з вимогами.

• Опис можливих рішень замість вимог.

• Нечіткі вимоги, які не допускають однозначну перевірку, залишають недомовленості, мають відтінок рад, обговорень, рекомендацій: "Можливо, що має сенс реалізувати також...", "і так далі".

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

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

Цикл роботи з вимогами

У зведенні знань по програмній інженерії SWEBOK визначаються наступні види діяльності при роботі з вимогами.

• Виділення вимог (requirements elicitation), націлене на виявлення всіх можливих джерел вимог і обмежень на роботу системи і витягання вимог з цих джерел.

• Аналіз вимог (requirements analysis), метою якого виявлення і усунення суперечностей і неоднозначностей у вимогах, їх уточнення і систематизація.

• Опис вимог (requirements specification). В результаті цієї діяльності вимоги повинні бути оформлені у вигляді структурованого набору документів і моделей, який може систематично аналізуватися, оцінюватися з різних позицій і у результаті повинен бути затверджений як офіційне формулювання вимог до системи.

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