- •7 Лекції
- •1. Основи програмних вимог (Software Requirements Fundamentals)
- •2. Процес роботи з вимогами (Requirements Process)
- •2.1 Модель процесу визначення вимог:
- •2.2 Учасники процесів (Process Actors)
- •2.3 Управління та підтримка процесів (Process Support and Management)
- •2.4 Якість та поліпшення процесів (Process Quality and Improvement)
- •3. Витяг вимог (Requirements Elicitation)
- •3.1 Джерела вимог (Requirement Sources)
- •3.2 Техніки вилучення вимог (Elicitation Techniques)
- •4. Аналіз вимог (Requirements Analysis)
- •4.1 Класифікація вимог (Requirements Classification)
- •4.2 Концептуальне моделювання (Conceptual Modeling)
- •4.3 Архітектурне проектування та розподіл вимог (Architectural Design and Requirements Allocation)
- •5. Специфікація вимог (Requirements Specification)
- •5.1 Визначення системи (System Definition Document)
- •5.2 Специфікація системних вимог (System Requirements Specification)
- •5.3 Специфікація програмних вимог (Software Requirements Specification - srs)
- •6. Перевірка вимог (Requirements Validation)
- •6.1 Огляд вимог (Requirements Review)
- •6.2 Прототипування (Prototyping)
- •6.3 Затвердження моделі (Model Validation)
- •6.4 Приймальні тести (Acceptance Tests)
- •7. Практичні переконання (Practical Considerations)
- •7.1 Ітеративна природа процесу роботи з вимогами (Iterative Nature of the Requirements Process)
- •7.2 Управління змінами (Change Management)
- •7.3 Атрибути вимог (Requirements Attributes)
- •7.4 Трасування вимог (Requirements Tracing)
- •7.5 Вимірювання вимог (Measuring Requirements)
7.4 Трасування вимог (Requirements Tracing)
Трасування вимог забезпечує зв'язок між вимогами та відстеження джерел вимог. Трасування є фундаментальною основою проведення аналізу впливу (impact analysis) при зміні вимог, допомагаючи передбачати ефект від внесення таких змін. Трасування передбачає спрямований зв'язок (подається у вигляді складного спрямованого ациклічного графа) між вимогами, тобто залежності.
Вимоги (B) аолодіють зворотною залежністю (тобто вторинні) по відношенню до вимог (A) і зацікавлених осіб, які є джерелом або утворюють причину появи аналізованих вимог (B). І, навпаки, вимоги (A) трасуються безпосередньо до тих вимог (B) і елементів дизайну (наприклад, моделі або, в загальному випадку, коду, запитів на зміни і т.п.), які породжуються або задовольняють вимогам (A).
7.5 Вимірювання вимог (Measuring Requirements)
З практичної точки зору, звісно, корисно мати щось, що дозволяє визначити "обсяг" вимог для заданого (створюваного) програмного продукту. Це число корисно для дослідження "масштабів" змін у вимогах, оцінки вартісних характеристик (cost estimation) розробки та підтримки програмної системи, опосередковано - оцінки продуктивності розробки та ефективності підтримки на етапах реалізації вимог і внесення змін і т.п.
Вимірювання об'єму функціональності (Functional Size Measurement, FSM) техніка такого роду чисельної оцінки, визначена на концептуальному рівні в стандарті IEEE 14143.1. Стандарти ISO/IEC та інші джерела описують приватні методи FSM (наприклад, модель COCOMO II для оцінки вартості, наприклад, можуть використовуватися в тісному зв'язку з методами функціональних точок - functional points для оцінки масштабів функціональності, тобто вимог, поставлених до заданої програмної системи).
Додаткова інформація про стандарти та підходи в оцінці масштабів подана в галузі знань "Процес програмної інженерії" (Software Engineering Process).
На додаток до практичних міркувань, представленим у SWEBOK, на тлі загальної тенденції розробки моделей <оцінки> зрілості, варто зазначити, що існують певні роботи і по створенню різних моделей зрілості вимог. Наприклад, найбільш популярна модель зрілості в індустрії програмного забезпечення - CMMI включає різний обсяг і зміст робіт з визначення і управління вимогами для рівнів зрілості 2 і 3.