Лекція №10. Документування вимог у відповідності зі стандартами

Стандарти документування вимог до ПЗ:

1.міжнародний, ІЕЕЕ Std 830-1998 = у ньому містяться рекомендації до структури і методів опису програмних вимог (Recommended Practice for Software Requirements Specifications)

2.наш, ГОСТ 34.602-89 = технічне завдання на створення автоматизованої системи (Інформаційна технологія. Комплекс стандартів на автоматизовані системи)

3.наш, ГОСТ 19.201-78 = ТЗ, вимоги до вмісту та оформлення (Єдина система програмної документації)

Документування вимог регламентується російським ГОСТ 19.201-78, 34.602-89. Другий документ, по суті, є більш проробленою версією першого, адаптованою до створення автоматизованих інформаційних систем (АІС). Використовуються на даний момент.

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

Зміст ГОСТ 34.602-89:

1.загальні відомості = у цьому розділі крім юридичних реквізитів сторін ГОСТ рекомендує вказувати джерела і порядок фінансування робіт.

2.призначення і цілі створення або розвитку системи = тут необхідно вказати показники об’єкту автоматизації, які повинні бути досягнуті, і критерії оцінки досягнення цих показників.

3.характеристика об’єктів автоматизації = організаційна структура, структура управління, структура розміщення підприємства і його філіалів. Гарний опис об’єкту автоматизації дозволяє зекономити час на визначення класів користувачів.

4.вимоги до системи

4.1.вимоги до структури системи у цілому = режими функціонування системи, персоналу (чисельність, необхідна кваліфікація, режим роботи), вимоги до надійності, безпеки, стандартизацій та уніфікацій, та інші;

4.2.вимоги до функцій (задач, що виконуються системою) = перелік функціональних вимог у прив’язці до підсистем і чергам автоматизації, часовий регламент реалізації функціональних вимог, вимоги до якості реалізації кожного із функціональних вимог, перелік і критерії відмов (??) для кожної функціональної вимоги;

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

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

6.порядок контролю і прийому системи = розподіляє ролі замовника і розробника у підготовці системи до тестування і його проведення (формулювання основних тестових сценаріїв і критеріїв прийому).

7.вимоги до складу і змісту (вмісту) робіт по підготовці об’єкту автоматизації до вводу системи у дію = обумовлюється порядок проведення реінженерингу підприємства, який необхідно здійснити для того, щоб досягти від впровадження АІС належного ефекту.

8.вимоги до документування = перелік і форми документації, що підлягає розробці.

9.джерела розробки = перелік документів, що містять передумови розробки.

Документування вимог Rational Unified Process (RUP)

RUP – методологія створення ПЗ, розроблена Rational Rose. Шаблон SRS, запропонований у RUP, по суті, представляє собою контейнер, у який необхідно упакувати артефакти, що отримані у процесі специфікування вимог. Крім того, SRS частково перекликається з документом бачення-концепції. Шаблон зручний своєю компактністю і лаконізмом.

1.Введення

1.1. Мета = документ повинен вичерпним чином описувати зовнішню поведінку системи, а також нефункціональні вимоги і обмеження

1.2. Коротке зведення можливостей

1.3. Визначення, акроніми і скорочення

1.4. Посилання

1.5. Короткий зміст

2.Огляд системи

2.1. Огляд прецедентів = містить список імен і коротких описів варіантів використання та акторів з ілюстраціями у вигляді діаграм прецедентів

2.2. Припущення і залежності = описує ключові технічні можливості, компоненти, підсистеми, зв’язані проекти, які можуть впливати на шви.. здатність (???) розроблюваної системи; припущення = положення, яке вважається істинним при відсутності доведення або визначаючої інформації; при визначенні залежностей проекту від зовнішніх факторів необхідно проаналізувати які нові ОС, регламенти бізнес-процесів, стандарти якості, інформаційні системи можуть з’явитися на підприємстві і як це може вплинути на функціонування виготовлюваної АІС

3.Опис вимог

3.1. Опис варіантів використання = містить опис варіантів використання і зв’язаних з ними нефункціональних вимог або посилання на відповідні артефакти

3.2. Спеціальні вимоги = містить опис функціональних вимог (не описаних як варіанти використання), а також опис нефункціональних вимог загального характеру (не співставлених жодному преценденту у попередньому розділі) або посилання на відповідні артефакти

4.Допоміжна інформація = сюди включається інформація, що полегшує розуміння документу, це може бути зміст і додатки, наприклад, що описують прототипи користувальницького інтерфейсу

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Лекція №8. Модель предметної області. Онтологія. Особливості онтологічного стандарту IDEF5	\|	Тема1. Теорія адміністративного менеджменту

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.012 сек.