Як швидко та ефективно написати функціональну специфікацію

Тому я просто прочитав тут чудові статті Джоеля про технічні характеристики . (Написано у 2000 році !!) Я прочитав усі 4 частини, але шукаю деякі методичні підходи до написання моїх специфікацій.

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

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

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

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

Отже, вся справа складається з

• Веб-сайт MVC (для перегляду адміністраторів та даних)
• 2 модулі Silverlight (для 2 конкретних завдань)
• 1 настільний додаток

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

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

Я думаю створити підроблений проект ASP.NET Web Forms, потім заповнити HTML- файли у папках і зробити це схожим на мою структуру URL-адреси MVC.

Тоді маючи розділ у специфікації для веб-сайту та записуйте сторінку для кожної URL-адреси, яку я отримав із екраном.

Для мого додатка виграшних форм я створив дещо демонстраційний проект Win Form, чи ставлю я тоді діалогове вікно або структурую все так, як було б у реальному додатку, а потім знімав його на екрані?

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

(І до цього часу йде добре, сьогодні я подав демонстрацію версії для попереднього перегляду, яка дуже сподобалась багатьом людям !! = D)

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

Чи читали ви частину статті та його специфікацію зразка ? Вони втілюють пару важливих принципів при написанні специфікації.

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

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

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

Про написання

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

• Знайте свою аудиторію. Хто повинен прочитати специфікацію? Якщо це лише ви та клієнт, то це те, кому ви пишете. Якщо у вас є хтось, хто відповідає за тестування, ви також будете мати кілька приміток до них.
• Почніть з найвищого пріоритету. Хоча автентифікація важлива, екран входу, мабуть, найкраще зрозумілий твір, який мають писати більшість людей. Натомість зосередьтесь на тій функції, яка найбільше потребує ваших користувачів. Ви знаєте, саме та частина, яка заробляє на них гроші, і є цілою причиною, що їм потрібно програмне забезпечення.
• Заповніть деталі, як з’являються запитання, і ви отримаєте відповіді. Зберігайте речі по-справжньому просто, накресливши серветки, якщо необхідно, поки клієнт не буде задоволений домовленістю. Важливо знати, про яку інформацію йдеться і як вони будуть її використовувати.
• Зупинка при додаванні більше не додає значення. Є деякі деталі, які ви просто не хочете в специфікації. Вам потрібно знати, коли у вас є правильна річ. Не потрібно знати, що всередині методу, який називається "albaquerque", є змінна. Це вихідний код, а не специфікація.