Я видел здесь несколько вопросов, говорящих, что нет необходимости писать многообещающую техническую спецификацию, если функциональная спецификация обладает всеми функциональными возможностями. Что касается ситуаций, когда клиент предоставил функциональную спецификацию, и вам нужно обернуть техническую спецификацию из этого документа?
Я понимаю, что в компании, пишущей меньше технических спецификаций, ориентированных на конкретные части решения, полезно, но если производство Технической спецификации является этапом проекта/может быть достигнуто с видимостью клиента, то какой способ лучше подойти к написанию?
Что делать, если я не знаю, как именно я собираюсь реализовать определенную функциональность, потому что я ее еще не создал? Как вы можете написать Техническую спецификацию таким образом, чтобы это играло не как катастрофу?
Я ищу шаблоны/рекомендации/рекомендации по лучшей практике и любой опыт реального мира, который может помочь мне создать документ, который можно использовать для будущих проектов такого рода.
Не будьте слишком конкретны в отношении внутренних систем.
Вы должны начать с отрывочного общего дизайна решения. Вероятно, вы знаете больше, чем думаете об окончательной архитектуре. Например: нужна ли вам база данных? сервер приложений? веб-сервисы? настольный клиент? кластеры?
Затем вы начинаете заполнять компоненты и начинаете задавать себе некоторые основные вопросы в соответствии с технологиями, которые, по вашему мнению, являются наиболее подходящими в зависимости от области проблемы и ваших знаний. Например: Java или .NET? Django или Ruby-on-Rails? JBoss или Tomcat? Монгрел или Апач? Oracle или MySQL?
Затем вы заходите за деталями. Вы все еще ничего не реализуете, это всего лишь предварительный документ, и очень вероятно, что вы все равно передумаете на полпути. Спросите себя, понадобится ли вам ORM, каркас, библиотека, специальное устройство. Например: (N) Hibernate или Toplink? Spring? JSF? Struts? Карманное устройство? Читатели штрих-кодов? Не помещайте их в техническую спецификацию, если это не заставит вас что-то изменить (например, проблемы несовместимости).
Теперь пришло время все пересмотреть.
Поиск в Интернете для альтернатив, новейших выпусков любого компонента, похожих проектов, конкурентов с открытым исходным кодом.
Добавьте данные, исправьте ошибки, изучите информацию о компонентах, о которых вы неясны.
Попросите своих коллег подтвердить доказательства вашего документа.
Не подавайте бесполезные детали, старайтесь решать проблемы большого масштаба, а не крошечные оптимизации. Сосредоточьтесь на том, что вам лучше известно. Создайте spike, когда захотите.
Каждый раз, когда вы делаете обзор, лучше сравнить эскиз архитектуры с требованиями (не забудьте нефункциональные требования).
Сделайте это итеративным процессом, чтобы вы могли его улучшить и все еще иметь готовый к отправке время для экспертных обзоров и совместной работы. Кроме того, если клиент удовлетворен достигнутым уровнем детализации, вам лучше остановиться, чтобы вы могли сосредоточиться на стадии разработки.
Возможно, вы могли бы использовать общую структуру этого документа.
http://reat.space.qinetiq.com/ssat/docs/ssat_ssd.pdf
1 INTRODUCTION 8 1.1 Contractual 8 1.2 Purpose of the Document 8 1.3 Scope of the Software 8 1.4 Definitions, acronyms and abbreviations 8 1.5 References 9 1.6 Overview of the document 9 2 LOGICAL MODEL DESCRIPTION 11 3 SPECIFIC REQUIREMENTS 13 3.1 Functional requirements 13 3.1.1 User input interface (SR 1) 13 3.1.2 User output interface (SR 2) 13 3.1.3 Geantino source definition – particle sampling (SR 3) 13 3.1.4 Particle tracking (SR 4) 15 3.1.5 Histogramming of data (SR 5) 15 3.1.6 Geometry description (SR 6) 16 3.1.7 Run repetition (SR 7) 16 3.2 Performance requirements (SR 8) 16 3.3 Interface requirements (SR 9) 16 3.4 Operational requirements (SR 10) 16 3.5 Verification requirements (SR 11) 16 3.6 Acceptance testing requirements (SR 12) 16 3.7 Portability requirements 16 3.7.1 Platform, operating system and compiler (SR 13) 16 3.7.2 Portability to other platforms (SR 14) 17 3.8 Quality requirements (SR 15) 17 3.9 Maintainability requirements (SR 16) 17 3.10 Other requirements 4 SYSTEM DESIGN 18 5 COMPONENT DESCRIPTION 20 5.1 main 20 5.1.1 Type 20 5.1.3 Interfaces 20 5.1.4 Dependencies 20 5.1.5 Data 20 5.1.6 Resources 20 5.1.7 Software requirements met 20 5.2 MyGeometryConstruction 20 5.2.1 Type 20 5.2.2 Functions 21 5.2.3 Interfaces 21 5.2.4 Dependencies 21 5.2.5 Data 21 5.2.6 Resources 21 5.2.7 Software requirements met 21 ... ... 6 USER REQUIREMENTS VERSUS SOFTWARE REQUIREMENTS TRACEABILITY MATRIX 38 7 SOFTWARE REQUIREMENTS VERSUS COMPONENTS TRACEABILITY MATRIX 41
Интересно - с моей стороны я всегда начинаю с очень высоких технических характеристик (.NET, HTML5, CSS3, AJAX, SQL Server DB, разделенных БД и серверами MS Windows Server, 2x аппаратных брандмауэров, 2x программных брандмауэров и т.д.), что я уже знаю, что буду использовать.
Далее я беру свою спецификацию функциональности, и я смотрю на базовую структуру БД и моделирование данных.
Отныне я смотрю на интеграцию с сторонними системами, в частности методы связи и форматы файлов (например, XML через HTTPS-сообщение в веб-службу и CSV через sFTP в запланированном задании). Затем я просматриваю частоты, порядок передачи данных (связанные с зависимостями внутри файлов) и обработку ошибок в системах связи между системами.
Техническая спецификация, которую я пишу, представляет собой расширенную версию спецификации функциональности с технической спецификацией, обозначенной для каждого функционального элемента.
В конце концов, техническая спецификация является самостоятельной продукцией, и, если она достаточно подробно, можно использовать в качестве основы для плана проекта и плана тестирования.
Я всегда открываю с оглавлением и высокоуровневую диаграмму Visio всего потока решений. Это позволяет читателю перейти к части, которая непосредственно применима к ним.
Я надеюсь, что это поможет.
Также от Joel: Проект Aardvark Spec
В конце вы найдете начальную спецификацию одного из своих проектов, Copilot