هندسة البرامجيات (محاضرة 5، 6)-PDF

Lesson 5 Requirements Analysis and Specification Version 2 EE IIT, Kharagpur 2 Specific Instructional Objectives At the end of this lesson, the student would be able to: Explain the role of a system analyst. Identify the important parts o...

Lesson 5 Requirements Analysis and Specification Version 2 EE IIT, Kharagpur 2 Specific Instructional Objectives At the end of this lesson, the student would be able to: Explain the role of a system analyst. Identify the important parts of SRS document. Identify the functional requirements from any given problem description. Document the functional requirements from any given problem description. Identify the important properties of a good SRS document. Identify the important problems that an organization would face if it does not develop an SRS document. Identify non-functional requirements from any given problem description. Identify the problems that an unstructured specification would create during software development. Represent complex conditions in the form of a decision tree. Represent complex conditions in the form of decision table. 2. Requirements Gathering And Analysis The analyst starts requirements gathering and analysis activity by collecting all information from the customer which could be used to develop the requirements of the system. He then analyses the collected information to obtain a clear and thorough understanding of the product to be developed, with a view to removing all ambiguities and inconsistencies from the initial customer perception of the problem. The following basic questions pertaining to the project should be clearly understood by the analyst in order to obtain a good grasp of the problem: What is the problem? Why is it important to solve the problem? What are the possible solutions to the problem? What exactly are the data input to the system and what exactly are the data output by the system? Version 2 EE IIT, Kharagpur 3  ‫اﻷھﺪاف اﻟﺘﻌﻠﯿﻤﯿﺔ اﻟﻤﺤﺪدة‬ ‫ﻗﺎدرا ﻋﻠﻰ‪:‬‬ ‫ﻓﻲ ﻧﮭﺎﯾﺔ ھﺬه اﻟﺪرس‪ ،‬ﺳﯿﻜﻮن اﻟﻄﺎﻟﺐ ً‬ ‫‪.1‬ﺷﺮح دور ﻣﺤﻠﻞ اﻟﻨﻈﺎم‬ ‫‪.2‬ﺗﺤﺪﯾﺪ اﻷﺟﺰاء اﻟﻤﮭﻤﺔ ﻓﻲ وﺛﯿﻘﺔ ‪SRS‬‬ ‫‪3.‬ﺗﺤﺪﯾﺪ اﻟﻤﺘﻄﻠﺒﺎت اﻟﻮظﯿﻔﯿﺔ ﻣﻦ أي وﺻﻒ ﻣﺸﻜﻠﺔ ﻣﻌﻄﻰ‪.‬ﺗﻮﺛﯿﻖ اﻟﻤﺘﻄﻠﺒﺎت اﻟﻮظﯿﻔﯿﺔ ﻣﻦ أي وﺻﻒ ﻣﺸﻜﻠﺔ ﻣﻌﻄﻰ‪.4‬ﺗﺤﺪﯾﺪ‬ ‫اﻟﺨﺼﺎﺋﺺ اﻟﻤﮭﻤﺔ ﻟﻮﺛﯿﻘﺔ ‪SRS‬ﺟﯿﺪة‬ ‫‪.5‬ﺗﺤﺪﯾﺪ اﻟﻤﺸﺎﻛﻞ اﻟﻤﮭﻤﺔ اﻟﺘﻲ ﻗﺪ ﺗﻮاﺟﮭﮭﺎ اﻟﻤﻨﻈﻤﺔ إذا ﻟﻢ ﺗﻘﻢ ﺑﺘﻄﻮﯾﺮ وﺛﯿﻘﺔ ‪SRS‬‬ ‫‪6.‬ﺗﺤﺪﯾﺪ اﻟﻤﺘﻄﻠﺒﺎت ﻏﯿﺮ اﻟﻮظﯿﻔﯿﺔ ﻣﻦ أي وﺻﻒ ﻣﺸﻜﻠﺔ ﻣﻌﻄﻰ‬ ‫‪.7‬ﺗﺤﺪﯾﺪ اﻟﻤﺸﺎﻛﻞ اﻟﺘﻲ ﻗﺪ ﺗﻨﺸﺄ ﺑﺴﺒﺐ اﻟﻤﻮاﺻﻔﺎت ﻏﯿﺮ اﻟﻤﻨﻈﻤﺔ أﺛﻨﺎء ﺗﻄﻮﯾﺮ اﻟﺒﺮﻣﺠﯿﺎت‪.‬‬ ‫‪.8‬ﺗﻤﺜﯿﻞ اﻟﺸﺮوط اﻟﻤﻌﻘﺪة ﻓﻲ ﺷﻜﻞ ﺷﺠﺮة اﺗﺨﺎذ اﻟﻘﺮار‬ ‫‪.9‬ﺗﻤﺜﯿﻞ اﻟﺸﺮوط اﻟﻤﻌﻘﺪة ﻓﻲ ﺷﻜﻞ ﺟﺪول اﺗﺨﺎذ اﻟﻘﺮار‬ ‫ﺟﻤﻊ وﺗﺤﻠﯿﻞ اﻟﻤﺘﻄﻠﺒﺎت‬ ‫ﯾﺒﺪأ اﻟﻤﺤﻠﻞ ﻧﺸﺎط ﺟﻤﻊ وﺗﺤﻠﯿﻞ اﻟﻤﺘﻄﻠﺒﺎت ﻣﻦ ﺧﻼل ﺟﻤﻊ ﻛﺎﻓﺔ اﻟﻤﻌﻠﻮﻣﺎت ﻣﻦ اﻟﻌﻤﯿﻞ اﻟﺘﻲ ﯾﻤﻜﻦ اﺳﺘﺨﺪاﻣﮭﺎ ﻟﺘﻄﻮﯾﺮ ﻣﺘﻄﻠﺒﺎت‬ ‫اﻟﻨﻈﺎم‪.‬ﺛﻢ ﯾﻘﻮم ﺑﺘﺤﻠﯿﻞ اﻟﻤﻌﻠﻮﻣﺎت اﻟﺘﻲ ﺗﻢ ﺟﻤﻌﮭﺎ ﻟﻠﺤﺼﻮل ﻋﻠﻰ ﻓﮭﻢ واﺿﺢ وﺷﺎﻣﻞ ﻟﻠﻤﻨﺘﺞ اﻟﺬي ﺳﯿﺘﻢ ﺗﻄﻮﯾﺮه‪ ،‬ﻣﻊ اﻟﺘﺮﻛﯿﺰ ﻋﻠﻰ‬ ‫إزاﻟﺔ ﻛﺎﻓﺔ اﻟﻐﻤﻮض واﻟﺘﻨﺎﻗﻀﺎت ﻣﻦ اﻟﺘﺼﻮر اﻷوﻟﻲ ﻟﻠﻌﻤﯿﻞ ﺣﻮل اﻟﻤﺸﻜﻠﺔ‪.‬ﯾﺠﺐ أن ﺗﻜﻮن اﻷﺳﺌﻠﺔ اﻷﺳﺎﺳﯿﺔ اﻟﺘﺎﻟﯿﺔ اﻟﻤﺘﻌﻠﻘﺔ‬ ‫ﺑﺎﻟﻤﺸﺮوع ﻣﻔﮭﻮﻣﺔ ﺑﻮﺿﻮح ﻣﻦ ﻗﺒﻞ اﻟﻤﺤﻠﻞ ﻣﻦ أﺟﻞ اﻟﺤﺼﻮل ﻋﻠﻰ ﻓﮭﻢ ﺟﯿﺪ ﻟﻠﻤﺸﻜﻠﺔ‪:‬‬ ‫‪.1‬ﻣﺎ ھﻲ اﻟﻤﺸﻜﻠﺔ؟‬ ‫‪.2‬ﻟﻤﺎذا ﻣﻦ اﻟﻤﮭﻢ ﺣﻞ اﻟﻤﺸﻜﻠﺔ؟‬ ‫‪.3‬ﻣﺎ ھﻲ اﻟﺤﻠﻮل اﻟﻤﻤﻜﻨﺔ ﻟﻠﻤﺸﻜﻠﺔ؟‬ ‫‪.4‬ﻣﺎ ھﻲ اﻟﺒﯿﺎﻧﺎت اﻟﻤﺪﺧﻠﺔ ﻟﻠﻨﻈﺎم ﺑﺎﻟﻀﺒﻂ‪ ،‬وﻣﺎ ھﻲ اﻟﺒﯿﺎﻧﺎت اﻟﺨﺎرﺟﺔ ﻣﻦ اﻟﻨﻈﺎم ﺑﺎﻟﻀﺒﻂ؟‬ ‫‪Version 2 EE IIT, Kharagpur‬‬ ‫‪3‬‬  What are the likely complexities that might arise while solving the problem? If there are external software or hardware with which the developed software has to interface, then what exactly would the data interchange formats with the external system be? After the analyst has understood the exact customer requirements, he proceeds to identify and resolve the various requirements problems. The most important requirements problems that the analyst has to identify and eliminate are the problems of anomalies, inconsistencies, and incompleteness. When the analyst detects any inconsistencies, anomalies or incompleteness in the gathered requirements, he resolves them by carrying out further discussions with the end- users and the customers. 3. Parts of a SRS Document The important parts of SRS document are: Functional requirements of the system Non-functional requirements of the system, and Goals of implementation 3.1.1. Functional Requirements The functional requirements part discusses the functionalities required from the system. The system is considered to perform a set of high- level functions {f}. The functional view of the system is shown in fig. 3.1. Each function fi of the system can be considered as a transformation of a set of input data (ii) to the corresponding set of output data (o). The user can get some meaningful piece of work done using a high-level function. i1 o1 i2 o2 Input.. Output data. data. fi.. in on Fig. 3.1 Vieofsystem performing a set of Function f3.1.2.Non-Functional Requirements Non-functional requirements deal with the characteristics of the system which can not be expressed as functions - such as the maintainability of the system, portability of the system, usability of the system, etc. Non-functional requirements may include: Reliability issues Accuracy of results Human-computer interface issues Constraints on the system implementation, etc. Version 2 EE IIT, Kharagpur 4  ‫اﻟﺘﻌﻘﯿﺪات اﻟﻤﺤﺘﻤﻠﺔ أﺛﻨﺎء ﺣﻞ اﻟﻤﺸﻜﻠﺔ‬ ‫ﻣﺎ ھﻲ اﻟﺘﻌﻘﯿﺪات اﻟﻤﺤﺘﻤﻠﺔ اﻟﺘﻲ ﻗﺪ ﺗﻨﺸﺄ أﺛﻨﺎء ﺣﻞ اﻟﻤﺸﻜﻠﺔ؟‬ ‫إذا ﻛﺎن ھﻨﺎك ﺑﺮاﻣﺞ أو أﺟﮭﺰة ﺧﺎرﺟﯿﺔ ﯾﺠﺐ أن ﯾﺘﻔﺎﻋﻞ ﻣﻌﮭﺎ اﻟﺒﺮﻧﺎﻣﺞ اﻟﻤﻄﻮر‪ ،‬ﻓﻤﺎ ھﻲ ﺑﺎﻟﻀﺒﻂ ﺻﯿﻎ ﺗﺒﺎدل اﻟﺒﯿﺎﻧﺎت ﻣﻊ‬ ‫اﻟﻨﻈﺎم اﻟﺨﺎرﺟﻲ؟‬ ‫ﺑﻌﺪ أن ﯾﻔﮭﻢ اﻟﻤﺤﻠﻞ اﻟﻤﺘﻄﻠﺒﺎت اﻟﺪﻗﯿﻘﺔ ﻟﻠﻌﻤﯿﻞ‪ ،‬ﯾﺘﺎﺑﻊ ﻟﺘﺤﺪﯾﺪ وﺣﻞ اﻟﻤﺸﻜﻼت اﻟﻤﺨﺘﻠﻔﺔ اﻟﻤﺮﺗﺒﻄﺔ ﺑﺎﻟﻤﺘﻄﻠﺒﺎت‪.‬ﻣﻦ أھﻢ‬ ‫اﻟﻤﺸﻜﻼت اﻟﺘﻲ ﯾﺠﺐ ﻋﻠﻰ اﻟﻤﺤﻠﻞ ﺗﺤﺪﯾﺪھﺎ وإزاﻟﺘﮭﺎ ھﻲ ﻣﺸﺎﻛﻞ اﻟﺸﺬوذات‪ ،‬اﻟﺘﻨﺎﻗﻀﺎت‪ ،‬واﻟﻨﻮاﻗﺺ‪.‬ﻋﻨﺪﻣﺎ ﯾﻜﺘﺸﻒ اﻟﻤﺤﻠﻞ‬ ‫أي ﺗﻨﺎﻗﻀﺎت أو ﺷﺬوذات أو ﻧﻘﺺ ﻓﻲ اﻟﻤﺘﻄﻠﺒﺎت اﻟﺘﻲ ﺗﻢ ﺟﻤﻌﮭﺎ‪ ،‬ﻓﺈﻧﮫ ﯾﻘﻮم ﺑﺤﻠﮭﺎ ﻣﻦ ﺧﻼل إﺟﺮاء ﻣﻨﺎﻗﺸﺎت إﺿﺎﻓﯿﺔ ﻣﻊ‬ ‫اﻟﻤﺴﺘﺨﺪﻣﯿﻦ اﻟﻨﮭﺎﺋﯿﯿﻦ واﻟﻌﻤﻼء‪.‬‬ ‫أﺟﺰاء وﺛﯿﻘﺔ ‪SRS‬‬ ‫اﻷﺟﺰاء اﻟﻤﮭﻤﺔ ﻟﻮﺛﯿﻘﺔ ‪SRS‬ھﻲ‪:‬‬ ‫ اﻟﻤﺘﻄﻠﺒﺎت اﻟﻮظﯿﻔﯿﺔ ﻟﻠﻨﻈﺎم‬ ‫ اﻟﻤﺘﻄﻠﺒﺎت ﻏﯿﺮ اﻟﻮظﯿﻔﯿﺔ ﻟﻠﻨﻈﺎم‬ ‫ أھﺪاف اﻟﺘﻨﻔﯿﺬ‬ ‫‪.3.1.1‬اﻟﻤﺘﻄﻠﺒﺎت اﻟﻮظﯿﻔﯿﺔ‬ ‫ﯾﺘﻨﺎول ﺟﺰء اﻟﻤﺘﻄﻠﺒﺎت اﻟﻮظﯿﻔﯿﺔ اﻟﻮظﺎﺋﻒ اﻟﻤﻄﻠﻮﺑﺔ ﻣﻦ اﻟﻨﻈﺎم‪.‬ﯾُﻌﺘﺒﺮ اﻟﻨﻈﺎم أﻧﮫ ﯾﺆدي ﻣﺠﻤﻮﻋﺔ ﻣﻦ اﻟﻮظﺎﺋﻒ ﻋﺎﻟﯿﺔ اﻟﻤﺴﺘﻮى‬ ‫‪f‬ﯾﺘﻢ ﻋﺮض اﻟﺮؤﯾﺔ اﻟﻮظﯿﻔﯿﺔ ﻟﻠﻨﻈﺎم ﻓﻲ اﻟﺸﻜﻞ ‪.3.1‬ﯾﻤﻜﻦ اﻋﺘﺒﺎر ﻛﻞ وظﯿﻔﺔ ‪fi‬ﻣﻦ وظﺎﺋﻒ اﻟﻨﻈﺎم ﻋﻠﻰ أﻧﮭﺎ ﺗﺤﻮﯾﻞ ﻣﺠﻤﻮﻋﺔ‬ ‫ﻣﻦ ﺑﯿﺎﻧﺎت اﻹدﺧﺎل إﻟﻰ ﻣﺠﻤﻮﻋﺔ اﻟﺒﯿﺎﻧﺎت اﻟﻤﻘﺎﺑﻠﺔ اﻟﻨﺎﺗﺠﺔ ﯾﻤﻜﻦ ﻟﻠﻤﺴﺘﺨﺪم إﺗﻤﺎم ﻋﻤﻞ ﻣﻔﯿﺪة ﺑﺎﺳﺘﺨﺪام وظﯿﻔﺔ ﻋﺎﻟﯿﺔ اﻟﻤﺴﺘﻮى‪.‬‬ ‫‪i1‬‬ ‫‪o1‬‬ ‫‪i2‬‬ ‫‪o2‬‬ ‫‪Input‬‬ ‫‪.‬‬ ‫‪.‬‬ ‫‪Output‬‬ ‫‪data‬‬ ‫‪.‬‬ ‫‪fi‬‬ ‫‪.‬‬ ‫‪data‬‬ ‫‪.‬‬ ‫‪.‬‬ ‫‪in‬‬ ‫‪on‬‬ ‫‪Fig. 3.1 Vieofsystem performing a set of Function‬‬ ‫‪.3.1.2‬اﻟﻤﺘﻄﻠﺒﺎت ﻏﯿﺮ اﻟﻮظﯿﻔﯿﺔ‬ ‫ﺗﺗﻧﺎول اﻟﻣﺗطﻠﺑﺎت ﻏﯾر اﻟوظﯾﻔﯾﺔ ﺧﺻﺎﺋص اﻟﻧظﺎم اﻟﺗﻲ ﻻ ﯾﻣﻛن اﻟﺗﻌﺑﯾر ﻋﻧﮭﺎ ﻛوظﺎﺋف‪ ،‬ﻣﺛل ﻗﺎﺑﻠﯾﺔ ﺻﯾﺎﻧﺔ اﻟﻧظﺎم‪،‬‬ ‫وﻗﺎﺑﻠﯾﺔ ﻧﻘل اﻟﻧظﺎم‪ ،‬وﺳﮭوﻟﺔ اﺳﺗﺧدام اﻟﻧظﺎم‪ ،‬وﻣﺎ إﻟﻰ ذﻟك‪.‬‬ ‫ﻗد ﺗﺷﻣل اﻟﻣﺗطﻠﺑﺎت ﻏﯾر اﻟوظﯾﻔﯾﺔ‪:‬‬ ‫‪ -‬ﻗﺿﺎﯾﺎ اﻻﻋﺗﻣﺎدﯾﺔ‬ ‫‪ -‬دﻗﺔ اﻟﻧﺗﺎﺋﺞ‬ ‫‪ -‬ﻗﺿﺎﯾﺎ واﺟﮭﺔ اﻹﻧﺳﺎن ﻣﻊ اﻟﻛﻣﺑﯾوﺗر‬ ‫‪ -‬اﻟﻘﯾود ﻋﻠﻰ ﺗﻧﻔﯾذ اﻟﻧظﺎم‪ ،‬وﻣﺎ إﻟﻰ ذﻟك‬ ‫‪.‬‬ 3.1.3. Goals of Implementation The goals of implementation part documents some general suggestions regarding development. These suggestions guide trade-off among design goals. The goals of implementation section might document issues such as revisions to the system functionalities that may be required in the future, new devices to be supported in the future, reusability issues, etc. These are the items which the developers might keep in their mind during development so that the developed system may meet some aspects that are not required immediately. 3.1.4. Identify Functional Requirements The high-level functional requirements often need to be identified either from an informal problem description document or from a conceptual understanding of the problem. Each high- level requirement characterizes a way of system usage by some user to perform some meaningful piece of work. There can be many types of users of a system and their requirements from the system may be very different. So, it is often useful to identify the different types of users who might use the system and then try to identify the requirements from each user’s perspective. Here we list all functions {fi} that the system performs. Each function fi, as shown in fig. 34.1, is considered as a transformation of a set of input data to some corresponding output data. input output data fi data Example Fig. 3.2 Book Function Consider the case of the library system, where – F1: Search Book function (fig. 34.2) Input: An author’s name Output: Details of the author’s books and the location of these books in the library Author Book name details f1 Fig. 3.2 Book Function So, the function Search Book (F1) takes the author's name and transforms it into book details. Functional requirements actually describe a set of high-level requirements, where each high- level requirement takes some data from the user and provides some data to the user as an output. Also each high-level requirement might consist of several other functions. 3.1.5. Document Functional Requirements For documenting the functional requirements, we need to specify the set of functionalities supported by the system. A function can be specified by identifying the state at which the data is Version 2 EE IIT, Kharagpur 5  ‫أھﺪاف اﻟﺘﻨﻔﯿﺬ‬ ‫ﯾﺘﻨﺎول ﺟﺰء أھﺪاف اﻟﺘﻨﻔﯿﺬ ﺑﻌﺾ اﻻﻗﺘﺮاﺣﺎت اﻟﻌﺎﻣﺔ ﺑﺸﺄن اﻟﺘﻄﻮﯾﺮ‪.‬ﺗﻮﺟﮫ ھﺬه اﻻﻗﺘﺮاﺣﺎت اﺗﺨﺎذ اﻟﻘﺮارات اﻟﻤﺘﻌﻠﻘﺔ ﺑﺎﻟﺘﻮازن ﺑﯿﻦ‬ ‫أھﺪاف اﻟﺘﺼﻤﯿﻢ‪.‬ﻗﺪ ﺗﻮﺛﻖ ﻗﺴﻢ أھﺪاف اﻟﺘﻨﻔﯿﺬ ﻣﺴﺎﺋﻞ ﻣﺜﻞ اﻟﺘﻌﺪﯾﻼت ﻋﻠﻰ وظﺎﺋﻒ اﻟﻨﻈﺎم اﻟﺘﻲ ﻗﺪ ﺗﻜﻮن ﻣﻄﻠﻮﺑﺔ ﻓﻲ اﻟﻤﺴﺘﻘﺒﻞ‪ ،‬أو‬ ‫اﻷﺟﮭﺰة اﻟﺠﺪﯾﺪة اﻟﺘﻲ ﯾﺠﺐ دﻋﻤﮭﺎ ﻓﻲ اﻟﻤﺴﺘﻘﺒﻞ‪ ،‬أو ﻗﻀﺎﯾﺎ اﻟﻘﺎﺑﻠﯿﺔ ﻹﻋﺎدة اﻻﺳﺘﺨﺪام‪ ،‬وﻣﺎ إﻟﻰ ذﻟﻚ‪.‬ھﺬه ھﻲ اﻟﻌﻨﺎﺻﺮ اﻟﺘﻲ ﻗﺪ‬ ‫ﯾﺤﺘﻔﻆ ﺑﮭﺎ اﻟﻤﻄﻮرون ﻓﻲ ذھﻨﮭﻢ أﺛﻨﺎء اﻟﺘﻄﻮﯾﺮ ﺑﺤﯿﺚ ﯾﻤﻜﻦ ﻟﻠﻨﻈﺎم اﻟﻤﻄﻮر ﺗﻠﺒﯿﺔ ﺑﻌﺾ اﻟﺠﻮاﻧﺐ اﻟﺘﻲ ﻗﺪ ﻻ ﺗﻜﻮن ﻣﻄﻠﻮﺑﺔ ﺑﺸﻜﻞ‬ ‫ﻓﻮري‪.‬‬ ‫ﺗﺤﺪﯾﺪ اﻟﻤﺘﻄﻠﺒﺎت اﻟﻮظﯿﻔﯿﺔ‬ ‫ﻏﺎﻟﺒًﺎ ﻣﺎ ﯾﺤﺘﺎج ﺗﺤﺪﯾﺪ اﻟﻤﺘﻄﻠﺒﺎت اﻟﻮظﯿﻔﯿﺔ ﻋﺎﻟﯿﺔ اﻟﻤﺴﺘﻮى إﻟﻰ أن ﯾﺘﻢ اﺳﺘﻨﺒﺎطﮭﺎ إﻣﺎ ﻣﻦ وﺛﯿﻘﺔ وﺻﻒ اﻟﻤﺸﻜﻠﺔ ﻏﯿﺮ اﻟﺮﺳﻤﯿﺔ أو ﻣﻦ‬ ‫اﻟﻔﮭﻢ اﻟﺘﺼﻮري ﻟﻠﻤﺸﻜﻠﺔ‪.‬ﻛﻞ ﻣﺘﻄﻠﺐ ﻋﺎﻟﻲ اﻟﻤﺴﺘﻮى ﯾﻤﯿﺰ طﺮﯾﻘﺔ اﺳﺘﺨﺪام اﻟﻨﻈﺎم ﻣﻦ ﻗﺒﻞ ﺑﻌﺾ اﻟﻤﺴﺘﺨﺪﻣﯿﻦ ﻷداء ﻋﻤﻞ ذي‬ ‫ﻣﻌﻨﻰ‪.‬ﯾﻤﻜﻦ أن ﯾﻜﻮن ھﻨﺎك اﻟﻌﺪﯾﺪ ﻣﻦ أﻧﻮاع اﻟﻤﺴﺘﺨﺪﻣﯿﻦ ﻟﻠﻨﻈﺎم وﻗﺪ ﺗﻜﻮن ﻣﺘﻄﻠﺒﺎﺗﮭﻢ ﻣﻦ اﻟﻨﻈﺎم ﻣﺨﺘﻠﻔﺔ ﺟﺪًا‪.‬ﻟﺬﻟﻚ‪ ،‬ﻣﻦ اﻟﻤﻔﯿﺪ ﻏﺎﻟﺒًﺎ‬ ‫ﺗﺤﺪﯾﺪ اﻷﻧﻮاع اﻟﻤﺨﺘﻠﻔﺔ ﻟﻠﻤﺴﺘﺨﺪﻣﯿﻦ اﻟﺬﯾﻦ ﻗﺪ ﯾﺴﺘﺨﺪﻣﻮن اﻟﻨﻈﺎم‪ ،‬ﺛﻢ ﻣﺤﺎوﻟﺔ ﺗﺤﺪﯾﺪ اﻟﻤﺘﻄﻠﺒﺎت ﻣﻦ ﻣﻨﻈﻮر ﻛﻞ ﻣﺴﺘﺨﺪم‪.‬‬ ‫ھﻨﺎ‪ ،‬ﻧﻘﻮم ﺑﺈدراج ﺟﻤﯿﻊ اﻟﻮظﺎﺋﻒ ‪fi‬اﻟﺘﻲ ﯾﺆدﯾﮭﺎ اﻟﻨﻈﺎم‪.‬ﯾﺘﻢ اﻋﺘﺒﺎر ﻛﻞ وظﯿﻔﺔ ‪ ،fi‬ﻛﻤﺎ ھﻮ ﻣﻮﺿﺢ ﻓﻲ اﻟﺸﻜﻞ ‪ ،34.1‬ﻋﻠﻰ أﻧﮭﺎ‬ ‫ﺗﺤﻮﯾﻞ ﻣﺠﻤﻮﻋﺔ ﻣﻦ ﺑﯿﺎﻧﺎت اﻹدﺧﺎل إﻟﻰ ﺑﻌﺾ ﺑﯿﺎﻧﺎت اﻹﺧﺮاج اﻟﻤﻘﺎﺑﻠﺔ‪.‬‬ ‫‪input‬‬ ‫‪output‬‬ ‫‪f1‬‬ ‫‪Fig. 3.2 Book Function‬‬ ‫‪Example‬‬ ‫اﻋﺘﺒﺎر ﺣﺎﻟﺔ ﻧﻈﺎم اﻟﻤﻜﺘﺒﺔ‪ ،‬ﺣﯿﺚ‬ ‫‪F1:‬وظﯿﻔﺔ اﻟﺒﺤﺚ ﻋﻦ اﻟﻜﺘﺎب )اﻟﺸﻜﻞ ‪(34.2‬‬ ‫اﻹدﺧﺎل‪ :‬اﺳﻢ اﻟﻤﺆﻟﻒ‬ ‫اﻹﺧﺮاج‪ :‬ﺗﻔﺎﺻﯿﻞ ﻛﺘﺐ اﻟﻤﺆﻟﻒ وﻣﻮﻗﻊ ھﺬه اﻟﻜﺘﺐ ﻓﻲ اﻟﻤﻜﺘﺒﺔ‬ ‫‪Author‬‬ ‫‪Book‬‬ ‫‪name‬‬ ‫‪details‬‬ ‫‪f1‬‬ ‫‪Fig. 3.2 Book Function‬‬ ‫إذن‪ ،‬ﺗﻘﻮم وظﯿﻔﺔ اﻟﺒﺤﺚ ﻋﻦ اﻟﻜﺘﺎب ) )‪F1‬ﺑﺄﺧﺬ اﺳﻢ اﻟﻤﺆﻟﻒ وﺗﺤﻮﯾﻠﮫ إﻟﻰ ﺗﻔﺎﺻﯿﻞ اﻟﻜﺘﺎب‪.‬‬ ‫ﺗﺼﻒ اﻟﻤﺘﻄﻠﺒﺎت اﻟﻮظﯿﻔﯿﺔ ﻓﻲ اﻟﻮاﻗﻊ ﻣﺠﻤﻮﻋﺔ ﻣﻦ اﻟﻤﺘﻄﻠﺒﺎت ﻋﺎﻟﯿﺔ اﻟﻤﺴﺘﻮى‪ ،‬ﺣﯿﺚ ﯾﺄﺧﺬ ﻛﻞ ﻣﺘﻄﻠﺐ ﻋﺎﻟﻲ‬ ‫اﻟﻤﺴﺘﻮى ﺑﻌﺾ اﻟﺒﯿﺎﻧﺎت ﻣﻦ اﻟﻤﺴﺘﺨﺪم وﯾﻘﺪم ﺑﻌﺾ اﻟﺒﯿﺎﻧﺎت ﻟﻠﻤﺴﺘﺨﺪم ﻛﺈﺧﺮاج‪.‬ﻛﻤﺎ أن ﻛﻞ ﻣﺘﻄﻠﺐ ﻋﺎﻟﻲ‬ ‫اﻟﻤﺴﺘﻮى ﻗﺪ ﯾﺘﻜﻮن ﻣﻦ ﻋﺪة وظﺎﺋﻒ أﺧﺮى‪.‬‬ ‫‪.3.1.5‬ﺗﻮﺛﯿﻖ اﻟﻤﺘﻄﻠﺒﺎت اﻟﻮظﯿﻔﯿﺔ‬ ‫ﻟﺘﻮﺛﯿﻖ اﻟﻤﺘﻄﻠﺒﺎت اﻟﻮظﯿﻔﯿﺔ‪ ،‬ﻧﺤﺘﺎج إﻟﻰ ﺗﺤﺪﯾﺪ ﻣﺠﻤﻮﻋﺔ اﻟﻮظﺎﺋﻒ اﻟﻤﺪﻋﻮﻣﺔ ﻣﻦ ﻗﺒﻞ اﻟﻨﻈﺎم‪.‬ﯾﻤﻜﻦ ﺗﺤﺪﯾﺪ وظﯿﻔﺔ‬ ‫ﻣﻦ ﺧﻼل ﺗﺤﺪﯾﺪ اﻟﺤﺎﻟﺔ اﻟﺘﻲ ﺗﻜﻮن ﻓﯿﮭﺎ اﻟﺒﯿﺎﻧﺎت‪.‬‬ to be input to the system, its input data domain, the output data domain, and the type of processing to be carried on the input data to obtain the output data. Let us first try to document the withdraw-cash function of an ATM (Automated Teller Machine) system. The withdraw-cash is a high-level requirement. It has several sub-requirements corresponding to the different user interactions. These different interaction sequences capture the different scenarios. Example: Withdraw Cash from ATM R1: withdraw cash Description: The withdraw cash function first determines the type of account that the user has and the account number from which the user wishes to withdraw cash. It checks the balance to determine whether the requested amount is available in the account. If enough balance is available, it outputs the required cash, otherwise it generates an error message. R1.1: select withdraw amount option Input: “withdraw amount” option Output: user prompted to enter the account type R1.2: select account type Input: user option Output: prompt to enter amount R1.3: get required amount Input: amount to be withdrawn in integer values greater than 100 and less than 10,000 in multiples of 100. Output: The requested cash and printed transaction statement. Processing: the amount is debited from the user’s account if sufficient balance is available, otherwise an error message displayed. 3.1.6. Properties of a Good SRS Document The important properties of a good SRS document are the following: Concise: The SRS document should be concise and at the same time unambiguous, consistent, and complete. Verbose and irrelevant descriptions reduce readability and also increase error possibilities. Structured: It should be well-structured. A well-structured document is easy to understand and modify. In practice, the SRS document undergoes several revisions to cope up with the customer requirements. Often, the customer requirements evolve over a period of time. Therefore, in order to make the modifications to the SRS document easy, it is important to make the document well- structured. Black-box view: It should only specify what the system should do and refrain from stating how to do these. This means that the SRS document should specify the external behaviour of the system and not discuss the implementation issues. The SRS document should view the system to be developed as black box, and should specify the externally visible behaviour of the system. For this reason, the SRS document is also called the black-box specification of a system. Conceptual integrity: It should show conceptual integrity so that the reader can easily understand it. Version 2 EE IIT, Kharagpur 6  ‫ﻟﺘﻜﻮن اﻟﺒﯿﺎﻧﺎت اﻟﻤﺪﺧﻠﺔ ﻟﻠﻨﻈﺎم‪ ،‬ﯾﺠﺐ ﺗﺤﺪﯾﺪ ﻣﺠﺎل ﺑﯿﺎﻧﺎت اﻹدﺧﺎل‪ ،‬ﻣﺠﺎل ﺑﯿﺎﻧﺎت اﻹﺧﺮاج‪ ،‬وﻧﻮع اﻟﻤﻌﺎﻟﺠﺔ اﻟﺘﻲ ﺳﺘﺘﻢ ﻋﻠﻰ ﺑﯿﺎﻧﺎت‬ ‫اﻹدﺧﺎل ﻟﻠﺤﺼﻮل ﻋﻠﻰ ﺑﯿﺎﻧﺎت اﻹﺧﺮاج‪.‬دﻋﻮﻧﺎ أوﻻً ﻧﺤﺎول ﺗﻮﺛﯿﻖ وظﯿﻔﺔ ﺳﺤﺐ اﻟﻨﻘﻮد ﻣﻦ ﺟﮭﺎز اﻟﺼﺮاف اﻵﻟﻲ ) ‪ATM).‬وظﯿﻔﺔ‬ ‫ﺳﺤﺐ اﻟﻨﻘﻮد ھﻲ ﻣﺘﻄﻠﺐ ﻋﺎﻟﻲ اﻟﻤﺴﺘﻮى‪.‬وﻟﮭﺎ ﻋﺪة ﻣﺘﻄﻠﺒﺎت ﻓﺮﻋﯿﺔ ﺗﺘﻌﻠﻖ ﺑﺘﻔﺎﻋﻼت اﻟﻤﺴﺘﺨﺪم اﻟﻤﺨﺘﻠﻔﺔ‪.‬ھﺬه اﻟﺘﻔﺎﻋﻼت اﻟﻤﺨﺘﻠﻔﺔ‬ ‫ﺗﻤﺜﻞ اﻟﺴﯿﻨﺎرﯾﻮھﺎت اﻟﻤﺨﺘﻠﻔﺔ‪.‬‬ ‫ﻣﺜﺎل‪ :‬ﺳﺤﺐ اﻟﻨﻘﻮد ﻣﻦ ﺟﮭﺎز اﻟﺼﺮاف اﻵﻟﻲ‬ ‫‪R1:‬ﺳﺤﺐ اﻟﻨﻘﻮد‬ ‫اﻟﻮﺻﻒ‪ :‬وظﯿﻔﺔ ﺳﺤﺐ اﻟﻨﻘﻮد ﺗﺤﺪد أوﻻً ﻧﻮع اﻟﺤﺴﺎب اﻟﺬي ﯾﻤﺘﻠﻜﮫ اﻟﻤﺴﺘﺨﺪم ورﻗﻢ اﻟﺤﺴﺎب اﻟﺬي ﯾﺮﻏﺐ اﻟﻤﺴﺘﺨﺪم ﻓﻲ ﺳﺤﺐ‬ ‫اﻟﻨﻘﻮد ﻣﻨﮫ‪.‬ﺗﻘﻮم ﺑﺎﻟﺘﺤﻘﻖ ﻣﻦ اﻟﺮﺻﯿﺪ ﻟﺘﺤﺪﯾﺪ ﻣﺎ إذا ﻛﺎن اﻟﻤﺒﻠﻎ اﻟﻤﻄﻠﻮب ﻣﺘﺎ ًﺣﺎ ﻓﻲ اﻟﺤﺴﺎب‪.‬إذا ﻛﺎن اﻟﺮﺻﯿﺪ ﻛﺎﻓﯿًﺎ‪ ،‬ﺗﻘﻮم ﺑﺈﺧﺮاج‬ ‫اﻟﻤﺒﻠﻎ اﻟﻤﻄﻠﻮب‪ ،‬وإﻻ ﯾﺘﻢ ﻋﺮض رﺳﺎﻟﺔ ﺧﻄﺄ‪.‬‬ ‫‪R1.1:‬اﺧﺘﯿﺎر ﺧﯿﺎر ﺳﺤﺐ اﻟﻤﺒﻠﻎ‬ ‫اﻹدﺧﺎل‪ :‬ﺧﯿﺎر "ﺳﺤﺐ اﻟﻤﺒﻠﻎ"‬ ‫اﻹﺧﺮاج‪ :‬ﯾﻄﻠﺐ ﻣﻦ اﻟﻤﺴﺘﺨﺪم إدﺧﺎل ﻧﻮع اﻟﺤﺴﺎب‬ ‫‪R1.2:‬اﺧﺘﯿﺎر ﻧﻮع اﻟﺤﺴﺎب‬ ‫اﻹدﺧﺎل‪ :‬ﺧﯿﺎر اﻟﻤﺴﺘﺨﺪم‬ ‫اﻹﺧﺮاج‪ :‬ﯾﻄﻠﺐ ﻣﻦ اﻟﻤﺴﺘﺨﺪم إدﺧﺎل اﻟﻤﺒﻠﻎ‬ ‫‪R1.3:‬اﻟﺤﺼﻮل ﻋﻠﻰ اﻟﻤﺒﻠﻎ اﻟﻤﻄﻠﻮب‬ ‫اﻹدﺧﺎل‪ :‬اﻟﻤﺒﻠﻎ اﻟﻤﺮاد ﺳﺤﺒﮫ ﺑﺎﻟﻘﯿﻢ اﻟﺼﺤﯿﺤﺔ اﻟﺘﻲ ﺗﺰﯾﺪ ﻋﻦ ‪ 100‬وأﻗﻞ ﻣﻦ ‪ 10,000‬وﺑﻤﻀﺎﻋﻔﺎت ‪.100‬‬ ‫اﻹﺧﺮاج‪ :‬اﻟﻨﻘﻮد اﻟﻤﻄﻠﻮﺑﺔ وﺑﯿﺎن اﻟﻤﻌﺎﻣﻠﺔ اﻟﻤﻄﺒﻮﻋﺔ‪.‬‬ ‫اﻟﻤﻌﺎﻟﺠﺔ‪ :‬ﯾﺘﻢ ﺧﺼﻢ اﻟﻤﺒﻠﻎ ﻣﻦ ﺣﺴﺎب اﻟﻤﺴﺘﺨﺪم إذا ﻛﺎن اﻟﺮﺻﯿﺪ ﻛﺎﻓﯿًﺎ‪ ،‬وإﻻ ﯾﺘﻢ ﻋﺮض رﺳﺎﻟﺔ ﺧﻄﺄ‪.‬‬ ‫‪.3.1.6‬ﺧﺼﺎﺋﺺ وﺛﯿﻘﺔ ‪SRS‬ﺟﯿﺪة‬ ‫اﻟﺨﺼﺎﺋﺺ اﻟﻤﮭﻤﺔ ﻟﻮﺛﯿﻘﺔ ‪SRS‬ﺟﯿﺪة ھﻲ ﻛﻤﺎ ﯾﻠﻲ‪:‬‬ ‫‪.1‬ﻣﻮﺟﺰة‪ :‬ﯾﺠﺐ أن ﺗﻜﻮن وﺛﯿﻘﺔ ‪SRS‬ﻣﻮﺟﺰة وﻓﻲ ﻧﻔﺲ اﻟﻮﻗﺖ ﻏﯿﺮ ﻏﺎﻣﻀﺔ‪ ،‬وﻣﺘﺴﻘﺔ‪ ،‬وﻛﺎﻣﻠﺔ‪.‬اﻷوﺻﺎف اﻟﻤﻔﺮطﺔ وﻏﯿﺮ ذات‬ ‫اﻟﺼﻠﺔ ﺗﻘﻠﻞ ﻣﻦ ﻗﺎﺑﻠﯿﺔ اﻟﻘﺮاءة وﺗﺰﯾﺪ أﯾﻀًﺎ ﻣﻦ اﺣﺘﻤﺎﻟﯿﺔ اﻷﺧﻄﺎء‪.‬‬ ‫‪.2‬ﻣﻨﻈﻤﺔ‪ :‬ﯾﺠﺐ أن ﺗﻜﻮن ﻣﻨﻈﻤﺔ ﺑﺸﻜﻞ ﺟﯿﺪ‪.‬اﻟﻮﺛﯿﻘﺔ اﻟﻤﻨﻈﻤﺔ ﺑﺸﻜﻞ ﺟﯿﺪ ﺳﮭﻠﺔ اﻟﻔﮭﻢ واﻟﺘﻌﺪﯾﻞ‪.‬ﻓﻲ اﻟﻮاﻗﻊ‪ ،‬ﺗﺨﻀﻊ وﺛﯿﻘﺔ ‪SRS‬‬ ‫ﻟﻠﻌﺪﯾﺪ ﻣﻦ اﻟﺘﻌﺪﯾﻼت ﻟﺘﺘﻨﺎﺳﺐ ﻣﻊ ﻣﺘﻄﻠﺒﺎت اﻟﻌﻤﯿﻞ‪.‬ﻓﻲ ﻛﺜﯿﺮ ﻣﻦ اﻷﺣﯿﺎن‪ ،‬ﺗﺘﻄﻮر ﻣﺘﻄﻠﺒﺎت اﻟﻌﻤﯿﻞ ﻋﻠﻰ ﻣﺪى ﻓﺘﺮة ﻣﻦ اﻟﺰﻣﻦ‪.‬‬ ‫ﻟﺬﻟﻚ‪ ،‬ﻣﻦ أﺟﻞ ﺟﻌﻞ اﻟﺘﻌﺪﯾﻼت ﻋﻠﻰ وﺛﯿﻘﺔ ‪SRS‬ﺳﮭﻠﺔ‪ ،‬ﻣﻦ اﻟﻤﮭﻢ أن ﺗﻜﻮن اﻟﻮﺛﯿﻘﺔ ﻣﻨﻈﻤﺔ ﺑﺸﻜﻞ ﺟﯿﺪ‪.‬‬ ‫‪.3‬رؤﯾﺔ اﻟﺼﻨﺪوق اﻷﺳﻮد‪ :‬ﯾﺠﺐ أن ﺗﺤﺪد اﻟﻮﺛﯿﻘﺔ ﻣﺎ ﯾﺠﺐ أن ﯾﻔﻌﻠﮫ اﻟﻨﻈﺎم ﻓﻘﻂ وﺗﺠﻨﺐ ﺗﺤﺪﯾﺪ ﻛﯿﻔﯿﺔ اﻟﻘﯿﺎم ﺑﺬﻟﻚ‪.‬وھﺬا ﯾﻌﻨﻲ أن‬ ‫وﺛﯿﻘﺔ ‪SRS‬ﯾﺠﺐ أن ﺗﺤﺪد اﻟﺴﻠﻮك اﻟﺨﺎرﺟﻲ ﻟﻠﻨﻈﺎم وأﻻ ﺗﻨﺎﻗﺶ ﻗﻀﺎﯾﺎ اﻟﺘﻨﻔﯿﺬ‪.‬ﯾﺠﺐ أن ﺗﻨﻈﺮ وﺛﯿﻘﺔ ‪SRS‬إﻟﻰ اﻟﻨﻈﺎم اﻟﺬي ﺳﯿﺘﻢ‬ ‫ﺗﻄﻮﯾﺮه ﻛﺼﻨﺪوق أﺳﻮد‪ ،‬وﯾﺠﺐ أن ﺗﺤﺪد اﻟﺴﻠﻮك اﻟﻤﺮﺋﻲ ﺧﺎرﺟﯿًﺎ ﻟﻠﻨﻈﺎم‪.‬ﻟﮭﺬا اﻟﺴﺒﺐ‪ ،‬ﺗُﺴﻤﻰ وﺛﯿﻘﺔ ‪SRS‬أﯾﻀًﺎ اﻟﻤﻮاﺻﻔﺔ ذات‬ ‫اﻟﺼﻨﺪوق اﻷﺳﻮد ﻟﻠﻨﻈﺎم‪.‬‬ ‫ً‬ ‫ﺗﻤﺎﺛﻼ ﻣﻔﮭﻮﻣﯿًﺎ ﺑﺤﯿﺚ ﯾﻤﻜﻦ ﻟﻠﻘﺎرئ ﻓﮭﻤﮭﺎ ﺑﺴﮭﻮﻟﺔ‪.‬‬ ‫‪.4‬اﻟﺘﻤﺎﺛﻞ اﻟﻤﻔﮭﻮﻣﻲ‪ :‬ﯾﺠﺐ أن ﺗﻈﮭﺮ اﻟﻮﺛﯿﻘﺔ‬ Response to undesired events: It should characterize acceptable responses to undesired events. These are called system response to exceptional conditions. Verifiable: All requirements of the system as documented in the SRS document should be verifiable. This means that it should be possible to determine whether or not requirements have been met in an implementation. 3.1.7. Problems without a SRS Document The important problems that an organization would face if it does not develop an SRS document are as follows: Without developing the SRS document, the system would not be implemented according to customer needs. Software developers would not know whether what they are developing is what exactly is required by the customer. Without SRS document, it will be very difficult for the maintenance engineers to understand the functionality of the system. It will be very difficult for user document writers to write the users’ manuals properly without understanding the SRS document. 3.1.8. Identify Non-Functional Requirements Nonfunctional requirements are the characteristics of the system which can not be expressed as functions - such as the maintainability of the system, portability of the system, usability of the system, etc. Non-functional requirements may include: Reliability issues Performance issues Human - computer interface issues Interface with other external systems Security and maintainability of the system, etc. 3.1.9. Problems with An Unstructured Specification It would be very difficult to understand that document. It would be very difficult to modify that document. Conceptual integrity in that document would not be shown. The SRS document might be ambiguous and inconsistent. Version 2 EE IIT, Kharagpur 7  ‫اﻻﺳﺘﺠﺎﺑﺔ ﻟﻸﺣﺪاث ﻏﯿﺮ اﻟﻤﺮﻏﻮب ﻓﯿﮭﺎ‪:‬‬ ‫ﯾﺠﺐ أن ﺗﺤﺪد اﻟﻮﺛﯿﻘﺔ اﻻﺳﺘﺠﺎﺑﺎت اﻟﻤﻘﺒﻮﻟﺔ ﻟﻸﺣﺪاث ﻏﯿﺮ اﻟﻤﺮﻏﻮب ﻓﯿﮭﺎ‪.‬ﺗُﺴﻤﻰ ھﺬه اﻻﺳﺘﺠﺎﺑﺎت اﺳﺘﺠﺎﺑﺔ اﻟﻨﻈﺎم ﻟﻠﺤﺎﻻت‬ ‫اﻻﺳﺘﺜﻨﺎﺋﯿﺔ‪.‬‬ ‫ﻗﺎﺑﻠﯿﺔ اﻟﺘﺤﻘﻖ‪:‬‬ ‫ﯾﺠﺐ أن ﺗﻜﻮن ﺟﻤﯿﻊ ﻣﺘﻄﻠﺒﺎت اﻟﻨﻈﺎم ﻛﻤﺎ ھﻲ ﻣﻮﺛﻘﺔ ﻓﻲ وﺛﯿﻘﺔ ‪SRS‬ﻗﺎﺑﻠﺔ ﻟﻠﺘﺤﻘﻖ‪.‬وھﺬا ﯾﻌﻨﻲ أﻧﮫ ﯾﺠﺐ أن ﯾﻜﻮن ﻣﻦ اﻟﻤﻤﻜﻦ ﺗﺤﺪﯾﺪ‬ ‫ﻣﺎ إذا ﻛﺎﻧﺖ اﻟﻤﺘﻄﻠﺒﺎت ﻗﺪ ﺗﻢ اﻟﻮﻓﺎء ﺑﮭﺎ ﻓﻲ اﻟﺘﻨﻔﯿﺬ أم ﻻ‪.‬‬ ‫اﻟﻤﺸﺎﻛﻞ اﻟﺘﻲ ﻗﺪ ﺗﻨﺸﺄ ﺑﺪون وﺛﯿﻘﺔ ‪SRS‬‬ ‫اﻟﻤﺸﺎﻛﻞ اﻟﻤﮭﻤﺔ اﻟﺘﻲ ﻗﺪ ﺗﻮاﺟﮭﮭﺎ اﻟﻤﻨﻈﻤﺔ إذا ﻟﻢ ﺗﻘﻢ ﺑﺘﻄﻮﯾﺮ وﺛﯿﻘﺔ ‪SRS‬ھﻲ ﻛﻤﺎ ﯾﻠﻲ‪:‬‬ ‫‪.1‬ﺑﺪون ﺗﻄﻮﯾﺮ وﺛﯿﻘﺔ ‪ ،SRS‬ﻟﻦ ﯾﺘﻢ ﺗﻨﻔﯿﺬ اﻟﻨﻈﺎم وﻓﻘًﺎ ﻻﺣﺘﯿﺎﺟﺎت اﻟﻌﻤﯿﻞ‪.‬‬ ‫‪.2‬ﻟﻦ ﯾﻌﺮف ﻣﻄﻮرو اﻟﺒﺮﻣﺠﯿﺎت ﻣﺎ إذا ﻛﺎﻧﻮا ﯾﻘﻮﻣﻮن ﺑﺘﻄﻮﯾﺮ ﻣﺎ ھﻮ ﻣﻄﻠﻮب ﺑﺎﻟﻀﺒﻂ ﻣﻦ ﻗﺒﻞ اﻟﻌﻤﯿﻞ‪.‬‬ ‫‪.3‬ﺑﺪون وﺛﯿﻘﺔ ‪ ،SRS‬ﺳﯿﻜﻮن ﻣﻦ اﻟﺼﻌﺐ ﻟﻠﻐﺎﯾﺔ ﻋﻠﻰ ﻣﮭﻨﺪﺳﻲ اﻟﺼﯿﺎﻧﺔ ﻓﮭﻢ وظﺎﺋﻒ اﻟﻨﻈﺎم‪.‬‬ ‫‪.4‬ﺳﯿﻜﻮن ﻣﻦ اﻟﺼﻌﺐ ﺟﺪًا ﻋﻠﻰ ﻛﺘّﺎب اﻟﻮﺛﺎﺋﻖ اﻟﺨﺎﺻﺔ ﺑﺎﻟﻤﺴﺘﺨﺪﻣﯿﻦ ﻛﺘﺎﺑﺔ أدﻟﺔ اﻟﻤﺴﺘﺨﺪﻣﯿﻦ ﺑﺸﻜﻞ ﺻﺤﯿﺢ دون ﻓﮭﻢ وﺛﯿﻘﺔ ‪SRS.‬‬ ‫ﺗﺤﺪﯾﺪ اﻟﻤﺘﻄﻠﺒﺎت ﻏﯿﺮ اﻟﻮظﯿﻔﯿﺔ‬ ‫اﻟﻤﺘﻄﻠﺒﺎت ﻏﯿﺮ اﻟﻮظﯿﻔﯿﺔ ھﻲ ﺧﺼﺎﺋﺺ اﻟﻨﻈﺎم اﻟﺘﻲ ﻻ ﯾﻤﻜﻦ اﻟﺘﻌﺒﯿﺮ ﻋﻨﮭﺎ ﻛﻮظﺎﺋﻒ‪ ،‬ﻣﺜﻞ ﻗﺎﺑﻠﯿﺔ ﺻﯿﺎﻧﺔ اﻟﻨﻈﺎم‪ ،‬وﻗﺎﺑﻠﯿﺔ ﻧﻘﻞ‬ ‫اﻟﻨﻈﺎم‪ ،‬وﺳﮭﻮﻟﺔ اﺳﺘﺨﺪام اﻟﻨﻈﺎم‪ ،‬وﻣﺎ إﻟﻰ ذﻟﻚ‪.‬‬ ‫ﻗﺪ ﺗﺸﻤﻞ اﻟﻤﺘﻄﻠﺒﺎت ﻏﯿﺮ اﻟﻮظﯿﻔﯿﺔ‪:‬‬ ‫‪ -‬ﻗﻀﺎﯾﺎ اﻻﻋﺘﻤﺎدﯾﺔ‬ ‫‪ -‬ﻗﻀﺎﯾﺎ اﻷداء‬ ‫‪ -‬ﻗﻀﺎﯾﺎ واﺟﮭﺔ اﻹﻧﺴﺎن ﻣﻊ اﻟﻜﻤﺒﯿﻮﺗﺮ‬ ‫‪ -‬اﻟﺘﻔﺎﻋﻞ ﻣﻊ اﻷﻧﻈﻤﺔ اﻟﺨﺎرﺟﯿﺔ اﻷﺧﺮى‬ ‫‪ -‬اﻷﻣﺎن وﻗﺎﺑﻠﯿﺔ ﺻﯿﺎﻧﺔ اﻟﻨﻈﺎم‪ ،‬وﻣﺎ إﻟﻰ ذﻟﻚ‪.‬‬ ‫اﻟﻤﺸﺎﻛﻞ اﻟﻨﺎﺗﺠﺔ ﻋﻦ اﻟﻤﻮاﺻﻔﺔ ﻏﯿﺮ اﻟﻤﻨﻈﻤﺔ‬ ‫‪ -‬ﺳﯿﻜﻮن ﻣﻦ اﻟﺼﻌﺐ ﺟﺪًا ﻓﮭﻢ ﺗﻠﻚ اﻟﻮﺛﯿﻘﺔ‪.‬‬ ‫‪ -‬ﺳﯿﻜﻮن ﻣﻦ اﻟﺼﻌﺐ ﺟﺪًا ﺗﻌﺪﯾﻞ ﺗﻠﻚ اﻟﻮﺛﯿﻘﺔ‪.‬‬ ‫‪ -‬ﻟﻦ ﯾﺘﻢ إظﮭﺎر اﻟﺘﻤﺎﺳﻚ اﻟﻤﻔﮭﻮﻣﻲ ﻓﻲ ﺗﻠﻚ اﻟﻮﺛﯿﻘﺔ‪.‬‬ ‫‪ -‬ﻗﺪ ﺗﻜﻮن وﺛﯿﻘﺔ ‪SRS‬ﻏﺎﻣﻀﺔ وﻏﯿﺮ ﻣﺘﺴﻘﺔ‪.‬‬ ‫‪Version 2 EE IIT, Kharagpur‬‬ ‫‪7‬‬  1. Decision Trees A decision tree gives a graphic view of the processing logic involved in decision making and the corresponding actions taken. The edges of a decision tree represent conditions and the leaf nodes represent the actions to be performed depending on the outcome of testing the condition. Example Consider Library Membership Automation Software (LMS) where it should support the following three options: New member Renewal Cancel membership New member option Decision: When the 'new member' option is selected, the software asks details about the member like member's name, address, phone number etc. Action: If proper information is entered, then a membership record for the member is created and a bill is printed for the annual membership charge plus the security deposit payable. Renewal option Decision: If the 'renewal' option is chosen, the LMS asks for the member's name and his membership number to check whether he is a valid member or not. Action: If the membership is valid then membership expiry date is updated and the annual membership bill is printed, otherwise an error message is displayed. Cancel membership option Decision: If the 'cancel membership' option is selected, then the software asks for member's name and his membership number. Action: The membership is cancelled, a cheque for the balance amount due to the member is printed and finally the membership record is deleted from the database. Decision tree representation of the above example The following tree (fig. 34.3) shows the graphical representation of the above example. After getting information from the user, the system makes a decision and then performs the corresponding actions. Version 2 EE IIT, Kharagpur 8  ‫‪.1‬أﺷﺠﺎر اﻟﻘﺮار‬ ‫ﺷﺠﺮة اﻟﻘﺮار ﺗﻮﻓﺮ رؤﯾﺔ رﺳﻮﻣﯿﺔ ﻟﻠﻤﻨﻄﻖ اﻟﻤﻌﺎﻟﺞ اﻟﻤﺘﻌﻠﻖ ﺑﺎﺗﺨﺎذ اﻟﻘﺮار واﻹﺟﺮاءات اﻟﻤﺘﺨﺬة ﺑﻨﺎ ًء ﻋﻠﻰ ذﻟﻚ‪.‬ﺗﻤﺜﻞ اﻟﺤﻮاف‬ ‫ﻓﻲ ﺷﺠﺮة اﻟﻘﺮار اﻟﺸﺮوط‪ ،‬ﺑﯿﻨﻤﺎ ﺗﻤﺜﻞ اﻟﻌﻘﺪ اﻟﻮرﻗﯿﺔ ‪leaf nodes‬اﻹﺟﺮاءات اﻟﺘﻲ ﯾﺘﻢ ﺗﻨﻔﯿﺬھﺎ ﺑﻨﺎ ًء ﻋﻠﻰ ﻧﺘﯿﺠﺔ اﺧﺘﺒﺎر‬ ‫اﻟﺸﺮط‪.‬‬ ‫ﻣﺜﺎل‬ ‫اﻓﺘﺮض وﺟﻮد ﺑﺮﻧﺎﻣﺞ أﺗﻤﺘﺔ اﻟﻌﻀﻮﯾﺔ ﻓﻲ اﻟﻤﻜﺘﺒﺔ ‪LMS‬ﺣﯿﺚ ﯾﺠﺐ أن ﯾﺪﻋﻢ اﻟﺨﯿﺎرات اﻟﺘﺎﻟﯿﺔ‪:‬‬ ‫‪ -‬ﻋﻀﻮ ﺟﺪﯾﺪ‬ ‫‪ -‬ﺗﺠﺪﯾﺪ اﻟﻌﻀﻮﯾﺔ‬ ‫‪ -‬إﻟﻐﺎء اﻟﻌﻀﻮﯾﺔ‬ ‫ﺧﯿﺎر اﻟﻌﻀﻮ اﻟﺠﺪﯾﺪ‬ ‫اﻟﻘﺮار‪ :‬ﻋﻨﺪﻣﺎ ﯾﺘﻢ اﺧﺘﯿﺎر ﺧﯿﺎر "ﻋﻀﻮ ﺟﺪﯾﺪ"‪ ،‬ﯾﻄﻠﺐ اﻟﺒﺮﻧﺎﻣﺞ ﺗﻔﺎﺻﯿﻞ ﻋﻦ اﻟﻌﻀﻮ ﻣﺜﻞ اﺳﻢ اﻟﻌﻀﻮ‪ ،‬اﻟﻌﻨﻮان‪ ،‬رﻗﻢ اﻟﮭﺎﺗﻒ‪،‬‬ ‫وﻣﺎ إﻟﻰ ذﻟﻚ‪.‬‬ ‫اﻹﺟﺮاء‪ :‬إذا ﺗﻢ إدﺧﺎل اﻟﻤﻌﻠﻮﻣﺎت اﻟﺼﺤﯿﺤﺔ‪ ،‬ﯾﺘﻢ إﻧﺸﺎء ﺳﺠﻞ ﻋﻀﻮﯾﺔ ﻟﻠﻌﻀﻮ وﯾﺘﻢ طﺒﺎﻋﺔ ﻓﺎﺗﻮرة ﻟﺮﺳﻮم اﻟﻌﻀﻮﯾﺔ اﻟﺴﻨﻮﯾﺔ‬ ‫ﺑﺎﻹﺿﺎﻓﺔ إﻟﻰ اﻟﻮدﯾﻌﺔ اﻷﻣﻨﯿﺔ اﻟﻤﺴﺘﺤﻘﺔ اﻟﺪﻓﻊ‪.‬‬ ‫ﺧﯿﺎراﻟﺘﺠﺪﯾﺪ‬ ‫ااﻟﻘﺮار‪ :‬إذا ﺗﻢ اﺧﺘﯿﺎر ﺧﯿﺎر "ﺗﺠﺪﯾﺪ"‪ ،‬ﯾﻄﻠﺐ اﻟﺒﺮﻧﺎﻣﺞ اﺳﻢ اﻟﻌﻀﻮ ورﻗﻢ اﻟﻌﻀﻮﯾﺔ ﻟﻠﺘﺤﻘﻖ ﻣﻤﺎ إذا ﻛﺎن اﻟﻌﻀﻮ ‪valid‬أم ﻻ‪.‬‬ ‫اﻹﺟﺮاء‪ :‬إذا ﻛﺎﻧﺖ اﻟﻌﻀﻮﯾﺔ ﺻﺎﻟﺤﺔ‪ ،‬ﯾﺘﻢ ﺗﺤﺪﯾﺚ ﺗﺎرﯾﺦ اﻧﺘﮭﺎء اﻟﻌﻀﻮﯾﺔ وطﺒﺎﻋﺔ ﻓﺎﺗﻮرة اﻟﻌﻀﻮﯾﺔ اﻟﺴﻨﻮﯾﺔ‪ ،‬وإﻻ ﯾﺘﻢ ﻋﺮض‬ ‫رﺳﺎﻟﺔ ﺧﻄﺄ‪.‬‬ ‫ﺧﯿﺎر إﻟﻐﺎء اﻟﻌﻀﻮﯾﺔ‬ ‫اﻟﻘﺮار‪ :‬إذا ﺗﻢ اﺧﺘﯿﺎر ﺧﯿﺎر "إﻟﻐﺎء اﻟﻌﻀﻮﯾﺔ"‪ ،‬ﯾﻄﻠﺐ اﻟﺒﺮﻧﺎﻣﺞ اﺳﻢ اﻟﻌﻀﻮ ورﻗﻢ اﻟﻌﻀﻮﯾﺔ‪.‬‬ ‫وأﺧﯿﺮا ﯾﺘﻢ ﺣﺬف ﺳﺠﻞ اﻟﻌﻀﻮﯾﺔ ﻣﻦ ﻗﺎﻋﺪة‬ ‫ً‬ ‫اﻹﺟﺮاء‪ :‬ﯾﺘﻢ إﻟﻐﺎء اﻟﻌﻀﻮﯾﺔ‪ ،‬وطﺒﺎﻋﺔ ﺷﯿﻚ ﺑﺎﻟﻤﺒﻠﻎ اﻟﻤﺘﺒﻘﻲ اﻟﻤﺴﺘﺤﻖ ﻟﻠﻌﻀﻮ‪،‬‬ ‫اﻟﺒﯿﺎﻧﺎت‪.‬‬ ‫ﺗﻤﺜﯿﻞ ﺷﺠﺮة اﻟﻘﺮار ﻟﻠﻤﺜﺎل أﻋﻼه‬ ‫ﺗُﻈﮭﺮ اﻟﺸﺠﺮة اﻟﺘﺎﻟﯿﺔ )اﻟﺸﻜﻞ ‪ (34.3‬اﻟﺘﻤﺜﯿﻞ اﻟﺮﺳﻮﻣﻲ ﻟﻠﻤﺜﺎل أﻋﻼه‪.‬ﺑﻌﺪ اﻟﺤﺼﻮل ﻋﻠﻰ اﻟﻤﻌﻠﻮﻣﺎت ﻣﻦ اﻟﻤﺴﺘﺨﺪم‪ ،‬ﯾﺘﺨﺬ‬ ‫ﻗﺮارا ﺛﻢ ﯾﻨﻔﺬ اﻹﺟﺮاءات اﻟﻤﻘﺎﺑﻠﺔ‪.‬‬ ‫ً‬ ‫اﻟﻨﻈﺎم‬ ‫‪Version 2 EE IIT, Kharagpur‬‬ ‫‪8‬‬  ask for members name,address,etc New member create membership details print bill Renewal ask for membership details updata expiry data Yes print bill Cancellation ask for membership details User output delete membership record print cheque No Invalid Option display error message Fig. 34.3 Decision tree for LMS 2. Decision Tables A decision table is used to represent the complex processing logic in a tabular or a matrix form. The upper rows of the table specify the variables or conditions to be evaluated. The lower rows of the table specify the actions to be taken when the corresponding conditions are satisfied. Example Consider the previously discussed LMS example. The decision table shown in fig. 34.4 shows how to represent the problem in a tabular form. Here the table is divided into two parts. The upper part shows the conditions and the lower part shows what actions are taken. Each column of the table is a rule. Version 2 EE IIT, Kharagpur 9  ‫‪ask for members name,address,etc‬‬ ‫‪New member‬‬ ‫‪create membership details print bill‬‬ ‫‪Renewal‬‬ ‫‪ask for membership details updata expiry data‬‬ ‫‪Yes‬‬ ‫‪print bill‬‬ ‫‪Cancellation‬‬ ‫‪ask for membership details‬‬ ‫‪User output‬‬ ‫‪delete membership record‬‬ ‫‪print cheque‬‬ ‫‪No‬‬ ‫‪Invalid Option‬‬ ‫‪display error message‬‬ ‫‪Fig. 34.3 Decision tree for LMS‬‬ ‫‪.2‬ﺟﺪاول اﻟﻘﺮار‬ ‫ﯾُﺴﺘﺨﺪم ﺟﺪول اﻟﻘﺮار ﻟﺘﻤﺜﯿﻞ ﻣﻨﻄﻖ اﻟﻤﻌﺎﻟﺠﺔ اﻟﻤﻌﻘﺪ ﻓﻲ ﺷﻜﻞ ﺟﺪوﻟﻲ أو ﻣﺼﻔﻮﻓﻲ‪.‬اﻟﺼﻔﻮف اﻟﻌﻠﯿﺎ ﻣﻦ اﻟﺠﺪول ﺗﺤﺪد اﻟﻤﺘﻐﯿﺮات‬ ‫أو اﻟﺸﺮوط اﻟﺘﻲ ﺳﯿﺘﻢ ﺗﻘﯿﯿﻤﮭﺎ‪.‬اﻟﺼﻔﻮف اﻟﺴﻔﻠﯿﺔ ﻣﻦ اﻟﺠﺪول ﺗﺤﺪد اﻹﺟﺮاءات اﻟﺘﻲ ﯾﺠﺐ اﺗﺨﺎذھﺎ ﻋﻨﺪﻣﺎ ﺗﺘﺤﻘﻖ اﻟﺸﺮوط اﻟﻤﻘﺎﺑﻠﺔ‪.‬‬ ‫ﯾُﻈﮭﺮ ﺟﺪول اﻟﻘﺮار اﻟﻤﻮﺿﺢ ﻓﻲ اﻟﺸﻜﻞ ‪LMS).‬اﻓﺘﺮض اﻟﻤﺜﺎل اﻟﺬي ﺗﻢ ﻣﻨﺎﻗﺸﺘﮫ ﺳﺎﺑﻘًﺎ ﻋﻦ ﻧﻈﺎم أﺗﻤﺘﺔ اﻟﻌﻀﻮﯾﺔ ﻓﻲ اﻟﻤﻜﺘﺒﺔ )‬ ‫‪ 34.4‬ﻛﯿﻔﯿﺔ ﺗﻤﺜﯿﻞ اﻟﻤﺸﻜﻠﺔ ﻓﻲ ﺷﻜﻞ ﺟﺪوﻟﻲ‪.‬ھﻨﺎ‪ ،‬ﯾﺘﻢ ﺗﻘﺴﯿﻢ اﻟﺠﺪول إﻟﻰ ﺟﺰﺋﯿﻦ‪.‬اﻟﺠﺰء اﻟﻌﻠﻮي ﯾﻈﮭﺮ اﻟﺸﺮوط‪ ،‬واﻟﺠﺰء اﻟﺴﻔﻠﻲ‬ ‫ﯾﻈﮭﺮ اﻹﺟﺮاءات اﻟﺘﻲ ﯾﺘﻢ اﺗﺨﺎذھﺎ‪.‬ﻛﻞ ﻋﻤﻮد ﻣﻦ اﻟﺠﺪول ﯾﻤﺜﻞ ﻗﺎﻋﺪة‬ ‫‪Version 2 EE IIT, Kharagpur‬‬ ‫‪9‬‬  Conditions Valid selection No Yes Yes Yes New member - Yes No No Renewal - No Yes No Cancellation - No No Yes Actions Display error message x - - - Ask member's details - x - - Build customer record - - x - Generate bill - x x - Ask member's name & membership number - - x x Update expiry date - - x - Print cheque - - - x Delete record - - - x Fig. 34.4 Decision table for LMS From the above table you can easily understand that, if the valid selection condition is false, then the action taken for this condition is 'display error message' ,similarly, the actoins taken for other conditions can be inferred form the table. Efficiency: It should be efficient. Maintainability: It should be easily amenable to change. Possibly the most important goodness criterion is design correctness. A design has to be correct to be acceptable. Given that a design solution is correct, understandability of a design is possibly the most important issue to be considered while judging the goodness of a design. A design that is easy to understand is also easy to develop, maintain and change. Thus, unless a design is easily understandable, it would require tremendous effort to implement and maintain it. Features of a design document In order to facilitate understandability, the design should have the following features: It should use consistent and meaningful names for various design components. The design should be modular. The term modularity means that it should use a cleanly decomposed set of modules. It should neatly arrange the modules in a hierarchy, e.g. in a tree-like diagram. Version 2 EE IIT, Kharagpur 10  ‫‪Conditions‬‬ ‫‪Valid selection‬‬ ‫‪No Yes Yes Yes‬‬ ‫‪New member‬‬ ‫‪- Yes No No‬‬ ‫‪Renewal‬‬ ‫‪- No Yes No‬‬ ‫‪Cancellation‬‬ ‫‪- No No Yes‬‬ ‫‪Actions‬‬ ‫‪Display error message‬‬ ‫‪x‬‬ ‫‪-‬‬ ‫‪-‬‬ ‫‪-‬‬ ‫‪Ask member's details‬‬ ‫‪-‬‬ ‫‪x‬‬ ‫‪-‬‬ ‫‪-‬‬ ‫‪Build customer record‬‬ ‫‪-‬‬ ‫‪-‬‬ ‫‪x‬‬ ‫‪-‬‬ ‫‪Generate bill‬‬ ‫‪-‬‬ ‫‪x‬‬ ‫‪x‬‬ ‫‪-‬‬ ‫‪Ask member's name & membership number -‬‬ ‫‪-‬‬ ‫‪x‬‬ ‫‪x‬‬ ‫‪Update expiry date‬‬ ‫‪-‬‬ ‫‪-‬‬ ‫‪x‬‬ ‫‪-‬‬ ‫‪Print cheque‬‬ ‫‪-‬‬ ‫‪-‬‬ ‫‪-‬‬ ‫‪x‬‬ ‫‪Delete record‬‬ ‫‪-‬‬ ‫‪-‬‬ ‫‪-‬‬ ‫‪x‬‬ ‫‪Fig. 34.4 Decision table for LMS‬‬ ‫ﻣﻦ اﻟﺠﺪول أﻋﻼه‪ ،‬ﯾﻤﻜﻨﻚ ﺑﺴﮭﻮﻟﺔ أن ﺗﻔﮭﻢ أﻧﮫ إذا ﻛﺎﻧﺖ ﺣﺎﻟﺔ "اﻻﺧﺘﯿﺎر اﻟﺼﺤﯿﺢ" ﺧﺎطﺌﺔ‪ ،‬ﻓﺈن اﻹﺟﺮاء اﻟﻤﺘﺨﺬ ﻟﮭﺬه اﻟﺤﺎﻟﺔ ھﻮ‬ ‫"ﻋﺮض رﺳﺎﻟﺔ ﺧﻄﺄ"‪.‬وﺑﺎﻟﻤﺜﻞ‪ ،‬ﯾﻤﻜﻦ اﺳﺘﻨﺘﺎج اﻹﺟﺮاءات اﻟﻤﺘﺨﺬة ﻟﻠﺤﺎﻻت اﻷﺧﺮى ﻣﻦ اﻟﺠﺪول‪.‬‬ ‫اﻟﻜﻔﺎءة‪ :‬ﯾﺠﺐ أن ﯾﻜﻮن اﻟﺘﺼﻤﯿﻢ ﻛﻒ ًءا‪.‬‬ ‫اﻟﻘﺎﺑﻠﯿﺔ ﻟﻠﺼﯿﺎﻧﺔ‪ :‬ﯾﺠﺐ أن ﯾﻜﻮن ﺳﮭﻞ اﻟﺘﻌﺪﯾﻞ واﻟﺘﻐﯿﯿﺮ‪.‬‬ ‫رﺑﻤﺎ ﯾﻜﻮن اﻟﻤﻌﯿﺎر اﻷﻛﺜﺮ أھﻤﯿﺔ ﻟﺘﻤﯿﯿﺰ ﺟﻮدة اﻟﺘﺼﻤﯿﻢ ھﻮ ﺻﺤﺔ اﻟﺘﺼﻤﯿﻢ‪.‬ﯾﺠﺐ أن ﯾﻜﻮن اﻟﺘﺼﻤﯿﻢ ﺻﺤﯿ ًﺤﺎ ﻟﯿﻜﻮن ﻣﻘﺒﻮ ًﻻ‪.‬‬ ‫وﺑﻤﺠﺮد أن ﯾﻜﻮن اﻟﺤﻞ اﻟﺘﺼﻤﯿﻤﻲ ﺻﺤﯿ ًﺤﺎ‪ ،‬ﻓﺈن ﻓﮭﻢ اﻟﺘﺼﻤﯿﻢ رﺑﻤﺎ ﯾﻜﻮن أھﻢ ﻗﻀﯿﺔ ﯾﺠﺐ ﻣﺮاﻋﺎﺗﮭﺎ ﻋﻨﺪ ﺗﻘﯿﯿﻢ ﺟﻮدة اﻟﺘﺼﻤﯿﻢ‪.‬‬ ‫اﻟﺘﺼﻤﯿﻢ اﻟﺬي ﯾﺴﮭﻞ ﻓﮭﻤﮫ ﯾﺴﮭﻞ أﯾﻀًﺎ ﺗﻄﻮﯾﺮه وﺻﯿﺎﻧﺘﮫ وﺗﻌﺪﯾﻠﮫ‪.‬ﻟﺬا‪ ،‬ﻣﺎ ﻟﻢ ﯾﻜﻦ اﻟﺘﺼﻤﯿﻢ ﺳﮭﻞ اﻟﻔﮭﻢ‪ ،‬ﻓﺈﻧﮫ ﺳﯿﺘﻄﻠﺐ ﺟﮭﺪًا‬ ‫ً‬ ‫ھﺎﺋﻼ ﻟﺘﻨﻔﯿﺬه وﺻﯿﺎﻧﺘﮫ‪.‬‬ ‫ﻣﯿﺰات وﺛﯿﻘﺔ اﻟﺘﺼﻤﯿﻢ‬ ‫ﻟﺘﺴﮭﯿﻞ اﻟﻔﮭﻢ‪ ،‬ﯾﺠﺐ أن ﯾﺤﺘﻮي اﻟﺘﺼﻤﯿﻢ ﻋﻠﻰ اﻟﻤﯿﺰات اﻟﺘﺎﻟﯿﺔ‪:‬‬ ‫‪ -‬ﯾﺠﺐ أن ﯾﺴﺘﺨﺪم أﺳﻤﺎء ﻣﺘﺴﻘﺔ وذات ﻣﻌﻨﻰ ﻟﻤﻜﻮﻧﺎت اﻟﺘﺼﻤﯿﻢ اﻟﻤﺨﺘﻠﻔﺔ‪.‬‬ ‫‪ -‬ﯾﺠﺐ أن ﯾﻜﻮن اﻟﺘﺼﻤﯿﻢ ﻣﻌﯿﺎرﯾًﺎ‪.‬ﯾﻌﻨﻲ ﻣﺼﻄﻠﺢ "اﻟﻤﻌﯿﺎرﯾﺔ" أن اﻟﺘﺼﻤﯿﻢ ﯾﺠﺐ أن ﯾﺴﺘﺨﺪم ﻣﺠﻤﻮﻋﺔ ﻣﻔﻜﻜﺔ ﺑﺸﻜﻞ ﺟﯿﺪ ﻣﻦ‬ ‫اﻟﻮﺣﺪات‪.‬‬ ‫‪ -‬ﯾﺠﺐ ﺗﺮﺗﯿﺐ اﻟﻮﺣﺪات ﺑﺸﻜﻞ ﻣﺮﺗﺐ ﻓﻲ ھﯿﻜﻞ ھﺮﻣﻲ‪ ،‬ﻣﺜﻞ اﻟﺮﺳﻢ اﻟﺒﯿﺎﻧﻲ اﻟﺸﺠﺮي‪.‬‬ ‫‪Version 2 EE IIT, Kharagpur 10‬‬ Lesson 6 Specific Instructional Objectives At the end of this lesson the student will be able to: Identify the software design activities, Identify the items to be designed during the preliminary and detailed design activities. Identify the primary differences between analysis and design activities Identify the important items developed during the software design phase. State the important desirable characteristics of a good software design. Identify the necessary features of a design document in order to facilitate understandability.. Software design and its activities Software design deals with transforming the customer requirements, asdescribed in the SRS document, into a form (a set of documents) that is suitable for implementation in a programming language. A good software design is seldom arrived by using a single step procedure but rather through several iterations through a series of steps. Design activities can be broadly classified into two important parts: Preliminary (or high-level) design and Detailed design. Preliminary and detailed design activities The meaning and scope of two design activities (i.e. high-level and detailed design) tend to vary considerably from one methodology to another. High-level design means identification of different modules and the control relationships among them and the definition of the interfaces among these modules. The outcome of high- level design is called the program structure or software architecture. Many different types of notations have been used to represent a high-level design. A popular way is to use a tree-like diagram called the structure chart to represent the control hierarchy in a high-level design. However, other notations such as Jackson diagram or Warnier-Orr [1977, 1981] diagram can also be used. During detailed design, the data structure and the algorithmsof the different modules are designed. The outcome of the detailed design stage is usually known as the module-specification document. Difference between analysis and design The aim of analysis is to understand the problem with a view to eliminate any deficiencies in the requirement specification such as incompleteness, inconsistencies, etc. The model which we are trying to build may be or may not be ready.  ‫‪Lesson 6‬‬ ‫اﻷﻫﺪاف اﻟﺘﻌﻠ ﻤ ﺔ اﻟﻤﺤﺪدة‬ ‫ف ﻧﻬﺎ ﺔ ﻫﺬە اﻟﺪرس‪ ،‬ﺳ ﻜﻮن اﻟﻄﺎﻟﺐ ‬ ‫ﻗﺎدرا ﻋ ‪:‬‬ ‫ي‬ ‫اﻟ ﻣﺠ ﺎت‪،‬‬ ‫‪ -‬ﺗﺤﺪ ﺪ أ ﺸﻄﺔ ﺗﺼﻤ ﻢ ب‬ ‫واﻟﺘﻔﺼ ‪،‬‬ ‫اﻷو ‬ ‫اﻟي ﺠﺐ ﺗﺼﻤ ﻤﻬﺎ ﺧﻼل أ ﺸﻄﺔ اﻟﺘﺼﻤ ﻢ‬ ‫ت‬ ‫ي‬ ‫ي‬ ‫‪ -‬ﺗﺤﺪ ﺪ اﻟﻌﻨﺎ ي‬ ‫ف‬ ‫‪ -‬ﺗﺤﺪ ﺪ اﻻﺧﺘﻼﻓﺎت اﻟﺮﺋ ﺴ ﺔ يﺑن أ ﺸﻄﺔ اﻟﺘﺤﻠ ﻞ واﻟﺘﺼﻤ ﻢ‪،‬‬ ‫اﻟ ﻣﺠ ﺎت‪،‬‬‫اﻟي ﻳﺘﻢ ﺗﻄ ﺮﻫﺎ ﺧﻼل ﻣﺮﺣﻠﺔ ﺗﺼﻤ ﻢ ب‬ ‫ت‬ ‫‪ -‬ﺗﺤﺪ ﺪ اﻟﻌﻨﺎ اﻟﻤﻬﻤﺔ ي‬ ‫اﻟ ﻣﺠ ﺎت اﻟﺠ ﺪ‪،‬‬‫‪ -‬ﺗﺤﺪ ﺪ اﻟﺨﺼﺎﺋﺺ اﻟﻤﺮﻏ ﺔ اﻟﻤﻬﻤﺔ ﻟﺘﺼﻤ ﻢ ب‬ ‫‪ -‬ﺗﺤﺪ ﺪ ي ف‬ ‫اﻟﻤ ات اﻟﻼزﻣﺔ ﻟﻮﺛ ﻘﺔ اﻟﺘﺼﻤ ﻢ ﻟتﺴﻬ ﻞ اﻟﻔﻬﻢ‪.‬‬ ‫اﻟ ﻣﺠ ﺎت وأ ﺸﻄﺘﻪ‬ ‫ﺗﺼﻤ ﻢ ب‬ ‫ض‬ ‫اﻟ ﻣﺠ ﺎت ﻣﻊ ﺗﺤ ﻞ ﻣﺘﻄﻠبﺎت اﻟﻌﻤ ﻞ‪ ،‬كﻤﺎ ﻫﻮ ﻣﻮﺿﺢ ي وﺛ ﻘﺔ ‪ ،SRS‬إ ﺷكﻞ )ﻣﺠﻤﻮﻋﺔ ﻣﻦ اﻟﻮﺛﺎﺋﻖ( ﻤﻜﻦ ﺗﻨﻔ ﺬە بﻠﻐﺔ ﺑﺮﻣﺠﺔ‪.‬‬ ‫ﻳﺘﻌﺎﻣﻞ ﺗﺼﻤ ﻢ ب‬ ‫ﻋ ﻋﺪة ﺗﻜﺮارات ﻣﻦ ﺧﻼل ﺳﻠﺴﻠﺔ ﻣﻦ اﻟﺨﻄﻮات‪.‬‬ ‫ ‬ ‫ﻟﻠ ﻣﺠ ﺎت ﻧﺎدرا ﻣﺎ ﻳﺘﻢ اﻟﻮﺻﻮل إﻟ ﻪ بﺎﺳﺘﺨﺪام إﺟﺮاء ﺧﻄﻮة واﺣﺪة‪ ،‬بﻞ ﻳﺘﻢ ب‬ ‫اﻟﺘﺼﻤ ﻢ اﻟﺠ ﺪ ب‬ ‫يف‬ ‫رﺋ ﺴﻴن‪:‬‬ ‫يف‬ ‫ﺟﺰﺋن‬ ‫ ﻤﻜﻦ ﺗﺼن ﻒ أ ﺸﻄﺔ اﻟﺘﺼﻤ ﻢ ﺸكﻞ ﻋﺎم إ ‬ ‫ﻋﺎ اﻟﻤﺴﺘﻮى(‬ ‫اﻷو )أو اﻟﺘﺼﻤ ﻢ ي‬ ‫ي‬ ‫‪ -‬اﻟﺘﺼﻤ ﻢ‬ ‫اﻟﺘﻔﺼ ‬ ‫ي‬ ‫‪ -‬اﻟﺘﺼﻤ ﻢ‬ ‫واﻟﺘﻔﺼ ‬ ‫ي‬ ‫اﻷو ‬ ‫ي‬ ‫أ ﺸﻄﺔ اﻟﺘﺼﻤ ﻢ‬ ‫ن‬ ‫ ﻌي‬ ‫ىن‬ ‫ﻛﺒ ﻣﻦ ﻣﻨﻬﺠ ﺔ إ أﺧﺮى‪.‬ي‬ ‫اﻟﺘﻔﺼ ( إ أن ﺨﺘﻠﻒ ﺸكﻞ ي‬ ‫ي‬ ‫ﻋﺎ اﻟﻤﺴﺘﻮى واﻟﺘﺼﻤ ﻢ‬ ‫ ‬ ‫ ﻤ ﻞ ﻣﻌ وﻧﻄﺎق اﻷ ﺸﻄﺔ اﻟﺘﺼﻤ ﻤ ﺔ )أي اﻟﺘﺼﻤ ﻢ ي‬ ‫ﺑن ﻫﺬە اﻟﻮﺣﺪات‪.‬‬ ‫اﻟﺘﺼﻤ ﻢ ﻋﺎ اﻟﻤﺴﺘﻮى ﺗﺤﺪ ﺪ اﻟﻮﺣﺪات اﻟﻤﺨﺘﻠﻔﺔ واﻟﻌﻼﻗﺎت اﻟﺘﺤكﻤ ﺔ ﺑيﻨﻬﺎ وﺗﻌ ﻒ اﻟﻮاﺟﻬﺎت ي ف‬ ‫ُ‬ ‫ي‬ ‫ﻋﺎ اﻟﻤﺴﺘﻮى‪.‬إﺣﺪى‬‫ي‬ ‫ﻤ ﻢ‬ ‫اﻟﺘﺼ‬ ‫ﻟﺘﻤﺜ ﻞ‬ ‫اﻟﺮﻣﻮز‬ ‫أﻧﻮاع‬ ‫ﻣﻦ‬ ‫اﻟﻌﺪ ﺪ‬ ‫اﺳﺘﺨﺪام‬ ‫ﺗﻢ‬ ‫‪.‬‬‫ﻣﺠ ﺔ‬ ‫اﻟ ‬ ‫ب‬ ‫اﻟﻌﻤﺎرة‬ ‫أو‬ ‫ﻧﺎﻣﺞ‬ ‫اﻟ ‬ ‫ب‬ ‫ﺑن ﺔ‬ ‫ﺴ ‬‫ ‬ ‫اﻟﻤﺴﺘﻮى‬ ‫ﻋﺎ ‬ ‫اﻟﺘﺼﻤ ﻢ‬ ‫ﻧت ﺠﺔ‬ ‫ﻋﺎ اﻟﻤﺴﺘﻮى‪.‬وﻣﻊ ذﻟﻚ‪ ،‬ﻤﻜﻦ‬ ‫اﻟﺘﺼﻤ ﻢ‬ ‫ ‬ ‫ف‬ ‫ﻟﻠﺘﺤكﻢ‬ ‫اﻟﻬﺮ ‬ ‫اﻟتﺴﻠﺴﻞ‬ ‫ﻟﺘﻤﺜ ﻞ‬ ‫اﻟﻬ كﻞ‬ ‫ﻣﺨﻄﻂ‬ ‫ ﺴ ‬ ‫ﺷﺠﺮي‬ ‫ﺑ ﺎئ‬‫اﻟﻄﺮق اﻟﺸﺎﺋﻌﺔ ياﺳﺘﺨﺪام رﺳﻢ ف‬ ‫ي‬ ‫ي‬ ‫ي‬ ‫ي‬ ‫ي‬ ‫ ‬ ‫وارﻧﻴ ‪-‬أور‪،(Warnier-Orr diagram) [1977‬‬ ‫ي‬ ‫أ ﻀﺎ اﺳﺘﺨﺪام رﻣﻮز أﺧﺮى ﻣﺜﻞ ﻣﺨﻄﻂ ﺟﺎ ﺴﻮن ]‪(Jackson diagram) [1975‬أو ﻣﺨﻄﻂ‬ ‫‪.‬‬ ‫ً ُ‬ ‫اﻟﺘﻔﺼ ‬ ‫ي‬ ‫اﻟﺘﻔﺼ ‪ ،‬ﻳﺘﻢ ﺗﺼﻤ ﻢ ﻫ ﺎ ﻞ اﻟﺒ ﺎﻧﺎت واﻟﺨﻮارزﻣ ﺎت اﻟﺨﺎﺻﺔ بﺎﻟﻮﺣﺪات اﻟﻤﺨﺘﻠﻔﺔ‪.‬ﻋﺎدة ﻣﺎ ﺴ ﻧت ﺠﺔ ﻣﺮﺣﻠﺔ اﻟﺘﺼﻤ ﻢ‬ ‫ي‬ ‫ﺧﻼل اﻟﺘﺼﻤ ﻢ‬ ‫وﺛ ﻘﺔ ﻣﻮاﺻﻔﺎت اﻟﻮﺣﺪة‪.‬‬ ‫اﻟﻔﺮق ي ف‬ ‫ﺑن اﻟﺘﺤﻠ ﻞ واﻟﺘﺼﻤ ﻢ‬ ‫ض‬ ‫اﻟﻬﺪف ﻣﻦ اﻟﺘﺤﻠ ﻞ ﻫﻮ ﻓﻬﻢ اﻟﻤﺸكﻠﺔ ﺑﻬﺪف إزاﻟﺔ أي ﻧﻘﺺ ي ﻣﻮاﺻﻔﺎت اﻟﻤﺘﻄﻠبﺎت ﻣﺜﻞ اﻟﻨﻘﺺ أو اﻟﺘﻨﺎﻗﻀﺎت أو ﻣﺎ إ ذﻟﻚ‪.‬اﻟﻨﻤﻮذج اﻟﺬي ﻧﺤﺎول‬ ‫ ‬ ‫ﺟﺎﻫﺰا أو ﻗﺪ ﻻ ﻜﻮن ﻛﺬﻟﻚ‪.‬‬ ‫ﺑﻨﺎؤە ﻗﺪ ﻜﻮن‬  Lesson 6 The aim of design is to produce a model that will provide a seamless transition to the coding phase, i.e. once the requirements are analyzed and found to be satisfactory, a design model is created which can be easily implemented. Items developed during the software design phase For a design to be easily implemented in a conventional programming language, the following items must be designed during the design phase. Different modules required to implement the design solution. Control relationship among the identified modules. The relationship is also known as the call relationship or invocation relationship among modules. Interface among different modules. The interface among different modules identifies the exact data items exchanged among the modules. Data structures of the individual modules. Algorithms required to implement each individual module. Characteristics of a good software design The definition of "a good software design" can vary depending on the application being designed. For example, the memory size used by a program may be an important issue to characterize a good solution for embedded software development - since embedded applications are often required to be implemented using memory of limited size due to cost, space, or power consumption considerations. For embedded applications, one may sacrifice design comprehensibility to achieve code compactness. For embedded applications, factors like design comprehensibility may take a back seat while judging the goodness of design. Therefore, the criteria used to judge how good a given design solution is can vary widely depending upon the application. Not only is the goodness of design dependent on the targeted application, but also the notion of goodness of a design itself varies widely across software engineers and academicians. However, most researchers and software engineers agree on a few desirable characteristics that every good software design for general application must possess. The characteristics are listed below Correctness: A good design should rectly implement all the functionalities identified in the SRS document Understandability: A good design is easily underst ‫‪Lesson 6‬‬ ‫اﻟﻬﺪف ﻣﻦ اﻟﺘﺼﻤ ﻢ‬ ‫ﺳﻠﺴﺎ إ ﻣﺮﺣﻠﺔ ت‬ ‫اﻟ ي ف‬ ‫ً‬ ‫اﻧﺘﻘﺎ ‬ ‫ﻣ ‪ ،‬أي بﻤﺠﺮد أن ﻳﺘﻢ ﺗﺤﻠ ﻞ اﻟﻤﺘﻄﻠبﺎت واﻟﺘﺄ ﺪ ﻣﻦ أﻧﻬﺎ ﻣﺮﺿ ﺔ‪ ،‬ﻳﺘﻢ إ ﺸﺎء‬ ‫اﻟﻬﺪف ﻣﻦ اﻟﺘﺼﻤ ﻢ ﻫﻮ إﻧﺘﺎج ﻧﻤﻮذج ﻳﻮﻓﺮ‬ ‫ﻧﻤﻮذج ﺗﺼﻤ ﻢ ﻤﻜﻦ ﺗﻨﻔ ﺬە ﺴﻬﻮﻟﺔ‪.‬‬ ‫اﻟ ﻣﺠ ﺎت‬ ‫ت‬ ‫اﻟي ﻳﺘﻢ ﺗﻄ ﺮﻫﺎ ﺧﻼل ﻣﺮﺣﻠﺔ ﺗﺼﻤ ﻢ ب‬ ‫اﻟﻌﻨﺎ ي‬ ‫ف‬ ‫ً‬ ‫ﻟ ﻜﻮن اﻟﺘﺼﻤ ﻢ ﻗﺎب ﻟﻠﺘﻨﻔ ﺬ ﺴﻬﻮﻟﺔ ي ﻟﻐﺔ ﺑﺮﻣﺠﺔ ﺗﻘﻠ ﺪ ﺔ‪ ،‬ﺠﺐ ﺗﺼﻤ ﻢ اﻟﻌﻨﺎ اﻟﺘﺎﻟ ﺔ ﺧﻼل ﻣﺮﺣﻠﺔ اﻟﺘﺼﻤ ﻢ‪:‬‬ ‫ي‬ ‫‪ -‬اﻟﻮﺣﺪات اﻟﻤﺨﺘﻠﻔﺔ اﻟﻤﻄﻠ ﺔ ﻟﺘﻨﻔ ﺬ ﺣﻞ اﻟﺘﺼﻤ ﻢ‪.‬‬ ‫ﺑن اﻻﺳﺘﺪﻋﺎء أو اﻟﻌﻼﻗﺔ ي ض‬ ‫ ‬ ‫اﻟﻤﺤﺪدة‪.‬ﺗﻌﺮف ﻫﺬە اﻟﻌﻼﻗﺔ أ ﻀﺎ بﺎﻟﻌﻼﻗﺔ ي ض‬‫ﺑن اﻟﻮﺣﺪات ُ‬‫‪-‬ﻋﻼﻗﺔ اﻟﺘﺤكﻢ ي ن‬ ‫ﺑن اﻟﻮﺣﺪات‪.‬‬ ‫ﺑن اﻟﻮﺣﺪات‪.‬‬ ‫ت‬ ‫اﻟي ﻳﺘﻢ ﺗبﺎدﻟﻬﺎ ي ن‬ ‫ن‬ ‫ف‬ ‫‪ -‬اﻟﻮاﺟﻬﺔ يﺑن اﻟﻮﺣﺪات اﻟﻤﺨﺘﻠﻔﺔ‪.‬ﺗﺤﺪد اﻟﻮاﺟﻬﺔ يﺑن اﻟﻮﺣﺪات اﻟﺒ ﺎﻧﺎت اﻟﺪﻗ ﻘﺔ ي‬ ‫‪-‬ﻫ ﺎ ﻞ اﻟﺒ ﺎﻧﺎت اﻟﺨﺎﺻﺔ بكﻞ وﺣﺪة‪.‬‬ ‫‪ -‬اﻟﺨﻮارزﻣ ﺎت اﻟﻼزﻣﺔ ﻟﺘﻨﻔ ﺬ كﻞ وﺣﺪة ﻓﺮد ﺔ‪.‬‬ ‫اﻟ ﻣﺠ ﺎت اﻟﺠ ﺪ‬ ‫ﺧﺼﺎﺋﺺ ﺗﺼﻤ ﻢ ب‬ ‫ ‬ ‫ﻟﻠ ﻣﺠ ﺎت" اﻋﺘﻤﺎدا ﻋ اﻟﺘﻄﺒﻴﻖ اﻟﺬي ﻳﺘﻢ ﺗﺼﻤ ﻤﻪ‪.‬ﻋ ﺳب ﻞ اﻟﻤﺜﺎل‪ ،‬ﻗﺪ ﻜﻮن ﺣﺠﻢ اﻟﺬا ﺮة اﻟﻤﺴﺘﺨﺪم‬ ‫ ﻤﻜﻦ أن ﺨﺘﻠﻒ ﺗﻌ ﻒ "اﻟﺘﺼﻤ ﻢ اﻟﺠ ﺪ ب‬ ‫ ‬ ‫اﻟ ﻣﺠ ﺎت اﻟﻤﺪﻣﺠﺔ ‪ -‬ﺣ ﺚ ﻏﺎﻟبﺎ ﻣﺎ ﻳﺘﻄﻠﺐ اﻷﻣﺮ ﺗﻄﺒ ﻘﺎت ﻣﺪﻣﺠﺔ بﺎﺳﺘﺨﺪام ذا ﺮة ﻣﺤﺪودة‬ ‫اﻟ ﻧﺎﻣﺞ ﻗﻀ ﺔ ﻣﻬﻤﺔ ﻟﺘﺤﺪ ﺪ ﺣﻞ ﺟ ﺪ ﻟﺘﻄ ﺮ ب‬ ‫ﻣﻦ ﻗبﻞ ب‬ ‫اﻟﺤﺠﻢ ﺴبﺐ اﻋﺘبﺎرات اﻟﺘكﻠﻔﺔ أو اﻟﻤﺴﺎﺣﺔ أو اﺳﺘﻬﻼك اﻟﻄﺎﻗﺔ‪.‬بﺎﻟنﺴبﺔ ﻟﻠﺘﻄﺒ ﻘﺎت اﻟﻤﺪﻣﺠﺔ‪ ،‬ﻗﺪ ﻳﺘﻢ اﻟﺘﻀﺤ ﺔ بﻔﻬﻢ اﻟﺘﺼﻤ ﻢ ﻣﻦ أﺟﻞ ﺗﺤﻘﻴﻖ ﺻﻐﺮ‬ ‫ف‬ ‫ﺣﺠﻢ اﻟ ﻮد‪.‬ﻟﺬا‪ ،‬ﻗﺪ ﺗﻜﻮن ﻋﻮاﻣﻞ ﻣﺜﻞ ﻓﻬﻢ اﻟﺘﺼﻤ ﻢ ي اﻟﻤﺮﺗبﺔ اﻟﺜﺎﻧ ﺔ أﺛﻨﺎء ﺗﻘﻴ ﻢ ﺟﻮدة اﻟﺘﺼﻤ ﻢ‪.‬‬ ‫ ‬ ‫اﻟﺘﺼﻤ اﻋﺘﻤﺎدا ﻋ اﻟﺘﻄﺒﻴﻖ اﻟﻤﺴﺘﻬﺪف‪.‬ﻟ ﺴﺖ ﻓﻘﻂ ﺟﻮدة اﻟﺘﺼﻤ ﻢ ﺗﻌﺘﻤﺪ ﻋ ‬ ‫ي‬ ‫اﻟﻤﻌﺎﻳ اﻟﻤﺴﺘﺨﺪﻣﺔ ﻟﺘﻘﻴ ﻢ ﺟﻮدة اﻟﺤﻞ‬ ‫ي‬ ‫ﻟﺬﻟﻚ‪ ،‬ﻤﻜﻦ أن ﺗﺨﺘﻠﻒ‬ ‫ن‬ ‫ف‬ ‫ ‬ ‫اﻟ ﻣﺠ ﺎت واﻷ ﺎد ﻤﻴ ين‪.‬وﻣﻊ ذﻟﻚ‪ ،‬ﻳﺘﻔﻖ ﻣﻌﻈﻢ‬ ‫ﻣﻬﻨﺪ ب‬ ‫ي‬ ‫ﻛﺒ يﺑن‬ ‫اﻟﺘﻄﺒﻴﻖ اﻟﻤﺴﺘﻬﺪف‪ ،‬وﻟ ﻦ أ ﻀﺎ ﻣﻔﻬﻮم "ﺟﻮدة اﻟﺘﺼﻤ ﻢ" ﻧﻔﺴﻪ ﺨﺘﻠﻒ ﺸكﻞ ي‬ ‫ كﻤﺎ‬ ‫ت‬ ‫يض‬ ‫اﻟئ ﺠﺐ أن ﻤﺘﻠ ﻬﺎ كﻞ ﺗﺼﻤ ﻢ ﺑﺮﻣﺠ ﺎت ﺟ ﺪ ﻟﻠﺘﻄﺒ ﻘﺎت اﻟﻌﺎﻣﺔ‪.‬اﻟﺨﺼﺎﺋﺺ ي‬ ‫اﻟ ﻣﺠ ﺎت ﻋ بﻌﺾ اﻟﺨﺼﺎﺋﺺ اﻟﻤﺮﻏ ﺔ ي‬ ‫وﻣﻬﻨﺪ ب‬ ‫ي‬ ‫اﻟبﺎﺣﺜن‬ ‫ ‪:‬‬ ‫ي‬ ‫ف‬ ‫‪ -‬اﻟﺼﺤﺔ‪ :‬ﺠﺐ أن ﻘﻮم اﻟﺘﺼﻤ ﻢ اﻟﺠ ﺪ ﺑتﻨﻔ ﺬ ﺟﻤﻴﻊ اﻟﻮﻇﺎﺋﻒ اﻟﻤﺤﺪدة ي وﺛ ﻘﺔ ‪ SRS‬ﺸكﻞ ﺻﺤﻴﺢ‪.‬‬ ‫‪ -‬اﻟﻘﺎبﻠ ﺔ ﻟﻠﻔﻬﻢ‪ :‬ﺠﺐ أن ﻜﻮن اﻟﺘﺼﻤ ﻢ اﻟﺠ ﺪ ﺳﻬﻞ اﻟﻔﻬﻢ‪.‬‬