VPasCode (डायग्राम एज कोड) सिस्टम एमएल आवश्यकता डायग्राम के लिए — एक व्यापक गाइड

1. आवश्यकता डायग्राम क्या है?

एकआवश्यकता डायग्राम एक सिस्टम एमएल डायग्राम प्रकार है जिसका एकमात्र उद्देश्य हैआवश्यकताओं को मॉडल के प्रथम-श्रेणी के तत्वों के रूप में कैप्चर करना और उनके संबंधों को स्पष्ट और अनुगमनीय बनाना. आवश्यकता दस्तावेज़ (जो केवल एक सूची है) के विपरीत, एक आवश्यकता डायग्राम एकग्राफ: आवश्यकताएं नोड हैं, और उनके बीच के संबंध — समावेशन, व्युत्पत्ति, संतुष्टि, सत्यापन और अनुगमनीयता — एज हैं।

मूल विचार हैअनुगमनीयता. आईटी सिस्टम में, एक आवश्यकता अलग से नहीं रहती। एक हितधारक की आवश्यकता एक सिस्टम आवश्यकता को चलाती है; उस आवश्यकता को एक वास्तुकला ब्लॉक द्वारा संतुष्ट किया जाता है; एक परीक्षण मामला उसकी जांच करता है; और उसे उप-आवश्यकताओं में परिष्कृत किया जा सकता है। आवश्यकता डायग्राम उनमें से प्रत्येक लिंक को दृश्य और ऑडिट योग्य बनाता है। यही वह है जो एक साधारण स्प्रैडशीट को एक मॉडल में बदल देता है।

आईटी सिस्टम के लिए इसका उपयोग क्यों करें?

आईटी परियोजनाएंआवश्यकताओं का विचलन — स्कोप क्रिप, अनियंत्रित परिवर्तन, और “हमने इसे बनाया लेकिन किसी ने इसे नहीं मांगा” समस्या के लिए प्रसिद्ध हैं। एक आवश्यकता डायग्राम मदद करता है क्योंकि यह आपको यह करने की अनुमति देता है:

• पीछे की ओर अनुगमन करें — “यह घटक क्यों मौजूद है?” → अनुसरण करेंसंतुष्ट लिंक आवश्यकता तक पहुंचते हैं, औरव्युत्पन्न लिंक व्यावसायिक आवश्यकता तक पहुंचते हैं।

• आगे की ओर अनुगमन करें — “क्या यह आवश्यकता सत्यापित है?” → अनुसरण करेंसत्यापित लिंक परीक्षण मामलों तक पहुंचते हैं।

• परिवर्तन के प्रभाव का आकलन करें — “यदि यह आवश्यकता बदलती है, तो अन्य क्या प्रभावित होता है?” → प्रत्येक आने वाले और जाने वाले एज का अनुसरण करें।

• कवरेज का प्रमाण दें — प्रत्येक आवश्यकता को संतुष्ट किया जाना चाहिएकुछ और सत्यापित किया गया है कुछ. अनाथ आवश्यकताएँ तुरंत दिखाई देती हैं।

2. मुख्य अवधारणाएँ और संकेतन

2.1 आवश्यकता तत्व

एक आवश्यकता को एक आयत के रूप में बनाया जाता है जिसमें एक नाम, एक अनन्य पहचानकर्ता (आमतौर पर हियरार्किकल, जैसे 1.2.3), और आवश्यकता पाठ. स्टिरियोटाइप है «आवश्यकता».

आवश्यकताओं में गुण — औपचारिक रूप से मॉडल किए गए गुण जैसे स्रोत, जोखिम, प्राथमिकता, स्थिति, या सत्यापन विधि. ये एक आवश्यकता को मापनीयबजाय अस्पष्ट।

2.2 संबंध (डायग्राम का हृदय)

महत्वपूर्ण नियम: कोई संबंध कभी किसी आवश्यकता के ID स्ट्रिंग — इसे तत्व के उपनाम. और यदि आवश्यकता A अंतर्गत है आवश्यकता B को, तो आपको नहीं भी उनके बीच एक «derive» खींचना चाहिए; एक ही जोड़े के लिए अंतर्भाव और व्युत्पत्ति परस्पर अपवर्जी हैं।

2.3 ब्लॉक, परीक्षण मामले और परिष्करण स्रोत

• ब्लॉक («block»): आवश्यकताओं को संतुष्ट करने वाला डिज़ाइन तत्व। आईटी संदर्भ में, यह आपका वास्तुकला घटक है — एक सेवा, मॉड्यूल या API।

• परीक्षण मामले («testCase»): सत्यापन इकाई।

• परिष्करण स्रोत: उपयोग मामले, गतिविधियाँ, या कोई भी मॉडल तत्व जो किसी आवश्यकता का विस्तार करता है।

नोटेशन नोट: संबंध तীরों के विशिष्ट सिर होते हैं (उदाहरण के लिए, «satisfy» तिर, उदाहरण के लिए, संतुष्ट की जा रही आवश्यकता की ओर खुलता है)। जब इनके बारे में प्रसंग में लिखा जाता है, तो हमेशा स्टीरियोटाइप को उद्धृत करें — लिखें `«satisfy»` — ताकि यह पाठक के मार्कडाउन पार्सर द्वारा नष्ट न हो जाए।

3. आरेख उदाहरण

उदाहरण 1 — एक मौलिक आवश्यकता हियरार्की

यह उदाहरण संतुलन और व्युत्पत्ति को दर्शाता है, जो प्रत्येक आवश्यकता आरेख की शुरुआत की रूपरेखा है। एक शीर्ष-स्तरीय प्रदर्शन आवश्यकता को मापने योग्य उप-आवश्यकताओं में विभाजित किया जाता है।

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType RequirementDiagram
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title वाहन प्रदर्शन आवश्यकता हियरार्की

$requirement("वाहन प्रदर्शन", ReqVehiclePerf, "1", "वाहन को सामान्य संचालन स्थितियों में निर्दिष्ट प्रदर्शन लक्ष्यों को पूरा करना चाहिए।")
$requirement("त्वरण", ReqAccel, "1.1", "वाहन को 0 से 100 किमी/घंटा की गति 6 सेकंड से कम समय में प्राप्त करनी चाहिए।")
$requirement("अधिकतम गति", ReqTopSpeed, "1.2", "वाहन को कम से कम 220 किमी/घंटा की अधिकतम गति प्राप्त करनी चाहिए।")
$requirement("ब्रेकिंग", ReqBraking, "1.3", "वाहन को सूखी सड़क पर 100 किमी/घंटा की गति से 38 मीटर से कम दूरी में रुकना चाहिए।")
$requirement("ईंधन दक्षता", ReqFuel, "1.4", "वाहन को संयुक्त चक्र पर कम से कम 15 किमी/लीटर की दक्षता प्राप्त करनी चाहिए।")

$containment(ReqVehiclePerf, ReqAccel)
$containment(ReqVehiclePerf, ReqTopSpeed)
$containment(ReqVehiclePerf, ReqBraking)
$containment(ReqVehiclePerf, ReqFuel)
$deriveReqt(ReqBraking, ReqVehiclePerf)
@enduml

इसे पढ़ना: त्वरण, अधिकतम गति, ब्रेकिंग, और ईंधन दक्षता सभी हिस्से हैं के वाहन प्रदर्शन आवश्यकता (संतुलन)। ब्रेकिंग भी व्युत्पन्न किया गया है इससे, जिसका अर्थ है कि इसे एक ठोस, मापने योग्य लक्ष्य में विभाजित किया गया था।

उदाहरण 2 — संतुष्टि और सत्यापन (डिजाइन आवश्यकताओं को पूरा करता है)

यह डिजाइन पक्ष जोड़ता है। वास्तुकला घटक संतुष्ट करते हैं आवश्यकताओं को, और परीक्षण मामले सत्यापित करते हैं उन्हें। यह वह आरेख है जिसे आप डिजाइन समीक्षा में दिखाते हैं।

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType RequirementDiagram
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title भुगतान प्रणाली — संतुष्टि और सत्यापन

$requirement("PCI-DSS अनुपालन", ReqPci, "3", "प्रणाली कार्ड सत्यापन मानों को संग्रहीत नहीं करेगी और विश्राम में कार्डधारक डेटा को एन्क्रिप्ट करेगी।")
$requirement("भुगतान प्रक्रिया", ReqPay, "3.1", "प्रणाली को 3 सेकंड के भीतर ग्राहक भुगतान की अनुमति देनी चाहिए।")
$requirement("आइडेंपोटेंट चार्ज", ReqIdem, "3.2", "प्रणाली को पुनः प्रयास पर ग्राहक पर दो बार चार्ज नहीं करना चाहिए।")

$block("PaymentService", PaymentService)
$block("VaultService", VaultService)

$testCase("PCI ऑडिट", TAudit)
$testCase("लेटेन्सी टेस्ट", TLatency)
$testCase("आइडेंपोटेंसी टेस्ट", TIdem)

$containment(ReqPci, ReqPay)
$containment(ReqPci, ReqIdem)

$satisfy(PaymentService, ReqPay)
$satisfy(VaultService, ReqPci)

$verify(TAudit, ReqPci)
$verify(TLatency, ReqPay)
$verify(TIdem, ReqIdem)
@enduml

इसे पढ़ना: PaymentService संतुष्ट करता है भुगतान-प्रसंस्करण आवश्यकता को, जबकि VaultService संतुष्ट करता है व्यापक PCI-DSS आवश्यकता को। प्रत्येक आवश्यकता सत्यापित एक परीक्षण मामले द्वारा। तीरों की दिशाओं पर ध्यान दें: `«satisfy»` उस आवश्यकता की ओर इशारा करता है जिसे यह पूरा करता है; `«verify»` उस आवश्यकता की ओर इशारा करता है जिसे यह सिद्ध करता है।

उदाहरण 3 — पूर्ण आईटी-सिस्टम ट्रेसबिलिटी चेन

यह वह आरेख है जिसे आप एक व्यावसायिक आवश्यकता को सत्यापन तक पूरी तरह से ट्रेस करने के लिए उपयोग करेंगे — यह क्लासिक “यह कोड क्यों मौजूद है?” प्रश्न है।

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType RequirementDiagram
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title ई-कॉमर्स सिस्टम — आवश्यकता ट्रेसबिलिटी

$requirement("व्यापार: कार्ट छोड़ना कम करें", ReqBiz, "B1", "व्यापार को दो तिमाहियों के भीतर कार्ट छोड़ने को 15% कम करना चाहिए।")
$requirement("Checkout UX", ReqUx, "S1", "प्रणाली को एक अतिथि को 5 चरणों से कम में चेकआउट पूरा करने की अनुमति देनी चाहिए।")
$requirement("One-Click Reorder", ReqReorder, "S2", "प्रणाली को एक लौटने वाले ग्राहक को एक कार्रवाई में पिछली खरीद को फिर से ऑर्डर करने की अनुमति देनी चाहिए।")
$requirement("Data Residency", ReqResidency, "S3", "प्रणाली को यूरोपीय ग्राहक डेटा को यूरोपीय क्षेत्रों के भीतर संग्रहीत करना चाहिए।")

$block("CheckoutUI", CheckoutUI)
$block("ReorderService", ReorderService)
$block("RegionalDatastore", RegionalDatastore)

$testCase("Checkout Flow Test", TCheckout)
$testCase("Reorder Test", TReorder)
$testCase("Residency Audit", TResidency)

$containment(ReqBiz, ReqUx)
$containment(ReqBiz, ReqReorder)
$deriveReqt(ReqUx, ReqBiz)
$deriveReqt(ReqReorder, ReqBiz)

$satisfy(CheckoutUI, ReqUx)
$satisfy(ReorderService, ReqReorder)
$satisfy(RegionalDatastore, ReqResidency)

$verify(TCheckout, ReqUx)
$verify(TReorder, ReqReorder)
$verify(TResidency, ReqResidency)

$trace(ReqResidency, ReqBiz)
@enduml

इसे पढ़ना: व्यावसायिक आवश्यकता B1 सब कुछ को आधारित करता है। सिस्टम आवश्यकताएं S1 और S2 हैं से व्युत्पन्न इसे (‘क्यों’), जबकि S3(डेटा निवास) एक पता लगाया जा सकने वाला प्रतिबंध केवल `«trace»`. प्रत्येक सिस्टम आवश्यकता संतुष्ट एक घटक द्वारा और सत्यापित एक परीक्षण द्वारा। यदि B1 बदलता है, तो यह आरेख आपको तुरंत बताता है कि कौन से घटक और परीक्षण सीमा में हैं।

4. एक कैसे बनाएं (व्यावहारिक कार्यप्रवाह)

1. शीर्ष-स्तरीय आवश्यकता से शुरू करें। सामान्यतः एक व्यावसायिक या हितधारक आवश्यकता। इसे एक स्पष्ट आईडी स्थान दें (उदाहरण के लिए, B* व्यावसाय के लिए, S* सिस्टम के लिए).

2. अंतर्निहितता के साथ नीचे की ओर विघटित करें। बड़ी आवश्यकताओं को छोटे, मापने योग्य एक। अच्छी आवश्यकता पाठ में एक संख्या होती है (“3 सेकंड से कम”, “15%”, “यूरोपीय संघ क्षेत्रों के भीतर”).

3. व्युत्पत्ति लिंक जोड़ें जहाँ बच्चा एक ठोस पुनःकथन है, केवल एक भाग नहीं। याद रखें: एक जोड़ा अंतर्निहितता द्वारा जुड़ा जा सकता है या व्युत्पत्ति, कभी भी दोनों नहीं।

4. डिज़ाइन को आवश्यकताओं के साथ संतुष्ट करें.प्रत्येक वास्तुकला ब्लॉक को कम से कम एक आवश्यकता को संतुष्ट करना चाहिए। वे ब्लॉक जो कुछ भी संतुष्ट नहीं करते हैं, उन्हें हटाने के लिए उम्मीदवार हैं; वे आवश्यकताएं जो कुछ भी संतुष्ट नहीं होती हैं, वे कवरेज की कमी हैं।

5. परीक्षणों को सत्यापित करें.प्रत्येक आवश्यकता को एक सत्यापन पथ की आवश्यकता होती है। वे आवश्यकताएं जो कुछ द्वारा सत्यापित नहीं होती हैं, वे परीक्षण योग्य नहीं हैं — यह एक चेतावनी संकेत है।

6. का उपयोग करें ट्रेसकेवल तभी जब कुछ और उपयुक्त न हो।यह ढीले संबंधों के लिए बचाव मार्ग है; इसका अत्यधिक उपयोग उसकी मूल्य को कम कर देता है।

7. इसे लगभग 24 तत्वों के नीचे रखें।बड़े चित्र अस्पष्ट हो जाते हैं। उप-प्रणाली या आवश्यकता श्रेणी (सुरक्षा, प्रदर्शन, कार्यात्मक) के आधार पर विभाजित करें।

तीन कवरेज प्रश्न

प्रत्येक आवश्यकता चित्र के खिलाफ यह जाँच सूची चलाएं:

• क्या प्रत्येक आवश्यकता संतुष्ट है?(यदि यह एक सिस्टम आवश्यकता है, तो कुछ इसे साकार करना चाहिए)

• क्या प्रत्येक आवश्यकता सत्यापित है?(कुछ इसे सिद्ध करना चाहिए)

• क्या प्रत्येक आवश्यकता एक आवश्यकता तक ट्रेस होती है?(कोई अनाथ आवश्यकताएं बिना व्यावसायिक औचित्य के तैरती नहीं हैं)

कोई भी ‘नहीं’ एक निष्कर्ष है।

5. आईटी सिस्टम पर इसे लागू करना — पैटर्न और चूकें

सुविधाएं

• आवश्यकताओं को अलग करें प्रकारदृश्य रूप से।आप आवश्यकताओं को स्टिरियोटाइप कर सकते हैं («कार्यात्मक», «प्रदर्शन», «सुरक्षा», «उपयोगिता») ताकि गैर-कार्यात्मक आवश्यकताएं कार्यात्मक आवश्यकताओं से अलग दिखें।

• ID हियरार्की को अर्थपूर्ण रखें। 2.3.4यह पाठक को यह बताना चाहिए कि यह आवश्यकता मॉड्यूल 2, फीचर 3, उप-फीचर 4 के तहत स्थित है। डायग्राम और आपके ALM टूल के बीच संगति महत्वपूर्ण है।

• स्रोत को मॉडल करें। एक स्रोत गुण (नियामक, हितधारक का नाम, बाजार आवश्यकता दस्तावेज़) जोड़ें। मूल तक ट्रेसिबिलिटी मूल अक्सर डिजाइन तक ट्रेसिबिलिटी से अधिक महत्वपूर्ण होती है।

• एक डायग्राम, एक चिंता। संतुष्टि डायग्राम (डिजाइन समीक्षा) और सत्यापन डायग्राम (टेस्ट समीक्षा) के अलग-अलग दर्शक होते हैं। दोनों को और पूरी हियरार्की को एक ही छवि में न दबाएं।

सामान्य गलतियां

• उत्पत्ति बनाम समावेशन की भ्रम। वे समान दिखते हैं लेकिन अलग अर्थ रखते हैं। समावेशन संरचनात्मक विघटन है; उत्पत्ति तार्किक विकास है। इन्हें मिलाकर (या एक जोड़े के बीच दोनों को खींचकर) मॉडल अमान्य हो जाता है।

• एलियास के बजाय ID के द्वारा संदर्भित करना। टूल में, संबंध तत्व एलियास के साथ बंधते हैं, न कि मानव-पठनीय ID स्ट्रिंग्स के साथ। एलियास को सही करें या संबंध चुपचाप कुछ भी लक्षित नहीं करेगा।

• इसे ट्रेस के रूप में संतुष्ट करना. एक ट्रेस लिंक यह दावा नहीं करता कि लक्ष्य कुछ भी पूरा करता है। यदि आपका मतलब “यह घटक इस आवश्यकता को लागू करता है” है, तो ” का उपयोग करें`«संतुष्ट»`.

• बिना संख्या वाली आवश्यकताएँ। “सिस्टम तेज़ होना चाहिए” की पुष्टि नहीं की जा सकती। बिना मापने योग्य सीमा वाली आवश्यकता एक इच्छा है, आवश्यकता नहीं।

• डायग्राम को स्पेसिफिकेशन बनने देना। डायग्राम दर्शाता है संबंध; आवश्यकता पाठ और गुण विवरण वहन करते हैं। पाठ को सटीक रखें और गुण (स्थिति, प्राथमिकता, जोखिम) संलग्न करें ताकि मॉडल को क्वेरी किया जा सके।

6. टूल्स

आप उपरोक्त दिखाए गए PlantUML स्रोत से इन डायग्रामों को सीधे VPasCode — कोड पेस्ट करें, और डायग्राम तुरंत रेंडर हो जाएगा। वहाँ से आप इसे निर्यात या परिष्कृत भी कर सकते हैं।

त्वरित संदर्भ: तत्व और संबंध मैक्रो

$requirement("Name", alias, "id", "Requirement text")
$block("BlockName", alias)
$testCase("TestCaseName", alias)

$containment(parentAlias, childAlias)
$deriveReqt(childAlias, parentAlias)
$satisfy(blockAlias, requirementAlias)
$verify(testCaseAlias, requirementAlias)
$refine(modelAlias, requirementAlias)
$trace(fromAlias, toAlias)
$copy(fromAlias, toAlias)

सारांश

एक आवश्यकता डायग्राम ट्रेसिबिलिटी की रीढ़ का मॉडल है। आईटी सिस्टम के लिए, यह तीन प्रश्नों के उत्तर देता है जो हर ऑडिट, डिज़ाइन समीक्षा और परिवर्तन अनुरोध पूछते हैं: यह क्यों मौजूद है? इसे क्या लागू करता है? इसे क्या सिद्ध करता है? अच्छी तरह उपयोग किया जाए — मापने योग्य आवश्यकता पाठ, सही संबंध अर्थशास्त्र और अनुशासित कवरेज जाँच के साथ — यह आवश्यकताओं को एक स्थिर दस्तावेज़ से एक जीवंत, क्वेरी योग्य मॉडल में बदल देता है जो डिज़ाइन, कोड और टेस्ट को व्यावसायिक उद्देश्य के साथ संरेखित रखता है।

संदर्भ

1. VPasCode: PlantUML, Mermaid और Graphviz के साथ AI-सहायक डायग्राम-एज-कोड: आधिकारिक गाइड जिसमें AI-सहायक डायग्राम जनरेशन, संशोधन कार्यप्रवाह और बहु-DSL समर्थन शामिल है, जिसमें PlantUML, Mermaid और Graphviz शामिल हैं।
2. Visual Paradigm VPasCode: संपूर्ण गाइड: VPasCode की विशेषताओं, लक्षित उपयोगकर्ताओं (विकासकर्ता, वास्तुकार, विश्लेषक) और एजिल दस्तावेज़ीकरण प्रक्रियाओं में इसके भूमिका का विस्तृत अवलोकन।
3. Visual Paradigm VPasCode में आपका स्वागत है: डायग्राम-एज-कोड (DaC) की ओर परिवर्तन: एकीकृत प्लेटफॉर्म का परिचय, जिसमें टेक्स्ट-से-डायग्राम प्रक्रियाओं और स्वचालित लेआउट इंजीनियरिंग के लाभों की व्याख्या की गई है।
4. 60 सेकंड की शुरुआती गाइड | VPasCode टेक्स्ट से डायग्राम गाइड: लाइव पूर्वावलोकन के साथ ब्राउज़र-आधारित एडिटर का उपयोग करके डायग्राम बनाने, अनुकूलित करने और निर्यात करने के लिए चरण-दर-चरण मार्गदर्शन।
5. VPasCode में नया: AI UML प्रोफ़ाइल डायग्राम जनरेटर: सामान्य अंग्रेजी प्रॉम्प्ट्स का उपयोग करके AI-संचालित UML प्रोफ़ाइल डायग्राम जनरेशन पेश करने वाला उत्पाद अपडेट, जिसमें स्वास्थ्य सेवा डेटा गोपनीयता अनुपालन के लिए उदाहरण शामिल है।
6. Visual Paradigm VPasCode में स्थानीय AI डायग्राम जनरेशन: एडिटर के भीतर सीधे प्राकृतिक भाषा प्रॉम्प्ट्स के माध्यम से डायग्राम बनाने, संशोधित करने और ठीक करने के लिए एम्बेडेड AI क्षमताओं की घोषणा।
7. AI-संचालित डायग्राम जनरेटर और उत्पादकता टूल्स | VPasCode: सुव्यवस्थित दस्तावेज़ीकरण पाइपलाइनों के लिए AI चैटबॉट्स, Visual Paradigm Desktop और OpenDocs के साथ VPasCode के एकीकरण का अवलोकन।
8. सर्वश्रेष्ठ PlantUML विकल्प और मुफ्त डायग्राम-एज-कोड एडिटर: PlantUML विकल्पों की तुलना मैट्रिक्स, जिसमें VPasCode की बहु-DSL सहायता, AI विशेषताएं और ब्राउज़र-आधारित शून्य-सेटअप दृष्टिकोण पर प्रकाश डाला गया है।
9. डायग्राम-एज-कोड एडिटर: टेक्स्ट को तुरंत डायग्राम में परिवर्तित करें: स्वचालित प्रारूप पता लगाने, वास्तविक समय रेंडरिंग और बहु-प्रारूप निर्यात विकल्पों (SVG, PNG, PDF) को कवर करने वाले विशेषताओं का अवलोकन।
10. Visual Paradigm पारिस्थितिकी तंत्र की गाइड: बताता है कि कब VPasCode बनाम VP Desktop का उपयोग करें, जिसमें संस्करण-नियंत्रित डायग्राम रखरखाव और जीवित दस्तावेज़ीकरण के साथ एकीकरण के लिए मार्गदर्शन शामिल है।

यह पोस्ट Deutsch, English और فارسی में भी उपलब्ध है।