အခန်း ၄ :: Requirements Engineering

Software Engineering မှာ အရေးကြီးဆုံး အပိုင်းတစ်ခုက “ဘာကို တည်ဆောက်မှာလဲ” ဆိုသည့် တိတိကျကျ လိုအပ်ချက် ကို သိရှိရန် ဖြစ်ပါသည်။ Requirement Engineering ဆိုသည်မှာ user နှင့် stakeholders များ၏ လိုအပ်ချက်များကို စနစ်တကျ စုဆောင်းခြင်း၊သုံးသပ်ခြင်း ၊ မှတ်တမ်းတင်ခြင်း နှင့် စီမံခန့်ခွဲ ခြင်း တို့ ကို ပြုလုပ်သည့် လုပ်ငန်း စဥ် တစ်ခု ဖြစ်ပါသည်။ Requirement မှန်ကန်မှသာ Software ၏ result သည်လည်း မှန်ကန်သည့် result ရမှာ ဖြစ်ပါတယ်။

၄.၁ Functional and Non-Functional Requirements

Requirement မှာ အဓိက အားဖြင့် နှစ်မျိုး ရှိပါသည်။

Functional Requirement

What the system should do ? ဒီ စနစ်က ဘာလုပ်မှာလဲ။ ဘာလုပ်သင့်သလဲ ဆိုတာက အဓိက requirement ပါပဲ။ ဘယ် feature တွေ ပါမယ်။ ဘယ်လို လုပ်ဆောင်မှု ရှိမလဲ။

ဥပမာ

User က account တစ်ခု ကို register လုပ်နိုင်ရမည်။
Report က PDF ဖြင့် လစဥ် ရောင်းအား ထုတ်ပေးနိုင်ရမည်။
Register လုပ်ထားသည့် သူများ သာ ဝယ်ယူခွင့်ရှိသည်။

တနည်းပြောရင် user က လုပ်ဆောင်နိုင်မယ့် function တွေပါ့။

Non-Functional Requirement

ဘယ်လို ကောင်းမွန်သည့် စနစ် တစ်ခု ကို တည်ဆောက်မှာလဲ ဆိုတာကို သတ်မှတ်ခြင်းပါ။ တနည်းပြောရင် quality goal လို့ ဆိုနိုင်တယ်။

ဥပမာ

Performance: system က ဘယ်စက္ကန့် အတွင်း home page က အပြည့်အစုံတက်လာရမလဲ
Security: SQL Injection မရှိအောင် ဘယ်လို လုပ်ထားမလဲ။ User Password ကို ဘယ် hash နဲ့ သုံးပြီး သိမ်းမလဲ။
Usability: Register ကို user တစ်ယောက်က ၂ မိနစ် အတွင်း လုပ်လို့ရနိုင်မလား။
Reliability: Server Up Time 99.8% အလုပ်လုပ်နိုင်ရမယ်။ Server တစ်ခု down သွားခဲ့ရင် နောက် server တစ်ခု က ဘယ် နှစ်မိနစ် အတွင်း ပြန်တက်လာမလဲ။
Portability: Linux က Ubuntu အပြင် Arch မှာ run ရင် အဆင်ပြေမလား။ Windows Server ပြောင်းရင်ကော အဆင်ပြေမလား။ ဒါမှမဟုတ် Application က windows ကော mac ကော UI support ပေး၇မလား။

တနည်းပြန်ပြောရရင် Functional က Yes/No နဲ့ တိုင်းတာနိုင်တယ်။ Non-Functional က တော့ စွမ်းဆောင်ရည် ကို တိုင်းတာတယ်။ ဥပမာ PDF တော့ ထုတ်လို့ရတယ်။ ဒါပေမယ့် user ၅ ယောက် အများဆုံး အပြိုင် ထုတ်နိုင်တယ်။ ၅ ယောက်ထက် ကျော်သွားရင် ၁၀ စက္ကန့် စောင့်ရမယ်။

ထပ်ပြီး နားလည်အောင် ရှင်းပြရရင် ကားတစ်စီး ဝယ်သည့် အခါမှာ fuctional , non-functional ကို ခွဲပြီး ဝယ်ကြတာပဲ။

Functional အနေနဲ့

Car Play ပါရမည်။
Auto Parking ပါရမည်။
Auto break ပါရမည်။

Non Functional အနေနဲ့

0-to-100 km/h ကို ၁၀ စက္ကန့်အတွင်း ရောက်ရမယ်။
ထိုင်ခုံတွေက သက်တောင့်သက်သာ ရှိရမယ်။
Engine က မိုင် ၁ သိန်း အထိ အနည်းဆုံး အာမခံချက် ရှိရမယ်။

၄.၂ The Requirement Process

Requirements Engineering လုပ်ငန်းစဥ်မှာ အဓိက အဆင့် ၄ ဆင့် ပါဝင်သည်။

Elicitation

Stakeholder များ (client, end-users, managers) ထံမှ requirement များကို စုဆောင်းသည့် အဆင့်ဖြစ်သည်။ requirement များကို စုဆောင်းသည့် နည်းလမ်းများစွာ ရှိပါသည်။ ဥပမာ အင်တာဗျူးခြင်း၊ workshop များ လုပ်ခြင်း၊ surveys ကောက်ခြင်း ၊ လက်ရှိ တကယ်လုပ်နေသည့် လုပ်ငန်းခွင်ထဲမှာ စောင့်ကြည့်လေ့လာခြင်းဖြင့် တကယ့် လိုအပ်ကို သိရှိနိုင်သည်။

Analysis

စုဆောင်းရရှိလာသည့် အချက်အလက်များကို သုံးသပ်သည့် အဆင့်ဖြစ်သည်။ requirement များတွင် မရှင်းလင်းသည် များကို ရှင်းလင်းအောင် ပြုလုပ်ခြင်း ၊ မည်သည့် အချက်များကို ဦးစားပေးလုပ်ရမည် တို့ကို စီစဥ် ခြင်း တို့ကို လုပ်ဆောင်ပါသည်။

Specification

သုံးသပ်ပြီးရလာသည့် requirement များကို ရှင်းလင်းတိကျပြီး အများနားလည်နိုင်သည့် ပုံစံဖြင့် document လုပ်ရန် လိုအပ်ပါသည်။ အခန်း ၂ မှာ ဖော်ပြထားသည့် Software Requirement Specification (SRS) document ကို ဤအဆင့်တွင် အသေးစိတ် ရေးသားရန်လိုအပ်ပါသည်။

Validation

ရေးဆွဲထားသည့် SRS document သည် stakeholder များ၏ တကယ့် requirement နှင့် ကိုက်ညီမှု ရှိမရှိ ပြည့်စုံမှု ရှိမရှိ စစ်ဆေးအတည်ပြုရပါမည်။ SRS ကို review လုပ်ခြင်း prototype သို့မဟုတ် mockup များ ဖန်တီးခြင်းဖြင့် ကိုက်ညီမှု ရှိမရှိ စစ်ဆေးနိုင်သည်။ အများအားဖြင့် Figma , Whimsical တို့ တွင် prototype လွယ်လင့် တကူ ဖန်တီး နိုင်သည်။

၄.၃ The Minimum Viable Product (MVP)

Project တစ်ခုကို စတင်သည့် အခါ feature အကုန်လုံးကို တစ်ခါတည်း တည်ဆောက်ခြင်းဟာ အချိန်အများကြီး ပေးရပြီး risk လည်း အရမ်းများပါတယ်။ ဒါကြောင့် နောက်ပိုင်း Software Development မှာ Minmium Viable Product ကို တည်ဆောက်ကြပါတယ်။ MVP ဆိုသည်မှာ လုပ်ဆောင်ချက် အနည်းဆုံး ဖြင့် တကယ် အလုပ်ဖြစ်သည့် ထုတ်ကုန် ကို ဆိုလိုပါတယ်။ Feature အနည်းငယ်သာ ပါဝင်သည့် product မဟုတ်ပါ။ သုံးစွဲသူ အတွက် အဓိက တန်ဖိုး ကို ပေးနိုင်ဖို့ လိုအပ်ပါသည်။

ဥပမာ user ရဲ့ requirement က လက်ရှိ လမ်းလျှောက်တာ ထက် ပိုမြန်ပြီး ခရီး ဝေးဝေး သွားနိုင်ဖို့။ ဒါကြောင့် product က ကားတစ်စီး တည်ဆောက်ဖို့ ဆုံးဖြတ်လိုက်တယ်။ ကား တစ်စီး ကို တည်ဆောက်မည့် ကာလ မှာ user ကို ဒါက ကားဘီး ။ ငါတို့ ကားဘီး အပိုင်းပြီးပြီ ဆိုပြီး ပေးလို့ မရပါဘူး။ တကယ် အသုံးပြုလို့ မရပါဘူး။ ဘီး ၂ ခု ပါသည့် skateboard ကို အရင် မိတ်ဆက်ပါတယ်။ ပထမဆုံး ဖြစ်သည့် အတွက်ကြောင့် ဘာ feature မှ မပါဝင်ပေမယ့် သုံးလို့ ရပါတယ်။ နောက်တဆင့် scooter ။ ပြီးတော့ စက်ဘီး ။ motorbike ။ နောက်ဆုံး ကား။ စသည် ဖြင့် အဆင့်ဆင့် user ကို မိတ်ဆက်သွားသည့် ပုံစံပါ။

MVP က ကိုယ်ပိုင် product မှာ ပြဿနာ မရှိပေမယ့် customer က ခိုင်းသည့် customize software တွေ မှာ ပြဿနာ ရှိပါတယ်။ customer က ကားလိုချင်တယ်။ ငါ့ကို ကားပဲ ပေး ဆိုပြီး တောင်းဆိုတတ်ကြပါတယ်။ ဘာကြောင့် MVP ကို လုပ်ရတယ် ဆိုတာကို customer ကို နားလည်အောင် ရှင်းပြဖို့ လိုတယ်။ Customer တွေ အနေနဲ့ မြင်တာကတော့ MVP အဆင့်ဆင့် သွားခြင်းဟာ impression ကို ကျစေတယ်။ marketing ဖိုး ခဏခဏ ကုန်တယ် လို့ မြင်ကြတယ်။ ဒါပေမယ့် ဒါဟာ risk နည်းတယ် ဆိုတာကို ရှင်းပြဖို့ လိုတယ်။ MVP မပါပဲ သွားသည့် product ဟာ အောင်မြင်ဖို့ အခွင့်အလမ်း အရမ်းကို နည်းပါတယ်။

ရိုးရှင်းအောင် ရှင်းပြရရင်

idea ကို စမ်းသပ်ရန် ဖြစ်ပါတယ်။ တကယ် အလုပ် ဖြစ်မဖြစ်။ တကယ် အသုံးပြုသူတွေ အနေနဲ့ feed back ကို အချိန် နဲ့ ငွေ လုပ်အားအနည်းဆုံး အသုံးပြုပြီး စမ်းသပ်ဖို့ ပါ။ တကယ့် product goal မဟုတ်ပါဘူး။
User Feedback အမြန်ရရန်။ စမ်းကြည့်မယ့် သူတွေ လက်ထဲ product ကို ထည်ပေးပြီး တကယ်လက်တွေ့ အသုံးပြုသူတွေ ရဲ့ တုံ့ပြန်ချက် feedback တွေ ရယူဖို့ပါ။ ဒီအချက်က အရေးပါတယ်။ တစ်ခါတစ်လေ customer က သူ့ user တွေ တကယ် အသုံးပြုသူတွေ လိုအပ်တာက တခြား သူ ထင်တာက တခြား ဖြစ်နေတာတွေ ရှိတတ်ပါတယ်။ ဥပမာ mobile app လုပ်ပေမယ့် တကယ် အသုံးပြုသူ အများစုဟာ ရုံးမှာ computer နဲ့ အသုံးပြုသူတွေ ဖြစ်နေကြတာတွေ ဖြစ်သလိုမျိုးပေါ့။
To Avoid Waste , လူမကြိုက်သည့် အသုံးမဝင်သည့် feature တွေ product တွေ ပြုလုပ်မိပြီး အချိန် နဲ့ လုပ်အား အလဟသ မဖြစ်စေဖို့ အတွက်ပါ။

ထပ်ပြီးဆိုရရင် MVP ဟာ half buit တဝက်တပျက် မဟုတ်ပါ။ အလုပ်မလုပ်သည့် product မဟုတ်ပါ။ ဒါကြောင့် အခန်း ၂ scrum မှာ ပြောခဲ့သလိုမျိုး increment တစ်ခု ထွက်လာဖို့ လိုတယ်ဆိုတာ MVP ကဦးစွာ ဖန်တီး သည့် အခါမှာ လိုအပ်ချက်ပါ။

ဥပမာ ဆိုပါဆို။ သင် က invoice system လုပ်တယ်။

ပထမဆုံး MVP မှာ invoice create တာပဲ ရှိမယ်။ invoice create လုပ်လို့ရမယ်။ PDF အနေနဲ့ ထုတ်လို့ရမယ်။

ဒုတိယ MVP မှာတော့ Customer ပါလာပြီ။ customer management လုပ်လို့ရမယ်။ invoice ကို customer email တိုက်ရိုက် ပို့လိုရမယ်။

တတိယ အဆင့်မှာတော့ item management ပါလာပြီ။ invoice create လုပ်သည့် အခါမှာ item ကို ရွေးလို့ ရလာမယ်။

invoice စနစ် တစ်ခုလုံး အစအဆုံး ဖန်တီး မယ့် အစား တကယ် အသုံးဝင်သည့် အစိတ်အပိုင်းတွေ တစ်ဆင့်ခြင်းဆီ ဖန်တီးပြီး ထုတ်သွားပေးပြီး အသုံးပြုသူ လက်ထဲ အမြန်ထည့်ပေးပြီး feedback အမြန်ပြန်ရစေပါတယ်။ ပြင်စရာရှိတာကိုလည်း အများကြီး မဖြစ်ခင်မှာ ကြိုတင်ပြီး ပြင်နိုင်ပါတယ်။

၄.၄ Agile Requirements: User Stories and Backlog Management

Agile Development မှာ requirement များကို SRS document အရှည်ကြီး ရေးဆွဲမည့် အစား ပိုမို ရိုးရှင်းပြီး ပြုပြင်ပြောင်းလွယ်သည့် User Stories များကို အသုံးပြုပါတယ်။

User Stories

User Story ဆိုသည်မှာ Software feature တစ်ခု ကို သုံးစွဲသူ၏ ရှုထောင့်မှ ရိုးရှင်းစွာ ဖော်ပြထားသော ဖော်ပြချက် ဖြစ်ပါသည်။ ပုံမှန် အားဖြင့် အောက်ဖော်ပြပါ ပုံစံ မျိုးကို အသုံးပြုပါသည်။

As a guest user, I want to register for an account so that I can purchase items.

User Story တစ်ခု မှာ “3 Cs” လို့ခေါ်သည့် အဓိက အစိတ်အပိုင်း ၃ ခု ပါဝင်ပါသည်။

Card: Story ကို ရေးမှတ်ထားသော card (အခုခေတ်မှာတော့ Jira, Trello တွင် မှတ်ပါသည်)
Conversation: Story နှင့် ပတ်သက်၍ Product Owner, Development Team နှင့် Stakeholder များ အကြား ဆွေးနွေးခြင်းဖြင့် requirement ကို အားလုံး နားလည်သွားစေသည်။
Confirmation : Story တစ်ခု ပြီးမြောက်ပြီဟု သတ်မှတ်ရန် အတွက် လိုအပ်သော အချက်အလက်များ (Defination Of Done)

Acceptance Criteria (AC)

AC ဆိုတာကတော့ user story တစ်ခု ကို “Done” ဟု သတ်မှတ်၇န် အတွက် စစ်ဆေးရမည့် အချက်စာရင်း ဖြစ်ပါသည်။ Developer များအတွက် test case များ လည်း ဖြစ်သည်။ “Done” ဖြစ်ရမည့် အချက်များကို Developer များ အနေနဲ့ User story ပြီးမပြီး ကို စစ်ဆေးနိုင်သည်။

User Register User Story

Acceptance Criteria:

Scenario: အောင်မြင်စွာ မှတ်ပုံတင်ခြင်း
- Given : User သည် register page တွင် ရှိနေသည်
- When: username, email, password တို့ကို ဖြည့်ပြီး “Register” ကို နှိပ်သည်
- Then: Account တစ်ခု ဖန်တီးပြီး home page ကို ပြန်ရောက်မည်။
Scenario: ရှိပြီးသား Email ဖြင့် မှတ်ပုံတင်ခြင်း
- Given: User သည် register page တွင် ရှိနေသည်
- When: ရှိပြီးသား email တစ်ခုကို အသုံးပြု၍ register လုပ်သည်
- Then: “This email is already registered” ဆိုပြီး error message ပြရမည်

Backlog Management

Agile တွင် requirement အားလုံးကို Product Backlog ထဲမှာ စုစည်းထားပါတယ်။ Product Backlog က project အတွက် လိုအပ်သည့် user stories, features, bug fixes အားလုံး၏ ဦးစားပေး အလိုက် စီထားသည့် စာရင်းဖြစ်ပါသည်။ Product Owner က backlog ကို တာဝန်ယူရသည်။ အရေးကြီးဆုံး card များကို အပေါ်ဆုံးမှာ ထားဖို့ လိုအပ်သည်။

User Story များကိုလည်း အဆိုပါ back log ထဲတွင် ရေးသား ကြသည်။ ထို့ကြောင့် Developer များသည် card ကို ကြည့်ပြီး User Story ကို ဖတ်ရုံဖြင့် ဘယ် feature develop လုပ်ရမည်။ test case တွေ က ဘာဖြစ်မည်။ Defination of Done က ဘာဖြစ်မည် တို့ကို ချက်ချင်း နားလည် သဘောပေါက်နိုင်ပါသည်။

**

**

Backlog Refinement (Grooming)

Backlog Refinement ဆိုသည်မှာ Product Backlog ကို ပုံမှန် ပြန်လည် သုံးသပ်ခြင်း ၊ user story များကို အသေးစိတ် ဆွေးနွေးခြင်း ၊ estimate (story porint) များ ပြုလုပ်ခြင်း နှင့် လုပ်ဆောင်ရမည်များကို priority အလိုက်စီစဥ်ခြင်းတို့ကို အစဥ်မပြတ် လုပ်ဆောင်ရသည့် meeting ဖြစ်သည်။

၄.၅ Requirement Traceability and Change Management

Requirements Traceability

Traceability ဆိုသည်မှာ requirement တစ်ခု ၏ lifecycle တစ်လျှောက်လုံး ခြေရာခံနိုင်စွမ်း ဟု ဆိုနိုင်သည်။ Requirement တစ်ခုသည် မည်သည့် business goal ကနေ ဆင်းသက်လာသည် မည်သည့် design component, source code နှင့် test case တို့ နှင့် ဆက်စပ်နေသည် ကို ခြေရာခံခြင်း ဖြစ်သည်။ impact analysis ကို နားလည် ရန် နှင့် requirement အားလုံး cover ဖြစ်ရန် အလွန် အရေးပါသည်။

Traceability Matrix

Traceability Matrix သည် requirement များကို test case များ ဖြင့် ချိတ်ဆက်ပြသရန် အသုံးပြုသည့် tool တစ်ခုပါ။


Requirement ID	Requirement Description	TC-001	TC-002	TC-003	TC-004
BR-1	User must be able to log in.
FR-1.1	System shall accept valid username/password.	X
FR-1.2	System shall reject invalid username/password.		X
FR-1.3	System shall lock account after 3 invalid attempts.			X
BR-2	User must be able to log out.
FR-2.1	System shall provide a logout button.				X
FR-2.2	System shall end the user session upon logout.				X

Change Management

Requirement များသည် project လုပ်ဆောင်နေစဥ် အတွင်းမှာ အမြဲတမ်း ပြောင်းလဲမှု ရှိနေပါသည်။ ထို့ကြောင့် အပြောင်းအလဲများကို စနစ်တက် စီမံခန့်ခွဲရန် Change Control Process တစ်ခု လိုအပ်ပါသည်။

Change Request
Impact Analysis
Approval
Implementation

စသည်တို့ ဟာ document အနေနဲ့ မှတ်တမ်း တင်ထားဖို့ လိုအပ်သည်။ ဒါကြောင့် change request ရှိလာခဲ့ရင် client ကို change request form အနေနဲ့ တင်ခိုင်းခြင်းဟာ နောင်တချိန်မှာ ဘာကြောင့် ပြင်ခဲ့ရတယ် ဘယ်သူ့ request ကြောင့် ပြင်ခဲ့ရသည် ဆိုသည့် အထောက်အထား တစ်ခု အနေနဲ့ တည်ရှိမှာပါ။ SRS document တွင် ပါဝင်သည့် အချက်များ နှင့် မတူညီရခြင်းမှာ မည်သည့် change request ကြောင့် ဖြစ်ကြောင်း အထောက်အထား ကို ပြန်ပြနိုင်ဖို့ မှတ်တမ်း တင်ထားဖို့ လိုအပ်ပါသည်။

၄.၆ Use Cases and Scenarios

User stories များအပြင် requirement ကို ဖော်ပြရန် အတွက် Use Case များကိုလည်း အသုံးပြုနိုင်သည်။

Use Cases

Use case ဆိုသည်မှာ သုံးစွဲသူ (Actor) တစ်ဦးက တိကျသော ရည်မှန်းချက် တစ်ခု ပြီးမြောက်ရန် အတွက် စနစ်တကျ အပြန်အလှန် လုပ်ဆောင်သည့် အဆင့်ဆင့် ကို ဖော်ပြထားခြင်း ဖြစ်သည်။

Use Case Name : Use Case ၏ နာမည်
Actor: လုပ်ဆောင်မည့် သူ
Main Flow (Success Scenario) : အောင်မြင်သည့် အခြေအနေ
Alternative Flow : အခြား ဖြစ်နိုင်သည့် အခြေအနေ
Preconditions: Use case မစခင် အခြေအနေ
Postcondition: Use Case ပြီးသွားသည့် အခြေအနေ

Scenarios

Scenario ဆိုသည်မှာ use case တစ်ခုအတွင်းမှ ဖြစ်နိုင်သော လမ်းကြောင်းတစ်ခု (a single path) ဖြစ်သည်။ Use case တစ်ခုသည် scenario များစွာ၏ စုစည်းမှု ဖြစ်သည်။

ဥပမာ: "User Login" use case တွင် အောက်ပါ scenario များ ပါဝင်နိုင်သည်။

Scenario 1: အောင်မြင်စွာ login ဝင်ခြင်း။
Scenario 2: Password မှားယွင်းစွာ ထည့်သွင်းခြင်း။
Scenario 3: Account ကို lock လုပ်ထားခြင်း။

Use Case တစ်ခု ကြည့်ရအောင်

Use Case Name: အသုံးပြုသူ Login ဝင်ခြင်း (User Login)
Actor: သုံးစွဲသူ (User)
Preconditions: သုံးစွဲသူသည် စနစ်၏ Login စာမျက်နှာ (Login Page) သို့ ရောက်ရှိနေရမည်။

Main Flow (Success Scenario) - အဓိက လုပ်ဆောင်မှု (အောင်မြင်သည့် အခြေအနေ)

သုံးစွဲသူ (User) က ၎င်းတို့၏ အီးမေးလ် (သို့မဟုတ်) Username ကို ထည့်သွင်းသည်။
သုံးစွဲသူက ၎င်းတို့၏ စကားဝှက် (Password) ကို ထည့်သွင်းသည်။
သုံးစွဲသူက "Login" ခလုတ်ကို နှိပ်သည်။
စနစ် (System) က ထည့်သွင်းထားသော အချက်အလက်များ (Credentials) ကို စစ်ဆေးအတည်ပြုသည်။
စနစ်က သုံးစွဲသူကို အောင်မြင်စွာ အတည်ပြု (Authenticate) ပြီး logged-in session တစ်ခု စတင်ပေးသည်။
စနစ်က သုံးစွဲသူကို ပင်မစာမျက်နှာ (Dashboard သို့မဟုတ် Home Page) သို့ ပို့ဆောင်ပေးသည်။

Alternative Flows (အခြား ဖြစ်နိုင်သော အခြေအနေများ)

A1: အသုံးပြုသူ အချက်အလက် မှားယွင်းခြင်း (Invalid Credentials)

(Main Flow အဆင့် 4 တွင်) 4.1. စနစ်က အချက်အလက်များကို စစ်ဆေးရာ မမှန်ကန်ကြောင်း တွေ့ရှိသည်။ 4.2. စနစ်က "သင်၏ အီးမေးလ် သို့မဟုတ် စကားဝှက် မှားယွင်းနေပါသည်" (Your email or password is incorrect) ဟူသော သတိပေးချက် (Error Message) ကို ပြသသည်။ 4.3. သုံးစွဲသူသည် Login စာမျက်နှာတွင် ဆက်ရှိနေမည်။ (Use case ပြီးဆုံးသည်)

A2: အချက်အလက် ဖြည့်သွင်းရန် ကျန်ရှိခြင်း (Empty Fields)

(Main Flow အဆင့် 3 တွင်) 3.1. စနစ်က လိုအပ်သော အကွက်များ (အီးမေးလ် သို့မဟုတ် စကားဝှက်) မပြည့်စုံသည်ကို စစ်ဆေးတွေ့ရှိသည်။ 3.2. စနစ်က "လိုအပ်သော အချက်အလက်များကို ဖြည့်စွက်ပါ" (Please fill in the required fields) ဟူသော သတိပေးချက်ကို ပြသသည်။ 3.3. သုံးစွဲသူသည် Login စာမျက်နှာတွင် ဆက်ရှိနေမည်။ (Use case ပြီးဆုံးသည်)

A3: စကားဝှက် မေ့လျော့ခြင်း (Forgot Password)

(Main Flow အဆင့် 1 မတိုင်ခင်) 1.1. သုံးစွဲသူက "စကားဝှက်မေ့သွားပါသလား" (Forgot Password?) လင့်ခ်ကို နှိပ်သည်။ 1.2. စနစ်က သုံးစွဲသူကို စကားဝှက် ပြန်လည်သတ်မှတ်ခြင်း (Password Reset) စာမျက်နှာသို့ ပို့ဆောင်ပေးသည်။ 1.3. (ဤ use case သည် ဤနေရာတွင် ပြီးဆုံးပြီး "Password Reset" use case သို့ ကူးပြောင်းသွားသည်။)

Postconditions (Use Case ပြီးသွားသည့် အခြေအနေများ)

အောင်မြင်ပါက (Main Flow): သုံးစွဲသူသည် စနစ်အတွင်းသို့ အောင်မြင်စွာ ဝင်ရောက်ပြီး ပင်မစာမျက်နှာ (Dashboard) သို့ ရောက်ရှိနေသည်။
မအောင်မြင်ပါက (A1, A2): သုံးစွဲသူသည် Login စာမျက်နှာတွင် ဆက်ရှိနေပြီး သက်ဆိုင်ရာ သတိပေးချက် (Error Message) ကို မြင်တွေ့ရသည်။
အခြားလမ်းကြောင်း (A3): သုံးစွဲသူသည် စကားဝှက် ပြန်လည်သတ်မှတ်ခြင်း (Password Reset) စာမျက်နှာသို့ ရောက်ရှိနေသည်။

တစ်ခါတစ်လေ Use Case များကိုရှင်းလင်း စေရန် Flow Chart Diagram ဖြင့်လည်း ဖော်ပြကြသည်။

Flowchart diagram ဟာ developer တွေ ကို လုပ်ဆောင်ရမည့် အဆင့်ကို ရှင်းလင်း စွာ မြင်စေပါတယ်။ UML မှာ အသုံးပြုသည့် Use case diagram ကတော့ စနစ် တစ်ခုလုံးမှာ ပါဝင်သည့် Use Case များ အားလုံးကို diagram တစ်ခုမှာ ဖော်ပြခြင်းဖြစ်ပါသည်။