पथ 07पाठ 3 / 8

Discovery के जुड़े documents का review करें

Requirement को specification, architecture, data flow और security documents में trace करें। पुरानी धारणाओं पर planning निर्भर होने से पहले revisions सँभालें।

व्यावहारिक12 minसमीक्षा की गई

प्रकाशक हम कैसे लिखते हैं

अपनी समझ जाँचेंDependent documents generate करने के बाद आप revised specification publish करते हैं। क्या करना चाहिए?अभ्यास करें
Dependent documents generate करने के बाद आप revised specification publish करते हैं। क्या करना चाहिए?

आप क्या सीखेंगे

  • बताएँ कि documents का क्रम और publication state क्यों जरूरी हैं।
  • बदली specification का dependent documents पर असर ढूँढ़ें।
  • Generated, published, reviewed और outdated सामग्री का अंतर समझें।

एक requirement को पूरे set में trace करें

यह scenario काल्पनिक equipment request service को आगे बढ़ाता है। पहली specification managers को requests दर्ज करने देती है। फिर team employee self-service जोड़ती है।

इस बदलाव का असर एक screen से अधिक है। Employees को identity और अपने requests का access चाहिए। Manager की visibility की सीमा तय होनी चाहिए। Data flow और security analysis में दोनों roles दिखनी चाहिए।

उद्देश्य तय करने और जाँचने के लिए Discovery के Context, Conversation और Documents चरण इस्तेमाल करें। Imported product में repository analysis conversation की जगह लेता है; अलग import workflow अपनाएँ।

जरूरी documents जानें

Specification समेत आठ जरूरी documents हैं:

Documentइस scenario में जाँचा जाने वाला प्रश्न
SpecificationEquipment कौन और किस उद्देश्य से माँग सकता है?
User flowsEmployee request कैसे भेजता और track करता है?
ArchitectureAccess decision कहाँ लागू होता है?
Technology decisionsक्या design approved identity और data services इस्तेमाल करता है?
Data flowEmployee और request data किन components को मिलता है?
DPIAक्या privacy assessment वास्तविक processing दिखाता है?
Threat modelक्या एक employee दूसरे employee का request पढ़ सकता है?
Risk registerहर अनसुलझे risk और उसे सँभालने की जिम्मेदारी किसकी है?

Generation dependencies और publication क्रम के अनुसार होता है। बाद के documents की धारणाएँ स्वीकार करने से पहले शुरुआती document review करें। Generated DPIA assessment की सामग्री है; उसका होना अपने आप legal compliance सिद्ध नहीं करता।

Look & Feel और Service Blueprint वैकल्पिक हैं। Rendered interface की दिशा या service का विवरण product का आकलन करने में मदद करे तो इन्हें इस्तेमाल करें।

Publication और review का अंतर समझें

Specification draft से शुरू होती है। आगे का generation published version इस्तेमाल करता है। Editing नया draft बनाती है; नया version publish करने पर बदलाव आगे लागू होते हैं।

दूसरे documents में publication और review की जानकारी होती है। Generate remaining missing set क्रम से बना सकता है; हर परिणाम को review चाहिए। Generation पूरा होना मानव निष्कर्ष नहीं कि धारणाएँ सही हैं।

Equipment service में सभी संबंधित documents का access rule जाँचें। सही specification और पुराना data flow संगत design नहीं हैं।

बदलाव सोचकर सँभालें

Specification फिर publish करने पर dependent generated documents Outdated हो सकते हैं। Taiga उन्हें चुपचाप दोबारा नहीं लिखता। किसी दूसरे source document का बदलाव भी आगे के documents को प्रभावित कर सकता है।

Discovery खुली रहते प्रभावित documents regenerate करें। Generate remaining में outdated documents शामिल हैं। नए परिणाम जाँचें, खासकर वे धारणाएँ जो कई documents में बदली हों।

Finish Discovery उपलब्ध होने से पहले सभी आठ जरूरी documents publish होने चाहिए। Outdated document finish करने से नहीं रोकता। Button को हर review पूरा होने का प्रमाण मानने के बजाय खुद संगति जाँचें।

Finish करने से set lock होता है और आगे का product workflow खुलता है। Locked set बदलना हो तो document से Discovery फिर खोलें।

Planning को संगत उद्देश्य दें

Planning से पहले वर्तमान user roles, स्वीकार की सीमाएँ और अनसुलझे decisions बताएँ। जाँचें कि initiative proposals ऐसे documents cite करते हैं जो वही product बताते हैं।

उपयोगी review result ठोस है: “Employee self-service flows, authorization design, data flow और threat treatment में शामिल है।” इस उद्देश्य को काम में बदलने के लिए initiatives पढ़ें।

अभ्यास करें

काल्पनिक equipment service manager-only उपयोग से employee self-service में बदलती है। User flows, architecture, data flow, DPIA, threat model और risk register पर असर पहचानें। बताएँ कि Discovery finish करने से पहले कौन-से documents देखेंगे या regenerate करेंगे।

Worksheet डाउनलोड करें (Markdown)
अपनी समझ जाँचें ↑

सीखना जारी रखें

स्रोत और आगे पढ़ें

← पिछला पाठ: मौजूदा codebase को Taiga में लाएँ