GOST 19 201 78 उदाहरण तकनीकी विनिर्देश। सूचना संरचनाओं और समाधान विधियों के लिए आवश्यकताएँ

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

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

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

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

तकनीकी विशिष्टताएँ लिखने के लिए मार्गदर्शक मानक GOST 34.602.89 "एक स्वचालित प्रणाली के निर्माण के लिए तकनीकी विशिष्टताएँ" और GOST 19.201-78 "तकनीकी विशिष्टताएँ" हैं। सामग्री और डिज़ाइन के लिए आवश्यकताएँ।" पहला मानक स्वचालित सिस्टम के डेवलपर्स के लिए है, दूसरा सॉफ्टवेयर के लिए (हमने "GOST क्या है" लेख में इन श्रृंखलाओं के बीच अंतर पर चर्चा की है)।

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

GOST 19.201-78 तकनीकी विशिष्टताएँ। सामग्री और डिज़ाइन के लिए आवश्यकताएँ	GOST 34.602.89 निर्माण के लिए तकनीकी विनिर्देश स्वचालित प्रणाली
1 परिचय	1. सामान्य जानकारी
2. विकास के कारण
3. विकास का उद्देश्य	2. सिस्टम बनाने का उद्देश्य और लक्ष्य
	3. स्वचालन वस्तु के लक्षण
4. किसी प्रोग्राम या सॉफ़्टवेयर उत्पाद के लिए आवश्यकताएँ	4. सिस्टम आवश्यकताएँ
4.1. के लिए आवश्यकताएँ कार्यात्मक विशेषताएँ	4.2. सिस्टम द्वारा निष्पादित कार्यों (कार्यों) के लिए आवश्यकताएँ
	4.1. समग्र रूप से सिस्टम के लिए आवश्यकताएँ
	4.1.1. सिस्टम की संरचना और कार्यप्रणाली के लिए आवश्यकताएँ
	4.1.3. गंतव्य संकेतक
4.2. विश्वसनीयता आवश्यकताएँ	4.1.4. विश्वसनीयता आवश्यकताएँ
	4. 1.5. सुरक्षा आवश्यकताएँ
	4. 1.6. एर्गोनॉमिक्स और तकनीकी सौंदर्यशास्त्र के लिए आवश्यकताएँ
4.3. उपयोग की शर्तें	4.1.2. सिस्टम कर्मियों की संख्या और योग्यता और उनके संचालन के तरीके के लिए आवश्यकताएँ
	4. 1.9. अनधिकृत पहुंच से जानकारी की सुरक्षा के लिए आवश्यकताएँ
	4. 1.10. दुर्घटनाओं की स्थिति में सूचना की सुरक्षा के लिए आवश्यकताएँ
	4. 1.11. प्रभाव से सुरक्षा के लिए आवश्यकताएँ बाहरी प्रभाव
	4. 1.12. पेटेंट शुद्धता के लिए आवश्यकताएँ
	4. 1.13. मानकीकरण और एकीकरण के लिए आवश्यकताएँ
4.4. तकनीकी साधनों की संरचना और मापदंडों के लिए आवश्यकताएँ	4. 1.8. परिचालन आवश्यकताएँ रखरखाव, सिस्टम घटकों की मरम्मत और भंडारण
4.5. सूचना और सॉफ़्टवेयर अनुकूलता के लिए आवश्यकताएँ
4.6. लेबलिंग और पैकेजिंग आवश्यकताएँ
4.7. परिवहन और भंडारण आवश्यकताएँ	4. 1.7. मोबाइल सिस्टम के लिए परिवहन योग्यता आवश्यकताएँ
4.8. विशेष ज़रूरतें	4. 1.14. अतिरिक्त जरूरतें
	4.3. संपार्श्विक के प्रकार के लिए आवश्यकताएँ
5. के लिए आवश्यकताएँ कार्यक्रम दस्तावेज़ीकरण	8. दस्तावेज़ीकरण आवश्यकताएँ
6. तकनीकी और आर्थिक संकेतक
7. विकास के चरण और चरण	5. सिस्टम बनाने के लिए कार्य की संरचना और सामग्री
8. नियंत्रण एवं स्वीकृति की प्रक्रिया	6. सिस्टम के नियंत्रण एवं स्वीकृति की प्रक्रिया
	7. सिस्टम को चालू करने के लिए स्वचालन वस्तु तैयार करने के लिए कार्य की संरचना और सामग्री के लिए आवश्यकताएँ
	9.विकास के स्रोत

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

उपरोक्त तालिका के आधार पर, हम तकनीकी विशिष्टताओं के मुख्य अनुभागों पर प्रकाश डाल सकते हैं:

• सिस्टम (कार्यक्रम) के बारे में सामान्य जानकारी;
• प्रणाली (कार्यक्रम) का उद्देश्य, लक्ष्य और उद्देश्य;
• सिस्टम आवश्यकताएँ (कार्यात्मक आवश्यकताएँ, उपयोगकर्ता आवश्यकताएँ, संपूर्ण सिस्टम के लिए आवश्यकताएँ, आदि);
• सुरक्षा के प्रकार के लिए आवश्यकताएँ;
• दस्तावेज़ीकरण आवश्यकताएँ;
• विकास के चरण और चरण;
• सिस्टम (प्रोग्राम) के नियंत्रण एवं स्वीकृति की प्रक्रिया।

सामान्य जानकारी
तकनीकी विशिष्टता दस्तावेज़ के इस अनुभाग में सिस्टम का पूरा नाम और सभी संक्षिप्ताक्षर शामिल होने चाहिए जिनका उपयोग दस्तावेज़ीकरण को विकसित करने में किया जाएगा।

उदाहरण:

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

साथ ही यहां आपको विकास में शामिल संगठनों (ग्राहक और ठेकेदार) का विवरण प्रदान करने वाले उपखंड भी शामिल करने चाहिए।

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

तकनीकी विशिष्टताओं के दस्तावेज़ का एक अभिन्न अंग शब्दों और संक्षिप्ताक्षरों की सूची भी होनी चाहिए। शब्दों और संक्षिप्ताक्षरों को दो कॉलमों "टर्म" और "फुल फॉर्म" वाली तालिका के रूप में प्रस्तुत करना बेहतर है।

शब्दों और संक्षिप्ताक्षरों को वर्णानुक्रम में व्यवस्थित किया गया है। सबसे पहले, रूसी-भाषा के शब्दों और संक्षिप्ताक्षरों को समझने की प्रथा है, फिर अंग्रेजी-भाषा वाले।

सिस्टम बनाने का उद्देश्य और लक्ष्य

तकनीकी विशिष्टता दस्तावेज़ के इस खंड में सिस्टम बनाने का उद्देश्य और लक्ष्य शामिल होने चाहिए।

उदाहरण:

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

प्रणाली का मुख्य लक्ष्य एक एकीकृत सूचना वातावरण बनाना और शैक्षणिक संस्थानों की व्यावसायिक प्रक्रियाओं को स्वचालित करना है रूसी संघ.

एकल खिड़की सूचना प्रणाली के निर्माण से यह सुनिश्चित होना चाहिए:

• उपयोगकर्ताओं को उपलब्ध कराना विस्तृत श्रृंखला सूचना संसाधन;
• ऊपर का स्तर सूचना सुरक्षा;
• कई व्यावसायिक प्रक्रियाओं को अनुकूलित करके शैक्षणिक संस्थानों और विभागों की दक्षता बढ़ाना;
• विभाग के भीतर सूचना प्रणालियों और सेवाओं के बीच बातचीत की प्रक्रिया की दक्षता बढ़ाना।

सिस्टम के निर्माण से विभाग की दक्षता में वृद्धि के परिणामस्वरूप परिचालन लागत में कमी आएगी।

सिस्टम आवश्यकताएं

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

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

उदाहरण:

"4.1 व्यावसायिक प्रक्रिया" रूसी संघ के शैक्षणिक संस्थानों के बारे में जानकारी प्रदान करना

इस व्यवसाय प्रक्रिया में निम्नलिखित प्रतिभागियों की पहचान की गई है:

मॉडरेटर विभाग का एक कर्मचारी है जो इसका हिस्सा है सेवा कर्मीप्रदान किए गए डेटा की शुद्धता के लिए जिम्मेदार सिस्टम

उपयोगकर्ता एक नागरिक है जिसे रूसी संघ के शैक्षणिक संस्थानों के काम के बारे में जानकारी प्राप्त करने की आवश्यकता है।

4.1.1 पंजीकरण शैक्षिक संस्थासिस्टम में

रूसी संघ के एक शैक्षणिक संस्थान का पंजीकरण संस्था के जिम्मेदार कर्मचारी ("सरकारी डिक्री ...") द्वारा किया जाता है।

किसी शैक्षणिक संस्थान के पंजीकरण की प्रक्रिया में निम्नलिखित चरण शामिल हैं:

• लेखक संगठन के बारे में एक रिकॉर्ड बनाता है;
• लेखक संगठन के डेटा में प्रवेश करता है;
• सिस्टम किसी दिए गए संगठन के लिए लाइसेंस की जाँच करता है

• यदि लाइसेंस डेटाबेस में मौजूद है, तो सिस्टम लेखक को इसके बारे में एक संदेश भेजता है सफल पंजीकरण;
• यदि डेटाबेस में लाइसेंस नहीं मिलता है, तो सिस्टम लेखक को इस संगठन के लिए लाइसेंस की अनुपस्थिति के बारे में एक संदेश भेजता है।

यदि समय मिले तो जानकारी दी जाएगी यह अनुभाग, संदर्भ की शर्तों के दस्तावेज़ के परिशिष्ट में पूरी तरह से खुलासा किया जाना चाहिए। तकनीकी विशिष्टताओं के परिशिष्ट में, आप एक स्क्रीन फॉर्म प्रदान कर सकते हैं और नीचे उस पर मौजूद सभी घटनाओं (निर्माण, देखना, संपादन, हटाना, आदि) का वर्णन कर सकते हैं।

समग्र रूप से सिस्टम की आवश्यकताओं में सभी उपप्रणालियों के विवरण के साथ इसकी वास्तुकला का खुलासा शामिल है। संदर्भ की शर्तों के इस भाग में सिस्टम को अन्य उत्पादों (यदि कोई हो) के साथ एकीकृत करने की आवश्यकताओं का वर्णन होना चाहिए। इसके अलावा, संदर्भ की शर्तों में शामिल होना चाहिए:

• सिस्टम ऑपरेटिंग मोड के लिए आवश्यकताएँ
• गंतव्य संकेतक
• विश्वसनीयता आवश्यकताएँ
• सुरक्षा आवश्यकताओं
• कर्मियों की संख्या और योग्यता और उनके कार्यसूची के लिए आवश्यकताएँ
• सूचना सुरक्षा आवश्यकताएँ
• दुर्घटनाओं की स्थिति में सूचना की सुरक्षा के लिए आवश्यकताएँ
• पेटेंट मंजूरी आवश्यकताएँ
• मानकीकरण और एकीकरण के लिए आवश्यकताएँ
• वगैरह।

संपार्श्विक के प्रकार के लिए आवश्यकताएँ

तकनीकी विशिष्टता दस्तावेज़ के इस अनुभाग में गणितीय, सूचना, भाषाई, सॉफ्टवेयर, तकनीकी और अन्य प्रकार के समर्थन (यदि कोई हो) की आवश्यकताएं शामिल होनी चाहिए।

दस्तावेज़ीकरण आवश्यकताएँ

तकनीकी विनिर्देश के "दस्तावेज़ीकरण आवश्यकताएँ" अनुभाग में डिज़ाइन और परिचालन दस्तावेज़ों की एक सूची शामिल है जो ग्राहक को प्रदान की जानी चाहिए।

तकनीकी विनिर्देश का यह खंड कार्यात्मक आवश्यकताओं के विवरण जितना ही महत्वपूर्ण है, इसलिए आपको खुद को वाक्यांश तक सीमित नहीं रखना चाहिए "ग्राहक को GOST 34 के अनुसार सभी दस्तावेज उपलब्ध कराए जाने चाहिए।" इसका मतलब है कि आपको "फॉर्म", "पासपोर्ट" आदि सहित दस्तावेजों का पूरा पैकेज प्रदान करना होगा। GOST 34.201-89 में निर्दिष्ट सूची के अधिकांश दस्तावेज़ों की आपको या ग्राहक को आवश्यकता नहीं है, इसलिए तकनीकी विनिर्देश दस्तावेज़ विकसित करने के चरण में सूची पर तुरंत सहमत होना बेहतर है।

दस्तावेज़ों के न्यूनतम पैकेज में आमतौर पर शामिल हैं:

• तकनीकी निर्देश;
• प्रारंभिक (तकनीकी) डिज़ाइन का विवरण;
• व्याख्यात्मक नोटको तकनीकी परियोजना;
• संगठन का विवरण सूचना आधार;
• उपयोगकर्ता की मार्गदर्शिका;
• प्रशासक की मार्गदर्शिका;
• परीक्षण कार्यक्रम और कार्यप्रणाली;
• स्वीकृति परीक्षण रिपोर्ट;
• पूर्ण किये गये कार्य का प्रमाण पत्र

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

विकास के चरण और चरण

संदर्भ दस्तावेज़ के इस अनुभाग में किए जाने वाले कार्य के सभी चरणों के बारे में जानकारी प्रदान की जानी चाहिए।

चरण के विवरण में नाम, समय, कार्य का विवरण और अंतिम परिणाम शामिल होना चाहिए।

सिस्टम के नियंत्रण एवं स्वीकृति की प्रक्रिया

तकनीकी विशिष्टताओं के दस्तावेज़ के इस खंड में, उस दस्तावेज़ को इंगित करना आवश्यक है जिसके आधार पर स्वीकृति परीक्षण किए जाने चाहिए।

यदि आवश्यक हो, तो तकनीकी विनिर्देश को अन्य अनुभागों के साथ पूरक किया जा सकता है, या अनुपयुक्त वस्तुओं को हटाकर कम किया जा सकता है।

तकनीकी विशिष्टताओं की संरचना को बदलते समय, बचने के लिए संघर्ष की स्थितियाँदस्तावेज़ विकसित करने से पहले ग्राहक के साथ इस पर सहमति होनी चाहिए।

तकनीकी निर्देश।

गोस्ट 19.201-78

यूएसएसआर संघ का राज्य मानक

तकनीकी निर्देश। सामग्री और डिज़ाइन के लिए आवश्यकताएँ कार्यक्रम प्रलेखन के लिए संयुक्त प्रणाली। विकास के लिए तकनीकी विशिष्टता. सामग्री और प्रस्तुति के रूप के लिए आवश्यकताएँ

गोस्ट 19.201-78

संकल्प राज्य समितियूएसएसआर 18 दिसंबर, 1978 संख्या 3351 के मानकों के अनुसार, परिचय तिथि स्थापित की गई है

01/01/1980 से

यह मानककिसी प्रोग्राम या सॉफ़्टवेयर उत्पाद के विकास के लिए तकनीकी विशिष्टताओं के निर्माण और उन्हें पूरा करने की प्रक्रिया स्थापित करता है कंप्यूटर, कॉम्प्लेक्स और सिस्टम, उनके उद्देश्य और दायरे की परवाह किए बिना।

1. सामान्य प्रावधान

सूचना भाग (एनोटेशन और सामग्री), परिवर्तन पंजीकरण शीट को दस्तावेज़ में शामिल नहीं किया जा सकता है।

1.3. किसी प्रोग्राम या सॉफ़्टवेयर उत्पाद के विकास के बाद के चरणों में तकनीकी विशिष्टताओं में परिवर्तन या परिवर्धन करने के लिए, इसमें एक अतिरिक्त जारी किया जाता है। तकनीकी विशिष्टताओं में परिवर्धन का समन्वय और अनुमोदन उसी तरीके से किया जाता है जैसे तकनीकी विशिष्टताओं के लिए स्थापित किया गया है।

1.4. संदर्भ की शर्तों में निम्नलिखित अनुभाग होने चाहिए:

आवेदन का नाम और दायरा;

विकास का आधार;

विकास का उद्देश्य;

किसी प्रोग्राम या सॉफ़्टवेयर उत्पाद के लिए तकनीकी आवश्यकताएँ;

तकनीकी और आर्थिक संकेतक;

विकास के चरण और चरण;

नियंत्रण और स्वीकृति प्रक्रिया;

अनुप्रयोग.

प्रोग्राम या सॉफ़्टवेयर उत्पाद की विशेषताओं के आधार पर, अनुभागों की सामग्री को स्पष्ट करना, नए अनुभागों को प्रस्तुत करना, या अलग-अलग अनुभागों को संयोजित करना संभव है।

2. अनुभाग सामग्री

2.1. अनुभाग "नाम और दायरा" में नाम इंगित करें, संक्षिप्त विवरणप्रोग्राम या सॉफ़्टवेयर उत्पाद के अनुप्रयोग का दायरा और वह वस्तु जिसमें प्रोग्राम या सॉफ़्टवेयर उत्पाद का उपयोग किया जाता है।

2.2. अनुभाग "विकास का आधार" इंगित करना चाहिए:

दस्तावेज़(ओं) जिनके आधार पर विकास किया जाता है;

वह संगठन जिसने इस दस्तावेज़ को मंजूरी दी और इसके अनुमोदन की तारीख;

नाम और (या) प्रतीकविकास विषय.

2.3. अनुभाग "विकास का उद्देश्य" में प्रोग्राम या सॉफ़्टवेयर उत्पाद के कार्यात्मक और परिचालन उद्देश्य का उल्लेख होना चाहिए।

2.4. अनुभाग "किसी प्रोग्राम या सॉफ़्टवेयर उत्पाद के लिए तकनीकी आवश्यकताएँ" में निम्नलिखित उपधाराएँ होनी चाहिए:

कार्यात्मक विशेषताओं के लिए आवश्यकताएँ;

विश्वसनीयता आवश्यकताएँ;

उपयोग की शर्तें;

तकनीकी साधनों की संरचना और मापदंडों के लिए आवश्यकताएँ;

सूचना और सॉफ़्टवेयर अनुकूलता के लिए आवश्यकताएँ;

लेबलिंग और पैकेजिंग आवश्यकताएँ;

परिवहन और भंडारण के लिए आवश्यकताएँ;

विशेष ज़रूरतें.

2.4.1. उपधारा "कार्यात्मक विशेषताओं के लिए आवश्यकताएँ" में किए गए कार्यों की संरचना, इनपुट और आउटपुट डेटा के संगठन, समय विशेषताओं आदि के लिए आवश्यकताओं को इंगित करना चाहिए।

2.4.2. उपधारा "विश्वसनीयता आवश्यकताएँ" में विश्वसनीय संचालन सुनिश्चित करने के लिए आवश्यकताओं को इंगित करना चाहिए (सुनिश्चित करना)। टिकाऊ कामकाज, इनपुट और आउटपुट जानकारी का नियंत्रण, विफलता के बाद पुनर्प्राप्ति समय, आदि)।

2.4.3. उपधारा "परिचालन की स्थिति" में परिचालन की स्थिति (परिवेश का तापमान, सापेक्षिक आर्द्रतावगैरह। चयनित प्रकार के भंडारण मीडिया के लिए), जिसे निर्दिष्ट विशेषताओं, साथ ही सेवा के प्रकार को सुनिश्चित करना होगा, आवश्यक मात्राऔर कार्मिक योग्यताएँ।

2.4.4. उपधारा में "तकनीकी साधनों की संरचना और मापदंडों के लिए आवश्यकताएँ" इंगित करें आवश्यक रचनातकनीकी साधन उनकी मुख्य तकनीकी विशेषताओं को दर्शाते हैं।

2.4.5उपधारा "सूचना और सॉफ़्टवेयर संगतता के लिए आवश्यकताएँ" के लिए आवश्यकताओं को इंगित करना चाहिए सूचना संरचनाएँइनपुट और आउटपुट और समाधान विधियों पर, स्रोत कोड, प्रोग्रामिंग भाषा।

आवश्यकतानुसार सूचना एवं कार्यक्रम उपलब्ध कराये जायें।

2.4.6. उपधारा में "लेबलिंग और पैकेजिंग आवश्यकताएँ"। सामान्य मामलासॉफ़्टवेयर उत्पाद लेबलिंग, पैकेजिंग विकल्पों और विधियों के लिए आवश्यकताओं को इंगित करें।

2.4.7. उपधारा "परिवहन और भंडारण के लिए आवश्यकताएँ" में सॉफ़्टवेयर उत्पाद के लिए परिवहन की स्थिति, भंडारण स्थान, भंडारण की स्थिति, भंडारण की स्थिति, विभिन्न स्थितियों में भंडारण की अवधि का संकेत होना चाहिए।

2.5. अनुभाग "तकनीकी और आर्थिक संकेतक" को इंगित करना चाहिए: अनुमानित आर्थिक दक्षता, अनुमानित वार्षिक मांग, सर्वोत्तम घरेलू की तुलना में विकास के आर्थिक लाभ और विदेशी नमूनेया एनालॉग्स।

2.6. अनुभाग "विकास के चरण और चरण" में विकास के आवश्यक चरण, चरण और कार्य की सामग्री स्थापित की गई है (सूची)। कार्यक्रम दस्तावेज़, जिसे विकसित किया जाना चाहिए, उस पर सहमति होनी चाहिए और अनुमोदित होना चाहिए), और, एक नियम के रूप में, विकास की समय सीमा कलाकारों को निर्धारित करती है।

2.7. अनुभाग "नियंत्रण और स्वीकृति के लिए प्रक्रिया" में परीक्षणों के प्रकार और शामिल होने चाहिए सामान्य आवश्यकताएँकार्य की स्वीकृति हेतु.

2.8. तकनीकी विशिष्टताओं के परिशिष्टों में, यदि आवश्यक हो, निम्नलिखित दिया गया है:

विकास को उचित ठहराने वाले अनुसंधान और अन्य कार्यों की एक सूची;

एल्गोरिदम आरेख, तालिकाएं, विवरण, औचित्य, गणना और अन्य दस्तावेज़ जिनका उपयोग विकास के दौरान किया जा सकता है;

अन्य विकास स्रोत।

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

मानक पूरी तरह से एसटी एसईवी 1627-79 का अनुपालन करता है।

डिज़ाइन नियम

संदर्भ की शर्तें, एक नियम के रूप में, शीट के फ़ील्ड को भरने के बिना, GOST 2.301-68 के अनुसार प्रारूप 11 और 12 की शीट पर GOST 19.106-78 के अनुसार तैयार की जाती हैं। शीट (पेज) नंबर टेक्स्ट के ऊपर शीट के शीर्ष पर रखे गए हैं।

अनुमोदन शीट और कवर शीट

अनुमोदन पत्र और मुखपृष्ठ GOST 19.104-78 के अनुसार तैयार किया गया।

सूचना भाग (एनोटेशन और सामग्री), परिवर्तन पंजीकरण शीट को दस्तावेज़ में शामिल नहीं किया जा सकता है।

परिवर्तन और परिवर्धन

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

सभी विवरणों को ध्यान में रखें प्रारंभिक चरणविकास असंभव है. व्यवहार में निर्दिष्ट दृष्टिकोणअक्सर प्रयोग किया जाता है। अनुभाग "विकास के चरण और चरण" में, तकनीकी विशिष्टताओं में परिवर्तन और परिवर्धन करने की संभावना को स्पष्ट रूप से इंगित किया जाना चाहिए: "इस तकनीकी विशिष्टता के अनुभागों की सामग्री को ग्राहक के साथ समझौते द्वारा बदला और पूरक किया जा सकता है।"

तकनीकी विशिष्टताओं के अनुभागों की संरचना

संदर्भ की शर्तों में निम्नलिखित अनुभाग होने चाहिए:

परिचय; विकास के कारण; विकास का उद्देश्य; किसी प्रोग्राम या सॉफ़्टवेयर उत्पाद के लिए आवश्यकताएँ; कार्यक्रम प्रलेखन के लिए आवश्यकताएँ; तकनीकी और आर्थिक संकेतक; विकास के चरण और चरण; नियंत्रण और स्वीकृति प्रक्रिया; अनुप्रयोगों को तकनीकी विशिष्टताओं में शामिल किया जा सकता है।

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

एक प्रशिक्षण कार्यक्रम के रूप में, हम ग्राफिकल यूजर इंटरफेस के साथ एक वास्तविक प्रोग्राम का उपयोग करेंगे, जो कई टेम्पलेट फ़ंक्शन (उदाहरण के लिए, एक साधारण टेक्स्ट एडिटर) करने की क्षमता प्रदान करता है।

परिचय

अनुभाग नाम, प्रोग्राम या सॉफ़्टवेयर उत्पाद के अनुप्रयोग के दायरे का संक्षिप्त विवरण और उस ऑब्जेक्ट को इंगित करता है जिसमें प्रोग्राम या सॉफ़्टवेयर उत्पाद का उपयोग किया जाता है।

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

कार्यक्रम का नाम

नाम - "आरटीएफ फाइलों के साथ काम करने के लिए टेक्स्ट एडिटर।"

आवेदन के क्षेत्र का संक्षिप्त विवरण

यह कार्यक्रम ग्राहक की सुविधाओं पर विशेष विभागों में उपयोग के लिए है।

सामग्री व्यक्तिगत आइटमहमेशा स्पष्ट नहीं. यदि आपको कोई कठिनाई हो तो आपको उनसे औपचारिक रूप से संपर्क करना चाहिए। ग्राहक के साथ तकनीकी विशिष्टताओं के अनुमोदन के चरण में सुधार किए जा सकते हैं।

विकास के कारण

अनुभाग को इंगित करना चाहिए:

दस्तावेज़ जिसके आधार पर विकास किया जाता है; वह संगठन जिसने इस दस्तावेज़ को मंजूरी दी और इसके अनुमोदन की तारीख; विकास विषय का नाम और (या) प्रतीक।

उपधारा में अनुबंध में निहित जानकारी शामिल होनी चाहिए।

विकास का आधार

विकास का आधार समझौता (पत्र, आदि) संख्या 000 दिनांक 1 जनवरी, 2001 (आने वाली संख्या ऐसी और ऐसी और ऐसी और ऐसी) है। इस समझौते पर राज्य एकात्मक उद्यम "स्पेटस्ट्याज़मोंटाज़स्ट्रॉयसेलखोज़ाव्टोमैटिका" के निदेशक इवानोव पेट्र इवानोविच के साथ सहमति हुई, जिन्हें कहा जाता है ग्राहक द्वारा आगे, और स्वीकृत महानिदेशकब्लमकिन्स इवान अरोनोविच, जिसे इसके बाद निष्पादक के रूप में जाना जाता है, ऐसे और ऐसे मार्च 2008.

GOST 34.602-89 के "सामान्य सूचना" अनुभाग का उपयोग करना सुविधाजनक है, क्योंकि डेवलपर के पास है हर अधिकारअपने विवेक पर तकनीकी विशिष्टताओं के अनुभागों को पूरक करें और हटाएँ। साथ ही, ऊपर निर्दिष्ट जानकारी अनुबंध में निहित है। उन्हें संदर्भ की शर्तों में शामिल किया जाना चाहिए या नहीं यह विशिष्ट मामले पर निर्भर करता है।

विकास विषय का नाम और प्रतीक

विकास विषय का नाम "विकास" है पाठ संपादकआरटीएफ फाइलों के साथ काम करने के लिए।"

विकास विषय (विषय कोड) का पदनाम "RTF-007" है।

विकास का उद्देश्य

अनुभाग में प्रोग्राम या सॉफ़्टवेयर उत्पाद के कार्यात्मक और परिचालन उद्देश्य का उल्लेख होना चाहिए।

कार्यात्मक उद्देश्य

कार्यक्रम का कार्यात्मक उद्देश्य उपयोगकर्ता को काम करने का अवसर प्रदान करना है पाठ दस्तावेज़आरटीएफ प्रारूप में.

उपधारा में "विस्तारित" दर्शाया जाना चाहिए कार्यात्मक उद्देश्यकार्यक्रम. विवरण - कार्यों की सूची, आदि - संबंधित अनुभागों में नीचे दी जाएगी।

परिचालन उद्देश्य की काफी व्यापक रूप से व्याख्या की जा सकती है। प्रोग्राम का उपयोग कहाँ, कैसे, किसके द्वारा, किसके साथ किया जाना चाहिए?

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

आइए एक औपचारिक दृष्टिकोण का उपयोग करें:

परिचालन उद्देश्य

कार्यक्रम का उपयोग ग्राहक की सुविधाओं के विशेष विभागों में किया जाना चाहिए।

कार्यक्रम के अंतिम उपयोगकर्ता ग्राहक की सुविधाओं के विशेष विभागों के कर्मचारी होने चाहिए।

किसी प्रोग्राम या सॉफ़्टवेयर उत्पाद के लिए आवश्यकताएँ

अनुभाग में निम्नलिखित उपधाराएँ होनी चाहिए:

कार्यात्मक विशेषताओं के लिए आवश्यकताएँ; विश्वसनीयता आवश्यकताएँ; उपयोग की शर्तें; तकनीकी साधनों की संरचना और मापदंडों के लिए आवश्यकताएँ; सूचना और सॉफ़्टवेयर अनुकूलता के लिए आवश्यकताएँ; लेबलिंग और पैकेजिंग आवश्यकताएँ; परिवहन और भंडारण के लिए आवश्यकताएँ; विशेष ज़रूरतें।

यदि किसी प्रोग्राम, सिस्टम या उत्पाद के लिए सामान्य (तकनीकी) आवश्यकताओं वाले मानक हैं, उदाहरण के लिए, "GOST। स्वचालित सूचना और माप प्रणाली. सामान्य (तकनीकी) आवश्यकताएँ", तकनीकी विशिष्टताओं का विकास काफी सरल हो गया है। निर्दिष्ट मानक की अधिकांश सामग्री को केवल तकनीकी विशिष्टताओं में फिर से लिखा गया है।

कार्यात्मक आवश्यकताएँ

उपधारा में किए गए कार्यों की संरचना, इनपुट और आउटपुट डेटा के संगठन, समय विशेषताओं आदि के लिए आवश्यकताओं को इंगित करना चाहिए।

निष्पादित कार्यों की संरचना के लिए आवश्यकताएँ

प्रोग्राम को निम्नलिखित कार्य करने की क्षमता प्रदान करनी चाहिए:

1. एक नई (खाली) फ़ाइल बनाने का कार्य।

2. किसी मौजूदा फ़ाइल को खोलने (लोड करने) के लिए कार्य।

4. वर्तमान फ़ाइल का उपयोग करके संपादन के लिए कार्य करता है बफरअदला-बदली ऑपरेटिंग सिस्टम.

5. फ़ाइल को मूल नाम से सहेजने का कार्य।

6. किसी फ़ाइल को मूल नाम से भिन्न नाम से सहेजने का कार्य।

7. वर्तमान फ़ाइल की सामग्री भेजने के लिए कार्य ईमेल द्वाराबाहरी क्लाइंट मेल प्रोग्राम का उपयोग करना।

8. स्ट्रिंग प्रारूप (टिप्स) में ऑनलाइन जानकारी प्रदर्शित करने के लिए कार्य।

9. ऑनलाइन सहायता प्रणाली के कार्य।

10. प्रोग्राम का नाम, प्रोग्राम संस्करण, कॉपीराइट और डेवलपर टिप्पणियाँ प्रदर्शित करने के लिए कार्य।

"निष्पादन क्षमता प्रदान करना" वाली कहावत ग्राफिकल यूजर इंटरफेस का उपयोग करके विकसित आधुनिक सॉफ्टवेयर पर लागू होती है। निर्दिष्ट सॉफ़्टवेयर ज्यादातर"निष्क्रिय", ऑपरेटर की कार्रवाई की प्रतीक्षा में।

इनपुट डेटा व्यवस्थित करने के लिए आवश्यकताएँ

प्रोग्राम के इनपुट डेटा को फॉर्म में व्यवस्थित किया जाना चाहिए अलग फ़ाइलेंविनिर्देश के अनुरूप आरटीएफ प्रारूप।

निर्दिष्ट प्रारूप की फ़ाइलों को ऑपरेटिंग सिस्टम की आवश्यकताओं के अनुसार स्वरूपित स्थानीय या हटाने योग्य मीडिया पर रखा (संग्रहीत) किया जाना चाहिए।

भिन्न प्रारूप की कोई भी फ़ाइल, लेकिन आरटीएफ एक्सटेंशन के साथ, नहीं खोली जानी चाहिए।

फ़ाइलें http:///file. आरटीएफ या एफ़टीपी:///फ़ाइल। आरटीएफ नहीं खोला जाना चाहिए. यदि फ़ाइल सिस्टम को FAT32 के रूप में स्वरूपित किया गया है, तो स्थानीय या हटाने योग्य मीडिया स्वरूपित फ़ाइलें, उदाहरण के लिए, ext3 प्रारूप में, नहीं खोली जानी चाहिए।

आउटपुट डेटा व्यवस्थित करने के लिए आवश्यकताएँ

इनपुट डेटा व्यवस्थित करने के लिए आवश्यकताएँ देखें।

आउटपुट डेटा को व्यवस्थित करने के लिए आवश्यकताएँ समान हैं। यह वही स्थिति है जब तकनीकी विशिष्टताओं के दोनों बिंदुओं को संयोजित किया जाना चाहिए।

समय संबंधी आवश्यकताएँ

कार्यक्रम की समय संबंधी विशेषताओं के लिए कोई आवश्यकता नहीं है।

यह स्पष्ट किया जाना चाहिए कि क्या ग्राहक के पास प्रोग्राम की गति के लिए आवश्यकताएं हैं, उदाहरण के लिए, प्रोग्राम को किसी दिए गए आकार की फ़ाइलों को शुरू करने, खोलने और बंद करने में कितना समय लगता है। यदि ग्राहक निर्दिष्ट करता है विशिष्ट संख्याएँ, आपको इसे सुरक्षित रूप से खेलना चाहिए और तकनीकी उपकरणों की संरचना और मापदंडों की आवश्यकताओं में $2,500 या अधिक लागत वाला एक सुपर कंप्यूटर शामिल करना चाहिए। सच है, ऐसी राशि को उचित ठहराना होगा। यदि ग्राहक के लिए समय विशेषताएँ महत्वपूर्ण नहीं हैं, तो समय विशेषताओं के लिए आवश्यकताओं की छूट के बारे में लिखना आवश्यक है (ऊपर शब्द देखें)।

विश्वसनीयता आवश्यकताएँ

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

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

कार्यक्रम के विश्वसनीय (स्थिर) संचालन को सुनिश्चित करने के लिए आवश्यकताएँ

कार्यक्रम का विश्वसनीय (टिकाऊ) संचालन ग्राहक द्वारा संगठनात्मक और तकनीकी उपायों के एक सेट के कार्यान्वयन द्वारा सुनिश्चित किया जाना चाहिए, जिसकी सूची नीचे दी गई है:

तकनीकी उपकरणों की निर्बाध बिजली आपूर्ति का संगठन; एक लाइसेंस प्राप्त का उपयोग करना सॉफ़्टवेयर; श्रम मंत्रालय की सिफ़ारिशों का नियमित कार्यान्वयन और सामाजिक विकासरूसी संघ के, 01.01.01 के संकल्प में निर्धारित "अंतरक्षेत्रीय के अनुमोदन पर" मानक मानककाम करने का समय सेवापीसी और कार्यालय उपकरण और सॉफ्टवेयर समर्थन"; GOST आवश्यकताओं का नियमित अनुपालन। सूचना सुरक्षा. कंप्यूटर वायरस की उपस्थिति के लिए सॉफ़्टवेयर का परीक्षण करना।

आप सूची में एक दर्जन और जोड़ सकते हैं। नियामक दस्तावेज़. तकनीकी विशिष्टताओं के प्रारंभिक अनुमोदन के दौरान, ग्राहक संभवतः समझौता करने की प्रवृत्ति दिखाना शुरू कर देगा।

अधिक मानवीय दृष्टिकोण संभव है। विश्वसनीयता (हालांकि, उसी GOST के अनुसार) को एक विशिष्ट समय अंतराल के दौरान एक निश्चित i-वें फ़ंक्शन का विफलता-मुक्त प्रदर्शन माना जा सकता है। हमारा सुझाव है कि ग्राहक कार्यक्रम के विश्वसनीय संचालन के मानदंड पर विचार करें अगला सूचक: ग्राहक एक घंटे के भीतर फ़ाइल को 100 बार खोलता और बंद करता है। यदि प्रोग्राम निर्दिष्ट समय अंतराल के भीतर विफल नहीं होता है, तो विश्वसनीयता आवश्यकताओं को पूरा माना जाता है।

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

कार्यक्रम के विश्वसनीय (स्थिर) संचालन को सुनिश्चित करने के लिए कोई आवश्यकता नहीं है।

विफलता के बाद पुनर्प्राप्ति का समय

तकनीकी उपकरण (अन्य) की बिजली विफलता के कारण हुई विफलता के बाद पुनर्प्राप्ति समय बाह्य कारक), ऑपरेटिंग सिस्टम की घातक विफलता (क्रैश नहीं) नहीं, इतने मिनटों से अधिक नहीं होनी चाहिए, बशर्ते कि हार्डवेयर और सॉफ्टवेयर की ऑपरेटिंग स्थितियां देखी जाएं।

हार्डवेयर की खराबी या ऑपरेटिंग सिस्टम की घातक विफलता (क्रैश) के कारण हुई विफलता के बाद पुनर्प्राप्ति समय हार्डवेयर की खराबी को खत्म करने और सॉफ़्टवेयर को फिर से स्थापित करने के लिए आवश्यक समय से अधिक नहीं होना चाहिए।

स्क्रॉल आपातकालीन स्थितियाँग्राहक द्वारा भी तैयार किया गया और ठेकेदार के साथ सहमति व्यक्त की गई। वास्तव में, यह ऑपरेटिंग सिस्टम को रिबूट करने का समय है, यदि विफलता घातक नहीं है, ऑपरेटिंग सिस्टम के क्रैश होने या हार्डवेयर की विफलता के कारण नहीं हुई है।

गलत ऑपरेटर कार्यों के कारण विफलताएँ

ऑपरेटिंग सिस्टम के साथ इंटरैक्ट करते समय ऑपरेटर (उपयोगकर्ता) के गलत कार्यों के कारण प्रोग्राम विफलता संभव है। उपरोक्त कारण से प्रोग्राम विफलताओं से बचने के लिए, आपको यह सुनिश्चित करना चाहिए कि अंतिम उपयोगकर्ता उसे प्रशासनिक विशेषाधिकार दिए बिना काम कर सकता है।

उपयोग की शर्तें

उपधारा में परिचालन स्थितियों (परिवेश तापमान, सापेक्ष) का संकेत होना चाहिए नमीआदि, चयनित प्रकार के भंडारण मीडिया के लिए), जिसे निर्दिष्ट विशेषताओं, साथ ही सेवा के प्रकार, आवश्यक संख्या और कर्मियों की योग्यता सुनिश्चित करनी चाहिए।

जलवायु परिचालन की स्थितियाँ

जलवायु परिस्थितियाँसंचालन, जिसके दौरान निर्दिष्ट विशेषताओं को सुनिश्चित किया जाना चाहिए, को आवश्यकताओं को पूरा करना चाहिए तकनीकी साधनउनकी परिचालन स्थितियों के संदर्भ में।

प्रोग्राम 90% की सापेक्ष आर्द्रता और 462 मिमी के वायुमंडलीय दबाव के साथ प्लस 5 से प्लस 35 डिग्री सेल्सियस तक पूरी तरह से काम करेगा। आरटी. कला।, चूंकि ऐसी स्थितियाँ लगभग आधुनिक कंप्यूटरों की परिचालन स्थितियों के अनुरूप हैं गैर-औद्योगिककार्यान्वयन। लेकिन, जैसे ही विनिर्देश विशिष्ट होते हैं और कार्य स्वीकृत हो जाता है, ग्राहक को ठेकेदार को जलवायु परीक्षण करने के लिए बाध्य करने का एक उत्कृष्ट मौका मिलता है। पूरे मेंठेकेदार के खर्च पर.

सेवाओं के प्रकार के लिए आवश्यकताएँ

कार्यक्रम के विश्वसनीय (स्थिर) संचालन को सुनिश्चित करने के लिए आवश्यकताएँ देखें।

प्रोग्राम को किसी भी प्रकार के रखरखाव की आवश्यकता नहीं है।

रखरखाव के प्रकारों को उपधारा "विश्वसनीय (टिकाऊ) संचालन सुनिश्चित करने के लिए आवश्यकताएँ" से उधार लिया जाना चाहिए।

यदि ग्राहक, तकनीकी विशिष्टताओं के अनुमोदन के दौरान, संसाधनों की कमी या सभी प्रकार के रखरखाव करने की इच्छा का उल्लेख करता है अपने दम पर, कुछ पैसे के लिए सॉफ़्टवेयर समर्थन के लिए तकनीकी विशिष्टताओं के विकास की पेशकश करना समझ में आता है एक अलग समझौता. यदि वह इनकार करता है, तो प्रोग्राम को असमर्थित माना जाना चाहिए।

कर्मियों की संख्या और योग्यता के लिए आवश्यकताएँ

कार्यक्रम को संचालित करने के लिए आवश्यक कर्मियों की न्यूनतम संख्या कम से कम 2 होनी चाहिए स्टाफिंग इकाइयाँ- सिस्टम प्रशासक और अंतिम उपयोगकर्ताप्रोग्राम - ऑपरेटर.

सिस्टम प्रशासक के पास उच्च शिक्षा की डिग्री होनी चाहिए विशेष शिक्षाऔर ऑपरेटिंग सिस्टम निर्माता से प्रमाणपत्र। निष्पादित कार्यों की सूची कार्यकारी प्रबंधक, शामिल होना चाहिए:

तकनीकी साधनों की कार्यक्षमता बनाए रखने का कार्य; सिस्टम सॉफ़्टवेयर - ऑपरेटिंग सिस्टम की स्थापना (इंस्टॉलेशन) और कार्यक्षमता को बनाए रखने के कार्य; किसी प्रोग्राम को स्थापित करने का कार्य.

प्रोग्राम के अंतिम उपयोगकर्ता (ऑपरेटर) के पास ऑपरेटिंग सिस्टम के ग्राफिकल यूजर इंटरफेस के साथ काम करने में व्यावहारिक कौशल होना चाहिए।

कार्मिक को विद्युत सुरक्षा (कार्यालय उपकरण के साथ काम करने के लिए) में योग्यता समूह II के लिए प्रमाणित किया जाना चाहिए।

अनुमोदित तकनीकी विशिष्टताओं में सबसे महत्वपूर्ण (बोल्ड) वाक्यांश की अनुपस्थिति में, ग्राहक को यह अनुरोध करने का अधिकार है कि ठेकेदार ऑपरेटिंग सिस्टम के ग्राफिकल यूजर इंटरफेस के संचालन के लिए एक मैनुअल विकसित करे, इस तथ्य का हवाला देते हुए कि ऑपरेटर "इसका सामना नहीं कर सकता" कार्यक्रम के साथ.

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

तकनीकी साधनों की संरचना और मापदंडों के लिए आवश्यकताएँ

उपधारा तकनीकी साधनों की आवश्यक संरचना को इंगित करती है, उनकी मुख्य तकनीकी विशेषताओं को दर्शाती है।

आपको ऐसे उपकरण का चयन करना चाहिए जो उस उपकरण से अधिक खराब न हो जिस पर विकास किया जाएगा। यह अनुरोध करना तर्कसंगत है कि ग्राहक जल्द से जल्द उपकरण उपलब्ध कराए निर्दिष्ट अवधि. इसके बारे मेंबेशक, कंप्यूटर के बारे में।

हार्डवेयर में आईबीएम-संगत शामिल होना चाहिए पर्सनल कंप्यूटर(पीसी), जिसमें शामिल हैं:

10 गीगाहर्ट्ज़ की क्लॉक फ़्रीक्वेंसी वाला पेंटियम-1000 प्रोसेसर, कम नहीं; मदरबोर्डएफएसबी के साथ, गीगाहर्ट्ज - 5, कम नहीं; टक्कर मारनामात्रा, टीबी - 10, कम नहीं; और इसी तरह…

सूचना और सॉफ़्टवेयर अनुकूलता के लिए आवश्यकताएँ

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

यदि आवश्यक हो तो इसे उपलब्ध कराया जाना चाहिए सूचना सुरक्षाऔर कार्यक्रम.

सूचना संरचनाओं और समाधान विधियों के लिए आवश्यकताएँ

फ़ाइल की सूचना संरचना में आरटीएफ प्रारूप विनिर्देश के लिए आवश्यक मार्कअप वाला पाठ शामिल होना चाहिए।

इनपुट और आउटपुट पर सूचना संरचनाओं (फ़ाइलों) के साथ-साथ समाधान विधियों के लिए कोई आवश्यकता नहीं है।

स्रोत कोड और प्रोग्रामिंग भाषाओं के लिए आवश्यकताएँ

प्रोग्राम के स्रोत कोड को C++ में लागू किया जाना चाहिए। बोरलैंड सी++ ब्यूडर वातावरण का उपयोग एक एकीकृत कार्यक्रम विकास वातावरण के रूप में किया जाना चाहिए।

प्रोग्राम द्वारा उपयोग किए जाने वाले सॉफ़्टवेयर के लिए आवश्यकताएँ

प्रोग्राम द्वारा उपयोग किया जाने वाला सिस्टम सॉफ़्टवेयर ऑपरेटिंग सिस्टम का लाइसेंस प्राप्त स्थानीयकृत संस्करण होना चाहिए। आप फलां सर्विस पैक का उपयोग कर सकते हैं.

सूचना और कार्यक्रमों की सुरक्षा के लिए आवश्यकताएँ

सूचना और कार्यक्रमों की सुरक्षा के लिए कोई आवश्यकता नहीं है।

ऐसी मांगों से बचना चाहिए. सूचना और कार्यक्रमों की एक निश्चित स्तर की सुरक्षा सुनिश्चित करना संभव है, लेकिन सुरक्षा सुनिश्चित करना असंभव है। ग्राहक को संभवतः इसका एहसास होगा और वह कायम नहीं रहेगा।

लेबलिंग और पैकेजिंग आवश्यकताएँ

प्रोग्राम को एक सॉफ़्टवेयर उत्पाद के रूप में - एक वितरण (बाहरी ऑप्टिकल) माध्यम (सीडी) पर आपूर्ति की जाती है।

हम वितरण मीडिया की लेबलिंग और पैकेजिंग के बारे में बात कर रहे हैं - एक सॉफ्टवेयर उत्पाद (GOST 19.004-80 देखें)।

लेबलिंग आवश्यकता

सॉफ़्टवेयर उत्पाद को पदनाम के साथ चिह्नित किया जाना चाहिए ट्रेडमार्कडेवलपर कंपनी, प्रकार (नाम), संस्करण संख्या, क्रम संख्या, निर्माण की तारीख और रूस के गोस्स्टैंडर्ट के अनुरूपता प्रमाण पत्र की संख्या (यदि कोई हो)।

GOST 9181-74 की आवश्यकताओं को ध्यान में रखते हुए, प्रिंटिंग द्वारा बनाए गए स्टिकर के रूप में मार्किंग को सॉफ़्टवेयर उत्पाद पर लागू किया जाना चाहिए।

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

पैकेजिंग आवश्यकताएँ

सॉफ़्टवेयर उत्पाद को निर्माता के पैकेजिंग कंटेनरों में पैक किया जाना चाहिए।

बिल्कुल निर्माता. ठेकेदार कंटेनर निर्माता से अधिक ज़िम्मेदारी नहीं उठा सकता और उसे उठाना भी नहीं चाहिए।

पैकिंग की शर्तें

सॉफ़्टवेयर उत्पाद की पैकेजिंग बंद हवादार क्षेत्रों में प्लस 15 से प्लस 40 डिग्री सेल्सियस के तापमान पर और वातावरण में आक्रामक अशुद्धियों की अनुपस्थिति में 80% से अधिक की सापेक्ष आर्द्रता पर की जानी चाहिए।

ग्राहक को सॉफ़्टवेयर उत्पाद उचित स्वरूप में प्राप्त होगा। यदि सॉफ़्टवेयर उत्पाद अनुचित स्थिति (खरोंच, दरार और अन्य दोष) में लौटाया जाता है, तो ठेकेदार ग्राहक द्वारा पैकेजिंग शर्तों के उल्लंघन के संबंध में दावा करने में सक्षम होगा और सॉफ़्टवेयर उत्पाद को स्वीकार नहीं करेगा।

पैकिंग प्रक्रिया

पैकेजिंग के लिए तैयार किए गए सॉफ़्टवेयर उत्पादों को कंटेनरों में रखा जाता है, जो पैकेजिंग निर्माता के चित्र के अनुसार नालीदार कार्डबोर्ड (GOST 7376-89 या GOST 79) से बने बक्से होते हैं।

सॉफ़्टवेयर उत्पाद को वॉटरप्रूफ़ फ़िल्म से बने कवर का उपयोग करके पैक किया जाता है अनिवार्य उपस्थितिरासायनिक रूप से गैर आक्रामक शोषक (सिलिका जेल)।

भरना मुक्त स्थाननालीदार कार्डबोर्ड या फोम प्लास्टिक से बने गैसकेट को पैकेजिंग कंटेनरों में रखा जाता है।

परिचालन दस्तावेज अवश्य रखा जाना चाहिए उपभोक्ता पैकेजिंगसॉफ्टवेयर उत्पाद के साथ.

शिपिंग दस्तावेज़ को कुशनिंग सामग्री की शीर्ष परत पर रखा जाता है - पैकिंग सूचीऔर कथनपैकेजिंग.

GOST के अनुसार उपभोक्ता पैकेजिंग को चिपकने वाली टेप 6-70 से कवर किया जाना चाहिए।

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

पैलेट बॉक्स में GOST के अनुसार पैकिंग सूची सहित शिपिंग दस्तावेज़ होना चाहिए।

कार्गो स्थान का आयाम 1250 x 820 x 1180 मिमी से अधिक नहीं होना चाहिए।

शुद्ध वजन - 200 किलो से अधिक नहीं।

सकल वजन - 220 किलो से अधिक नहीं।

उपधारा कुछ तकनीकी उपकरणों के लिए पहले से विकसित दस्तावेज़ से पैकेजिंग प्रक्रिया दिखाती है। सॉफ़्टवेयर उत्पाद के संदर्भ में यह कुछ हद तक असामान्य लगता है। सीधे शब्दों में कहें तो रूसी भाषा- पूरा मजाक.

परिवहन और भंडारण आवश्यकताएँ

उपधारा में सॉफ्टवेयर उत्पाद के लिए परिवहन की स्थिति, भंडारण स्थान, भंडारण की स्थिति, भंडारण की स्थिति, विभिन्न स्थितियों में भंडारण की अवधि का संकेत होना चाहिए।

उपधारा कुछ तकनीकी उपकरणों के लिए पहले से विकसित दस्तावेज़ से परिवहन और भंडारण की शर्तें प्रदान करती है। यह पैकेजिंग आवश्यकताओं पर भी लागू होता है। सॉफ़्टवेयर उत्पाद के संदर्भ में यह कुछ हद तक असामान्य लगता है।

ग्राहक को परिवहन और भंडारण की शर्तों का उल्लंघन करने का कोई अधिकार नहीं है। ठेकेदार यह दावा करते हुए ग्राहक को सॉफ़्टवेयर उत्पाद वापस करने से इंकार कर सकेगा उपस्थितिसॉफ़्टवेयर उत्पाद परिवहन और भंडारण शर्तों का अनुपालन न करने का परिणाम है।

परिवहन और भंडारण की स्थिति

सॉफ़्टवेयर उत्पाद को परिवहन कंटेनर में सभी प्रकार के परिवहन (बिना दूरी प्रतिबंध के विमान के गर्म सीलबंद डिब्बों सहित) द्वारा परिवहन करने की अनुमति है। जब रेलवे कारों में परिवहन किया जाता है, तो शिपमेंट का प्रकार छोटा, कम टन भार वाला होता है।

सॉफ़्टवेयर उत्पाद का परिवहन और भंडारण करते समय, धूल और वर्षा से सुरक्षा प्रदान की जानी चाहिए। सॉफ़्टवेयर उत्पाद को झुकाने की अनुमति नहीं है. परिवहन के लिए जलवायु परिस्थितियाँ नीचे दी गई हैं:

परिवेशी वायु तापमान, डिग्री सेल्सियस - प्लस 5 से प्लस 50 तक; वायुमंडलीय दबाव, केपीए - ऐसा और ऐसा; 25 डिग्री सेल्सियस पर सापेक्ष वायु आर्द्रता ऐसी-ऐसी होती है।

विशेष ज़रूरतें

प्रोग्राम को ऑपरेटिंग सिस्टम निर्माता की सिफारिशों के अनुसार विकसित ग्राफिकल यूजर इंटरफेस के माध्यम से उपयोगकर्ता (ऑपरेटर) के साथ बातचीत प्रदान करनी चाहिए।

इस मानक के डेवलपर्स ने भविष्य की ओर देखा। उन वर्षों में ग्राफिकल यूजर इंटरफ़ेस वाला कोई प्रोग्राम नहीं था।

सॉफ़्टवेयर दस्तावेज़ीकरण के लिए आवश्यकताएँ

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

कार्यक्रम दस्तावेज़ीकरण की संरचना GOST 19.101-77 द्वारा प्रदान की गई है।

कार्यक्रम प्रलेखन की प्रारंभिक संरचना

कार्यक्रम दस्तावेज़ीकरण की संरचना में शामिल होना चाहिए:

तकनीकी निर्देश; परीक्षण कार्यक्रम और विधियाँ; सिस्टम प्रोग्रामर गाइड; नियम - पुस्तक संचालक; परिचालन दस्तावेजों की सूची.

कार्यक्रम और परीक्षण विधियों को ग्राहक को यह दिखाने की आवश्यकता होगी कि ठेकेदार द्वारा विकसित कार्यक्रम सहमत और अनुमोदित तकनीकी विशिष्टताओं की आवश्यकताओं को पूरा करता है। संयुक्त (स्वीकृति) परीक्षण करने के बाद, ग्राहक और ठेकेदार कार्य स्वीकृति (डिलीवरी) प्रमाणपत्र पर हस्ताक्षर करेंगे। और, इस प्रकार, काम बंद हो जाएगा, समझौते की शर्तें पूरी हो जाएंगी।

खंड 2.6 के अनुसार. GOST 19.101-77 “इसे संयोजित करने की अनुमति है व्यक्तिगत प्रजातिपरिचालन दस्तावेज़ (परिचालन दस्तावेज़ों की सूची और प्रपत्र को छोड़कर)। इन दस्तावेज़ों को संयोजित करने की आवश्यकता तकनीकी विशिष्टताओं में इंगित की गई है। मर्ज किए गए दस्तावेज़ को मर्ज किए गए दस्तावेज़ों में से एक का नाम और पदनाम दिया गया है।

सॉफ़्टवेयर दस्तावेज़ीकरण शामिल है प्रारंभिक सूची, GOST 19.106-78 की आवश्यकताओं के अनुसार जारी किया जाना चाहिए।

तकनीकी और आर्थिक संकेतक

अनुमानित आर्थिक दक्षता की गणना नहीं की जाती है.

प्रति वर्ष कार्यक्रम के उपयोग की अनुमानित संख्या एक कार्य केंद्र पर 365 कार्य सत्र है।

अनुभाग को इंगित करना चाहिए: अनुमानित आर्थिक दक्षता, अनुमानित वार्षिक मांग, सर्वोत्तम घरेलू और विदेशी नमूनों या एनालॉग्स की तुलना में विकास के आर्थिक लाभ।

मान लीजिए कि ग्राहक एक दर्जन वर्कस्टेशनों को प्रोग्राम से सुसज्जित करता है। ठेकेदार ने विकास के लिए $1000 की मांग की। ग्राहक कार्यस्थानों पर स्थापित कर सकता है सॉफ्टवेयर उत्पादएक तीसरी कंपनी से, प्रत्येक कार्य केंद्र के लिए प्रति वितरण $500 और प्रति लाइसेंस $100 की लागत।

विकास के आर्थिक लाभ

सर्वोत्तम घरेलू और विदेशी समकक्षों की तुलना में विकास के आर्थिक लाभ होंगे:

नौकरियों की संख्या

विकास

आर्थिक लाभ

विकास के चरण और चरण

अनुभाग विकास के आवश्यक चरणों, चरणों और कार्य की सामग्री (कार्यक्रम दस्तावेजों की सूची जिन्हें विकसित, सहमत और अनुमोदित किया जाना चाहिए) स्थापित करता है, साथ ही, एक नियम के रूप में, विकास की समय सीमा और निष्पादकों को निर्धारित करता है।

विकास के चरण और चरण GOST 19.102-77 द्वारा नियंत्रित होते हैं। GOST 19.102-77 कार्य के व्यक्तिगत चरणों के बहिष्कार के साथ-साथ संयोजन को भी नहीं रोकता है व्यक्तिगत चरणकाम करता है

विकास के चरण

विकास तीन चरणों में किया जाना चाहिए:

तकनीकी विशिष्टताओं का विकास; विस्तृत डिजाइन; कार्यान्वयन।

विकास के चरण

तकनीकी विशिष्टताओं के विकास के चरण में, इस तकनीकी विशिष्टता के विकास, समन्वय और अनुमोदन का चरण पूरा किया जाना चाहिए।

विस्तृत डिज़ाइन चरण में, कार्य के निम्नलिखित चरणों को पूरा किया जाना चाहिए:

कार्यक्रम विकास; कार्यक्रम प्रलेखन का विकास; कार्यक्रम का परीक्षण.

कार्यान्वयन चरण में, विकास चरण पूरा किया जाना चाहिए - कार्यक्रम की तैयारी और स्थानांतरण।

तकनीकी विशिष्टताओं के विकास के चरण में, निम्नलिखित कार्य किए जाने चाहिए:

समस्या का विधान; तकनीकी साधनों के लिए आवश्यकताओं का निर्धारण और स्पष्टीकरण; कार्यक्रम की आवश्यकताओं का निर्धारण; कार्यक्रम के विकास और उसके लिए दस्तावेज़ीकरण के चरणों, चरणों और समय का निर्धारण करना; प्रोग्रामिंग भाषाओं का चयन; तकनीकी विशिष्टताओं का समन्वय और अनुमोदन।

कार्यक्रम विकास स्तर पर होना चाहिए काम कियाप्रोग्रामिंग (कोडिंग) और प्रोग्राम डिबगिंग पर।

प्रोग्राम दस्तावेज़ीकरण के विकास के चरण में, प्रोग्राम दस्तावेज़ों का विकास इस तकनीकी विनिर्देश के प्रोग्राम दस्तावेज़ीकरण की प्रारंभिक संरचना के खंड की आवश्यकता के साथ GOST 19.101-77 की आवश्यकताओं के अनुसार किया जाना चाहिए।

कार्यक्रम के परीक्षण चरण के दौरान, निम्नलिखित प्रकार के कार्य किए जाने चाहिए:

एक कार्यक्रम का विकास, समन्वय और अनुमोदन (GOST में, ऐसा लगता है, एक टाइपो है - "ऑर्डर") और परीक्षण विधियां; स्वीकृति परीक्षण करना; परीक्षण परिणामों के आधार पर कार्यक्रम और कार्यक्रम प्रलेखन का समायोजन।

कार्यक्रम की तैयारी और हस्तांतरण के चरण में, ग्राहक की सुविधाओं पर संचालन के लिए कार्यक्रम और कार्यक्रम दस्तावेज तैयार करने और स्थानांतरित करने का काम पूरा किया जाना चाहिए।

नियंत्रण एवं स्वीकृति प्रक्रिया

अनुभाग में कार्य की स्वीकृति के लिए परीक्षणों के प्रकार और सामान्य आवश्यकताओं को इंगित किया जाना चाहिए।

परीक्षणों के प्रकार

स्वीकृति परीक्षण ग्राहक की साइट पर समय सीमा के भीतर किए जाने चाहिए...

कार्यक्रम की स्वीकृति परीक्षण ठेकेदार द्वारा विकसित और ग्राहक द्वारा सहमत कार्यक्रम और परीक्षण विधियों (अमुक अवधि से बाद में नहीं) के अनुसार किया जाना चाहिए।

ग्राहक और ठेकेदार परीक्षण रिपोर्ट में स्वीकृति परीक्षणों की प्रगति का दस्तावेजीकरण करते हैं।

कार्य की स्वीकृति के लिए सामान्य आवश्यकताएँ

परीक्षण प्रोटोकॉल के आधार पर, ठेकेदार, ग्राहक के साथ मिलकर कार्यक्रम स्वीकृति और कमीशनिंग प्रमाणपत्र पर हस्ताक्षर करता है।

अनुप्रयोग

तकनीकी विशिष्टताओं के परिशिष्टों में, यदि आवश्यक हो, निम्नलिखित दिया गया है:

विकास को उचित ठहराने वाले अनुसंधान और अन्य कार्यों की एक सूची; एल्गोरिदम आरेख, तालिकाएं, विवरण, औचित्य, गणना और अन्य दस्तावेज़ जिनका उपयोग विकास के दौरान किया जा सकता है; अन्य विकास स्रोत।

अगर है तो क्यों नहीं लाते. और GOSTs की एक सूची पोस्ट करना सुनिश्चित करें जिसके आधार पर विकास किया जाना चाहिए। उदाहरण के लिए:

गोस्ट 19.201-78. तकनीकी विशिष्टताएँ, सामग्री और डिज़ाइन के लिए आवश्यकताएँ; और इसी तरह...

हाल ही में उन्होंने स्वचालित सिस्टम (एएस) और सॉफ्टवेयर (सॉफ्टवेयर) के विकास के लिए तकनीकी विनिर्देश (टीओआर) लिखने के मानकों पर सलाह देने के लिए मुझसे संपर्क किया। मैं सोच रहा हूं, अब मैं यांडेक्स जाऊंगा, एक उपयुक्त लेख ढूंढूंगा और उसे भेजूंगा। लेकिन बात वो नहीं थी! टेम्प्लेट और उदाहरणों सहित तकनीकी विशिष्टताओं के लिए मानकों को सूचीबद्ध करने वाला एक लेख तैयार दस्तावेज़, मुझे यह नहीं मिला। यह लेख आपको स्वयं बनाना होगा...

और इसलिए, मुख्य मानक, कार्यप्रणाली और ज्ञान के निकाय जो टीके या एसआरएस (सॉफ़्टवेयर (या सिस्टम) आवश्यकताएँ विशिष्टता) का उल्लेख करते हैं:

गोस्ट 34
गोस्ट 19
आईईईई एसटीडी 830-1998
आईएसओ/आईईसी/आईईईई 29148-2011
आरयूपी
स्वेबोक, बाबोक, आदि।

गोस्ट 34

GOST 34.602-89 एक स्वचालित प्रणाली के निर्माण के लिए संदर्भ की शर्तें सिस्टम के निर्माण के लिए तकनीकी विशिष्टताओं की संरचना को नियंत्रित करती हैं, जिसमें सॉफ्टवेयर, हार्डवेयर, सॉफ्टवेयर के साथ काम करने वाले लोग और स्वचालित प्रक्रियाएं शामिल हैं।

GOST 34 के अनुसार, तकनीकी विनिर्देश में निम्नलिखित अनुभाग शामिल होने चाहिए:

1. सामान्य जानकारी
2. सिस्टम के निर्माण (विकास) का उद्देश्य और लक्ष्य
3. स्वचालन वस्तुओं की विशेषताएँ
4. सिस्टम आवश्यकताएँ
5. सिस्टम बनाने के लिए कार्य की संरचना और सामग्री
6. सिस्टम के नियंत्रण एवं स्वीकृति की प्रक्रिया
7. सिस्टम को चालू करने के लिए स्वचालन वस्तु तैयार करने के लिए कार्य की संरचना और सामग्री के लिए आवश्यकताएँ
8. दस्तावेज़ीकरण आवश्यकताएँ
9. विकास स्रोत

के लिए तकनीकी विशिष्टताएँ विकसित करते समय सरकारी परियोजनाएँग्राहकों को, एक नियम के रूप में, इस विशेष मानक के अनुपालन की आवश्यकता होती है।

गोस्ट 19

“GOST 19.xxx एकीकृत प्रणालीप्रोग्राम डॉक्यूमेंटेशन (ईएसपीडी)'' एक जटिल है राज्य मानक, प्रोग्राम (या सॉफ़्टवेयर) और प्रोग्राम दस्तावेज़ीकरण के विकास, डिज़ाइन और संचलन के लिए परस्पर जुड़े नियमों की स्थापना करना। वे। यह मानक विशेष रूप से सॉफ़्टवेयर विकास पर लागू होता है।
GOST 19.201-78 तकनीकी विशिष्टताओं, सामग्री और डिज़ाइन के लिए आवश्यकताओं के अनुसार, तकनीकी विशिष्टताओं में निम्नलिखित अनुभाग शामिल होने चाहिए:

1 परिचय;
2. विकास के कारण;
3. विकास का उद्देश्य;
4. प्रोग्राम या सॉफ़्टवेयर उत्पाद के लिए आवश्यकताएँ;
5. कार्यक्रम प्रलेखन के लिए आवश्यकताएँ;
6. तकनीकी और आर्थिक संकेतक;
7. विकास के चरण और चरण;
8. नियंत्रण एवं स्वीकृति की प्रक्रिया;
9. अनुप्रयोग.

स्वाभाविक रूप से, GOST 34 (और 19) पहले से ही पुराने हैं, और मैं उनका उपयोग करना पसंद नहीं करता, लेकिन मानकों की सही व्याख्या के साथ, आप अच्छी तकनीकी विशिष्टताएँ प्राप्त कर सकते हैं, निष्कर्ष देखें।

आईईईई एसटीडी 830-1998

830-1998 मानक - आईईईई अनुशंसित अभ्यास फॉर सॉफ्टवेयर रिक्वायरमेंट्स स्पेसिफिकेशंस की एक काफी अच्छी परिभाषा इसके विवरण में दी गई है:

सामग्री का वर्णन करता है और गुणवत्ता विशेषताएँके लिए आवश्यकताओं का सही ढंग से तैयार किया गया विवरण सॉफ़्टवेयर(एसआरएस) और कई एसआरएस टेम्पलेट प्रदान करता है। इस अनुशंसित अभ्यास का उद्देश्य विकसित किए जा रहे सॉफ़्टवेयर के लिए आवश्यकताओं को स्थापित करना है, लेकिन इसका उपयोग स्वामित्व और वाणिज्यिक के चयन में सहायता के लिए भी किया जा सकता है सॉफ्टवेयर उत्पाद.

मानक के अनुसार, संदर्भ की शर्तों में निम्नलिखित अनुभाग शामिल होने चाहिए:

1 परिचय

• 1. उद्देश्य
• 2। घेरा
• 3. परिभाषाएँ, परिवर्णी शब्द और संक्षिप्ताक्षर
• 4. लिंक
• 5. संक्षिप्त अवलोकन

2. सामान्य विवरण

• 1. उत्पाद इंटरैक्शन (अन्य उत्पादों और घटकों के साथ)
• 2. उत्पाद विशेषताएँ (संक्षिप्त विवरण)
• 3. उपयोगकर्ता विशेषताएँ
• 4. सीमाएँ
• 5. धारणाएँ और निर्भरताएँ

3. विस्तृत आवश्यकताएं (विभिन्न तरीकों से व्यवस्थित की जा सकती हैं, उदाहरण के लिए इस तरह)

• 1. बाहरी इंटरफेस के लिए आवश्यकताएँ
  • 1. यूजर इंटरफेस
  • 2. हार्डवेयर इंटरफेस
  • 3. सॉफ्टवेयर इंटरफेस
  • 4. इंटरेक्शन इंटरफेस
• 2. कार्यात्मक आवश्यकताएँ
• 3. प्रदर्शन आवश्यकताएँ
• 4. डिज़ाइन बाधाएं (और मानकों के संदर्भ)
• 5. गैर-कार्यात्मक आवश्यकताएँ (विश्वसनीयता, उपलब्धता, सुरक्षा, आदि)
• 6. अन्य आवश्यकताएँ

4. अनुप्रयोग
5. वर्णानुक्रमिक अनुक्रमणिका

वास्तव में, एक नौसिखिया के लिए यह समझना काफी कठिन है कि उपरोक्त संरचना के अनुसार इन अनुभागों में क्या शामिल होना चाहिए (जैसा कि GOST के मामले में है), इसलिए आपको मानक को स्वयं पढ़ने की आवश्यकता है, जो। हालाँकि, अंग्रेजी में। भाषा।

खैर, जिसने भी अंत तक पढ़ा - एक बोनस है: तकनीकी विशिष्टताओं का एक उदाहरण जो मैंने कई साल पहले लिखा था (अब मैं लंबे समय से एक विश्लेषक के रूप में काम नहीं कर रहा हूं, और अन्य अधिक हैं) सफल उदाहरणएनडीए को सार्वजनिक रूप से उपलब्ध कराने से रोकता है)।

• यूरी बुलुय द्वारा प्रस्तुति, सॉफ्टवेयर आवश्यकताओं का वर्गीकरण और मानकों और कार्यप्रणाली में इसका प्रतिनिधित्व।
• स्वचालित के लिए आवश्यकताओं का विश्लेषण जानकारी के सिस्टम. व्याख्यान 11: दस्तावेज़ीकरण आवश्यकताएँ।
• सॉफ़्टवेयर आवश्यकताओं के विनिर्देश तैयार करने के नियम (टिप्पणियों के साथ पढ़ें)
• आर्थिक विकास मंत्रालय के लिए एएस के विकास के लिए तकनीकी विशिष्टताओं और अन्य दस्तावेज़ों के उदाहरण
• GOST प्रबंधन शैली। गैपरटन द्वारा लेख उचित संचालन GOST के अनुसार तकनीकी विशिष्टताओं से
• व्यवसाय विश्लेषक दस्तावेज़ टेम्पलेट्स से