🛎️ 📙 🎞️ उंगली सॉफ्टवेयर आवश्यकताओं 🙇🏿 👩‍✈️ 🚦

विकासशील आवश्यकताओं की मूल बातें के बारे में एक पोस्ट - जटिल आरेख, नियम और तालिकाओं के बिना, लेकिन जीआईएफ के साथ।

संक्षेप में, विकासशील आवश्यकताओं में मुख्य चरण हैं:

हमें कुछ करना क्यों है? (अधिक सोना चाहिए)
हम क्या करें? (सब कुछ लोगों की तरह है, लेकिन सस्ता है)
हम इसे कैसे करते हैं? (ब्लॉकचेन और डेट्रिएंटिस्ट के साथ, निश्चित रूप से)
हम ऐसा कब करेंगे? (कल, और रिफ्लेक्टर "बाद में")

और अब और अधिक विस्तार से।

यदि आपने कभी कुछ करने के लिए कहा है, तो इसका मतलब है कि आपने आवश्यकताओं को बनाया है। वे एक मौखिक इच्छा, पत्र, तकनीकी कार्य, कार्य या कुछ और के रूप में हो सकते हैं।
इसलिए आवश्यकताएं हर जगह हैं।

यदि, अनुरोध को पूरा करने के बाद, कुछ गलत हो गया - यह या तो कलाकार को गड़बड़ कर देता है,
या आप कार्य को गलत तरीके से सेट करते हैं।

जैसा कि आप जानते हैं, गलत कार्य काफी महंगा हो सकता है। उदाहरण के लिए, अगर आधे साल के लिए 5 प्रोग्रामर की टीम ने एक ऐसी प्रणाली विकसित की जिसकी किसी को जरूरत नहीं है।

इस अशांत उम्र में, चंचल डिजाइन आवश्यकताओं को अक्सर उपेक्षित किया जाता है। लेकिन लचीली कार्यप्रणाली आपको हमेशा बड़े नुकसान से नहीं बचाती है। इसलिए, यहां तक कि अगर आपके पास परियोजना पर एक विश्लेषक नहीं है, भले ही आप बिल्कुल भी आईटी नहीं हैं, तो सामान्य ज्ञान के बारे में मत भूलो और इस समय सर्वोत्तम प्रथाओं से ले लो जो आपको चाहिए।

तो क्या आवश्यकताएं हैं और उन्हें विकसित करने में सक्षम होना क्यों महत्वपूर्ण है?

तो, चलो स्रोतों की ओर मुड़ें:

अर्थात, आप भविष्य के गुणों के बारे में आवश्यकताओं के बारे में बात कर सकते हैं। कैसे एक उत्पाद है जो विकास के लक्ष्यों को पूरा करता है

विकासशील आवश्यकताओं को कहाँ से शुरू करें? एक संकेत परिभाषा में छिपा हुआ है: आपको लक्ष्य से शुरू करने की आवश्यकता है - हमें कुछ भी करने की आवश्यकता क्यों है।

1. क्यों?

जैसे "ASAP !!!!" कुछ करने की आवश्यकता नहीं थी - यह आवश्यक है कि यह पता लगाने के लिए समय और ऊर्जा का पता लगाना महत्वपूर्ण है।

क्योंकि अक्सर, लक्ष्य को स्पष्ट करने के बाद, कार्य बदल जाता है या पूरी तरह से समाप्त हो जाता है।

उदाहरण के लिए,

ग्राहक उसे तुरंत उन सभी आदेशों को दिखाएगा जो सिस्टम में किए गए थे। मान लें कि हमने व्यवस्थापक के सभी आदेशों को प्रदर्शित करने के लिए स्प्रिंट के बीच में टास्क किया और टास्क दिया। उसके बाद, ग्राहक एक अलग विंडो में उन सभी कंपनियों की एक सूची प्रदर्शित करने के लिए कहता है जिनके आदेश वह देखता है। उन्होंने ऐसा किया भी। फिर ग्राहक सभी साझेदार कंपनियों के अलावा वापस लेने के लिए कहता है। ठीक है ... कुछ समय बाद, हम ग्राहक से मिलते हैं और देखते हैं कि वह एक्सेल में दोनों सूचियों को कैसे अपलोड करता है, अंतर को पहचानता है और उन कंपनियों को फोन करना शुरू करता है जिनके पास हमारे सिस्टम के माध्यम से ऑर्डर देने के लिए उन्हें याद दिलाने के लिए ऑर्डर नहीं हैं।

अगर हमने शुरू से ही ग्राहक से पूछा कि वह सभी आदेशों को देखकर क्या लक्ष्य हासिल करना चाहता है, तो हम तुरंत उन कंपनियों को रिपोर्ट करके बहुत समय और प्रयास बचाएंगे जो अब तक ऑर्डर नहीं देते थे।

आप "पांच क्यों" विधि या किसी अन्य का उपयोग कर सकते हैं। लेकिन आमतौर पर लोग विरोध नहीं करते हैं: यदि आप उनके काम में रुचि दिखाते हैं, तो एक समाधान उपलब्ध हो जाता है।

एक लक्ष्य पर निर्णय लेने के बाद, इसे स्पष्ट रूप से परिभाषित करना और मानदंड स्थापित करना आवश्यक है जिसके द्वारा आप सटीक रूप से कह सकते हैं कि लक्ष्य प्राप्त किया गया है।

उदाहरण के लिए,

ऑर्डरिंग सामग्रियों की प्रक्रिया को स्वचालित माना जाता है अगर> 90% भागीदार कंपनियां सिस्टम के माध्यम से ऑर्डर देती हैं।

इससे कार्यों को समझने में आसानी होती है और साथ ही लक्ष्य प्राप्त करने के साधनों को चुनने में हाथों को मुक्त करता है।

और हां, इस सुंदरता को ग्राहकों के साथ समन्वित करना मत भूलना। सामान्य तौर पर, सभी इच्छुक पार्टियों के साथ आवश्यकताओं का समन्वय करना न भूलें।

2. क्या?

लक्ष्य अलग-अलग तरीकों से हासिल किया जाता है। और विकासशील आवश्यकताओं में दूसरा महत्वपूर्ण कदम सिर्फ रास्ता चुनना है - लक्ष्य तक पहुंचने के लिए हम वास्तव में क्या करेंगे।

, :

. . . // .

. — , .

. . .

सभी विकल्पों पर विचार करने के लिए, आपको यह पता लगाने की आवश्यकता है - अब क्या हो रहा है? आपके सिस्टम के बिना प्रक्रिया कैसे काम करती है, उपयोगकर्ता और ग्राहक कैसे काम करते हैं? भले ही अभी तक कोई प्रक्रिया नहीं है, लेकिन वर्तमान स्थिति के बारे में विस्तृत जानकारी बहुत महत्वपूर्ण है। तो हम समझेंगे कि कौन सा समाधान समस्या को ठीक करेगा, और दूसरा नहीं बनाएगा।

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

3. कैसे?

इसलिए, हमने अपने लक्ष्य को समझा और इसे हासिल करने के लिए हम क्या करेंगे। यह पता लगाना बाकी है कि हम इसे कैसे लागू कर रहे हैं: हम उपयोगकर्ताओं को कौन से पेज दिखाएंगे, किस रूप में हम ग्राहक के लिए रिपोर्ट प्रदर्शित करेंगे, कैसे हम किसी अन्य सिस्टम से डेटा प्राप्त करेंगे, हम उन्हें कैसे स्टोर करेंगे आदि।

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

उदाहरण के लिए

प्रश्नावली में एक तस्वीर के साथ एक फ़ाइल होनी चाहिए, क्योंकि दस्तावेजों को संसाधित करते समय एक फोटो आवश्यक है - यह एक व्यावसायिक आवश्यकता है । और शायद एक व्यापार नियम।
- , — . , .
, — , . , .
base64 . — .
, . : 10.

प्रत्येक व्यावसायिक आवश्यकता के लिए, एक नियम के रूप में, कई उपयोगकर्ता आवश्यकताएं हैं। एक उपयोगकर्ता की आवश्यकता कई कार्यात्मक लोगों में विघटित होती है। प्रत्येक कार्यात्मक आवश्यकता के लिए, गैर-कार्यात्मक आवश्यकताओं और सीमाओं पर विचार किया जाना चाहिए।

इसके अलावा, गैर-कार्यात्मक आवश्यकताएं और प्रतिबंध उपयोगकर्ता की आवश्यकताओं और व्यावसायिक आवश्यकताओं और नियमों दोनों से सीधे प्रवाह कर सकते हैं।
इस तरह, पेड़ों को आवश्यकताओं से प्राप्त किया जाता है, जिनमें से प्रत्येक व्यवसाय की आवश्यकता के शीर्ष पर है।

4. कब?

आपकी आवश्यकताओं के "जंगल" में, कोई भी परस्पर अनन्य और किसी भी दोहराए जाने की संभावना है। इसलिए, यह सभी सौंदर्य को तालिकाओं और आरेखों के रूप में दस्तावेज़ करने और प्रस्तुत करने के लिए उपयोगी है।

यहां कई उपकरण हैं: उदाहरण के लिए, व्यावसायिक प्रक्रियाओं और यूएमएल को सेवाओं और घटकों के बीच बातचीत की योजना बनाने के लिए बीपीएमएन।

यदि आप सभी को यह समझाने का प्रबंधन करते हैं कि आप नैपकिन और कॉफी के 3 स्पॉट का उपयोग करके सिस्टम के साथ क्या और कैसे करना चाहते हैं, तो आप एनालिटिक्स से जॉन विक हैं और यह आश्चर्यजनक है।

हालांकि, एक नियम के रूप में, विस्तार का "स्पॉट" स्तर आपको नुकसान को देखने और सभी संभावित परिदृश्यों के माध्यम से सोचने की अनुमति नहीं देता है। आखिरकार, सब कुछ स्पष्ट प्रतीत होता है, लेकिन मैंने थोड़ा आरेख खींचा - और यहां आपके पास एक अंतहीन चुनौती है, और एक भूली हुई प्रक्रिया शाखा है, और सोने का सबसे छोटा रास्ता है।
इसलिए, यह जानना उपयोगी है कि रिवर्स अराजकता के लिए कौन से उपकरण उपलब्ध हैं।

योजनाबद्ध और संरचित रूप में, आवश्यकताओं को प्राथमिकता देने की आवश्यकता है - उपयोगिता के आधार पर (ग्राहक और उपयोगकर्ता आपको यह बताएंगे) और जटिलता (विकास टीम आपको यह बताएगी)।

और फिर आप पहले से ही विकास और कार्यान्वयन के क्षेत्रों / चरणों में बिखेर सकते हैं। खैर, प्रत्येक पुनरावृत्ति के भीतर इन अभ्यासों को दोहराएं। और आप खुश होंगे - कोई परिवर्तन नहीं, एक संतुष्ट ग्राहक, एक खुश टीम, एक उत्पाद जो काम करता है और लाभ करता है, कल्पित बौने एक इंद्रधनुष पृष्ठभूमि पर वीणा बजाते हैं।

बेशक, हमेशा समस्याएं होंगी। इसमें बदलाव, जले हुए डेडलाइन और बग होंगे। हमेशा सभी चरणों से गुजरना और सामान्य विश्लेषिकी करना, सहमत होना या यहां तक कि ग्राहक के साथ बात करना, दस्तावेज़ और आवश्यकताओं का पता लगाना संभव नहीं होगा। लेकिन किसी भी स्थिति में, "यह कैसे होना चाहिए" को समझने से उत्पाद को बेहतर बनाने में मदद मिलती है। यहां तक कि अगर आप इस समय कर रहे हैं "यह कैसे पता चला" - आप जानते हैं कि आप याद कर रहे हैं और आप जोखिम जानते हैं। और यदि आप जोखिम जानते हैं, तो आप उन्हें प्रबंधित कर सकते हैं।

मैं Wigers और Beatty की पुस्तक में आवश्यकताओं के बारे में अधिक पढ़ने की सलाह देता हूं: "सॉफ्टवेयर आवश्यकताओं का विकास"। हालांकि पुस्तक हमेशा सरल नहीं होती है, लेकिन बहुत उपयोगी होती है। विषय पर अधिकांश अन्य सामग्री स्वतंत्रता की अलग-अलग डिग्री के साथ इन सच्चाइयों की वापसी है।

आपका ध्यान और अच्छे डिजाइन के लिए धन्यवाद।

उंगली सॉफ्टवेयर आवश्यकताओं

1. क्यों?

2. क्या?

3. कैसे?

4. कब?

More articles: