Requirements Gathering (Requirement တွေ စုဆောင်းခြင်း)
ဘယ်မှာ အသုံးဝင်လဲ: ဘာမှ မတည်ဆောက်ခင် ပြဿနာ တစ်ခုကို သေချာ နားလည်ဖို့ပါ။ IB Computer Science (နိုင်ငံတကာ ကျောင်းတွေမှာ သင်တဲ့ ကွန်ပျူတာသိပ္ပံ သင်ရိုး) ရဲ့ Internal Assessment (IA၊ IB သင်တန်းမှာ ကျောင်းသားတစ်ယောက်ချင်း ကိုယ်တိုင် တည်ဆောက်ရပြီး ကျောင်းက ဆရာက အမှတ်ပေးတဲ့ အပိုင်း) မှာ ဒါက Criterion A: Problem specification (အမှတ်ပေး စံနှုန်း A: ပြဿနာကို တိတိကျကျ ဖော်ပြချက်) ရဲ့ အလုပ်ပါ။ အဲဒီ criterion က problem scenario (ပြဿနာ ဖြစ်နေတဲ့ အခြေအနေ) ကို ဖြေရှင်းချက်အတွက် တိုင်းတာလို့ရတဲ့ requirement (software က ဘာလုပ်ရမလဲ ဆိုတဲ့ သတ်မှတ်ချက်) တွေ၊ success criteria (အောင်မြင်မှု စံနှုန်းများ) နဲ့ ဖြေရှင်းချက်ရဲ့ computational context (ဖြေရှင်းချက် ပါဝင်တဲ့ computing နယ်ပယ်) တို့နဲ့ ဖော်ပြခိုင်းပါတယ်။ IA မှာ ပြဿနာကို ကိုယ်တိုင် ရွေးရပြီး IA ရဲ့ criteria တွေက client (software ဖန်တီးပေးဖို့ မှာတဲ့သူ) ရှိရမယ်လို့ မတောင်းပါဘူး။ ကိုယ့် project မှာ တကယ့် user တွေ ရှိရင် အောက်က နည်းလမ်းတွေက သူတို့ ဘာလိုအပ်လဲ သိအောင် ကူညီပါတယ်။ IA ပြင်ပက software project တွေမှာလည်း ဒီကျွမ်းကျင်မှု အတူတူကို သုံးပါတယ်။
မာတိကာ
- ခြုံငုံ မိတ်ဆက်
- Code ကနေ မစဘဲ client ကနေ စပါ
- Requirement အမျိုးအစား နှစ်မျိုး
- မရေမရာ ဆန္ဒ တစ်ခုကနေ စမ်းစစ်လို့ရတဲ့ requirement တစ်ခုဆီ
- Success Criteria (အောင်မြင်မှု စံနှုန်းများ)
- တည်ဆောက်ဖို့ တန်ရဲ့လား: Feasibility (လက်တွေ့ ဖြစ်နိုင်ခြေ)
- အဆင့်ဆင့် ရှင်းပြထားတဲ့ ဥပမာ: ဂီတ ဆရာမ တစ်ယောက်ရဲ့ ငွေပေးချေမှု မှတ်တမ်း app
- Quick Check (အမြန် စစ်ဆေးမေးခွန်း)
- Classify the Requirement (requirement အမျိုးအစား ခွဲခြားခြင်း)
- Practice Exercises (လေ့ကျင့်ခန်းများ)
- ဆက်စပ် ခေါင်းစဉ်များ
ခြုံငုံ မိတ်ဆက်
Program တစ်ခုက မြန်ပြီး မှန်ကန်နေရင်တောင် user တွေမှာ မရှိတဲ့ ပြဿနာကို ဖြေရှင်းထားရင် သူတို့အတွက် အသုံးမဝင်ဘဲ ကျရှုံးနိုင်ပါတယ်။ Requirements gathering (requirement တွေ စုဆောင်းခြင်း) က software ဘာလုပ်ရမလဲ၊ ဘယ်သူ့အတွက်လဲ ဆိုတာကို ရှာဖွေ သိရှိတဲ့ အလုပ်ပါ။ အများစုကို development (software တည်ဆောက်တဲ့ အလုပ်) မစခင် လုပ်ပါတယ်၊ project အများအပြားမှာတော့ software ကို တည်ဆောက်ရင်း သုံးမယ့် လူတွေကို ပြနေစဉ်မှာလည်း ဆက်လုပ်ပါတယ်။
ဒီမှာ အလုပ် သုံးခု ပါပါတယ်: software ကို သုံးမယ့် လူတွေ ဘာလိုအပ်လဲ လေ့လာခြင်း၊ အဲဒီ လိုအပ်ချက်တွေကို တည်ဆောက်ဖို့နဲ့ စမ်းစစ်ဖို့ အခြေခံ ယူနိုင်လောက်အောင် ရှင်းရှင်းလင်းလင်း ချရေးခြင်း၊ ပြီးတော့ မစခင်မှာ project က feasible (ရှိတဲ့ အချိန်၊ ကျွမ်းကျင်မှုနဲ့ အရင်းအမြစ်တွေနဲ့ ပြီးအောင် လုပ်နိုင်တဲ့) ဖြစ်မဖြစ် ဆုံးဖြတ်ခြင်း တို့ပါ။
Code ကနေ မစဘဲ client ကနေ စပါ
Client ဆိုတာ software ကို သူ့အတွက် ဖန်တီးပေးနေတဲ့ လူ ဒါမှမဟုတ် အဖွဲ့အစည်းပါ: ဖောက်သည် တစ်ယောက်၊ ဆရာ တစ်ယောက်၊ လုပ်ငန်း တစ်ခု ဒါမှမဟုတ် မိသားစုဝင် တစ်ယောက် ဖြစ်နိုင်ပါတယ်။ Stakeholder (project နဲ့ သက်ဆိုင်သူ) တွေ ဆိုတာ software ကြောင့် အကျိုး ရနိုင်တဲ့ ဒါမှမဟုတ် နစ်နာနိုင်တဲ့ လူအားလုံးပါ: client၊ software ကို နေ့စဉ် သုံးမယ့် လူတွေနဲ့ software က ထိခိုက်တဲ့ တခြားသူတွေ ပါဝင်ပါတယ်၊ ဥပမာ software ကို ထိန်းသိမ်း ပြုပြင်ပေးမယ့်သူ ဒါမှမဟုတ် software က သူတို့ ဒေတာကို သိမ်းထားတဲ့ လူတွေပါ။ ကိုယ့်ဘာသာ မခန့်မှန်းပါနဲ့၊ သူတို့ကို မေးပါ။ သူတို့ အခု ဘယ်လို အလုပ်လုပ်နေလဲ၊ ဘာတွေ ပြောင်းဖို့ လိုလဲ ဆိုတာ ရှာဖွေ သိရှိပါ။
Software ကို ကိုယ်တိုင် သုံးမယ် ဆိုရင်တောင် တခြား user တွေက ကိုယ်နဲ့ မတူဘဲ အလုပ်လုပ်နိုင်ပါတယ်။ ကိုယ့်အတွက် ထင်ရှားနေတဲ့ အရာက client အလုပ်လုပ်ပုံနဲ့ ကိုက်ချင်မှ ကိုက်ပါမယ်၊ ကိုယ် တည်ဆောက်ရတာ စိတ်ဝင်စားတဲ့ feature (program ရဲ့ လုပ်ဆောင်ချက်) တွေကလည်း သူတို့ လိုအပ်တဲ့ feature တွေ ဖြစ်ချင်မှ ဖြစ်ပါမယ်။ သူတို့ လိုအပ်ချက်တွေအကြောင်း အထောက်အထား စုဆောင်းဖို့ ဒီနည်းလမ်းတွေကို သုံးပါ:
| နည်းလမ်း | ဘာလဲ | ဘာအတွက် ကောင်းလဲ |
|---|---|---|
| Interview (တွေ့ဆုံ မေးမြန်းခြင်း) | Client နဲ့ သူ့ ပြဿနာအကြောင်း၊ အခု သူ ဘယ်လို အလုပ်လုပ်နေလဲ ဆိုတာအကြောင်း စကားပြောခြင်း | နက်နက်ရှိုင်းရှိုင်း သိဖို့: client တောင်းဆိုတဲ့ အရာရဲ့ နောက်ကွယ်က ဘာကြောင့် ဆိုတာကို နားလည်ဖို့ |
| Questionnaire (မေးခွန်းလွှာ) | လူ အများအပြားဆီ ပို့တဲ့ ရေးထားတဲ့ မေးခွန်း အစု | ကျယ်ကျယ်ပြန့်ပြန့် သိဖို့: user အများအပြားမှာ ဘာတွေ တူကြလဲ ရှာဖို့ |
| Observation (လုပ်ပုံကို စောင့်ကြည့်ခြင်း) | Software က ကူညီပေးမယ့် အလုပ်ကို client လုပ်နေတာကို စောင့်ကြည့်ခြင်း | လူတွေ ပြောဖို့ မေ့တတ်တဲ့ အဆင့်တွေကို သတိထားမိဖို့ |
| Studying the current system (လက်ရှိ စနစ်ကို လေ့လာခြင်း) | အလုပ်ကို အခု ဘယ်လို လုပ်နေလဲ၊ အဲဒီ အလုပ်မှာ သုံးတဲ့ စာရွက်စာတမ်းတွေ (စက္ကူ ဖောင်တွေ၊ spreadsheet တွေ၊ အစီရင်ခံစာတွေ၊ တခြား app တစ်ခု) ကို ကြည့်ခြင်း။ စာရွက်စာတမ်းတွေကို လေ့လာတာကို document analysis (စာရွက်စာတမ်း ဆန်းစစ်ခြင်း) လို့လည်း တစ်ခါတလေ ခေါ်ပါတယ် | ဘာကို ဆက်ထားရမလဲ၊ ဘာကို ပြင်ရမလဲ ရှာဖို့ |
Interview မှာ open question (ကိုယ့်စကားနဲ့ကိုယ် လွတ်လပ်စွာ ဖြေရတဲ့ မေးခွန်း) တွေနဲ့ စပါ (“ဒါကို အခု ဘယ်လို လုပ်နေလဲ အဆင့်ဆင့် ပြောပြပေးပါ”)။ ဒီလို မေးခွန်းတွေက client ကို ပြဿနာအကြောင်း သူ့စကားနဲ့သူ ဖော်ပြခွင့် ပေးပါတယ်။ ပြီးရင် အသေးစိတ်တွေကို အတည်ပြုဖို့ closed question (ဟုတ်တယ် ဒါမှမဟုတ် မဟုတ်ဘူး လို အဖြေတို ရှိတဲ့ မေးခွန်း) တွေကို သုံးပါ (“ပြီးခဲ့တဲ့ လက ငွေပေးချေမှုတွေကိုလည်း ကြည့်ဖို့ လိုသလား”)။ ပြဿနာကို ကိုယ်တိုင် ကြုံနေရတာက client ဖြစ်လို့ သူ့အတွေ့အကြုံကို သူ ရှင်းပြနိုင်ပါတယ်၊ ဒါကြောင့် ကိုယ်က ဖြေရှင်းချက် မအကြံပြုခင် သူ့ကို အရင် ဖော်ပြခွင့် ပေးပါ။ နောက်ပိုင်းမှာ ပုံကြမ်း တစ်ခု ဒါမှမဟုတ် prototype (စမ်းသပ် ပုံစံ: system ရဲ့ အစိတ်အပိုင်း တစ်ခုရဲ့ အစောပိုင်း version၊ ဥပမာ screen တွေ) ကို ပြတာက ကိုယ် နားလည်တာ မှန်မမှန် အမြန် စစ်နိုင်တဲ့ နည်းပါ။
Client ကို မေးဖို့ အသုံးဝင်တဲ့ မေးခွန်း တစ်ခုက “ဒါ မှားသွားရင် အခု ဘာဖြစ်လဲ” ဆိုတဲ့ မေးခွန်း ဒါမှမဟုတ် အဲဒီလို သဘောရှိတဲ့ မေးခွန်းပါ။ သူတို့ အဖြေက ပျောက်နေတဲ့ အဆင့်တွေ၊ workaround (ပြဿနာကို လောလောဆယ် ရှောင်ကွင်း ဖြေရှင်းထားတဲ့ နည်းတွေ) နဲ့ ပြဿနာရဲ့ အကျိုးဆက်တွေကို ဖော်ပြနိုင်ပါတယ်၊ သူတို့ တိုက်ရိုက် တောင်းဖို့ စဉ်းစားမိမှာ မဟုတ်တဲ့ requirement တွေလည်း ပါပါတယ်။
Requirement အမျိုးအစား နှစ်မျိုး
ပြဿနာကို နားလည်ပြီးရင် requirement တွေကို ချရေးပါ: requirement ဆိုတာ software က ဘာလုပ်ရမလဲ၊ ဒါမှမဟုတ် ဘယ်လို အခြေအနေတွေနဲ့ ကိုက်ညီရမလဲ ဆိုတာကို ရှင်းရှင်းလင်းလင်း ဖော်ပြတဲ့ ဖော်ပြချက်တွေပါ။ ပုံမှန်အားဖြင့် နှစ်မျိုး ခွဲပါတယ်:
Functional requirements (စနစ်က လုပ်ရမယ့် အလုပ်ကို ဖော်ပြတဲ့ requirement များ)
Functional requirement ဆိုတာ စနစ်က လုပ် ရမယ့် အရာပါ: feature တစ်ခု ဒါမှမဟုတ် အပြုအမူ တစ်ခုပါ။ လုပ်ဆောင်ချက် တစ်ခုနဲ့ သူ့ရလဒ်ကို ဖော်ပြပါတယ်။
- “စနစ်က ကျောင်းသား တစ်ယောက် သင်ခန်းစာ တစ်ခုအတွက် ငွေပေးပြီးကြောင်း ဆရာ မှတ်တမ်းတင်နိုင်အောင် လုပ်ပေးရမယ်။”
- “စနစ်က ရွေးထားတဲ့ လ တစ်လအတွက် ငွေမပေးရသေးတဲ့ သင်ခန်းစာ အားလုံးရဲ့ စာရင်းကို ပြရမယ်။”
- “စနစ်က ကျောင်းသား တစ်ယောက်ချင်းစီ ပေးရန် ကျန်တဲ့ စုစုပေါင်း ငွေကို တွက်ပေးရမယ်။”
Functional requirement ဟုတ်မဟုတ် အမြန် စစ်နည်း: စနစ်က လုပ်တဲ့ လုပ်ဆောင်ချက် တစ်ခုကို ဖော်ပြထားပြီး အလုပ်လုပ်နေတာကို ပြလို့ရတဲ့ ရလဒ် တစ်ခု ပါသလား။
Non-functional requirements (စနစ်မှာ ရှိရမယ့် အရည်အသွေး ဒါမှမဟုတ် ကန့်သတ်ချက်ကို ဖော်ပြတဲ့ requirement များ)
Non-functional requirement ဆိုတာ စနစ်မှာ ရှိ ရမယ့် အရည်အသွေး တစ်ခု၊ ဒါမှမဟုတ် စနစ်က လိုက်နာပြီး အလုပ်လုပ်ရမယ့် constraint (ဖြေရှင်းချက်က လိုက်နာရမယ့် ကန့်သတ်ချက်) တစ်ခုပါ: စနစ်က ဘာလုပ်လဲ ဆိုတာ မဟုတ်ဘဲ ဘယ်လောက် ကောင်းကောင်း လုပ်လဲ၊ ဒါမှမဟုတ် ဘယ်စည်းမျဉ်းတွေကို လိုက်နာရလဲ ဆိုတာပါ။
- “App က client ရဲ့ ကိုယ်ပိုင် ဖုန်းပေါ်မှာ သုံးစက္ကန့်အောက်နဲ့ ပွင့်ရမယ်။” (performance: မြန်နှုန်း)
- “စနစ်က ကျောင်းသား တစ်ယောက်ရဲ့ ငွေပေးချေမှု မှတ်တမ်းတွေကို တခြား ကျောင်းသား တစ်ယောက်ကို မပြရဘူး။” (security: လုံခြုံရေး)
- “User အသစ် တစ်ယောက်က သင်တန်း မတက်ရဘဲ ငွေပေးချေမှု တစ်ခုကို မှတ်တမ်းတင်နိုင်ရမယ်။” (usability: သုံးရလွယ်ခြင်း)
- “စနစ်က ကျောင်းမှာ ရှိပြီးသား laptop တွေပေါ်မှာ run နိုင်ရမယ်။” (portability: တခြား platform တွေမှာ ပြောင်းသုံးနိုင်ခြင်း)
Non-functional requirement ရဲ့ အသုံးများတဲ့ အမျိုးအစားတွေက performance (မြန်နှုန်း)၊ security (ဒေတာကို ဘယ်သူ ကြည့်ခွင့်၊ ပြင်ခွင့် ရလဲ ထိန်းချုပ်ခြင်း)၊ usability (စနစ်ကို သုံးရတာ ဘယ်လောက် လွယ်လဲ)၊ reliability (ဘယ်လောက် စိတ်ချရအောင် အလုပ်လုပ်လဲ) နဲ့ portability (မတူတဲ့ device တွေပေါ်မှာ run နိုင်မနိုင်) တို့ပါ။ Client တွေက မပြောဘဲ မျှော်လင့်ထားတတ်လို့ ဒါတွေကို လွတ်သွားလွယ်ပါတယ်၊ ပြီးတော့ ပြီးသွားတဲ့ software ကို လူတွေ ဆက်သုံးမသုံး ဆုံးဖြတ်ပေးနိုင်ပါတယ်။ အများစုက problem specification (ပြဿနာကို တိတိကျကျ ဖော်ပြချက်) ထဲက constraint တွေကနေ လာပါတယ်: “app ထည့်သွင်းစရာ မလိုဘဲ ကျောင်း device တွေပေါ်မှာ အလုပ်လုပ်ရမယ်” ဆိုတာက အဲဒီမှာ constraint တစ်ခု ဖြစ်ပြီး ဒီမှာ non-functional (portability) requirement တစ်ခု ဖြစ်ပါတယ်။
အဖြစ်များတဲ့ ရောထွေးမှု: “စနစ်က လုံခြုံရမယ်” ဆိုတာ သူ့ချည်းသက်သက်ဆိုရင် requirement ကောင်း တစ်ခု မဟုတ်ပါဘူး။ Non-functional ရည်မှန်းချက် တစ်ခုကို ဖော်ပြထားပေမယ့် စမ်းစစ်လို့ရမယ့် နည်း မပေးထားပါဘူး။ စစ်လို့ရတဲ့ ဖော်ပြချက် တစ်ခုအဖြစ် ပြောင်းရေးပါ: “password နဲ့ login ဝင်ပြီးမှသာ ငွေပေးချေမှု မှတ်တမ်းတွေကို မြင်ရမယ်။” ဖော်ပြချက် တစ်ခုကို စမ်းစစ်လို့ မရရင် ပြီးသွားတဲ့ စနစ်က အဲဒီ ဖော်ပြချက်နဲ့ ကိုက်ညီကြောင်း ပြလို့ မရပါဘူး။
Security လိုအပ်ချက် တချို့ကို နှစ်မျိုးလုံး ရေးလို့ရပါတယ်။ “Login ဝင်ပြီးမှသာ ငွေပေးချေမှု မှတ်တမ်းတွေကို မြင်ရမယ်” ဆိုတာက စနစ်မှာ ရှိရမယ့် အရည်အသွေး တစ်ခုကို ဖော်ပြတာပါ၊ “ငွေပေးချေမှု မှတ်တမ်းတွေကို မပြခင် စနစ်က password တောင်းတယ်” ဆိုတာကတော့ အပြုအမူ တစ်ခုကို ဖော်ပြတာပါ၊ ဒါကြောင့် အဖွဲ့ တချို့က ဒီလိုအပ်ချက်ကို functional requirement အဖြစ် စာရင်းသွင်းကြပါတယ်။ ဘယ်လိုပဲ ရေးရေး ဖော်ပြချက်က စမ်းစစ်လို့ ရရပါမယ်။
မရေမရာ ဆန္ဒ တစ်ခုကနေ စမ်းစစ်လို့ရတဲ့ requirement တစ်ခုဆီ
Client တွေက သူတို့ လိုချင်တာကို ယေဘုယျ ဆန္ဒတွေအဖြစ် ပြောတတ်ပါတယ်။ ကိုယ့်အလုပ်က ဆန္ဒ တစ်ခုချင်းစီကို တည်ဆောက်ဖို့နဲ့ စမ်းစစ်ဖို့ လုံလောက်အောင် တိကျတဲ့ requirement တစ်ခုအဖြစ် ပြောင်းဖို့ပါ။ Requirement ကောင်း တစ်ခုက specific (တိကျတဲ့)၊ measurable (တိုင်းတာလို့ရတဲ့) နဲ့ testable (စမ်းစစ်လို့ရတဲ့) ဖြစ်ပါတယ်: ဘာလိုအပ်လဲ ဆိုတာကို အတိအကျ ပြောပါတယ်၊ စစ်လို့ရတဲ့ ဂဏန်း တစ်ခု ဒါမှမဟုတ် ရှင်းလင်းတဲ့ ရလဒ် တစ်ခု ပါပါတယ် (measurable)၊ ပြီးသွားတဲ့ စနစ်က အဲဒါနဲ့ ကိုက်ညီမညီ ပြဖို့ test (စမ်းသပ်မှု) တစ်ခု run လို့ ရပါတယ် (testable)။
| Client က ပြောတာ | ကိုယ် ရေးရမယ့် requirement |
|---|---|
| “မြန်မြန် ဖြစ်သင့်တယ်။” | “ဆရာမက သူ့ဖုန်းပေါ်မှာ ငွေပေးချေမှု စာရင်းကို ဖွင့်ပြီး 2 စက္ကန့်အောက်မှာ စာရင်း ပေါ်လာတယ်။” |
| “ဘယ်သူ ငွေ ပေးရန် ကျန်သေးလဲ မြင်ချင်တယ်။” | “စနစ်က ကျောင်းသား တစ်ယောက်ချင်းစီရဲ့ နာမည်နဲ့ ပေးရန် ကျန်တဲ့ ငွေ စုစုပေါင်းကို ပမာဏအလိုက် စီပြီး ပြတယ်။” |
| “သုံးရ လွယ်ရမယ်။” | “ဆရာ တစ်ယောက်က main screen (အဓိက screen) ကနေ click 3 ချက် ဒါမှမဟုတ် ဒီထက် နည်းတဲ့ click နဲ့ ငွေပေးချေမှု တစ်ခုကို မှတ်တမ်းတင်နိုင်တယ်။” |
အတန်း တိုင်းမှာ ခံစားချက် (“မြန်”၊ “လွယ်”) ကို တိုင်းတာပြီး စမ်းစစ်လို့ရတဲ့ အရာနဲ့ အစားထိုးထားပါတယ်။ ဒါက နည်းလမ်း နှစ်မျိုးနဲ့ ကူညီပါတယ်: တည်ဆောက်တဲ့အခါ “ပြီးပြီ” ဆိုတာ ဘာကို ဆိုလိုလဲ သိပါတယ်၊ စမ်းစစ်တဲ့အခါ ဘာကို စစ်ရမလဲ သိပါတယ်။
Success Criteria (အောင်မြင်မှု စံနှုန်းများ)
Success criteria ဆိုတာ requirement တွေကနေ ထုတ်ယူထားတဲ့ တိုင်းတာလို့ရတဲ့ ရလဒ်တွေ ဖြစ်ပြီး product (တည်ဆောက်ထားတဲ့ program ဒါမှမဟုတ် app) ကို အောင်အောင်မြင်မြင် တည်ဆောက်နိုင်ခဲ့လား ဆိုတာကို ပြပါတယ်။ တည်ဆောက်နေစဉ်မှာ test တွေကို စီစဉ်ဖို့နဲ့ အဆုံးမှာ ပြီးသွားတဲ့ product ကို အကဲဖြတ်ဖို့ သုံးပါတယ်။ Client ရှိရင် တည်ဆောက်တာ မစခင် success criteria တွေကို client နဲ့ သဘောတူညီချက် ယူထားပါ၊ ဒါမှ ပြီးသွားတဲ့ product ကို နှစ်ဦးစလုံးက ပန်းတိုင် တစ်ခုတည်းနဲ့ ချိန်ပြီး အကဲဖြတ်နိုင်ပါမယ်။
Problem Specification စာမျက်နှာမှာတော့ measurable goal (တိုင်းတာလို့ရတဲ့ ပန်းတိုင်) တွေနဲ့ evaluation criteria (ဖြေရှင်းချက် အောင်မြင်မအောင်မြင် အကဲဖြတ်မယ့် စံနှုန်းများ) က အလားတူ အလုပ်ကို လုပ်ပါတယ်။ IA ကတော့ success criteria ဆိုတဲ့ term ကို သုံးပါတယ်။
Success criteria ကောင်းတွေက စမ်းစစ်လို့ရပြီး client ရဲ့ တကယ့် လိုအပ်ချက်တွေနဲ့ ချိတ်ဆက်ထားပါတယ်:
- “ဆရာ တစ်ယောက်က သင်ခန်းစာ ငွေပေးချေမှု တစ်ခုကို မှတ်တမ်းတင်ပြီး confirmation screen (အတည်ပြုချက် ပြတဲ့ screen) ပေါ်မှာ ကျောင်းသားရဲ့ စုစုပေါင်း အသစ်ကို မြင်နိုင်တယ်။”
- “လစဉ် ငွေမပေးရသေးတဲ့ သင်ခန်းစာ အစီရင်ခံစာကို တစ်မိနစ်အောက်မှာ ထုတ်နိုင်တယ်။”
- “Login မဝင်ဘဲ ငွေပေးချေမှု မှတ်တမ်း တစ်ခုမှ မမြင်ရဘူး။”
Success criterion တစ်ခုမှာ ရှင်းလင်းတဲ့ test တစ်ခု လိုပါတယ်။ “code ကို ကောင်းကောင်း ရေးထားတယ်” ဒါမှမဟုတ် “program က သုံးရ လွယ်တယ်” လို ဖော်ပြချက်တွေက ပြည့်မီမမီ စစ်နိုင်ဖို့ တိုင်းတာလို့ရတဲ့ အသေးစိတ်တွေ လိုပါသေးတယ်။ Criterion တစ်ခုကို စစ်ဖို့ run မယ့် test ကို မမြင်ယောင်နိုင်ရင် ပြန်ရေးပါ။
IB CS သင်တန်း တက်နေသူတွေအတွက် မှတ်ချက်: Internal Assessment မှာ Criterion A မှာ ဖော်ပြထားတဲ့ success criteria တွေကို ကိုယ့် plan (Criterion B)၊ testing strategy (စမ်းသပ်ပုံ အစီအစဉ်၊ Criterion C)၊ product တည်ဆောက်ခြင်း (Criterion D) နဲ့ evaluation (အကဲဖြတ်ခြင်း၊ Criterion E) မှာ ပြန်သုံးရပါတယ်။ Evaluation မှာ criterion တစ်ခုစီကို ဘယ်အတိုင်းအတာအထိ ပြည့်မီလဲ အကဲဖြတ်ရပါတယ်။ အစမှာ မရေမရာ ဖြစ်နေတဲ့ criteria တွေကို နောက်ပိုင်းမှာ စီစဉ်ဖို့၊ စမ်းစစ်ဖို့ ဒါမှမဟုတ် အကဲဖြတ်ဖို့ ခက်ပါတယ်၊ ဒါကြောင့် စောစောကတည်းက တိုင်းတာလို့ရအောင် ရေးထားတာ တန်ပါတယ်။
တည်ဆောက်ဖို့ တန်ရဲ့လား: Feasibility (လက်တွေ့ ဖြစ်နိုင်ခြေ)
Feasibility ဆိုတာ ရှိတဲ့ အချိန်၊ ငွေနဲ့ ကျွမ်းကျင်မှု စတဲ့ constraint တွေအတွင်းမှာ project က အောင်မြင်နိုင်မနိုင် အစောပိုင်းမှာ စစ်ဆေးခြင်းပါ။ ရလဒ်က ဆက်လုပ်ဖို့၊ scope (project ရဲ့ အတိုင်းအတာ) ကို လျှော့ဖို့ (version အသေး တစ်ခု တည်ဆောက်ဖို့) ဒါမှမဟုတ် ရပ်ဖို့ ဆုံးဖြတ်ချက် ဖြစ်နိုင်ပါတယ်။ နည်းနည်းပဲ တည်ဆောက်ဖို့ ဒါမှမဟုတ် လုံးဝ မတည်ဆောက်ဖို့ ဆုံးဖြတ်တာက ဒီစစ်ဆေးမှုရဲ့ သင့်တော်တဲ့ ရလဒ် တစ်ခုပါ။
TELOS က feasibility စစ်ဆေးမှုကို စနစ်တကျ စီစဉ်တဲ့ အသုံးများတဲ့ နည်းပါ။ သူ့နာမည်က သူ စစ်ဆေးတဲ့ နယ်ပယ် ငါးခုရဲ့ ပထမ စာလုံးတွေကနေ လာပါတယ်:
| စာလုံး | နယ်ပယ် | မေးတဲ့ မေးခွန်း |
|---|---|---|
| T | Technical (နည်းပညာ) | ဒါကို တကယ် တည်ဆောက်နိုင်ဖို့ ကျွမ်းကျင်မှုနဲ့ နည်းပညာ ရှိသလား။ |
| E | Economic (ကုန်ကျစရိတ်နဲ့ အကျိုးအမြတ်) | ရမယ့် အကျိုးနဲ့ နှိုင်းယှဉ်ရင် ကုန်ကျစရိတ်၊ အချိန်နဲ့ အားထုတ်မှုက တန်သလား။ |
| L | Legal (ဥပဒေ) | ဒါကို လုပ်ခွင့် ရှိသလား။ (ကိုယ်ရေး ဒေတာ ကာကွယ်ရေး၊ မူပိုင်ခွင့်၊ သုံးခွင့် လိုင်စင်) |
| O | Operational (လုပ်ငန်း လည်ပတ်မှု) | တည်ဆောက်ပြီးရင် လူတွေ တကယ် အလုပ်လုပ်ပုံနဲ့ ကိုက်ညီပါ့မလား၊ ထိန်းသိမ်းနိုင်ပါ့မလား (ဆက် အလုပ်လုပ်နေအောင်နဲ့ ခေတ်နဲ့ အညီ update ဖြစ်နေအောင် ထားနိုင်မလား)။ |
| S | Schedule (အချိန်ဇယား) | ရှိတဲ့ အချိန်အတွင်း ပြီးအောင် လုပ်နိုင်မလား။ |
Project တစ်ခုက နည်းပညာအရ ဖြစ်နိုင်ပေမယ့် အချိန်မီ ပြီးဖို့ ကြီးလွန်းနိုင်ပါတယ်၊ ဒါမှမဟုတ် ဥပဒေအရ ခွင့်ပြုပေမယ့် ကုန်ကျစရိတ်နဲ့ မတန်နိုင်ပါဘူး။ TELOS က development မစခင် နယ်ပယ် ငါးခုလုံးကို စစ်ဆေးနိုင်အောင် ကူညီပါတယ်၊ ဒါမှ ကြီးမားတဲ့ ပြဿနာကို တစ်ဝက်ရောက်မှ သိရတာမျိုး မဖြစ်ပါဘူး။
ကျောင်း project တစ်ခုအတွက်ဆိုရင် ကိုယ့် နည်းပညာ ကျွမ်းကျင်မှုနဲ့ ရှိတဲ့ အချိန်က အဓိက ကန့်သတ်ချက်တွေ ဖြစ်တတ်ပါတယ်။ IA အတွက် IB guide (IB ရဲ့ တရားဝင် သင်ရိုး လမ်းညွှန်) က ကိုယ့် ပြဿနာကို ဖြေရှင်းဖို့ လိုတဲ့ နည်းပညာ ကျွမ်းကျင်မှု၊ hardware နဲ့ software၊ ဒေတာတွေ ကိုယ့်မှာ ရှိသင့်တယ်လို့ ဆိုပါတယ်: တကယ်တော့ ကိုယ့် project ပေါ်မှာ feasibility စစ်ဆေးတာပါပဲ။ Guide က သင်တန်းအတွက် လုံလောက်အောင် ရှုပ်ထွေးတဲ့ ဖြေရှင်းချက် လိုတဲ့ ပြဿနာကိုလည်း တောင်းပါတယ်၊ ဒါကြောင့် လုံလောက်အောင် ရှုပ်ထွေးပေမယ့် deadline (နောက်ဆုံး ပြီးရမယ့် အချိန်) မတိုင်ခင် implement (တကယ် အလုပ်လုပ်အောင် code ရေး) လုပ်၊ စမ်းစစ်ပြီး အကဲဖြတ်နိုင်လောက်အောင် သေးတဲ့ project ကို ရွေးပါ။
အဆင့်ဆင့် ရှင်းပြထားတဲ့ ဥပမာ: ဂီတ ဆရာမ တစ်ယောက်ရဲ့ ငွေပေးချေမှု မှတ်တမ်း app
အခြေအနေ။ Ms Okafor က ကျောင်းသား လေးဆယ်လောက်ကို သူ့ကိုယ်ပိုင် studio မှာနဲ့ ရပ်ရွာ ခန်းမ နှစ်ခုမှာ တယော သင်ပါတယ်။ လက်ရှိမှာ သင်ခန်းစာအတွက် ဘယ်သူ ငွေပေးပြီးပြီလဲ ဆိုတာကို စက္ကူ မှတ်စုစာအုပ်မှာ မှတ်ထားပြီး ဘယ်သူ ဘယ်လောက် ပေးရန် ကျန်လဲ ဆိုတာကို ခဏခဏ ရှုပ်ထွေးပြီး မသိတော့ ဖြစ်နေပါတယ်။ ကူညီပေးမယ့် တစ်ခုခု တည်ဆောက်ပေးဖို့ ကိုယ့်ကို တောင်းဆိုပါတယ်။
Consultation (တိုင်ပင် မေးမြန်းခြင်း)။ ခန့်မှန်းမယ့်အစား သူ့ကို interview လုပ်ပါတယ်။ သူက စာရင်းကိုင် စနစ် အပြည့်အစုံ မလိုချင်ဘူး ဆိုတာ သိရပါတယ်၊ မေးခွန်း တစ်ခုကို မြန်မြန် ဖြေနိုင်ချင်တာပါ: ဘယ်သူတွေက ကျွန်မကို ငွေ ပေးရန် ကျန်သေးလဲ၊ ဘယ်လောက်လဲ။ သူက သင်ခန်းစာတွေကြားမှာ ဖုန်းကနေ အလုပ်လုပ်တာမို့ software ကို screen သေးသေးပေါ်မှာ သုံးလို့ ရရပါမယ်။
Functional requirement များ (နမူနာ):
- ကျောင်းသား တစ်ယောက်ကို၊ သူ့ သင်ခန်းစာတွေ လုပ်တဲ့ နေရာနဲ့ သင်ခန်းစာ ကြေးကို မှတ်တမ်းတင်ခြင်း။
- ပေးထားတဲ့ ရက်စွဲ တစ်ခုမှာ သင်ခန်းစာ တစ်ခုကို ငွေပေးပြီး ဒါမှမဟုတ် ငွေမပေးရသေး လို့ မှတ်ခြင်း။
- ဘယ်လ အတွက်မဆို ငွေမပေးရသေးတဲ့ သင်ခန်းစာ ရှိတဲ့ ကျောင်းသား စာရင်းနဲ့ တစ်ယောက်ချင်းစီ ပေးရန် ကျန်တဲ့ စုစုပေါင်းကို ပြခြင်း။
Non-functional requirement များ:
- သင်ခန်းစာတွေကြားမှာ ဖုန်း screen ပေါ်မှာ လက်တစ်ဖက်တည်းနဲ့ သုံးလို့ရခြင်း (usability)။
- ငွေပေးချေမှု ဒေတာကို လျှို့ဝှက်ထားပြီး ကျောင်းသားတွေ မမြင်ရခြင်း (security)။
- ခန်းမ တစ်ခုမှာ signal အားနည်းလို့ အင်တာနက် မရှိဘဲ အလုပ်လုပ်ခြင်း (reliability)။
Success criterion တစ်ခု: “Ms Okafor က လက်ရှိ လအတွက် ငွေ ပေးရန် ကျန်တဲ့ လူအားလုံးရဲ့ မှန်ကန်တဲ့ စာရင်းကို 30 စက္ကန့်အောက်မှာ မြင်နိုင်တယ်။”
Feasibility (TELOS နဲ့ အကျဉ်းချုပ်): Technical အရ ရိုးရှင်းပါတယ်: ဒေတာ နည်းနည်းပဲ သိမ်းပြီး screen အနည်းငယ်ပဲ လိုပါတယ်။ Economic အရ developer (software ရေးသူ) က အားလပ်ချိန် ရက်သတ္တပတ် အနည်းငယ်အတွင်း တည်ဆောက်နိုင်ရင် လစဉ် သူ့အတွက် ချွေတာပေးမယ့် နာရီတွေကြောင့် တည်ဆောက်ဖို့ တန်ပါတယ်။ Legal အရ ကိုယ်ရေး ဒေတာ သိမ်းထားလို့ အဲဒီ ဒေတာကို လျှို့ဝှက်ထားရပါမယ်။ Operational အရ သင်ခန်းစာတွေကြား ဖုန်းနဲ့ အလုပ်လုပ်တဲ့ သူ့ပုံစံနဲ့ ကိုက်ညီရပါမယ်၊ မဟုတ်ရင် သူ မှတ်စုစာအုပ်ဆီ ပြန်သွားပါလိမ့်မယ်။ Schedule အရ ရှိတဲ့ အချိန်အတွင်း ပြီးနိုင်မနိုင် ရိုးရှင်းတဲ့ အစီအစဉ် တစ်ခုနဲ့ စစ်ကြည့်ပါမယ်။ အချိန်နဲ့ ကုန်ကျစရိတ် စစ်ဆေးမှုတွေက ဖြစ်နိုင်တယ်လို့ ပြရင် ဆုံးဖြတ်ချက်က: တည်ဆောက်ပါ၊ ပြီးတော့ တမင် သေးသေးလေးပဲ ထားပါ။
Interview က project ကို ပြောင်းလဲသွားစေတာကို သတိပြုပါ။ ခန့်မှန်းခဲ့ရင် စာရင်းကိုင် tool အကြီးကြီး တစ်ခု တည်ဆောက်မိကောင်း တည်ဆောက်မိပါလိမ့်မယ်။ နားထောင်ခဲ့လို့ တကယ့် requirement က မေးခွန်း တစ်ခုကို မြန်မြန် ဖြေနိုင်ဖို့ ဖြစ်ကြောင်း သိရပြီး အဲဒါက ကျန်တဲ့ ဒီဇိုင်းကို ဆုံးဖြတ်ပေးခဲ့ပါတယ်။
Quick Check (အမြန် စစ်ဆေးမေးခွန်း)
Q1. "စနစ်က ရှာဖွေမှု ရလဒ်တွေကို နှစ်စက္ကန့်အောက်မှာ ပြန်ပေးရမယ်။" ဒါက ဘယ်လို requirement အမျိုးအစားလဲ။
Q2. ဒါတွေထဲက ဘယ်ဟာက functional requirement လဲ။
Q3. Client တကယ် ဘာလိုအပ်လဲ သိဖို့ အယုံကြည်ရဆုံး နည်းက ဘာလဲ။
Q4. ပရဟိတ အဖွဲ့ တစ်ခုက သူ့ စေတနာ့ဝန်ထမ်းတွေအတွက် app တစ်ခု လုပ်ဖို့ စီစဉ်ပါတယ်။ အလုပ်များတဲ့ တာဝန်ချိန်တွေမှာ သူတို့ အလုပ်လုပ်ပုံနဲ့ app က မကိုက်ညီမှာမို့ စက္ကူ ဖောင်တွေကိုပဲ ဆက်သုံးမယ်လို့ စေတနာ့ဝန်ထမ်းတွေက ပြောပါတယ်။ TELOS feasibility စစ်ဆေးမှုမှာ ဒါက ဘယ်နယ်ပယ်လဲ။
Q5. ဒါတွေထဲက ဘယ်ဟာက အခိုင်မာဆုံး success criterion လဲ။
Q6. Feasibility စစ်ဆေးမှုရဲ့ ရည်ရွယ်ချက်က ဘာလဲ။
Classify the Requirement (requirement အမျိုးအစား ခွဲခြားခြင်း)
Requirement တစ်ခုစီက functional လား non-functional လား ရေးပါ။ Requirement တွေကို English နဲ့ ရေးထားပြီး ကွက်လပ်တွေကိုလည်း English လို functional ဒါမှမဟုတ် non-functional လို့ ရိုက်ထည့်ရပါမယ်။ Type: ဆိုတာ “အမျိုးအစား:” လို့ ဆိုလိုပြီး requirement တစ်ခုချင်းရဲ့ အဓိပ္ပာယ်က အောက်ပါအတိုင်းပါ:
- “စနစ်က user ကို မေ့သွားတဲ့ password ကို ပြန်သတ်မှတ် (reset) ခွင့် ပေးတယ်”
- “စနစ်က ဖုန်း၊ tablet နဲ့ laptop တွေပေါ်မှာ အလုပ်လုပ်တယ်”
- “ငွေပေးချေမှု တစ်ခုစီပြီးတိုင်း စနစ်က ပြေစာကို email နဲ့ ပို့ပေးတယ်”
- “ကျောင်းချိန်အတွင်း အချိန်ရဲ့ အနည်းဆုံး 99% မှာ စနစ်ကို သုံးလို့ ရတယ်”
- “စနစ်က ကျောင်းသားတွေကို သူတို့ ပေးရန် ကျန်တဲ့ ပမာဏအလိုက် စီပေးတယ်”
ကွက်လပ် ဖြည့်ပါ: functional ဒါမှမဟုတ် non-functional ကို ရိုက်ထည့်ပါ။
// The system lets a user reset a forgotten password
// Type:
// The system works on phones, tablets, and laptops
// Type:
// The system emails a receipt after each payment
// Type:
// The system is available at least 99% of the time during school hours
// Type:
// The system sorts students by the amount they owe
// Type: Feature တစ်ခုတည်းမှာ requirement နှစ်မျိုးလုံး ရှိနိုင်ပါတယ်။ “သင်ခန်းစာ တစ်ခုအတွက် ငွေပေးပြီးကြောင်း စနစ်က မှတ်တမ်းတင်တယ်” ဆိုတာ စနစ်လုပ်တဲ့ အရာ တစ်ခုကို ဖော်ပြလို့ functional ဖြစ်ပါတယ်။ “တစ်စက္ကန့်အောက်မှာ” လို့ ထပ်ထည့်ရင် အဲဒီ အချိန်နဲ့ ဆိုင်တဲ့ အပိုင်းက feature တစ်ခုတည်းအပေါ်က non-functional (performance) requirement ဖြစ်ပါတယ်။
Practice Exercises (လေ့ကျင့်ခန်းများ)
IB CS သင်တန်း တက်နေသူတွေအတွက် မှတ်ချက်: Internal Assessment ရဲ့ Criterion A က ဖြေရှင်းချက်အတွက် တိုင်းတာလို့ရတဲ့ requirement တွေကို တောင်းပါတယ်။ Core 2 နဲ့ Core 3 က requirement ရေးတာကို လေ့ကျင့်ပေးတာမို့ requirement တစ်ခုချင်းစီကို တိုင်းတာလို့ရအောင် ရေးဖို့ ကြိုးစားပါ။
Distinguish နဲ့ Explain လို English စကားလုံးတွေက IB command term (မေးခွန်းမှာ ဘာလုပ်ရမလဲ ပြတဲ့ ညွှန်ကြားချက် စကားလုံး) တွေပါ။ (4 marks) လို mark allocation (မေးခွန်း တစ်ခုစီအတွက် ပေးတဲ့ အမှတ်) တွေက IB Computer Science စာမေးပွဲ ပုံစံအတိုင်း ပေးထားတာပါ၊ ဥပမာ (4 marks) ဆိုတာ 4 မှတ်ပါ။ IB သင်တန်း မတက်တဲ့သူတွေကတော့ အဖြေ ဘယ်လောက် အသေးစိတ် ရေးရမလဲ ချိန်ကြည့်ဖို့ လမ်းညွှန်အဖြစ် သုံးနိုင်ပါတယ်။
Core (အခြေခံ အဆင့်)
-
Distinguish (အရာ နှစ်ခု ဒါမှမဟုတ် ပိုများတဲ့ အရာတွေကြားက ကွာခြားချက်ကို ရှင်းရှင်းလင်းလင်း ပြပါ) (4 marks): Functional requirement နဲ့ non-functional requirement ကြားက ကွာခြားချက်ကို distinguish လုပ်ပါ။ ကျောင်းမှာ ပျောက်နေတဲ့ ပစ္စည်းတွေကို ပိုင်ရှင်တွေဆီ ပြန်ပေးဖို့ ကူညီတဲ့ app တစ်ခုအတွက် ကိုယ်တိုင် စဉ်းစားထားတဲ့ ဥပမာ တစ်ခုစီ ပေးပါ။
-
Identify (ဖြစ်နိုင်တဲ့ အဖြေတွေထဲက ရွေးပြီး ဖော်ပြပါ) (4 marks): ရိုးရှင်းတဲ့ canteen (ကျောင်း စားသောက်ဆိုင်) ကြိုတင် မှာယူတဲ့ app တစ်ခုအတွက် functional requirement နှစ်ခုနဲ့ non-functional requirement နှစ်ခု ရေးပါ။
-
Suggest (ဖြစ်နိုင်တဲ့ အဖြေ တစ်ခုကို အကြံပြုပါ) (4 marks): ရပ်ရွာ သံပြိုင်အဖွဲ့ (choir) တစ်ခုက အဖွဲ့ဝင်တွေ အစမ်းလေ့ကျင့်ချိန် တိုင်းမှာ sign in (ရောက်ကြောင်း မှတ်တမ်းတင်) လုပ်ဖို့ သုံးမယ့် app တစ်ခု လိုချင်ပါတယ်။ ဒီဆန္ဒ တစ်ခုစီအတွက် တိကျပြီး စမ်းစစ်လို့ရတဲ့ requirement တစ်ခုကို suggest လုပ်ပါ: (a) “လူတိုင်း တစ်ပြိုင်နက် sign in လုပ်တဲ့အခါ ကိုင်တွယ်နိုင်သင့်တယ်”၊ (b) “မျက်စိ အားနည်းတဲ့ အဖွဲ့ဝင်တွေ ဖတ်ရ လွယ်သင့်တယ်”။
Extension (တိုးချဲ့ အဆင့်)
-
Suggest (6 marks): ကိုယ် သိတဲ့ တစ်ယောက်ယောက် တကယ် ကြုံနေရတဲ့ ပြဿနာ သေးသေး တစ်ခုကို ရွေးပါ။ သူ့ကို မေးမယ့် interview မေးခွန်း သုံးခုကို suggest လုပ်ပြီး မေးခွန်း တစ်ခုစီက ဘာကို သိဖို့ ကြိုးစားနေလဲ ရှင်းပြပါ။
-
Explain (ရှင်းပြပါ) (6 marks): TELOS framework ကို သုံးပြီး နည်းပညာအရ ဖြစ်နိုင်တဲ့ project တစ်ခု ဆက်မလုပ်ဖြစ်နိုင်တဲ့ အကြောင်းရင်း သုံးခုကို explain လုပ်ပါ။ အကြောင်းရင်း တစ်ခုစီက မတူတဲ့ TELOS နယ်ပယ် တစ်ခုစီကနေ ဖြစ်ရပါမယ်။
Challenge (စိန်ခေါ်မှု အဆင့်)
- Discuss (အမြင် အမျိုးမျိုးကို ချိန်ဆပြီး ဆွေးနွေးပါ) (8 marks): ကျောင်းသား တစ်ယောက်က “Code စရေးလိုက်မယ်၊ requirement တွေကိုတော့ ရေးရင်းနဲ့ စဉ်းစားသွားမယ်” လို့ ပြောပါတယ်။ ဒီချဉ်းကပ်ပုံရဲ့ အန္တရာယ်တွေနဲ့ requirement တွေကို အရင် စုဆောင်းခြင်းရဲ့ တန်ဖိုးကို Discuss လုပ်ပါ။ အကြောင်းပြချက် ခိုင်လုံတဲ့ နိဂုံးချုပ် တစ်ခုအထိ ရေးပါ။ (Prose နဲ့ ရေးပါ: bullet point (အချက်ပြ စာကြောင်းတို) တွေ မဟုတ်ဘဲ စာပိုဒ်တွေထဲမှာ စာကြောင်း အပြည့်အစုံတွေနဲ့ ရေးပါ။)
ဆက်စပ် ခေါင်းစဉ်များ
- နောက်ထပ် လေ့လာမယ့် ခေါင်းစဉ်: Design Representations (ဒီဇိုင်းကို ဖော်ပြတဲ့ နည်းလမ်းများ): requirement တွေကို သိပြီးရင် ဖြေရှင်းချက်ကို စာရွက်ပေါ်မှာ ဒီဇိုင်းဆွဲပါတယ်
- ဆက်စပ် ခေါင်းစဉ်: Testing Strategy (စမ်းသပ်ပုံ အစီအစဉ်): success criteria တွေက ဖြေရှင်းချက် အလုပ်လုပ်မလုပ် စစ်တဲ့ test တွေ ဖြစ်လာပါတယ်
- ဆက်စပ် ခေါင်းစဉ်: Problem Specification (ပြဿနာကို တိတိကျကျ ဖော်ပြချက်): constraint၊ goal နဲ့ evaluation criteria တွေနဲ့ ပြဿနာကို သတ်မှတ် ဖော်ပြခြင်း
- ဆက်စပ် ခေါင်းစဉ်: Internal Assessment: Criterion A မှာ requirement တွေနဲ့ success criteria တွေကို ဘယ်လို အမှတ်ပေးလဲ