VPasCode (نمودار به عنوان کد) برای نمودار الزامات SysML — یک راهنمای جامع

۱. نمودار الزامات چیست؟

یکنمودار الزامات یک نوع نمودار SysML است که هدف واحد آنثبت الزامات به‌عنوان عناصر مدل درجه‌یک و شفاف و ردیاب‌پذیر کردن روابط آن‌ها است. برخلاف سند الزامات (که صرفاً یک لیست است)، نمودار الزامات یکگراف است: الزامات گره‌ها هستند و روابط بین آن‌ها — شامل تعلق، استنتاج، ارضاء، تأیید و ردیابی — یال‌ها می‌باشند.

ایده اصلیردیابی. در یک سیستم فناوری اطلاعات، یک الزام به‌تنهایی وجود ندارد. نیاز ذینفع، یک الزام سیستمی را هدایت می‌کند؛ آن الزام توسط یک بلوک معماری ارضاء می‌شود؛ یک مورد آزمایش آن را تأیید می‌کند؛ و ممکن است به زیرالزامات دقیق‌تر تفکیک شود. نمودار الزامات هر یک از این پیوندها را قابل مشاهده و قابل بازبینی می‌کند. این همان چیزی است که یک صفحه‌گسترده تخت را به یک مدل تبدیل می‌کند.

چرا از آن برای سیستم‌های فناوری اطلاعات استفاده کنیم؟

پروژه‌های فناوری اطلاعات به‌خاطرانحراف الزامات — رشد دامنه، تغییرات مدیریت‌نشده و مشکل «آن را ساختیم اما کسی آن را درخواست نکرده بود» معروف هستند. نمودار الزامات کمک می‌کند زیرا به شما اجازه می‌دهد:

• ردیابی به عقب — «چرا این جزء وجود دارد؟» → دنبال کردنارتباط ارضاء به الزام، وارتباط استنتاج به نیاز کسب‌وکار متصل می‌شود.

• ردیابی به جلو — «آیا این الزام تأیید شده است؟» → دنبال کردنارتباط تأیید به موارد آزمایش متصل می‌شود.

• ارزیابی تأثیر تغییر — «اگر این الزام تغییر کند، چه چیز دیگری تحت تأثیر قرار می‌گیرد؟» → دنبال کردن هر یال ورودی و خروجی.

• اثبات پوشش — هر الزام باید توسطچیزی و تأیید شده توسط چیزی. الزامات یتیم بلافاصله قابل مشاهده هستند.

۲. مفاهیم کلیدی و نمادگذاری

۲.۱ عنصر الزام

یک الزام به صورت یک مستطیل با یک نام، یک شناسه یکتا (معمولاً سلسله‌مراتبی، مانند 1.2.3) و متن الزام. استریوتایپ ««الزام».

الزامات می‌توانند شامل ویژگی‌ها — ویژگی‌های مدل‌سازی‌شده به صورت رسمی مانند منبع, ریسک, اولویت, وضعیت، یا روش تأیید. این موارد یک الزام را قابل اندازه‌گیریبه جای مبهم.

۲.۲ روابط (قلب نمودار)

قانون حیاتی: یک رابطه هرگز به رشته‌ی شناسه‌ی یک نیازمندی رسم نمی‌شود،شناسه‌ی — بلکه به نام مستعار عنصر رسم می‌شود.نام مستعارو اگر نیازمندی Aشاملنیازمندی B باشد، شما نبایدنبایدهمچنین یکرابطه‌ی «استخراج»بین آن‌ها در هیچ جهتی رسم کنید؛ چون احتوا و استخراج برای یک جفت مشخص، متقابل‌الاستثنا هستند.

۲.۳ بلوک‌ها، موارد آزمایش، و منابع بازنگری

• بلوک («block»): عنصر طراحی‌ای که نیازمندی‌ها را برآورده می‌کند. در یک زمینه‌ی فناوری اطلاعات، این جزء معماری شماست — یک سرویس، ماژول، یا API.

• مورد آزمایش («testCase»): واحد تأیید.

• منابع بازنگری: موارد استفاده، فعالیت‌ها، یا هر عنصر مدل دیگری که یک نیازمندی را بسط می‌دهد.

یادداشت نمادگذاری:فلش‌های رابطه سرهای خاصی دارند (مثلاً فلش«satisfy»، برای مثال، به سمت نیازمندی‌ای که برآورده می‌شود باز می‌شود). هنگام نوشتن درباره‌ی آن‌ها در متن، همیشه استریوتایپ را در گیومه بنویسید — بنویسید`«satisfy»` — تا توسط پردازشگر مارک‌داون خواننده بلعیده نشود.

۳. نمونه‌های نمودار

نمونه ۱ — یک سلسله‌مراتب بنیادی نیازمندی‌ها

این مثال شامل‌سازی و استنتاج را نشان می‌دهد، که اسکلت‌بندی اولیه هر نمودار الزامات است. یک الزام عملکردی سطح بالا به زیرالزامات قابل اندازه‌گیری تجزیه می‌شود.

@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

خواندن آن: شتاب, سرعت نهایی, ترمز، و مصرف سوخت همگی بخش‌هایی از الزام کلی عملکرد خودرو الزام (شامل‌سازی) است. ترمز همچنین استنتاج شده از آن است، به این معنی که به یک هدف مشخص و قابل اندازه‌گیری تجزیه شده است.

مثال ۲ — ارضاء و تأیید (طراحی، الزامات را برآورده می‌کند)

این بخش طراحی را اضافه می‌کند. اجزای معماری الزامات را ارضاء می‌کنند و موارد آزمون آن‌ها را تأیید می‌کنند آن‌ها هستند. این نموداری است که در بازبینی طراحی ارائه می‌دهید.

@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", "سیستم باید پرداخت مشتری را در مدت ۳ ثانیه تأیید کند.")
$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»` از مورد آزمون به سمت نیازمندی که اثبات می‌کند، اشاره می‌کند.

مثال ۳ — زنجیره کامل ردیابی سیستم فناوری اطلاعات

این نموداری است که برای ردیابی یک نیاز کسب‌وکار تا مرحله تأیید استفاده می‌کنید — سوال کلاسیک «چرا این کد وجود دارد؟».

@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", "کسب‌وکار باید رها کردن سبد خرید را در مدت دو فصل ۱۵٪ کاهش دهد.")
$requirement("تجربه کاربری پرداخت", ReqUx, "S1", "سیستم باید اجازه دهد یک مهمان پرداخت را در کمتر از ۵ مرحله تکمیل کند.")
$requirement("سفارش مجدد با یک کلیک", ReqReorder, "S2", "سیستم باید به مشتری بازگشته اجازه دهد یک خرید قبلی را در یک اقدام سفارش مجدد دهد.")
$requirement("مکان‌یابی داده‌ها", ReqResidency, "S3", "سیستم باید داده‌های مشتریان اتحادیه اروپا را در مناطق اتحادیه اروپا ذخیره کند.")

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

$testCase("آزمون جریان پرداخت", TCheckout)
$testCase("آزمون سفارش مجدد", TReorder)
$testCase("بازرسی مکان‌یابی", 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 (محل نگهداری داده) یک قابل ردیابی محدودیتی که تنها با `«ردیابی»` هر الزام سیستمی برآورده می‌شود توسط یک مؤلفه و تأیید می‌شود توسط یک آزمون. اگر B1 تغییر کند، این نمودار بلافاصله به شما می‌گوید که کدام مؤلفه‌ها و آزمون‌ها در محدوده هستند.

۴. چگونه یک مورد بسازیم (روند عملی)

1. با نیاز سطح بالا شروع کنید. معمولاً یک الزام کسب‌وکار یا ذینفع است. به آن یک فضای شناسه واضح بدهید (مثلاً B* برای کسب‌وکار، S* برای سیستم).

2. با استفاده از دربرگیری، به سمت پایین تجزیه کنید. الزامات بزرگ را به الزامات کوچک‌تر، قابل اندازه‌گیری یکی. متن الزام خوب باید یک عدد در خود داشته باشد («کمتر از ۳ ثانیه»، «۱۵٪»، «در مناطق اتحادیه اروپا»).

3. لینک‌های استنتاج را در جایی اضافه کنید که یک فرزند، بیان عینی‌تری از آن باشد، نه صرفاً یک جزء. به خاطر داشته باشید: یک جفت می‌تواند با دربرگیری یا استنتاج پیوند بخورند، هرگز هر دو.

4. طراحی را با «رضایت.هر بلوک معماری باید حداقل یک نیاز را برآورده کند. بلوک‌هایی که هیچ نیازی را برآورده نمی‌کنند، کاندیدای حذف هستند؛ نیازهایی که توسط هیچ چیز برآورده نمی‌شوند، شکاف‌های پوشش هستند.

5. آزمون‌ها را با «تأیید.هر نیاز به یک مسیر تأیید نیاز دارد. نیازهایی که توسط هیچ چیز تأیید نمی‌شوند، غیرقابل آزمون هستند — یک پرچم قرمز.

6. از «ردیابیفقط زمانی استفاده کنید که هیچ چیز دیگری مناسب نباشد.این دریچه فرار برای پیوندهای شل است؛ استفاده بیش از حد از آن ارزش آن را رقیق می‌کند.

7. آن را زیر حدود ۲۴ عنصر نگه دارید.نمودارهای بزرگ غیرقابل خواندن می‌شوند. آن‌ها را بر اساس زیرسیستم یا دسته‌بندی نیاز (امنیت، عملکرد، عملکردی) تقسیم کنید.

سه سوال پوشش

این چک‌لیست را روی هر نمودار نیاز اجرا کنید:

• آیا هر نیاز برآورده شده است؟(اگر یک نیاز سیستمی است، چیزی باید آن را محقق کند)

• آیا هر نیاز تأیید شده است؟(چیزی باید آن را اثبات کند)

• آیا هر نیاز به یک نیاز بالاتر ردیابی می‌شود؟(بدون نیازهای یتیم که بدون توجیه کسب‌وکاری معلق باشند)

هر «خیر» یک یافته است.

۵. کاربرد آن در سیستم‌های فناوری اطلاعات — الگوها و دام‌ها

روش‌های خوب

• انواع نیاز را به صورت بصری جدا کنید.انواعبه صورت بصری.می‌توانید نیازها را استریوتایپ کنید («عملکردی», «عملکرد», «امنیت», «قابلیت استفاده») تا الزامات غیرعملکردی از الزامات عملکردی متمایز شوند.

• سلسله‌مراتب شناسه‌ها را معنادار نگه دارید. 2.3.4باید به خواننده بگوید که این الزام در زیر ماژول ۲، ویژگی ۳ و زیرویژگی ۴ قرار دارد. ثبات در نمودارها و ابزار مدیریت چرخه عمر نرم‌افزار (ALM) شما اهمیت دارد.

• منبع را مدل‌سازی کنید. یک منبع (تنظیمات قانونی، نام ذینفع، سند الزامات بازار) پیوندپذیری به منشأاغلب مهم‌تر از پیوندپذیری به طراحی است.

• یک نمودار، یک دغدغه.یک نمودار ارضاء (بازنگری طراحی) و یک نمودار تأیید (بازنگری آزمون) مخاطبان متفاوتی دارند. هر دو را به همراه کل سلسله‌مراتب در یک تصویر فشرده نکنید.

اشتباهات رایج

• اشتباه گرفتن استنتاج با دربرگیری. آن‌ها شبیه به هم به نظر می‌رسند اما معانی متفاوتی دارند. دربرگیری تجزیه ساختاری؛ استنتاج تکامل منطقیقصد است. ترکیب آن‌ها (یا رسم هر دو بین یک جفت) مدل را نامعتبر می‌کند.

• ارجاع با شناسه به جای نام مستعار. در ابزار، روابط به عنصر نام‌های مستعارنه رشته‌های شناسه قابل خواندن توسط انسان. نام مستعار را درست تنظیم کنید، در غیر این صورت رابطه به‌صورت خاموش به هیچ‌چیز هدف‌گیری نمی‌شود.

• مورد قرار دادن ردیابی به عنوان ایفای نقش. یک پیوند ردیابی ادعا نمی‌کند که هدف هر چیزی را ایفا می‌کند. اگر منظور شما «این جزء این الزام را پیاده‌سازی می‌کند» است، از `«ایفای نقش»`.

• الزامات بدون شماره. «سیستم باید سریع باشد» قابل تأیید نیست. الزامی بدون آستانه قابل اندازه‌گیری، یک آرزو است، نه یک الزام.

• اجازه دادن به اینکه نمودار به مشخصات تبدیل شود. نمودار نشان می‌دهد روابط؛ الزام متن و ویژگی‌هاجزئیات را حمل می‌کنند. متن را دقیق نگه دارید و ویژگی‌ها (وضعیت، اولویت، ریسک) را پیوست کنید تا مدل قابل پرس‌وجو باشد.

۶. ابزارها

شما می‌توانید این نمودارها را مستقیماً از منبع PlantUML نشان‌داده‌شده در بالا با استفاده از VPasCode — کد را پیست کنید و نمودار بلافاصله رندر می‌شود. از آنجا می‌توانید آن را نیز صادر یا اصلاح کنید.

مرجع سریع: ماکروهای عنصر و رابطه

$requirement("Name", alias, "id", "متن الزام")
$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: راهنمای رسمی که شامل تولید نمودار با کمک هوش مصنوعی، گردش کارهای اصلاح و پشتیبانی از چندین زبان توصیف دامنه (DSL) از جمله PlantUML، Mermaid و Graphviz است.
2. Visual Paradigm VPasCode: راهنمای جامع: مرور دقیق ویژگی‌های VPasCode، کاربران هدف (توسعه‌دهندگان، معماران، تحلیل‌گران) و نقش آن در گردش کارهای مستندسازی چابک.
3. به Visual Paradigm VPasCode خوش آمدید: تحول به سمت نمودار-به-کد (DaC): معرفی پلتفرم یکپارچه، توضیح مزایای گردش کارهای متن-به-نمودار و مهندسی چیدمان خودکار.
4. راهنمای شروع سریع ۶۰ ثانیه‌ای | راهنمای متن-به-نمودار VPasCode: راهنمای گام‌به‌گام برای ایجاد، سفارشی‌سازی و صادرات نمودارها با استفاده از ویرایشگر مبتنی بر مرورگر با پیش‌نمایش زنده.
5. جدید در VPasCode: مولد نمودار پروفایل UML هوشمند: به‌روزرسانی محصول که مولد نمودار پروفایل UML با قدرت هوش مصنوعی را با استفاده از دستورات ساده انگلیسی معرفی می‌کند، همراه با مثال برای انطباق حریم خصوصی داده‌های سلامت.
6. تولید نمودار هوش مصنوعی بومی در Visual Paradigm VPasCode: اعلام قابلیت‌های هوش مصنوعی تعبیه‌شده برای تولید، اصلاح و رفع خطای نمودارها از طریق دستورات زبان طبیعی مستقیماً در ویرایشگر.
7. مولد نمودار هوشمند و ابزارهای بهره‌وری | VPasCode: مروری بر یکپارچه‌سازی VPasCode با چت‌بات‌های هوش مصنوعی، Visual Paradigm Desktop و OpenDocs برای تسهیل خطوط لوله مستندسازی.
8. بهترین جایگزین‌های PlantUML و ویرایشگرهای رایگان نمودار-به-کد: ماتریس مقایسه‌ای جایگزین‌های PlantUML، با تأکید بر پشتیبانی چند-زبان برنامه‌نویسی (DSL)، ویژگی‌های هوش مصنوعی و رویکرد بدون تنظیمات مبتنی بر مرورگر VPasCode.
9. ویرایشگر نمودار-به-کد: تبدیل متن به نمودر در لحظه: مرور ویژگی‌ها شامل تشخیص خودکار فرمت، رندرینگ بلادرنگ و گزینه‌های صادرات چندفرمت (SVG، PNG، PDF).
10. راهنمای اکوسیستم Visual Paradigm: توضیح می‌دهد که چه زمانی از VPasCode در مقابل VP Desktop استفاده شود، همراه با راهنمایی برای نگهداری نمودارهای کنترل‌شده نسخه و یکپارچه‌سازی با مستندات زنده.

This post is also available in Deutsch, English and English.