វិធីសាស្រ្តទំនើបសម្រាប់ការពិពណ៌នាអំពីតម្រូវការមុខងារសម្រាប់ប្រព័ន្ធ។ Alistair Coburn ។ ការពិនិត្យឡើងវិញនៃសៀវភៅនិងការបន្ថែម

សៀវភៅនេះពិពណ៌នាអំពីវិធីសាស្រ្តមួយសម្រាប់ការសរសេរផ្នែកនៃសេចក្តីថ្លែងការណ៍បញ្ហា ពោលគឺវិធីសាស្ត្រករណីប្រើប្រាស់។

តើ​វា​ជា​អ្វី? នេះគឺជាការពិពណ៌នាអំពីសេណារីយ៉ូអន្តរកម្មអ្នកប្រើប្រាស់ជាមួយប្រព័ន្ធ (ឬជាមួយអាជីវកម្ម)។ ក្នុងករណីនេះ ប្រព័ន្ធដើរតួជាប្រអប់ខ្មៅ (ហើយនេះធ្វើឱ្យវាអាចបែងចែកកិច្ចការរចនាដ៏ស្មុគស្មាញទៅជាការរចនាអន្តរកម្ម និងធានានូវអន្តរកម្មនេះ)។ ក្នុងពេលជាមួយគ្នានេះ ស្តង់ដារកំណត់ចំណាំត្រូវបានណែនាំ ដែលធានាភាពងាយស្រួលនៃការអាន រួមទាំងសម្រាប់អ្នកដែលមិនចូលរួម និងអនុញ្ញាតឱ្យមានការត្រួតពិនិត្យមួយចំនួនសម្រាប់ភាពពេញលេញ និងការអនុលោមតាមគោលដៅរបស់អ្នកពាក់ព័ន្ធ។

ប្រើឧទាហរណ៍ករណី

តើសេណារីយ៉ូមើលទៅដូចម្ដេច ដោយប្រើឧទាហរណ៍នៃការអនុញ្ញាតនៅលើគេហទំព័រតាមរយៈអ៊ីមែល៖

(ប្រព័ន្ធ) ចូលទៅកាន់គេហទំព័រ ដើម្បីចូលប្រើគណនីផ្ទាល់ខ្លួនរបស់អ្នក។ ~~ (កម្រិតទឹកសមុទ្រ)

បរិបទ៖ អតិថិជនដែលគ្មានការអនុញ្ញាតចូលគេហទំព័រ ដើម្បីឱ្យគេហទំព័រស្គាល់គាត់ និងបង្ហាញព័ត៌មានផ្ទាល់ខ្លួនសម្រាប់គាត់៖ ប្រវត្តិរុករក ប្រវត្តិទិញ ចំនួនពិន្ទុបន្ថែមបច្ចុប្បន្ន។ល។ ដោយប្រើអ៊ីមែលជាការចូល។ 
កំរិត៖ គោលដៅអ្នកប្រើប្រាស់
តួឯក: អតិថិជន (អ្នកទស្សនាហាងអនឡាញរបស់យើង)
វិសាលភាព៖ អន្តរកម្មរបស់អតិថិជនជាមួយគេហទំព័រហាងអនឡាញ
ភាគីពាក់ព័ន្ធ និងផលប្រយោជន៍៖

• អ្នកទីផ្សារចង់ឱ្យចំនួនអតិបរមានៃអ្នកចូលមើលគេហទំព័រត្រូវបានកំណត់អត្តសញ្ញាណសម្រាប់ការគ្របដណ្តប់កាន់តែច្រើននៃការផ្ញើសំបុត្រផ្ទាល់ខ្លួន,
• អ្នកឯកទេសសុវត្ថិភាពចង់ធានាថាមិនមានករណីនៃការចូលប្រើប្រាស់ទិន្នន័យផ្ទាល់ខ្លួនរបស់អ្នកទស្សនាដោយគ្មានការអនុញ្ញាត រួមទាំងការព្យាយាមទាយពាក្យសម្ងាត់សម្រាប់គណនីមួយ ឬស្វែងរកគណនីដែលមានពាក្យសម្ងាត់ខ្សោយ។
• អ្នកវាយប្រហារចង់ទទួលបានប្រាក់រង្វាន់ពីជនរងគ្រោះ
• ដៃគូប្រកួតប្រជែងចង់ទុកការវាយតម្លៃអវិជ្ជមានលើផលិតផល
• botnet ចង់ទទួលបានមូលដ្ឋានអតិថិជនរបស់ហាង និងប្រើការវាយប្រហារដើម្បីធ្វើឱ្យគេហទំព័រមិនអាចដំណើរការបាន។

លក្ខខណ្ឌជាមុន៖ ភ្ញៀវមិនគួរត្រូវបានអនុញ្ញាតទេ។
ការធានាអប្បបរមា៖ អ្នកទស្សនានឹងដឹងថាតើការព្យាយាមអនុញ្ញាតបានជោគជ័យឬមិនជោគជ័យ។
ការធានានៃភាពជោគជ័យ: ភ្ញៀវត្រូវបានអនុញ្ញាត។

សេណារីយ៉ូចម្បង៖

1. អតិថិជនចាប់ផ្តើមការអនុញ្ញាត។
2. ប្រព័ន្ធ​បញ្ជាក់​ថា​អតិថិជន​មិន​ត្រូវ​បាន​អនុញ្ញាត និង​មិន​លើស​ចំនួន​នៃ​ការ​ព្យាយាម​អនុញ្ញាត​ដែល​មិន​បាន​ជោគជ័យ​ពី​វគ្គ​ដែល​បាន​ផ្តល់​ឱ្យ (ការ​ស្វែង​រក​ពាក្យ​សម្ងាត់​ខ្សោយ​សម្រាប់​គណនី​ច្រើន) ដោយ​យោង​តាម "ច្បាប់​សុវត្ថិភាព​លេខ 23"។
3. ប្រព័ន្ធបង្កើនការរាប់ចំនួននៃការព្យាយាមអនុញ្ញាត។
4. ប្រព័ន្ធបង្ហាញទម្រង់ការអនុញ្ញាតដល់អតិថិជន។
5. អតិថិជនបញ្ចូលអ៊ីមែល និងពាក្យសម្ងាត់របស់គាត់។
6. ប្រព័ន្ធបញ្ជាក់វត្តមានរបស់អតិថិជនដែលមានអ៊ីមែលបែបនេះនៅក្នុងប្រព័ន្ធ ហើយថាពាក្យសម្ងាត់ត្រូវគ្នា ហើយចំនួននៃការព្យាយាមចូលគណនីនេះមិនត្រូវលើសពីនេះបើយោងតាម ​​"ច្បាប់សុវត្ថិភាពលេខ 24"។
7. ប្រព័ន្ធផ្តល់សិទ្ធិឱ្យអតិថិជន បន្ថែមប្រវត្តិរុករក និងកញ្ចប់នៃវគ្គនេះជាមួយនឹងវគ្គចុងក្រោយនៃគណនីអតិថិជននេះ។
8. ប្រព័ន្ធបង្ហាញសារជោគជ័យនៃការអនុញ្ញាត និងផ្លាស់ទីទៅជំហានស្គ្រីបដែលអតិថិជនត្រូវបានរំខានសម្រាប់ការអនុញ្ញាត។ ក្នុងករណីនេះ ទិន្នន័យនៅលើទំព័រត្រូវបានផ្ទុកឡើងវិញដោយគិតពីទិន្នន័យគណនីផ្ទាល់ខ្លួន។

ផ្នែកបន្ថែម៖
2. ក. អតិថិជនត្រូវបានអនុញ្ញាតរួចហើយ៖
 2.a.1. ប្រព័ន្ធជូនដំណឹងដល់អតិថិជនអំពីការពិតនៃការអនុញ្ញាតដែលបានអនុវត្តពីមុន និងការផ្តល់ជូនដើម្បីរំខានស្គ្រីប ឬទៅកាន់ជំហានទី 4 ហើយប្រសិនបើជំហានទី 6 ត្រូវបានបញ្ចប់ដោយជោគជ័យ នោះជំហានទី 7 ត្រូវបានអនុវត្តដោយការបញ្ជាក់៖
 2.a.7. ប្រព័ន្ធនេះ deactorize អតិថិជននៅក្រោមគណនីចាស់ ផ្តល់សិទ្ធិឱ្យអតិថិជននៅក្រោមគណនីថ្មី ខណៈពេលដែលប្រវត្តិរុករក និងរទេះនៃសម័យអន្តរកម្មនេះនៅតែមាននៅក្នុងគណនីចាស់ ហើយមិនផ្ទេរទៅគណនីថ្មី។ បន្ទាប់មកចូលទៅកាន់ជំហានទី 8 ។
2.b ចំនួននៃការព្យាយាមអនុញ្ញាតបានលើសពីកម្រិតកំណត់យោងតាម ​​"ច្បាប់សុវត្ថិភាពលេខ 23"៖
 2.b.1 ទៅកាន់ជំហានទី 4 captcha ត្រូវបានបង្ហាញបន្ថែមនៅលើទម្រង់ការអនុញ្ញាត
 2.b.6 ប្រព័ន្ធបញ្ជាក់ការបញ្ចូល captcha ត្រឹមត្រូវ។
    2.b.6.1 Captcha បញ្ចូលមិនត្រឹមត្រូវ៖
      ២.b.៦.១.១. ប្រព័ន្ធនេះបង្កើនការប្រឆាំងនៃការព្យាយាមអនុញ្ញាតដែលមិនជោគជ័យសម្រាប់គណនីនេះផងដែរ។
      ២.b.៦.១.២. ប្រព័ន្ធបង្ហាញសារបរាជ័យ ហើយត្រឡប់ទៅជំហានទី 2 វិញ។
6. ក. រកមិនឃើញគណនីដែលមានអ៊ីមែលនេះទេ៖
 6.a.1 ប្រព័ន្ធបង្ហាញសារអំពីការបរាជ័យ និងផ្តល់នូវជម្រើសនៃការចូលទៅកាន់ជំហានទី 2 ឬចូលទៅកាន់សេណារីយ៉ូ "ការចុះឈ្មោះអ្នកប្រើប្រាស់" និងរក្សាទុកអ៊ីមែលដែលបានបញ្ចូល។
៦.ខ. ពាក្យសម្ងាត់សម្រាប់គណនីដែលមានអ៊ីមែលនេះមិនត្រូវគ្នានឹងពាក្យសម្ងាត់ដែលបានបញ្ចូលទេ៖
 6.b.1 ប្រព័ន្ធបង្កើនការប្រឆាំងនៃការប៉ុនប៉ងចូលដែលមិនជោគជ័យទៅកាន់គណនីនេះ។
 6.b.2 ប្រព័ន្ធបង្ហាញសារអំពីការបរាជ័យ និងផ្តល់នូវជម្រើសនៃការចូលទៅកាន់សេណារីយ៉ូ "ការសង្គ្រោះពាក្យសម្ងាត់" ឬទៅកាន់ជំហានទី 2 ។
6.c៖ បញ្ជរការប៉ុនប៉ងចូលសម្រាប់គណនីនេះបានលើសពីកម្រិតកំណត់សម្រាប់ “ច្បាប់សុវត្ថិភាពលេខ 24”។
 6.c.1 ប្រព័ន្ធបង្ហាញសារអំពីការទប់ស្កាត់ការចូលគណនីសម្រាប់ X នាទី ហើយបន្តទៅជំហានទី 2 ។

អ្វីដែលអស្ចារ្យ

ពិនិត្យមើលភាពពេញលេញ និងការអនុលោមតាមគោលដៅ ពោលគឺអ្នកអាចផ្តល់តម្រូវការដល់អ្នកវិភាគផ្សេងទៀតសម្រាប់ការផ្ទៀងផ្ទាត់ ដោយធ្វើឱ្យមានកំហុសតិចជាងមុននៅដំណាក់កាលនៃការបង្កើតបញ្ហា។

ការធ្វើការជាមួយប្រព័ន្ធប្រអប់ខ្មៅអនុញ្ញាតឱ្យអ្នកបំបែកការអភិវឌ្ឍន៍ និងការសម្របសម្រួលជាមួយអតិថិជននូវអ្វីដែលនឹងត្រូវស្វ័យប្រវត្តិពីវិធីសាស្ត្រនៃការអនុវត្ត។

វាគឺជាផ្នែកមួយនៃផ្លូវរបស់អ្នកវិភាគ ដែលជាផ្នែកសំខាន់មួយនៃការប្រើប្រាស់។ សេណារីយ៉ូរបស់អ្នកប្រើប្រាស់កំណត់ផ្លូវសំខាន់ៗនៃចលនារបស់គាត់ ដែលកាត់បន្ថយយ៉ាងខ្លាំងនូវសេរីភាពនៃការជ្រើសរើសសម្រាប់អ្នករចនា និងអតិថិជន និងជួយបង្កើនល្បឿននៃការអភិវឌ្ឍន៍ការរចនា។

ខ្ញុំពេញចិត្តនឹងកន្លែងនៅក្នុងការពិពណ៌នាដែលករណីលើកលែងចំពោះជំហានអន្តរកម្មនីមួយៗត្រូវបានកំណត់អត្តសញ្ញាណ។ ប្រព័ន្ធ IT ពេញលេញត្រូវតែផ្តល់សម្រាប់ការដោះស្រាយករណីលើកលែងមួយចំនួន ខ្លះដោយដៃ ខ្លះដោយស្វ័យប្រវត្តិ (ដូចក្នុងឧទាហរណ៍ខាងលើ)។

បទពិសោធន៍បង្ហាញថាការដោះស្រាយករណីលើកលែងដែលមិនបានគិតទុកជាមុនអាចប្រែក្លាយប្រព័ន្ធមួយទៅជាប្រព័ន្ធដែលរអាក់រអួលបានយ៉ាងងាយស្រួល។ ខ្ញុំចាំរឿងដែលនៅសម័យសូវៀត ដើម្បីទទួលបានការសម្រេចចិត្ត អ្នកត្រូវតែទទួលបានការយល់ព្រមជាច្រើនពីសេវាកម្មផ្សេងៗគ្នា ហើយតើវាឈឺចាប់ប៉ុណ្ណានៅពេលដែលសេវាកម្មចុងក្រោយនិយាយថា - ប៉ុន្តែពាក្យសុំរបស់អ្នកមានឈ្មោះខុស ឬកំហុសផ្សេងទៀតនៅក្នុង វណ្ណយុត្តិ ធ្វើឡើងវិញអ្វីៗគ្រប់យ៉ាង និងសម្របសម្រួលអ្វីៗគ្រប់យ៉ាងឡើងវិញ។

ជារឿយៗខ្ញុំជួបប្រទះនឹងស្ថានភាពដែលតក្កវិជ្ជាប្រតិបត្តិការនៃប្រព័ន្ធដែលមិនត្រូវបានគិតសម្រាប់ករណីលើកលែងតម្រូវឱ្យធ្វើការឡើងវិញយ៉ាងសំខាន់នៃប្រព័ន្ធ។ ដោយសារតែនេះចំណែករបស់សត្វតោនៃការងាររបស់អ្នកវិភាគត្រូវបានចំណាយលើការដោះស្រាយករណីលើកលែង។

ការសម្គាល់អត្ថបទ ផ្ទុយពីដ្យាក្រាម អនុញ្ញាតឱ្យកំណត់អត្តសញ្ញាណ និងគ្របដណ្តប់ករណីលើកលែងបន្ថែមទៀត។

បន្ថែមលើវិធីសាស្រ្តពីការអនុវត្ត

ករណីប្រើប្រាស់មិនមែនជាផ្នែកអាទិភាពដោយឯករាជ្យនៃសេចក្តីថ្លែងការណ៍ មិនដូចរឿងរបស់អ្នកប្រើនោះទេ។

នៅក្នុងសេណារីយ៉ូខាងលើ សូមពិចារណាករណីលើកលែង “6.a. រកមិនឃើញគណនីដែលមានអ៊ីមែលនេះទេ។” និងជំហានបន្ទាប់ “6.a.1 ប្រព័ន្ធបង្ហាញសារបរាជ័យ ហើយបន្តទៅជំហានទី 2”។ តើ​រឿង​អវិជ្ជមាន​អ្វី​ខ្លះ​ត្រូវ​បាន​បន្សល់​ទុក? សម្រាប់អតិថិជន ការត្រឡប់មកវិញណាមួយគឺស្មើនឹងការពិតដែលថាការងារទាំងអស់ដែលគាត់បានបញ្ចូលទិន្នន័យត្រូវបានបោះចោលទៅក្នុងកន្លែងចាក់សំរាម។ (វាមិនអាចមើលឃើញនៅក្នុងស្គ្រីបទេ!) តើអាចធ្វើអ្វីបាន? បង្កើតស្គ្រីបឡើងវិញ ដើម្បីកុំឱ្យរឿងនេះកើតឡើង។ តើវាអាចទៅរួចទេក្នុងការធ្វើបែបនេះ? អ្នកអាច - ជាឧទាហរណ៍ សូមមើលស្គ្រីបការអនុញ្ញាតរបស់ Google ។

ការបង្កើនប្រសិទ្ធភាពសេណារីយ៉ូ

សៀវភៅនេះនិយាយអំពីការបង្កើតជាផ្លូវការ ប៉ុន្តែនិយាយតិចតួចអំពីវិធីសាស្រ្តសម្រាប់ការបង្កើនប្រសិទ្ធភាពនៃសេណារីយ៉ូបែបនេះ។

ប៉ុន្តែវាអាចធ្វើទៅបានដើម្បីពង្រឹងវិធីសាស្រ្តដោយការបង្កើនប្រសិទ្ធភាពសេណារីយ៉ូ ហើយវិធីសាស្ត្រប្រើប្រាស់ករណីផ្លូវការអនុញ្ញាតឱ្យវាធ្វើ។ ជាពិសេស អ្នកត្រូវគិតអំពីករណីលើកលែងនីមួយៗដែលកើតឡើង កំណត់មូលហេតុ និងបង្កើតស្គ្រីបឡើងវិញ ដើម្បីកម្ចាត់ករណីលើកលែង ឬកាត់បន្ថយការធ្វើដំណើររបស់អតិថិជន។

នៅពេលធ្វើការបញ្ជាទិញពីហាងអនឡាញ អ្នកត្រូវតែបញ្ចូលទីក្រុងដឹកជញ្ជូន។ វាអាចបង្ហាញថា ហាងមិនអាចដឹកជញ្ជូនទំនិញទៅទីក្រុងដែលអតិថិជនជ្រើសរើសទេ ដោយសារវាមិនដឹកជញ្ជូននៅទីនោះ ដោយសារតែការកម្រិតទំហំ ឬដោយសារកង្វះទំនិញនៅក្នុងឃ្លាំងដែលត្រូវគ្នា។

ប្រសិនបើយើងពណ៌នាសាមញ្ញអំពីសេណារីយ៉ូនៃអន្តរកម្មនៅដំណាក់កាលចុះឈ្មោះ យើងអាចសរសេរ "ជូនដំណឹងដល់អតិថិជនថាការដឹកជញ្ជូនគឺមិនអាចទៅរួចនោះទេ ហើយផ្តល់ជូនការផ្លាស់ប្តូរទីក្រុង ឬខ្លឹមសារនៃរទេះ" (ហើយអ្នកវិភាគថ្មីថ្មោងជាច្រើនឈប់នៅទីនោះ)។ ប៉ុន្តែប្រសិនបើមានករណីបែបនេះច្រើន នោះសេណារីយ៉ូអាចត្រូវបានធ្វើឱ្យប្រសើរ។

រឿងដំបូងដែលអ្នកត្រូវធ្វើគឺអនុញ្ញាតឱ្យអ្នកជ្រើសរើសតែទីក្រុងដែលយើងអាចដឹកជញ្ជូនបាន។ ពេលណាត្រូវធ្វើបែបនេះ? មុនពេលជ្រើសរើសផលិតផលនៅលើគេហទំព័រ (ការរកឃើញទីក្រុងដោយស្វ័យប្រវត្តិតាមរយៈ IP ជាមួយនឹងការបំភ្លឺ) ។

ទីពីរ យើងត្រូវផ្តល់ជម្រើសតែទំនិញដែលយើងអាចប្រគល់ជូនអតិថិជន។ ពេលណាត្រូវធ្វើបែបនេះ? នៅពេលជ្រើសរើស - នៅលើក្បឿងផលិតផលនិងកាតផលិតផល។

ការផ្លាស់ប្តូរទាំងពីរនេះដើរទៅឆ្ងាយឆ្ពោះទៅរកការលុបបំបាត់ការលើកលែងនេះ។

តម្រូវការសម្រាប់ការវាស់វែងនិងម៉ែត្រ

នៅពេលពិចារណាលើភារកិច្ចកាត់បន្ថយការដោះស្រាយករណីលើកលែង អ្នកអាចកំណត់កិច្ចការរាយការណ៍ (ករណីប្រើប្រាស់មិនត្រូវបានពិពណ៌នា)។ តើមានករណីលើកលែងចំនួនប៉ុន្មាន នៅក្នុងករណីណាដែលបានកើតឡើង បូកនឹងចំនួនសេណារីយ៉ូដែលចូលមកបានឆ្លងកាត់ដោយជោគជ័យ។

ប៉ុន្តែអាឡា។ បទពិសោធន៍បានបង្ហាញថាតម្រូវការរាយការណ៍សម្រាប់សេណារីយ៉ូក្នុងទម្រង់នេះគឺមិនគ្រប់គ្រាន់ទេ វាចាំបាច់ក្នុងការពិចារណាលើតម្រូវការរាយការណ៍សម្រាប់ដំណើរការដែលត្រូវបានពិពណ៌នាជាចម្បងមិនមែនក្នុងទម្រង់នៃករណីប្រើប្រាស់នោះទេ។

ការចូលទៅកាន់លទ្ធភាពប្រើប្រាស់

នៅក្នុងការអនុវត្តរបស់យើង យើងបានពង្រីកទម្រង់ការពិពណ៌នាករណីប្រើប្រាស់ជាមួយនឹងការពិពណ៌នាអំពីលក្ខណៈជាក់លាក់នៃអង្គភាព និងទិន្នន័យសម្រាប់អតិថិជនដើម្បីធ្វើការសម្រេចចិត្ត ដែលបង្កើនលទ្ធភាពប្រើប្រាស់ជាបន្តបន្ទាប់។

សម្រាប់ការរចនាលទ្ធភាពប្រើប្រាស់ យើងបានបន្ថែមផ្នែកបញ្ចូល - បង្ហាញទិន្នន័យ។

នៅក្នុងសេណារីយ៉ូដែលមានការអនុញ្ញាតនេះគឺជាការពិតដែលថាអតិថិជនត្រូវបានអនុញ្ញាតនៅក្នុងប្រព័ន្ធ។ ប្រសិនបើអតិថិជនត្រូវបានអនុញ្ញាតជាមុន បន្ទាប់មកបង្ហាញការព្រមានអំពីការប្តូរប្រវត្តិរុករក និងរទេះទៅគណនីថ្មីបន្ទាប់ពីការអនុញ្ញាតដោយជោគជ័យ។

ជាទូទៅ នេះគឺជាការបង្ហាញព័ត៌មានចាំបាច់សម្រាប់អតិថិជន ដូច្នេះគាត់អាចធ្វើការសម្រេចចិត្តអំពីសកម្មភាពបន្ថែមទៀតរបស់គាត់តាមសេណារីយ៉ូ (អ្នកអាចសួរថាតើទិន្នន័យនេះគឺគ្រប់គ្រាន់សម្រាប់អតិថិជន តើត្រូវការអ្វីទៀត តើព័ត៌មានអ្វី អតិថិជនត្រូវធ្វើការសម្រេចចិត្ត) ។  
វាក៏មានតម្លៃផងដែរក្នុងការបែងចែកព័ត៌មានដែលបានបញ្ចូលទៅក្នុងវាលបញ្ចូល ប្រសិនបើពួកគេត្រូវបានដំណើរការដោយឡែកពីគ្នា និងជាមួយនឹងការបង្កើតករណីលើកលែងផ្សេងៗគ្នា។

នៅក្នុងឧទាហរណ៍ជាមួយការអនុញ្ញាតរបស់អតិថិជន ប្រសិនបើអ្នកបំបែកព័ត៌មានដែលបានបញ្ចូលទៅជាការចូល និងពាក្យសម្ងាត់ នោះវាមានតម្លៃផ្លាស់ប្តូរស្គ្រីបការអនុញ្ញាតដើម្បីបញ្ជាក់ពីដំណាក់កាលនៃការបញ្ចូលការចូលដាច់ដោយឡែក និងពាក្យសម្ងាត់ដាច់ដោយឡែក (ហើយនេះត្រូវបានធ្វើនៅក្នុង Yandex, Google ប៉ុន្តែ មិនបានធ្វើនៅក្នុងហាងអនឡាញភាគច្រើនទេ)។

ឈានដល់ការបំប្លែងទិន្នន័យដែលត្រូវការ

អ្នកក៏អាចទាញយកតម្រូវការសម្រាប់ក្បួនដោះស្រាយការបម្លែងទិន្នន័យពីស្គ្រីបផងដែរ។

ឧទហរណ៍:

• ដើម្បីសម្រេចចិត្តទិញផលិតផលនៅក្នុងហាងអនឡាញ អតិថិជនត្រូវដឹងពីលទ្ធភាព ថ្លៃដើម ពេលវេលាដឹកជញ្ជូនទៅកាន់ទីក្រុងរបស់គាត់នៃផលិតផលនេះនៅលើកាតផលិតផល (ដែលត្រូវបានគណនាដោយក្បួនដោះស្រាយដោយផ្អែកលើភាពអាចរកបាននៃផលិតផលនៅក្នុង ឃ្លាំង និងប៉ារ៉ាម៉ែត្រខ្សែសង្វាក់ផ្គត់ផ្គង់) ។
• នៅពេលបញ្ចូលឃ្លាមួយទៅក្នុងបន្ទាត់ស្វែងរក អតិថិជនត្រូវបានបង្ហាញការផ្ដល់យោបល់ស្វែងរកដោយយោងតាមក្បួនដោះស្រាយ (ដែលបង្កើតដោយក្បួនដោះស្រាយ...)។

សរុប

ជាទូទៅបន្ទាប់ពីអានសៀវភៅនេះជាអកុសល វាមិនច្បាស់ពីរបៀបធ្វើដំណើរពីអ្នកវិភាគទៅកាន់បញ្ហាអាជីវកម្ម ទៅជាលក្ខណៈបច្ចេកទេសផ្លូវការសម្រាប់អ្នកអភិវឌ្ឍន៍នោះទេ។ សៀវភៅប្រាប់តែផ្នែកនៃដំណើរការប៉ុណ្ណោះ ដោយជំហានបញ្ចូលមិនច្បាស់លាស់ និងជំហានបន្ទាប់មិនច្បាស់លាស់។ ករណីប្រើប្រាស់ខ្លួនវាភាគច្រើនមិនមែនជាសេចក្តីថ្លែងការណ៍ពេញលេញសម្រាប់អ្នកអភិវឌ្ឍន៍នោះទេ។

ទោះជាយ៉ាងណាក៏ដោយ នេះគឺជាវិធីដ៏ល្អមួយក្នុងការរៀបចំ និងដំណើរការសេណារីយ៉ូនៃអន្តរកម្មរវាងវត្ថុ និងប្រធានបទ នៅពេលដែលអន្តរកម្មបណ្តាលឱ្យមានការផ្លាស់ប្តូរអ្វីមួយនៅក្នុងប្រធានបទ។ វាគឺជាវិធីសាស្រ្តមួយក្នុងចំណោមវិធីសាស្ត្រសរសេរមួយចំនួនដែលអនុញ្ញាតឱ្យមានតម្រូវការដែលអាចផ្ទៀងផ្ទាត់បានជាមួយនឹងចំណុចស្វែងរកករណីលើកលែងច្បាស់លាស់។

សៀវភៅ​នេះ​គឺ​ជា​សៀវភៅ​ដែល​ត្រូវ​អាន​សម្រាប់​អ្នក​វិភាគ​ដើម្បី​ចាប់​ផ្ដើម​សរសេរ​រឿង​ដែល​អាច​សាកល្បង​បាន។

ប្រភព: www.habr.com