क्या आप अंग्रेजी जैसी प्राकृतिक भाषा में एक स्पष्ट विनिर्देश लिख सकते हैं?

10

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

यह एक ज्ञात परिणाम है या मैं कुछ याद कर रहा हूँ?

documentation specifications

— jl6
स्रोत

1

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

— S.Lott

@ S.Lott: उपयोगकर्ता अपनी भाषा में विनिर्देशों चाहते हैं, गणित या औपचारिक तर्क नहीं। दो डोमेन के बीच अनुवाद करना हमारा काम है।

— tdammers

2

आपका कोड अस्पष्ट हो सकता है, लेकिन इसका मतलब यह नहीं है कि यह सही है।

— जेएफओ

1

@ दोस्त: क्या? प्रश्न प्राकृतिक भाषा बनाम औपचारिक भाषा पर था। इसके लिए उपयोगकर्ताओं को क्या करना होगा? इसके अलावा, क्या होगा यदि उपयोगकर्ता वास्तव में एक तर्कशास्त्री है? इसके अलावा, "व्यापार विश्लेषक" आमतौर पर उपयोगकर्ताओं की ओर से नहीं लिखते हैं? "उपयोगकर्ता" चीज़ इस प्रश्न के बाहर और बाहर लगती है।

— S.Lott

@ एस.लॉट: मैं एक ऐसी स्थिति मान रहा था, जहां आपको ग्राहक / उपयोगकर्ता / अन्य गैर-तकनीकी हितधारक को सॉफ्टवेयर का वर्णन करना होगा, जो पहली जगह में एक प्राकृतिक भाषा का उपयोग करने के लिए सबसे अच्छा कारण होगा।

— t तैमूर

9

क्या यह नहीं है कि वकीलों ने हमेशा अस्पष्टताओं से बचने के लिए क्या किया?

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

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

यह इसलिए भी है क्योंकि हम अपने कोड को डॉक्यूमेंट करते हैं, क्योंकि कभी-कभी हमारे दिमाग के लिए पढ़ना मुश्किल होता है।

दूसरे कोड के साथ डॉक्यूमेंटिंग कोड का कोई मतलब नहीं है।

— जोस फेटी
स्रोत

2

कुछ वकील चीजों को बाधित और अस्पष्ट करना पसंद करते हैं। अपने लक्ष्य पर निर्भर करता है।

— duffymo

1

आप वकीलों को गणितज्ञों के साथ भ्रमित कर रहे हैं।

— डॉक्टर ब्राउन

1

@ डॉक: मैथ सिर्फ एक और कोड है, क्योंकि केवल गणितज्ञ इसे पढ़ सकते हैं, और कोड के साथ कोड डॉक्यूमेंट करने का कोई मतलब नहीं है, यह क्रिप्टोग्राफी है।

— जोस फ़ेती

2

@ जोस: मैं कहूंगा कि आप भारी ओवरसाइप्लाइज़िंग हैं। सभी गणितीय प्रमाणों के 99% प्राकृतिक भाषा में लिखे गए हैं - बेशक, एक तकनीकी भाषा जिसमें विशेष शब्द हैं और कमोबेश सूत्रों का उपयोग कर रहे हैं, लेकिन निश्चित रूप से कोई "औपचारिक रूप से निर्दिष्ट भाषा" नहीं है।

— डॉक्टर ब्राउन

@ डॉक: यही मैं कह रहा हूं ... डॉक्स प्राकृतिक भाषा में लिखे गए हैं। एक कोड के साथ दूसरे कोड की व्याख्या करने वाला गैर-अर्थ।

— जोस फ़ेती

4

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

मैं कहूंगा कि यह साबित करना असंभव है कि कुछ भी सटीक और अस्पष्ट है, दोनों कल्पना और सॉफ्टवेयर के लिए।

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

समस्या जितनी बड़ी होगी, दर्शकों को उतना ही मुश्किल होगा।

लेकिन एवियोनिक्स और अन्य जटिल समस्याओं का सुझाव है कि बड़ी समस्याओं को हल करने के लिए अंग्रेजी में "अच्छा पर्याप्त" विनिर्देशों को लिखना संभव है।

— duffymo
स्रोत

2

"अच्छा काफी अच्छा है, लेकिन पूर्णता एक पीआईटीए है" - मैं पर्यावरण नियंत्रण का निर्माण करने के लिए काम करता था, और वहाँ पूरी तरह से अस्पष्ट कल्पना जैसी कोई चीज नहीं है, यहां तक कि जब वे 400 पृष्ठों तक चलते हैं - कभी-कभी इससे कोई फर्क नहीं पड़ता था , और कई बार इसके लिए हमारे पास

— RFI

4

अच्छी तरह से .. समस्या का एक पूरी तरह से स्पष्ट विनिर्देश वास्तविक कोड ही है :)

यह एक ज्ञात समस्या है और विशेष मिशन क्रिटिकल सिस्टम के लिए यह एक औपचारिक (प्रोग्रामिंग) भाषा में स्पष्ट विनिर्देश लिखने और फिर एक कोड है कि करने के लिए बदलने कि अनिवार्य है provably क्या विनिर्देश का कहना है। यह एक बहुत ही संकीर्ण क्षेत्र है, 99.999% डेवलपर्स को कभी भी इस तरह के कार्य करने की आवश्यकता नहीं होती है, लेकिन मैंने एक बार एक लड़के के साथ बात की थी जिसने ट्रैफिक कंट्रोलिंग / रेलवे सिस्टम के लिए ऐसा किया था।

— करोली होरवाथ
स्रोत

3

मैं एक W3C अनुयायी लड़का हूं, और मैं उनके विनिर्देशों के आधार पर लेख लिखना चाहता हूं। मेरा अनुभव मुझे बताता है कि लिखित उदाहरण कोड के बिना किसी भी विनिर्देश को पढ़ना, बस एक सिरदर्द है।

मैं पूरी तरह से सहमत हूं और मुझे लगता है कि मुख्य कारण यह है कि, डेवलपर्स कोड को बेहतर ढंग से पढ़ना और समझना चाहते हैं। जरा सोचिए आपको बिना किसी फॉर्मूले के गणित का पेपर मिल जाए।

To calculate the result, simply add variable x to variable y, 
and then divide that by the b factor.

या:

result = (x + y) / b

कौन सा छोटा है? कौन सा अधिक पठनीय है? जो इसके साथ अधिक समझ लाता है?

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

— सईद नेमाटी
स्रोत

और फिर भी, मैं पूछता हूँ कि (x + y) और (x + y) / b के डोमेन क्या हैं। क्या वे दोहरे हैं? क्या वे पूर्णांक हैं? क्या वे अनंत-लंबाई पूर्णांक हैं? मुझे आशा है, यदि वे पूर्णांक हैं, तो आपने नियम को लिखा है :-)

— xanatos

1

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

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

मुझे यकीन है कि तर्क स्पष्ट है क्योंकि यह सादे अंग्रेजी में है। क्या आप इसे औपचारिक भाषा में लिख सकते हैं?

— ब्लूब

1

मुझे विश्वास है कि यह आपकी धारणा है: citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.88.1151

— थॉमस ओवेन्स

और फिर वहाँ रुकने की समस्या है, जो अस्पष्टता का अनुवाद करता है: एन 1 से अधिक एन से परिभाषित नहीं होता है

— मोजुबा

1

-1 Gödels प्रमेय गलत होने के लिए।

— इंगो सेप

1

विनिर्देशों अस्पष्ट और अभेद्य हैं क्योंकि लोग अस्पष्ट और अभेद्य हैं। एक पूर्ण व्यक्ति खोजें और शायद तब आप एक आदर्श विनिर्देश प्राप्त कर सकते हैं।

अंग्रेजी, स्वाहिली, संस्कृत या बेबीलोन में कोई अंतर नहीं है।

— दवे नाइ
स्रोत

1

इस संदर्भ में अस्पष्टता वास्तव में एक ताकत है।

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

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

तो लक्ष्य आम तौर पर एक पूर्ण, सही और अस्पष्ट कल्पना नहीं है; लक्ष्य एक ऐसी युक्ति लिखना है जो स्पष्ट रूप से मनुष्य को बताए, कि आप क्या बनाने जा रहे हैं।

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

— tdammers
स्रोत

0

आप कुछ भी याद नहीं कर रहे हैं, सिवाय इसके कि प्रलेखन मनुष्यों को पढ़ने के लिए लिखा गया है। कुछ अस्पष्टता की उम्मीद की जाती है, और यहां तक कि स्वागत है, क्योंकि कठिन पाठ को पढ़ना मुश्किल है (= मनुष्यों के लिए नहीं)।

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

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

— Radim
स्रोत

0

(मेरे कुछ बिंदुओं को पहले ही अन्य उत्तरों द्वारा समझा गया है, लेकिन मुझे लगता है कि मैं एक टिप्पणी के बजाय इस उत्तर के लायक बनाने के लिए एक अलग दृष्टिकोण प्रदान कर रहा हूं।)

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

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

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

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

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

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

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

— ग्रेग जैक्सन
स्रोत

0

कोई भी प्राकृतिक भाषा को अपेक्षाकृत अस्पष्ट बना सकता है, लेकिन केवल बड़ी कठिनाई के साथ।

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

यह कानूनी के आविष्कार के लिए नेतृत्व की जरूरत है। आप कितनी दूर जाने के लिए तैयार हैं?

— Waquo
स्रोत

0

खुले समूह, आईएसओ, आईईटीएफ और आईटीयू द्वारा कई विनिर्देश हैं जो अत्यधिक प्रतिस्पर्धी कंपनियों के लिए पर्याप्त रूप से असंदिग्ध हैं जो कि काफी सफलतापूर्वक इंटरोपर्ट करने के लिए हैं। ऐसे कई विनिर्देश हैं जो अनुबंध या कानूनों का आधार हैं जहां लाखों डॉलर दांव पर हैं।

इसलिए विनिर्देशन "सही" नहीं हो सकता है। हालाँकि ऐसा इसलिए है क्योंकि मनुष्य परिपूर्ण नहीं हैं। उदाहरण के लिए यह असंदिग्ध है कि HTTP को "रेफर" हेडर का उपयोग करना चाहिए - सही वर्तनी वास्तव में "रेफ़रल" है।

अंग्रेजी भाषा असंदिग्ध होने में सक्षम है, लेकिन मनुष्य गलतियाँ करने में सक्षम हैं - जिसमें अस्पष्टता भी शामिल है।

इसके अलावा यह उन विवरणों के लिए जानबूझकर अस्पष्ट होने में सहायक हो सकता है जिन्हें अंतिम रूप नहीं दिया गया है या भविष्य में अपडेट करने की आवश्यकता हो सकती है। उदाहरण के लिए एक विनिर्देश विशेष रूप से md5, sha1, crc32 आदि को निर्दिष्ट करने के बजाय एक "हैश" निर्दिष्ट कर सकता है।

— teambob
स्रोत

0

मेरा मानना है कि सही उत्तर नकारात्मक है। निम्नलिखित प्रश्नों में अंतर करना आवश्यक है:

क्या एक प्राकृतिक भाषा में सॉफ़्टवेयर विनिर्देश लिखना संभव है जिसमें अस्पष्टता नहीं है?
क्या ऐसी प्राकृतिक भाषा में सॉफ़्टवेयर लिखना संभव है जिसमें अस्पष्टता न हो?

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

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

Variables: x,y,z,...
Constants: 1,2,3,...
Rules: (1) if x is a variable and n a constant, then
           "The variable x contains the number n" is a sentence.
       (2) if x is a variable and n a constant, then
           "Assign the number n to the variable x" is a sentence.

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

Over the domain D supporting operations f,g,h over elements a,b,c in relations
P,R,Q with properties φ,ψ,θ, design a program that does X,Y,Z.

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

— danportin
स्रोत

0

नहीं

एक संगणना का एक स्पष्ट विनिर्देश एक कंप्यूटर प्रोग्राम है।

— केविन क्लाइन
स्रोत