Який правильний спосіб створити документи з вимогами?

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

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

Я дуже здивований, що поки ніхто ще не рекомендував використовувати вікі для вимог стеження.

Я знайшов це майже ідеальною системою, оскільки:

• Це дозволяє людям співпрацювати над вимогами та робить цей аспект добре помітним;
• Це дозволяє легко оновлювати вимоги по мірі прогресування проекту;
• Ви можете зайти і переглянути історію в будь-який час, у випадку суперечки "це не те, про що ми домовилися";
• Більшість сучасних вікі мають пристойні можливості форматування, тому це виглядає майже так само добре, як Word Word;
• Ви можете гіперпосилання безпосередньо зі своїх вимог у фактичну документацію;
• Вам ніколи не потрібно турбуватися про людей, які працюють з різними / застарілими копіями;
• Вимоги можуть почати трактуватися як ітераційний процес, як і розробка / реалізація;
• Якщо вимоги стають справді великими / складними, їх легко розділити на сторінки / теми.
• Більшість вікі-сервісів приймають HTML, тому якщо вам справді потрібне розширене форматування, ви, ймовірно, можете використовувати такий інструмент, як Windows Live Writer .

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

Я завжди використовую IEEE Std 830-1998 (рекомендована IEEE практика щодо специфікацій вимог до програмного забезпечення) як шаблон для мого документа SRS. Дивіться http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html

Остаточний документ SRS, як правило, є єдиним документом OpenOffice.org, але зазвичай в ньому входить багато складових частин, включаючи електронні таблиці та діаграми.

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

Пам'ятайте, що SRS - це живий, еволюціонуючий документ. Він буде продовжувати змінюватися і рости деякий час. Не тільки важливо, щоб усі зацікавлені сторони мали доступ до СРС, але також важливо мати повну історію змін та можливість відмовити ці зміни, якщо це необхідно. Таким чином, система контролю ревізії чудово працює для цієї мети. Удачі!

Використання інструмента пошуку помилок для управління вимогами має тенденцію приховувати відсутність співпраці та комунікацій всередині компанії.

Не приймаючи рішення про якийсь конкретний метод:

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

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

Звичайно, вони зробили це без огляду на:

• власна кваліфікація
• їхня частка в проекті
• суперечить іншим вимогам
• прогалини в вимогах
• витрати
• будь-які технічні міркування
• тощо.

Я вважаю, що документи "Word" - це неправильний шлях до вимог з наступних причин:

1. Ні в якому разі не можна "відрізняти" два документи, щоб побачити, що змінилося.
2. Користувацький інтерфейс відмовляє від використання послідовного стилю впродовж усього. Так, використовувати стилі можна, але більшість людей не можуть турбуватися через труднощі.
3. Формат документа по суті прихований. Звичайно, є специфікація файлів OLE, які, мабуть, є у документах Word, але Microsoft захопила все корисне під тонни блату, тому ніхто насправді не знає. Рано чи пізно ваше блискуче нове "Слово" не відкриє документ.
4. Не грає добре з іншими форматами. Тобто, якщо ви не використовуєте Windows та IE, вам не пощастить, якщо хтось організував документи проекту у файлах HTML із посиланнями на файли формату «Word». Клацніть неправильне посилання, і вам доведеться провести довгий період завантаження і запуску-Word, перериваючи потік думки. Гіперпосилання з "Word" -документів до інших можуть працювати або не працювати.
5. "Слово" - це в основному для написання документів, призначених для появи на папері. Приємна мета, але така, яка робить її менш корисною для перегляду в режимі он-лайн.

У мене немає альтернативних пропозицій, з якими я маю досвід роботи, але я подумав про переструктурований текст Python або Markdown як альтернативу.

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

Також ми можемо використовувати різні файли pdf, Excel або Visio. Усі вони для проекту збираються та редагуються з SharePoint, тому ми можемо побачити більш ранні версії, якщо це потрібно.

Я підтримую відставання продукту (по одному на проект чи продукт), що містить Історії користувачів . Вони можуть зберігатися в програмному забезпеченні для відстеження помилок, як і те, що ви використовуєте. Я особисто використовую Excel для відставання та Trac для спринт-відставання (ви, мабуть, використовуєте такий інструмент, як цей інструмент).

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

З невеликими історіями користувачів простіше керувати (включаючи оцінку)

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

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

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

Мені навіть не спадало на думку використовувати інструмент відстеження помилок, але це має повний сенс.

З цікавості, що це з того, що вам не подобається?

EDIT: один застереження; скажіть своєму менеджеру провести ребрендинг програмного забезпечення для відстеження помилок. Інакше все в ньому вважається помилкою. У мене була ця політична проблема у мого останнього клієнта, де я ставив завдання в програмі пошуку помилок. Не добре.

Я писав базу даних вимог 6 або 7 років тому, щоб вирішити це. Кожен запис вимог містить короткий опис, нагадування "визначення" та нагадування "примітки" (обидва тексти з можливістю вставляти знімки екрана тощо). Є й інші поля для проекту, доставлення, порядкового номера (тому їх можна впорядкувати логічно), використання випадку / функції, пов’язаних із ним, оцінка часу, поле для людини, що обробляє його, якщо хтось обрав його для реалізації, тощо.

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

Хитрість зробити це добре - це розумна деталізація. Іноді може бути сенс мати вимоги до одного речення (наприклад, "проблема, описана у випуску 12345, виправлена"), але в цілому вимоги повинні описувати всі важливі аспекти цілої функції (або великий фрагмент). Наприклад, типова функція "нового звіту" матиме вимогу до формату звіту (як виглядає вихід) та вимога до діалогового вікна параметрів (пояснення полів, перевірка вантажу тощо). є складний генератор, який розсипає дані, а не просто простий запит чи щось таке. Крім того, ми створимо вимогу "Довідка" для відповідної теми довідки.

Є величезні переваги зберігання цього матеріалу в записах баз даних, а не у великому документі. Кілька програмістів можуть працювати над вимогами одночасно. Окремі записи заблоковані, тож одночасно може редагувати лише одна людина, але їх можна відкривати та читати, поки хтось інший редагує. Найбільша перевага, однак, полягає в тому, що вона забезпечує легкий пошук документації як вимог, так і приміток про те, як вони були виконані. Зараз у нас понад 25 000 вимог, і ми можемо легко знайти всі вимоги з конкретними словами у всіх полях, або визначення, або примітки, або що завгодно, за 10 секунд. (Спробуйте це з документами Word більше 6 років.)

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

Я колись використовував http://www.pivotaltracker.com/, але в моїй теперішній компанії ми використовуємо .doc як основне джерело специфікації та Маяк як комбіновані функції списку бажань та відстеження проблем. Мені важко змусити інших людей в команді почати використовувати будь-які інші інструменти, коли вони так сильно звикли до Word.

Якщо ви можете дотримуватися методології Agile, наступні посилання можуть допомогти вам у виборі хорошого інструменту управління Agile Project:

• Agile Інструменти управління проектами
• Порівняння різних інструментів управління Agile Project

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

Удачі!