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

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

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

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

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

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

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

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

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

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

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

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