प्रणालीहरूको लागि कार्यात्मक आवश्यकताहरू वर्णन गर्नका लागि आधुनिक विधिहरू। एलिस्टेयर कोबर्न। पुस्तक र थपको समीक्षा

पुस्तकले समस्या कथनको अंश लेख्नको लागि एउटा विधि वर्णन गर्दछ, अर्थात् प्रयोग केस विधि।

यो के हो? यो प्रणाली (वा व्यापार संग) संग प्रयोगकर्ता अन्तरक्रिया परिदृश्य को एक विवरण हो। यस अवस्थामा, प्रणालीले ब्ल्याक बक्सको रूपमा कार्य गर्दछ (र यसले जटिल डिजाइन कार्यलाई अन्तरक्रिया डिजाइन गर्न र यो अन्तरक्रिया सुनिश्चित गर्नमा विभाजन गर्न सम्भव बनाउँछ)। एकै समयमा, नोटेशन मापदण्डहरू प्रस्तुत गरिएका छन्, जसले गैर-सहभागीहरू सहित पढ्नको सहजता सुनिश्चित गर्दछ, र सरोकारवालाको लक्ष्यहरूसँग पूर्णता र अनुपालनको लागि केही जाँचहरूको लागि अनुमति दिन्छ।

केस उदाहरण प्रयोग गर्नुहोस्

इमेल मार्फत साइटमा प्राधिकरणको उदाहरण प्रयोग गरेर परिदृश्य कस्तो देखिन्छ:

(प्रणाली) आफ्नो व्यक्तिगत खाता पहुँच गर्न वेबसाइटमा लग इन गर्नुहोस्। ~~ (समुद्री सतह)

सन्दर्भ: एक अनाधिकृत क्लाइन्टले साइटमा लग इन गर्दछ ताकि साइटले उसलाई चिन्छ र उसको लागि व्यक्तिगत जानकारी देखाउँछ: ब्राउजिङ इतिहास, खरिद इतिहास, हालको बोनस अंकको संख्या, इमेल लगइनको रूपमा प्रयोग गरी। 
स्तर: प्रयोगकर्ता लक्ष्य
मुख्य पात्र: ग्राहक (हाम्रो अनलाइन स्टोर को आगन्तुक)
दायरा: अनलाइन स्टोर वेबसाइट संग ग्राहक अन्तरक्रिया
सरोकारवाला र चासोहरू:

• मार्केटर व्यक्तिगत मेलिङको ठूलो कभरेजको लागि साइट आगन्तुकहरूको अधिकतम संख्या पहिचान गर्न चाहन्छ,
• सुरक्षा विशेषज्ञले एक खाताको पासवर्ड अनुमान गर्ने प्रयास वा कमजोर पासवर्ड भएको खाता खोजी सहित आगन्तुकको व्यक्तिगत डेटामा अनाधिकृत पहुँचको कुनै केसहरू छैनन् भनी सुनिश्चित गर्न चाहन्छ,
• आक्रमणकारीले पीडितको बोनसमा पहुँच प्राप्त गर्न चाहन्छ,
• प्रतिस्पर्धीहरू उत्पादनहरूमा नकारात्मक समीक्षा छोड्न चाहन्छन्,
• बोटनेटले स्टोरको ग्राहक आधार प्राप्त गर्न चाहन्छ र साइटलाई निष्क्रिय बनाउनको लागि आक्रमण प्रयोग गर्दछ।

पूर्वसर्तहरू: आगन्तुक अधिकृत हुनु हुँदैन।
न्यूनतम ग्यारेन्टीहरू: आगन्तुकले थाहा पाउनेछ कि प्राधिकरण प्रयास सफल वा असफल थियो।
सफलताको ग्यारेन्टीहरू: आगन्तुक अधिकृत छ।

मुख्य परिदृश्य:

1. ग्राहकले प्राधिकरण प्रारम्भ गर्दछ।
2. प्रणालीले पुष्टि गर्छ कि क्लाइन्ट अधिकृत छैन र "सुरक्षा नियम नम्बर 23" अनुसार दिइएको सत्र (बहु खाताहरूको लागि कमजोर पासवर्ड खोज्दै) बाट असफल प्राधिकरण प्रयासहरूको संख्या भन्दा बढी छैन।
3. प्रणालीले प्राधिकरण प्रयासहरूको संख्याको लागि काउन्टर बढाउँछ।
4. प्रणालीले ग्राहकलाई प्राधिकरण फारम देखाउँछ।
5. ग्राहकले आफ्नो इमेल र पासवर्ड प्रविष्ट गर्दछ।
6. प्रणालीले प्रणालीमा यस्तो इमेल भएको ग्राहकको उपस्थिति पुष्टि गर्दछ र पासवर्ड मेल खान्छ र यस खातामा लगइन प्रयासहरूको संख्या "सुरक्षा नियम नम्बर 24" अनुसार नाघिँदैन।
7. प्रणालीले ग्राहकलाई अधिकार दिन्छ, ब्राउजिङ इतिहास र यस ग्राहक खाताको अन्तिम सत्रको साथ यो सत्रको टोकरी थप्छ।
8. प्रणालीले प्राधिकरण सफलता सन्देश देखाउँछ र स्क्रिप्ट चरणमा जान्छ जहाँबाट ग्राहकलाई प्राधिकरणको लागि अवरोध गरिएको थियो। यस अवस्थामा, पृष्ठमा डेटा व्यक्तिगत खाता डेटालाई ध्यानमा राखेर पुन: लोड गरिएको छ।

विस्तारहरू:
2.a ग्राहक पहिले नै अधिकृत छ:
 2.a.1. प्रणालीले क्लाइन्टलाई पहिले प्रदर्शन गरिएको प्राधिकरणको तथ्यको बारेमा सूचित गर्दछ र स्क्रिप्टमा अवरोध गर्न वा चरण 4 मा जाने प्रस्ताव गर्दछ, र यदि चरण 6 सफलतापूर्वक पूरा भयो भने, त्यसपछि चरण 7 स्पष्टीकरणको साथ प्रदर्शन गरिन्छ:
 2.a.7. प्रणालीले पुरानो खाता अन्तर्गत ग्राहकलाई डिएक्टोराइज गर्छ, नयाँ खाता अन्तर्गत ग्राहकलाई अधिकार दिन्छ, जबकि ब्राउजिङ इतिहास र यस अन्तरक्रिया सत्रको कार्ट पुरानो खातामा रहन्छ र नयाँ खातामा स्थानान्तरण गर्दैन। अर्को, चरण 8 मा जानुहोस्।
2.b "सुरक्षा नियम नम्बर 23" अनुसार प्राधिकरण प्रयासहरूको संख्या थ्रेसहोल्ड नाघेको छ:
 2.b.1 चरण 4 मा जानुहोस्, प्राधिकरण फारममा क्याप्चा थप रूपमा प्रदर्शित हुन्छ
 2.b.6 प्रणालीले सही क्याप्चा प्रविष्टि पुष्टि गर्दछ
    2.b.6.1 क्याप्चा गलत रूपमा प्रविष्ट गरियो:
      2.b.6.1.1. प्रणालीले यस खाताको लागि असफल प्राधिकरण प्रयासहरूको काउन्टर पनि बढाउँछ
      2.b.6.1.2। प्रणालीले विफलता सन्देश देखाउँछ र चरण 2 मा फर्काउँछ
६.a यो इमेल भएको कुनै खाता फेला परेन:
 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 प्राधिकरण स्क्रिप्ट हेर्नुहोस्।

परिदृश्य अनुकूलन

पुस्तक औपचारिकीकरणको बारेमा कुरा गर्छ, तर त्यस्ता परिदृश्यहरूलाई अनुकूलन गर्ने तरिकाहरूको बारेमा थोरै भन्छ।

तर परिदृश्यहरू अनुकूलन गरेर विधिलाई बलियो बनाउन सम्भव छ, र प्रयोग केस औपचारिकीकरण विधिले यो गर्न अनुमति दिन्छ। विशेष रूपमा, तपाईंले प्रत्येक अपवादको बारेमा सोच्न आवश्यक छ जुन हुन्छ, कारण निर्धारण गर्नुहोस्, र स्क्रिप्टलाई पुन: निर्माण गर्नुहोस् ताकि अपवादबाट छुटकारा पाउन वा ग्राहकको यात्रालाई कम गर्नुहोस्।

अनलाइन स्टोरबाट अर्डर गर्दा, तपाईंले डेलिभरी शहर प्रविष्ट गर्नुपर्छ। यो बाहिर आउन सक्छ कि स्टोरले ग्राहक द्वारा छनोट गरिएको शहरमा सामानहरू डेलिभर गर्न सक्दैन किनभने यसले त्यहाँ डेलिभर गर्दैन, साइज प्रतिबन्धको कारण, वा सम्बन्धित गोदाममा सामानहरूको अभावको कारण।

यदि हामीले दर्ता चरणमा अन्तर्क्रियाको परिदृश्यलाई मात्र वर्णन गर्छौं भने, हामी "ग्राहकलाई सूचित गर्न सक्छौं कि डेलिभरी असम्भव छ र शहर वा कार्टको सामग्री परिवर्तन गर्न प्रस्ताव गर्नुहोस्" (र धेरै नौसिखिया विश्लेषकहरू त्यहाँ रोकिन्छन्)। तर यदि त्यहाँ यस्ता धेरै केसहरू छन् भने, परिदृश्य अनुकूलित गर्न सकिन्छ।

तपाईले गर्नु पर्ने पहिलो कुरा तपाईलाई हामीले डेलिभर गर्न सक्ने शहर मात्र छनोट गर्न दिनुपर्छ। यो कहिले गर्ने? वेबसाइटमा उत्पादन चयन गर्नु अघि (स्पष्टीकरणको साथ आईपी मार्फत शहरको स्वत: पत्ता लगाउने)।

दोस्रो, हामीले ग्राहकलाई डेलिभर गर्न सक्ने सामानहरू मात्र छनौट गर्न आवश्यक छ। यो कहिले गर्ने? चयन को क्षण मा - उत्पादन टाइल र उत्पादन कार्ड मा।

यी दुई परिवर्तनहरूले यस अपवादलाई हटाउनको लागि लामो बाटो जान्छन्।

मापन र मेट्रिक्स को लागी आवश्यकताहरु

अपवाद ह्यान्डलिङलाई कम गर्ने कार्यलाई विचार गर्दा, तपाईंले रिपोर्टिङ कार्य सेट गर्न सक्नुहुन्छ (प्रयोग केस वर्णन गरिएको छैन)। त्यहाँ कति अपवादहरू थिए, कुन अवस्थामा तिनीहरू भए, साथै कति आगमन परिदृश्यहरू सफलतापूर्वक पारित भयो।

तर अफसोस। अनुभवले देखाएको छ कि यस फारममा परिदृश्यहरूको लागि रिपोर्टिङ आवश्यकताहरू पर्याप्त छैनन्; यो प्रक्रियाहरूको लागि रिपोर्टिङ आवश्यकताहरू विचार गर्न आवश्यक छ जुन मुख्य रूपमा प्रयोग केसको रूपमा वर्णन गरिएको छैन।

उपयोगितामा पहुँच

हाम्रो अभ्यासमा, हामीले ग्राहकलाई निर्णय गर्नका लागि निकायका विशिष्ट विशेषताहरू र डेटाको विवरणसहित प्रयोग केस विवरण फारम विस्तार गरेका छौं, जसले पछिको उपयोगितालाई बढाउँछ।

उपयोगिता डिजाइनको लागि, हामीले इनपुट खण्ड - प्रदर्शन डेटा थप्यौं।

प्राधिकरणको साथ परिदृश्यमा, यो तथ्य हो कि ग्राहक प्रणालीमा अधिकृत छ। यदि ग्राहक पूर्व-अधिकृत छ भने, सफल प्रमाणीकरण पछि नेभिगेसन इतिहास र कार्टलाई नयाँ खातामा स्विच गर्ने बारे चेतावनी प्रदर्शन गर्नुहोस्।

सामान्यतया, यो ग्राहकको लागि आवश्यक जानकारीको प्रदर्शन हो ताकि उसले परिदृश्य अनुसार आफ्नो थप कार्यहरूको बारेमा निर्णय गर्न सक्छ (तपाईले सोध्न सक्नुहुन्छ कि यो डाटा ग्राहकको लागि पर्याप्त छ, अरू के आवश्यक छ, के जानकारी गर्दछ। ग्राहकले निर्णय गर्न आवश्यक छ)।  
प्रविष्ट गरिएको जानकारीलाई इनपुट क्षेत्रहरूमा विभाजन गर्न पनि लायक छ यदि तिनीहरू अलग-अलग र विभिन्न अपवादहरूको गठनको साथ प्रशोधन गरिएका छन्।

ग्राहक प्राधिकरणको साथ उदाहरणमा, यदि तपाइँ लगइन र पासवर्डमा प्रविष्ट गरिएको जानकारी अलग गर्नुहुन्छ भने, त्यसपछि यो एक अलग लगइन र छुट्टै पासवर्ड प्रविष्ट गर्ने चरणहरू हाइलाइट गर्न प्राधिकरण लिपि परिवर्तन गर्न लायक छ (र यो Yandex, Google मा गरिन्छ, तर। धेरै अनलाइन स्टोरहरूमा गरिएको छैन)।

आवश्यक डेटा रूपान्तरणहरू पुग्न

तपाईं स्क्रिप्टबाट डाटा रूपान्तरण एल्गोरिदमका लागि आवश्यकताहरू पनि निकाल्न सक्नुहुन्छ।

उदाहरण:

• अनलाइन स्टोरमा उत्पादन खरिद गर्ने निर्णय गर्न, ग्राहकले उत्पादन कार्डमा यो उत्पादनको आफ्नो शहरमा हुने सम्भावना, लागत, डेलिभरी समय जान्न आवश्यक छ (जुन उत्पादनको उपलब्धतामा आधारित एल्गोरिदमद्वारा गणना गरिन्छ। गोदाम र आपूर्ति श्रृंखला मापदण्डहरू)।
• खोज रेखामा वाक्यांश प्रविष्ट गर्दा, ग्राहकलाई एल्गोरिथ्म (जुन एल्गोरिदम द्वारा उत्पन्न गरिएको हो...) अनुसार खोज सुझावहरू देखाइन्छ।

कुल

सामान्यतया, पुस्तक पढिसकेपछि, दुर्भाग्यवश, यो स्पष्ट छैन कि कसरी एक विश्लेषकबाट व्यावसायिक समस्याहरू एक विकासकर्ताको लागि औपचारिक प्राविधिक विशिष्टता सम्म सबै तरिकामा जान सकिन्छ। पुस्तकले प्रक्रियाको अंश मात्र बताउँछ, इनपुट चरणहरू अस्पष्ट र अर्को चरणहरू अस्पष्ट। प्रयोग केस आफैं प्रायः विकासकर्ताको लागि पूर्ण कथन होइन।

जे होस्, यो एक वस्तु र एक विषय बीच अन्तरक्रिया को परिदृश्य को औपचारिक र प्रक्रिया को एक धेरै राम्रो तरिका हो, जब अन्तरक्रिया को विषय मा केहि परिवर्तन को कारण हो। यो केहि लेखन विधिहरू मध्ये एक हो जसले स्पष्ट अपवाद खोज बिन्दुहरूको साथ प्रमाणित आवश्यकताहरूलाई अनुमति दिन्छ।

परीक्षण योग्य नाटकहरू लेख्न सुरु गर्न विश्लेषकहरूका लागि पुस्तक पढ्नै पर्छ।

स्रोत: www.habr.com