Чим відрізняються вимоги та технічні характеристики? [зачинено]


122

Мені доручено розробляти вимоги та технічні характеристики для проекту, який розпочинає наша група.

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


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

1
Так, саме тому люди повинні говорити "Бізнес-вимоги" та "Технічні умови" / "Технічні умови" чи щось таке. Слова самі по собі досить розпливчасті.
user606723

Подумайте про це так (грубо кажучи): Вимоги = вимоги doc та технічні характеристики = docs-use / design docs
PhD

4
Чому ви не запитаєте у людини, яку ви робите? Тільки вони можуть відповісти, що потрібно у вашому конкретному випадку .
Яап

Ця стаття пропонує ґрунтовну відповідь: ece.cmu.edu/~koopman/des_s99/requirements_specs
Julien-L

Відповіді:


129

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

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


4
Що / як звук прикус право, свого роду; але заплутано, тому що ви також можете розглянути специфікацію програми як опис того, що вона повинна робити, а дизайн як те, як це робити. Інший - декларативний pl (наприклад, prolog та SQL), в якому ви заявляєте що не як . Одна з резолюцій полягає в тому, що вони є ієрархічною абстракцією, батько вказує, що, а діти заявляють, як (зовні та всередині). Я набагато більше віддаю перевагу вашому другому погляду, який ближче до того, «що це за » проти «що це таке », тобто користь проти особливості.
13рен

Я, як правило, погоджуюся з вами, але це просто "інша" думка, а не правильна відповідь. Наприклад, подивіться на сторінку Вікі щодо вимог ( en.wikipedia.org/wiki/Requirement ). Існують нефункціональні вимоги, які за визначенням ставляться до технічної групи. Або вимоги архітектури та обмежень, знову ж таки технічні, але вони не називають їх "специфікаціями". Я думаю, що правильної відповіді немає, і вона завжди буде "розмитою" від компанії до компанії та від розробника до розробника.
Jeach

1
Подивіться на відповідь "Адам Вюрль" нижче, я думаю, що це найточніше твердження на розміщене запитання.
Jeach

1
@Jeach: "нижче" [sic] відносний. Наразі воно може бути нижче цієї публікації, але воно може перейти вище, що зробить ваш коментар важче зрозуміти
Брайан Оуклі

1
Інша перспектива .. Вікіпедія визначає характеристики як "набір вимог". Це означає, що специфікація може бути лише 1 вимогою, s: = {r1}. Більше здається, що розмовні "вимоги" - це вимоги "високого рівня", а "технічні характеристики" - вимоги низького рівня, річ LOD.
Ленс Поллард

38

Вимоги документують те, що потрібно - вони повинні вказувати не як, а що.

Технічні умови документують, як досягти вимог - у них слід вказати як.

У багатьох місцях ці документи не є окремими і використовуються взаємозамінно.


2
У моїй компанії ми зазвичай використовуємо терміни "специфікація вимог" для того, що (ти вказуєш, записуєш деталі, що ти що) і "специфікація дизайну" для того, як (ти вказуєш, записуєш деталі, як ти план її реалізації).
Джорджіо

16

Я системний інженер в аерокосмічній галузі, де обидва терміни широко використовуються. Відмінність чітка і не така складна, як інші.

Специфікація є документом , який визначає систему або продукт, наприклад , специфікації розробки прайм-елемента для F-14. У специфікації є багато розділів / вмісту: вимоги, визначення, довідкові документи, словник, інформація про перевірку тощо.

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

Отже, специфікація - це документ, повний вимог, а також інша допоміжна та допоміжна інформація.


4
Як я вже говорив в іншому коментарі, це дуже розмито для всіх і, мабуть, завжди буде. Але, грунтуючись на моєму ДУЖЕ великому дослідженні з цього питання, я б сказав, що ваша відповідь є найбільш точною для моїх власних висновків / висновків.
Jeach

2
Завжди корисно отримати справжній інженерний внесок. Дякую!
LeWoody

Крім того, Spec може мати 0 вимог. Ваш приклад справді хороший для дуже специфічної авіаційної інженерної дисципліни. Я не дуже впевнений, що це взагалі застосовно до домену розробки / програмування програмного забезпечення. Коли більшість програмного забезпечення керується вимогами бізнесу, є сенс почати з детального документа про вимоги бізнесу, перш ніж оцінювати технічні обмеження та розробляти рішення. Технічна специфікація повинна відповідати вимогам BRD, обмеженням у документах та надаватиме детальний та конкретний підхід до задоволення бізнес-вимог у BRD.
Брайан 'BJ' Hoffpauir Jr.

1
@ Bryan'BJ'Hoffpauir Я впевнений, що є випадки, коли документи мають маркування специфікацій і не мають до них вимог, але я заперечую, що це неправильне використання терміна. Специфікація - це документ, що пред'являється до вимог - кінець розповіді. Це загальноприйнятий термін мистецтва в більшій галузі, що стосується аерокосмічної та оборонної діяльності і недоступний в рамках системної інженерії, що є дисципліною, відповідальною за вимоги та перевірку. Навіть у випадку, коли ви описуєте термін, застосовується: BRD - це специфікація, технічна специфікація теж звучить як одна, лише з різними вимогами.
Адам Вюрль

13

Вимоги:

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

Технічні умови:

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

Цитата з "Системних інженерних основ * ".

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

* Defense Acquisition University Press, 2001. PDF версія тексту.


Я думаю, що важливо, щоб ваше визначення говорило, що специфікація визначає ПРОБЛЕМУ. Таким чином, специфіка ПРОБЛЕМ є вимогою. Технічні характеристики РЕШЕННЯ або ДИЗАЙНУ є частиною дизайну.
LeWoody

6

Вимоги - це опис користувачів, що повинен робити готовий продукт.

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

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

(Зверніть увагу на термінологію - продукт та рішення - те саме, але з різних точок зору ...)


1
Я б міняв місцями терміни "продукт" та "рішення", тому що рішення, як правило, стосується проблеми замовника, тоді як товар зазвичай стосується продавця (тобто технічного реалізатора). Аналогічний контраст - це вигода / особливість, де вигода полягає у споживчих термінах (яка користь від них), а особливість - у термінах впровадження (що насправді є , тому ми можемо це зробити)
13реч

1
Я бачу вашу думку, але я думаю, що будь-який кут адекватно описує ситуацію. Я вважав, що клієнт купує товар - як ви робите, коли ходите в магазин. Тоді постачальник програмного забезпечення пропонував би вирішити основну проблему. Якби я ходив за покупками, щоб вирішити свою проблему, я, мабуть, подумав би: "Мені потрібен продукт, що робить xyz", а не "мені потрібно вирішити проблему abc". Я думаю, що це просто питання переваги.
Арж

цікаво. Я бачу, що клієнти "шукають товар", коли існує встановлена ​​категорія товару. Але вони шукають цей продукт, тому що вони вже розробили, що це вирішить їхню проблему - тобто вони шукають цей товар не заради нього, а як рішення. Правда також, що продавець продає свій товар як "рішення" - але це тому, що вони намагаються спілкуватися з клієнтами (які шукають рішення для своїх проблем) та будують щось, що буде потрібне. Насправді побудова продукту (тобто сама річ та її особливості незалежно від того, для чого вони потрібні)
13,

Я бачу, що клієнти "шукають товар", коли існує встановлена ​​категорія товару, - але вони розглядають це як рішення проблеми / потреби. Постачальники продають свою продукцію як "рішення" - тому що вони спілкуються з клієнтами (у яких проблеми вимагають рішення). При будівництві продукту (сама річ та її особливості, а не чому вони будують їх). Один з аргументів полягає в тому, що проблема може мати дуже різні рішення, але продукт - це одна конкретна річ.
13,

[пояснюючи, чому два коментарі]: Так коментарі - це біль - натискання на "повернення" подасть коментар, навіть якщо це багаторядковий текстовий пояс. І якщо після цього вам знадобиться більше 5 хвилин, вона не прийме зміни. Отже, ви повинні надіслати це як другий коментар. Я редагував лише для того, щоб він відповідав довжині. зітхати . Наступного разу я просто перекладу два коментарі, в першу чергу ... [у всякому разі, я згоден, що точка зору - покупець / продавець - головна відмінність. Мене хвилює ваша термінологія, але я думаю, що це поглиблює моє розуміння, щоб спробувати сформулювати чому.]
13,

4

Вимога - що система (або підсистема) повинна (повинна) робити.

Специфікація - Що таке компонент, підсистема чи система.

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

Після того, як це все зроблено, вам потрібно буде підтвердити вимоги користувача щодо продукту.


3

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

Приклад шаблону стандартного SRS IEEE

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

EDIT: Я щойно помітив, що посилання невірне ... Невдовзі я опублікую правильне посилання.


1
Добрий момент щодо терміну СРС!
LeWoody

2
Зараз посилання повністю розірвано. Я не впевнений, на що він вказував, ні на який матеріал там він повинен вказувати.

3

Специфікація - це вимога, яка пройшла техніко-економічну реалізацію та готова до впровадження. Це вимога, яка переросла до етапу проектування.

Іншими словами:

  • Вимога - це поведінка (або не поведінка) "як заплановано" або "за бажанням"
  • Специфікація - це поведінка (або не поведінка) "будувати" або "як будувати"

Приклад:

  • вимога: 1. користувач натискає кнопку ОК 2. система друкує рахунок-фактуру
  • специфікація: 1. користувач натискає кнопку ОК 2. система друкує рахунок-фактуру

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

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

Зауваження: приклад вище містить елементи дизайну через обмеження дизайну.


0

Вимоги - це те, що робить додаток

Специфікації - ЯК додаток робить те, що робить.

Вони повинні бути ортогональними!

Керівники продуктів пишуть вимоги, головні інженери пишуть технічні характеристики.


2
Я не впевнений, що вони абсолютно ортогональні, принаймні на практиці. На жаль, багато сірого.
LeWoody

Вони залишаються сірими лише в тому випадку, якщо ви не залишаєте модифікаторів - Бізнес-вимоги, функціональні вимоги, нефункціональні вимоги відносяться до можливостей системи (що вона робить). Технічні характеристики є ортогональними вимогам бізнесу (як це робить).
Брайан 'BJ' Hoffpauir Jr.

0

Один із способів, можливо, не правильний погляд на це:

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

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


це лише твоя думка чи ти можеш якось підкріпити це?
гнат

2
@gnat, я думав, що це було розглянуто у початковій лінії? Звичайно, це з досвіду, і я не вимагаю нічого іншого - з того, що я збираю, це дещо суб'єктивне запитання на досить суб'єктивному форумі, і цей пост підказує, що питання повинні бути максимально об'єктивними, але мало згадує відповіді . Але у мене є одна на моє ім’я, і у вас є набагато більше, тому я відкритий для отримання освіти :-)
berad

0

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

Визначення вимоги з Негалуженого словника Вебстера (3-е нове внутрішнє видання):

а) щось, що потрібно або потрібно: необхідність b) щось, що вимагається або вимагається: необхідна або істотна умова: необхідна якість, курс або вид навчання

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


0

У попередній компанії, що створює комерційну продукцію, ми мали таке розрізнення:

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

Технічні характеристики - це те, що насправді робить вбудована система. Наприклад, у вас може виникнути вимога, згідно з якою система має поведінку X при температурі –10 ° C. Фактична специфікація системи може бути такою, що система робить X при –5 ° C; це буде в аркуші, який надсилається потенційним клієнтам, коли вони хочуть придбати систему.

Зверніть увагу: у цьому випадку специфікація не дорівнює вимозі.


-1

Подумайте, ви збираєтеся будувати багатоповерхівку на землі.

Тепер перед початком роботи потрібно розглянути вимоги, наприклад:

  1. Інженер з архітектури та дизайну
  2. Інженер з ґрунтових випробувань
  3. Команда випробувань тиску вітру
  4. Знищувач
  5. Копач
  6. Людина сила
  7. Постачання води
  8. Працівники, які живуть / відпочивають
  9. Досить фонду
  10. Управління проектами
  11. Управління якістю
  12. Контроль безпеки та безпеки

І т.д.

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

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

Вищенаведений пункт буде частиною посібника, який можна зателефонувати за Технічною специфікацією.


1
Я думаю, ви плутаєте вимоги з ресурсами ( en.wikipedia.org/wiki/Resource_%28project_management%29 ).
Джей Елстон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.