1. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory1 Requirements Validation Section Four Version: 1.0 Mehr 1383

2. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory2 نگاه اجمالي 1.تشريح مفهوم ارزيابي تشخيص نيازها، هدف از انجام آن 2.تعيين فاکتورهاي ارزيابي نيازها 3.بررسي ويژگيهاي ارزيابي نيازها 4.بررسي تکنيکهاي فرآيند ارزيابي نيازها

3. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory3 مجموعه پرسشها 1.اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟ 2.چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟ 3.تکنيکهاي اعتبارسنجي نيازها چيست؟ 4.چه افرادي در جلسات بازنگري شرکت مي کنند؟ 5.نقش نمونه سازي در اعتبارسنجي نيازها چيست؟ 6. نکات حائز اهميت در بازنگري نيازها چيست؟

4. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory4 راهنماي مدرس ( اسلايدهاي 5- 10) مجموعه اسلايدهاي اين قسمت به معرفي کلي Verification and Validation مي پردازد. علت نياز به Requirement Validation و سطوح مختلف تست سيستم در اين قسمت مورد بررسي قرار مي گيرد. و هدف از ارزيابي نيازها و فاکتورهايي که در انجام اين فعاليت مطرح هستند مشخص مي شود.

5. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory5 What is V&V? Purpose of V&V is to deliver a product that works properly and performs to customer expectations. Verification is the process of confirming deliverable hardware and software are in compliance with the functional, performance, and design requirements.( Have we built the system right?) Validation is the process of providing evidence that a systems meets the needs of the User.( Have we built the right system?) What we are trying to do is to establish confidence in the system, support equipment, test equipment, and people. What

6. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory6 V&V The definition of V&V encompasses many of the activities that refer as Software Quality Assurance (SQA). V&V encompasses a wide array of SQA activities that include: –Formal technical reviews –Quality audits –Performance monitoring –Simulation – documentation review –testing

7. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory7 Different levels testing Unit Testing Integration Testing Code Integration Testing Acceptance Testing Validation Testing Design Requirements

8. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory8 Requirements validation Concerned with demonstrating that the requirements define the system that the customer really wants. (Define the right system) Pickup any problem before resources are committed to addressing the requirements. Requirements error costs are high so validation is very important –Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error What

9. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory9 Relative Cost to Fix an Error Phase in Which Requirement is Found Cost Ratio Requirements1 Design3-6 Coding10 Development Testing15-40 Acceptance Testing30-70 Operation40-1000 Why

10. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory10 Requirements checking Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked? What

11. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory11 راهنماي مدرس ( اسلايدهاي 12-31 ) در اين قسمت ويژگيهاي نيازهاي يک سيستم مشخص مي شوند و به اين موضوع پرداخته مي شود که بررسي نيازهاي سيستم بايد به صورتي انجام گيرد که هر يک از نيازهايي که براي يک سيستم تشخيص داده مي شوند همه اين ويژگيها را دارا باشند. دقت، کامل بودن، وضوح ، قابليت تست، ثبات، ارتباط با يک مشکل مشخص، قابليت تغيير و قابليت پيگيري ويژگيهايي هستند که در اين قسمت براي هر يک از نيازها و فرآيند مستندسازي و تعيين آنها معرفي مي گردند.

12. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory12 Characteristics of requirements Correct Unambiguous Complete Testable Consistent Deal only with the problem Modifiable Traceable What

13. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory13 Correct Each requirement statement accurately represents the functionality required of the system to be built. Example (of an incorrect requirement): Problem domain (real life) states that policeman ID numbers are in the range [10000…) and the requirements document specifies that each policeman has an ID number. When

14. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory14 Characteristics of requirements Correct Unambiguous Complete Testable Consistent Deal only with the problem Modifiable Traceable What

15. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory15 Unambiguous The difficulty of ambiguity stems from the use of natural language which in itself is inherently ambiguous. There is one and only one interpretation for every requirement. Requirement statements should be short, explicit, precise and clear. A glossary should be used when a term used in a particular context could have multiple meanings (I.e. “the user”). Formal requirements languages help reduce ambiguity. When

16. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory16 Unambiguous (cont.) Example of ambiguity –The TVRS shall store changes made in the details of a traffic report as soon as the data is entered. Disambiguation: –The TVRS shall store changes made in the details of a traffic report if and only all input fields are valid and user approved saving of data How

17. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory17 Characteristics of requirements Correct Unambiguous Complete Testable Consistent Deal only with the problem Modifiable Traceable What

18. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory18 Complete A requirements document is complete if it includes all of the significant requirements, relating to –functionality, – performance, – design constraints attributes – external interfaces. No sections are marked “To be determined” (TBD). Conforms to the company standards. When

19. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory19 Characteristics of requirements Correct Unambiguous Complete Testable Consistent Deal only with the problem Modifiable Traceable What

20. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory20 Testable A requirements document is testable (verifiable) if and only if every requirement statement in it is testable. A requirement is testable if and only if there is some finite cost-effective way in which a person or machine can check to see if the software product satisfies that requirement. When

21. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory21 Testable (cont.) Example of a non-verifiable requirement: –The TVRS shall complete storage of data within a reasonable time of the user confirming a “Save” sequence. Example of a verifiable requirement: –The TVRS shall complete storage of data within 5 seconds of the user confirming a “Save” sequence, 80% of the time. How

22. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory22 Characteristics of requirements Correct Unambiguous Complete Testable Consistent Deal only with the problem Modifiable Traceable What

23. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory23 Consistent Three types of conflicts: –Different terms used for the same object: F323 and a “Policeman Details Form” might be used to describe the same form. –Characteristics of objects: In one part of the requirements document: – “A policeman ID shall consist of decimal digits only”, while in another part – “Incase the policeman ID consists of non- alphanumerical characters, display an error message”. When

24. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory24 Consistent (cont.) –Logical or temporal faults: “A follows B” in one part, “A and B occur simultaneously” in another. “TVRS shall support removal of a policeman record from the personal database” vs. “TVRS shall support read-only access to policeman details”. Do clients know what a database is? When

25. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory25 Characteristics of requirements Correct Unambiguous Complete Testable Consistent Deal only with the problem Modifiable Traceable What

26. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory26 Deal only with the problem Requirements should state “what” is required at the appropriate system level, not “how”. –In some cases, a requirement may dictate how a task is to be accomplished. Avoid telling the designer “how” to do this job, instead state “what” has to be accomplished. Requirements should be understood by the clients as well as the developers. When

27. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory27 Characteristics of requirements Correct Unambiguous Complete Testable Consistent Deal only with the problem Modifiable Traceable What

28. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory28 Modifiable A requirements document is modifiable if its structure and style are such that changes can be made easily, completely and consistently : –Easy to use organization – table of contents, index and cross references. –No redundancy – a requirement should not be in more than one place. When

29. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory29 Characteristics of requirements Correct Unambiguous Complete Testable Consistent Deal only with the problem Modifiable Traceable What

30. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory30 Traceable Each requirement should be contained in a single, numbered paragraph so that it may be referred to in other documents: –Backward traceability - implies that we know where every requirement exists Each requirement explicitly references its source in previous documents. –Forward traceability – all documents to follow will be able to reference each requirement. When

31. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory31 Traceable (cont.) Example: –2.1 Functional requirements: 2.1.1 TVRS initialization: –… –2.1.15 TVRS shall display the user login window (see section 2.1.2.2) 2.1.2 TVRS user interfaces: –2.1.2.1 All user interaction with the TVRS shall occur by means of a graphical user interface. –2.1.2.2 User login window: »… How

32. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory32 راهنماي مدرس ( اسلايدهاي 33-38 ) مجموعه اسلايدهاي اين قسمت تکنيکهايي که در فرآيند ارزيابي نيازها مورد استفاده قرار مي گيرد را معرفي مي نمايد. بازنگري به عنوان يکي از تکنيکهاي ارزيابي در اين قسمت تشريح ميگيردد. زمان انجام بازنگري، شرکت کنندگان در جلسات بازنگري و ويژگيهاي هر يک از آنها و نکاتي که بايد در بازنگري مورد توجه قرار گيرند، در اين قسمت به تفصيل شرح داده مي شود.

33. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory33 Requirements validation techniques Requirements reviews Prototyping Acceptance tests Model Validation and Automated consistency analysisModel Validation and Automated consistency analysis What

34. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory34 Requirements reviews Requirements review is a systematic manual analysis of the requirements Regular reviews should be held while the requirements definition is being formulated Both client and contractor staff should be involved in reviews Reviews may be formal (with completed documents) or informal. What

35. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory35 General Guidelines for Review Good communications between developers, customers and users can resolve problems at an early stage Always conduct reviews in a meeting format, although the meeting participants might prepare some reviews on their own. Continuously check what is produced to make sure the product quality is as high as possible. Checkpoints are provided for this purpose; refer to the checkpoints for each analysis activity. What

36. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory36 Roles in Review Meetings a person has essential knowledge of the business or technology domain and detailed knowledge of the applied facilitation and modeling techniques: –Requirements Reviewer –Requirements Specifier –System Analyst possibly at milestones such as the beginning or end of a Phase: –Stakeholders - customers and end-users (Where possible) –Change Control Manager (Where reviewing Change Requests) –Test Designer (Optional) –Software Architect (Optional, usually in Inception and Elaboration) –Project Manager (Optional, usually at Phase Start) Who

37. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory37 Review checks Verifiability. Is the requirement realistically testable? Comprehensibility. Is the requirement properly understood? Traceability. Is the origin of the requirement clearly stated? Adaptability. Can the requirement be changed without a large impact on other requirements? What

38. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory38 RUP Checkpoints: Requirements Attributes –Has the correct set of requirements attributes been used as specified in the Requirements Management Plan? –Have attributes been set up for each requirement type to account for the following, where applicable, for each requirement? Tracking status? Benefit? Rationale? Level of effort to implement? Type and amount of each type of risk involved in implementing? –Schedule risk? –Resource risk? –Technical risk? Stability of the requirement? Target release? Assignment? Marketing input? Development input? Revision history? Location? Reasons for change? Inconclusive requirements? –Have all traceabilities been set up as specified for the project in the Requirements Management Plan? What

39. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory39 راهنماي مدرس ( اسلايدهاي40 -60) نمونه سازي يکي از ابزارهايي است که در ارزيابي تشخيص صحيح نيازهاي يک سيستم مورد استفاده قرار مي گيرد. دراين قسمت به معرفي نمونه سازي، مزايا و معايب آن، روشهاي مختلفي که براي ساخت نمونه ها وجود دارد، ويژگيهاي هر روش، مورد استفاده آن و ابزارهايي که در ساخت نمونه ها به کار مي رود ، پرداخته مي شود.

40. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory40 Requirements validation techniques Requirements reviews Prototyping Acceptance tests Model Validation and Automated consistency analysisModel Validation and Automated consistency analysis What

41. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory41 System prototyping Prototyping is the rapid development of a system Using an executable model of the system to check requirements. In the past, the developed system was normally thought of as inferior in some way to the required system so further development was required Now, the boundary between prototyping and normal system development is blurred and many systems are developed using an evolutionary approach What

42. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory42 Uses of system prototypes The principal use is to help customers and developers understand the requirements for the system –Requirements elicitation. Users can experiment with a prototype to see how the system supports their work –Requirements validation. The prototype can reveal errors and omissions in the requirements Prototyping can be considered as a risk reduction activity which reduces requirements risks What

43. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory43 Prototyping benefits Misunderstandings between software users and developers are exposed Missing services may be detected and confusing services may be identified A working system is available early in the process The prototype may serve as a basis for deriving a system specification The system can support user training and system testing Why

44. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory44 Prototyping benefits Improved system usability Closer match to the system needed Improved design quality Improved maintainability Reduced overall development effort Why

45. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory45 Prototyping in the software process Evolutionary prototyping –an initial prototype is produced and refined through a number of stages to the final system Throw-away prototyping –a practical implementation of the system is produced to help discover requirements problems and then discarded. The system is then developed using some other development process What

46. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory46 Prototyping objectives Evolutionary prototyping –to deliver a working system to end-users. –The development starts with those requirements which are best understood. Throw-away prototyping – to validate or derive the system requirements. – The prototyping process starts with those requirements which are poorly understood What

47. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory47 Evolutionary prototyping Must be used for systems where the specification cannot be developed in advance e.g. AI systems and user interface systems Based on techniques which allow rapid system iterations Verification is impossible as there is no specification. Validation means demonstrating the adequacy of the system. What

48. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory48 Evolutionary prototyping What

49. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory49 Evolutionary prototyping advantages Accelerated delivery of the system –Rapid delivery and deployment are sometimes more important than functionality or long-term software maintainability User engagement with the system –Not only is the system more likely to meet user requirements, –they are more likely to commit to the use of the system Why

50. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory50 Evolutionary prototyping Specification, design and implementation are inter-twined The system is developed as a series of increments that are delivered to the customer Techniques for rapid system development are used such as CASE tools and 4GLs User interfaces are usually developed using a GUI development toolkit How

51. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory51 Evolutionary prototyping problems Management problems –If management processes assume a waterfall model of development –Specialist skills are required which may not be available in all development teams Maintenance problems –Continual change tends to corrupt system structure so long-term maintenance is expensive Contractual problems What

52. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory52 Prototypes as specifications Some parts of the requirements (e.g. safety- critical functions) may be impossible to prototype and so don’t appear in the specification An implementation has no legal standing as a contract Non-functional requirements cannot be adequately tested in a system prototype What

53. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory53 Throw-away prototyping Used to reduce requirements risk The prototype is developed from an initial specification, delivered for experiment then discarded The throw-away prototype should NOT be considered as a final system –Some system characteristics may have been left out –There is no specification for long-term maintenance –The system will be poorly structured and difficult to maintain What

54. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory54 Prototype delivery Developers may be pressured to deliver a throw-away prototype as a final system This is not recommended –It may be impossible to tune the prototype to meet non-functional requirements –The prototype is inevitably undocumented –The system structure will be degraded through changes made during development –Normal organisational quality standards may not have been applied Why not

55. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory55 Rapid prototyping techniques Various techniques may be used for rapid development –Dynamic high-level language development –Database programming –Component and application assembly These are not exclusive techniques - they are often used together Visual programming is an inherent part of most prototype development systems What

56. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory56 Component and application assembly Prototypes can be created quickly from a set of reusable components plus some mechanism to ‘glue’ these component together The composition mechanism must include control facilities and a mechanism for component communication The system specification must take into account the availability and functionality of existing components What

57. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory57 Visual programming Scripting languages such as Visual Basic support visual programming where the prototype is developed by creating a user interface from standard items and associating components with these items A large library of components exists to support this type of development These may be tailored to suit the specific application requirements What

58. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory58 Visual programming with reuse What

59. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory59 Problems with visual development Difficult to coordinate team-based development No explicit system architecture Complex dependencies between parts of the program can cause maintainability problems What

60. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory60 User interface prototyping It is impossible to pre-specify the look and feel of a user interface in an effective way. Prototyping is essential UI development consumes an increasing part of overall system development costs User interface generators may be used to ‘draw’ the interface and simulate its functionality with components associated with interface entities Web interfaces may be prototyped using a web site editor What

61. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory61 راهنماي مدرس ( اسلايدهاي 62-67) Acceptance Test به عنوان يکي از تکنيکهاي ارزيابي در اين قسمت تشريح ميگيردد. حدود انجام اين تست مشخص مي شود و در نهايت Alpha Testing و Beta Testing براي تست نرم افزار معرفي مي شوند. سپس اعتبارسنجي مدلها بررسي شده و از طريق آن کيفيت مدلهاي تحليلي بررسي شده و موارد استفاده از اعتبارسنجِ مدلها بيان مي شود.

62. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory62 Requirements validation techniques Requirements reviews Prototyping Acceptance tests Model Validation and Automated consistency analysisModel Validation and Automated consistency analysis What

63. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory63 Acceptance Test Enable the customer to validate all requirements Conducted by end user Can range from informal “test drive” to a planned and systematically executed series of tests If software is developed as a product to be used by many customers a process called alpha and beta testing is used.

64. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory64 Alpha Testing Conducted at the developer’s site by a customer Software is used in a natural setting with the developer “looking over the shoulder” of the user and recording errors and usage problems.

65. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory65 Beta Testing Conducted at one or more customer sites by the end-user of the software. The developer is generally not present. Live application of the software in an environment that can not be controlled by the developer. Customer records all problems that are encountered and reports them to the developer. Developer modifies software and then prepare for release of the software product.

66. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory66 Requirements validation techniques Requirements reviews Prototyping Acceptance tests Model Validation and Automated consistency analysisModel Validation and Automated consistency analysis What

67. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory67 Model Validation Validating the quality of analysis models Is used to check the consistency of a structured requirements description E.g. Static analysis to verify that communication paths exist between objects that in stakeholder domain exchange data. If formal specification is used, using formal reasoning to prove properties of the requirements specification (e.g. completeness) What

68. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory68 پاسخ به پرسشها 1.اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟ 2.چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟ 3.تکنيکهاي اعتبارسنجي نيازها چيست؟تکنيکهاي اعتبارسنجي نيازها چيست؟ 4.چه افرادي در جلسات بازنگري شرکت مي کنند؟چه افرادي در جلسات بازنگري شرکت مي کنند؟ 5.نقش نمونه سازي در اعتبارسنجي نيازها چيست؟نقش نمونه سازي در اعتبارسنجي نيازها چيست؟ 6. نکات حائز اهميت در بازنگري نيازها چيست؟ نکات حائز اهميت در بازنگري نيازها چيست؟

69. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory69 What is V&V? Purpose of V&V is to deliver a product that works properly and performs to customer expectations. Verification is the process of confirming deliverable hardware and software are in compliance with the functional, performance, and design requirements.( Have we built the system right?) Validation is the process of providing evidence that a systems meets the needs of the User.( Have we built the right system?) What we are trying to do is to establish confidence in the system, support equipment, test equipment, and people. What

70. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory70 پاسخ به پرسشها 1.اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟ 2.چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟ 3.تکنيکهاي اعتبارسنجي نيازها چيست؟تکنيکهاي اعتبارسنجي نيازها چيست؟ 4.چه افرادي در جلسات بازنگري شرکت مي کنند؟چه افرادي در جلسات بازنگري شرکت مي کنند؟ 5.نقش نمونه سازي در اعتبارسنجي نيازها چيست؟نقش نمونه سازي در اعتبارسنجي نيازها چيست؟ 6. نکات حائز اهميت در بازنگري نيازها چيست؟ نکات حائز اهميت در بازنگري نيازها چيست؟

71. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory71 Requirements checking Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked? What

72. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory72 پاسخ به پرسشها 1.اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟ 2.چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟ 3.تکنيکهاي اعتبارسنجي نيازها چيست؟تکنيکهاي اعتبارسنجي نيازها چيست؟ 4.چه افرادي در جلسات بازنگري شرکت مي کنند؟چه افرادي در جلسات بازنگري شرکت مي کنند؟ 5.نقش نمونه سازي در اعتبارسنجي نيازها چيست؟نقش نمونه سازي در اعتبارسنجي نيازها چيست؟ 6. نکات حائز اهميت در بازنگري نيازها چيست؟ نکات حائز اهميت در بازنگري نيازها چيست؟

73. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory73 Requirements validation techniques Requirements reviews Prototyping Acceptance tests Model Validation and Automated consistency analysisModel Validation and Automated consistency analysis What

74. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory74 پاسخ به پرسشها 1.اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟ 2.چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟ 3.تکنيکهاي اعتبارسنجي نيازها چيست؟تکنيکهاي اعتبارسنجي نيازها چيست؟ 4.چه افرادي در جلسات بازنگري شرکت مي کنند؟چه افرادي در جلسات بازنگري شرکت مي کنند؟ 5.نقش نمونه سازي در اعتبارسنجي نيازها چيست؟نقش نمونه سازي در اعتبارسنجي نيازها چيست؟ 6. نکات حائز اهميت در بازنگري نيازها چيست؟ نکات حائز اهميت در بازنگري نيازها چيست؟

75. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory75 Roles in Review Meetings a person has essential knowledge of the business or technology domain and detailed knowledge of the applied facilitation and modeling techniques: –Requirements Reviewer –Requirements Specifier –System Analyst possibly at milestones such as the beginning or end of a Phase: –Stakeholders - customers and end-users (Where possible) –Change Control Manager (Where reviewing Change Requests) –Test Designer (Optional) –Software Architect (Optional, usually in Inception and Elaboration) –Project Manager (Optional, usually at Phase Start) Who

76. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory76 پاسخ به پرسشها 1.اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟ 2.چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟ 3.تکنيکهاي اعتبارسنجي نيازها چيست؟تکنيکهاي اعتبارسنجي نيازها چيست؟ 4.چه افرادي در جلسات بازنگري شرکت مي کنند؟چه افرادي در جلسات بازنگري شرکت مي کنند؟ 5.نقش نمونه سازي در اعتبارسنجي نيازها چيست؟نقش نمونه سازي در اعتبارسنجي نيازها چيست؟ 6. نکات حائز اهميت در بازنگري نيازها چيست؟ نکات حائز اهميت در بازنگري نيازها چيست؟

77. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory77 Uses of system prototypes The principal use is to help customers and developers understand the requirements for the system –Requirements elicitation. Users can experiment with a prototype to see how the system supports their work –Requirements validation. The prototype can reveal errors and omissions in the requirements Prototyping can be considered as a risk reduction activity which reduces requirements risks What

78. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory78 پاسخ به پرسشها 1.اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟ 2.چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟ 3.تکنيکهاي اعتبارسنجي نيازها چيست؟تکنيکهاي اعتبارسنجي نيازها چيست؟ 4.چه افرادي در جلسات بازنگري شرکت مي کنند؟چه افرادي در جلسات بازنگري شرکت مي کنند؟ 5.نقش نمونه سازي در اعتبارسنجي نيازها چيست؟نقش نمونه سازي در اعتبارسنجي نيازها چيست؟ 6. نکات حائز اهميت در بازنگري نيازها چيست؟ نکات حائز اهميت در بازنگري نيازها چيست؟

79. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory79 General Guidelines for Review Good communications between developers, customers and users can resolve problems at an early stage Always conduct reviews in a meeting format, although the meeting participants might prepare some reviews on their own. Continuously check what is produced to make sure the product quality is as high as possible. Checkpoints are provided for this purpose; refer to the checkpoints for each analysis activity. What