Написання специфікації вимог до програмного забезпечення


15

У мене є кілька запитань щодо написання специфікації, і вони:

  1. Коли ми пишемо специфікацію програмного забезпечення, під темою "Визначення вимог користувачів" ми повинні вказати лише "Функції" та "Обмеження"?

  2. Чи потрапляє "Користувацький інтерфейс" у "функції" чи "обмеження"?

  3. На які основні сфери (вимоги) програмне забезпечення може бути розбито (наприклад, інтерфейс користувача)?


Ця стаття може бути корисною: 10 типових помилок у специфікаціях
yegor256

Відповіді:


16

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

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

Ось посилання на додаткову інформацію про шаблон:

http://www.volere.co.uk/template.htm

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

Ось короткий опис розділів у ньому (цитується за вищенаведеним посиланням):

  1. Мета проекту

  2. Зацікавлені сторони

  3. Обмежені обмеженнями

  4. Названня конвенцій та визначень

  5. Релевантні факти та припущення

  6. Сфера роботи

  7. Модель бізнес-даних та словник даних

  8. Сфера застосування продукту

  9. Функціональні вимоги та вимоги до даних

  10. Подивіться і відчуйте вимоги

  11. Потреби в користуванні та людстві

  12. Вимоги до виконання

  13. Експлуатаційні та екологічні вимоги

  14. Вимоги до технічного обслуговування та підтримки

  15. Вимоги безпеки

  16. Культурно-політичні вимоги

  17. Юридичні вимоги

  18. Відкриті випуски

  19. Позаставні рішення

  20. Нові проблеми

  21. Завдання

  22. Міграція до нового продукту

  23. Ризики

  24. Витрати

  25. Документація та навчання користувачів

  26. Зал очікування

  27. Ідеї ​​для рішень


10

Рекомендую прочитати Joel на програмному забезпеченні. Я не впевнений, чи відповідає він на ваші конкретні запитання, але він має чудовий огляд того, що означає писати функціональні характеристики :

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

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

... Коли ви пишете специфікацію, вам потрібно лише повідомити, як програма повинна працювати один раз . Усі в команді можуть просто прочитати специфікацію. Люди з якості контролю читають його, щоб вони знали, як повинна працювати програма, і вони знали, для чого перевірити. Люди, що продають маркетинг, використовують його для написання своїх розпливчастих білих паперів для випуску на веб-сайті про продукти, які ще не створені. Люди з розвитку бізнесу неправильно читають, щоб розпочати дивні фантазії про те, як продукт виліковує облисіння, бородавки та інше, але це отримує інвесторів, тож це нормально. Розробники прочитали його, щоб вони знали, який код написати. Клієнти читають його, щоб переконатися, що розробники будують продукт, за який вони хочуть заплатити. Технічні письменники прочитали його і написали хороший посібник ...

Коли у вас немає специфіки, все це спілкування все-таки відбувається, оскільки воно має бути , але це трапляється ad hoc . Люди QA дуріють з програмою мимоволі, і коли щось виглядає дивно, вони йдуть і перебивають програмістів ще раз, щоб задати їм ще одне дурне питання про те, як річ повинна працювати ...

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


@gnat Я не думаю, що цитата зі статті не потрібна. Якщо ви хочете виділити свій вибір уривків, пропоную вам опублікувати власну відповідь на питання.
Джонатан Свінні

Ви можете прочитати Вашу відповідь в іншому замку: коли відповідь не відповідь? "Дозвольте мені бути зрозумілим: такий варіант відповіді - це не відповідь . Якщо ви бачите це, позначте це. Модератори, якщо ви бачите його позначеним, видаліть його "
gnat

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

6

Коли ми пишемо специфікацію програмного забезпечення, під темою "Визначення вимог користувачів" ми повинні вказати лише "Функції" та "Обмеження"?

Вимога - це поєднання двох речей ...

  1. Що річ робить. Функціональна вимога.
  2. Як добре це робить. Нефункціональна вимога або "обмеження"

Чи потрапляє "Користувацький інтерфейс" у "функції" чи "обмеження"?

Я б сказав, що "Інтерфейс користувача" буде категорією вимог, як ви визначили в своєму останньому запитанні.

На які основні сфери (вимоги) програмне забезпечення може бути розбито (наприклад, інтерфейс користувача)?

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

Звичайно, все це є другорядним для вашої реальної мети, яка полягає у визначенні чіткого, однозначного та перевіряемого опису програмної системи.


4

Основна вимога до вимоги - це тестування. Якщо ви не можете зрозуміти, як перевірити вимогу, шанси на те, що вона не буде реалізована так, як планував автор.

Я ніколи не бачив документа з вимогами, обмеженим лише функціями та обмеженнями, але я можу побачити певну цінність у такій структурі - це змушує письменника класифікувати вимоги до "речей, які програмне забезпечення повинно робити" та "правила правил потрібно дотримуватися програмного забезпечення ".

Я думаю, що в користувальницькому інтерфейсі є вимоги в обох категоріях

Обмеження:

  • "на екрані запуску відображаються дві кнопки:" Пуск "і" Стоп "
  • "Шрифт дисплея повинен бути не менше 10 точок."

Функції:

  • "При Startнатисканні клавіші програмне забезпечення встановлює TCP / IP-з'єднання з WOPR "

Ваші приклади не вимоги, вони дизайн. Конкретність того, як потрібно виконати вимогу, є дизайнерським рішенням, а не вимогою. Таким чином, "дві кнопки" - це дизайнерське рішення. Це стає очевидним, коли ви розумієте, що існує багато інших дійсних способів досягнення тієї ж мети (щось почати чи зупинити). Таким чином, щоб зробити його більш вимогою, ви б сказали, що "Інтерфейс повинен забезпечити запуск і зупинку чогось". Але я б пішов далі, адже використання інтерфейсу - це також дизайнерське рішення. Отже, для системної вимоги це було б "Система повинна забезпечити запуск і зупинити щось"
Данк
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.