Research Report on Current Trends in Requirements Engineering

1. Research Report onCurrent Trends in Requirements Engineering July 2009

2. Taking Related Courses & Reading their references Research Method Collecting required Knowledge Finding Related Books Finding Related Papers Finding Related Journals Finding Related Projects Finding Related Researchers Finding Related Conferences Finding Related Courses Finding Related Research Groups

3. Taking Related Courses & Reading their references Research Method Collecting required Knowledge Finding Related Books Finding Related Papers Finding Related Journals Finding Related Projects Finding Related Researchers Finding Related Conferences Finding Related Courses Finding Related Research Groups

4. Results • Collected Knowledge • Understanding Requirements Engineering • Drawing Research Tree • Defining Interested Research Area

5. Outline IntroductiontoRequirementsEngineering Research Tree Interested Research Area Research Plan Abbas Rasoolzadegan rasoolzadegan@aut.ac.ir Oral Comprehensive Exam Intelligent Systems Lab http://ceit.aut.ac.ir/islab

6. Introduction to RE Environment User system Cost-effective? Feasible? RE Requirement RE Wish Need Techniques Tools ... Techniques Tools ... Oral Comprehensive Exam

7. Introduction to RE (Cont.) RUP Definition: A systematic approach to eliciting, organizing, documenting the requirements of the system, establishing and maintaining agreement between the customer and the project team on the changing requirements of the system. Oral Comprehensive Exam

8. Introduction to RE (Cont.) Oral Comprehensive Exam

9. Introduction to RE (Cont.) Ian Sommerville Definition: Appropriatemechanism for Understanding what the customer wants, Analyzing needs, Negotiating a reasonable solution, Validating the Specification and Managing Changes in requirements. Oral Comprehensive Exam

10. Introduction to RE (Cont.) We Consider RE as: A systematicand disciplined approach to Eliciting, Organizing, Documenting (Specifying), Analyzing, Validating and Managing changes in the requirements of the system. Oral Comprehensive Exam

11. Why Requirement Engineering? If we don’t engineer the requirements: In most systems, It’s highly likely that you’ll build a very elegantsoftware solution that solves a wrong problem. The result is: Wasted time and money Personal frustration Unhappy Users Oral Comprehensive Exam

12. RE Process Schema Oral Comprehensive Exam

13. Requirements Engineering Process Generic activities common to all RE processes: Requirements Elicitation; Requirements Analysis; Requirements Validation; Requirement Specification Requirements Change Management. Oral Comprehensive Exam

14. Results of Incorrect Requirements Oral Comprehensive Exam

15. Challenged software projects Oral Comprehensive Exam

16. Outline IntroductiontoRequirementsEngineering Research Tree Interested Research Area Research Plan Oral Comprehensive Exam

17. Taking Related Courses & Reading their references Research Method Collecting required Knowledge Finding Related Books Finding Related Papers Finding Related Journals Finding Related Projects Finding Related Researchers Finding Related Conferences Finding Related Courses Finding Related Research Groups

18. Resources (Value) Abbas Rasoolzadegan rasoolzadegan@aut.ac.ir Oral Comprehensive Exam Intelligent Systems Lab http://ceit.aut.ac.ir/islab

19. Resources (Value) Abbas Rasoolzadegan rasoolzadegan@aut.ac.ir Oral Comprehensive Exam 19Intelligent Systems Lab http://ceit.aut.ac.ir/islab

20. Papers (Share by Important Activities) Oral Comprehensive Exam

21. Papers (Share by Important Activities) Oral Comprehensive Exam

22. Oral Comprehensive Exam

23. Tools, Research Groups, Projects (Share by Important Topics) Oral Comprehensive Exam

24. Tools, Research Groups, Projects (Share by Important Topics) Oral Comprehensive Exam

25. Tools, Research Groups, Projects (Share by Important Topics) Oral Comprehensive Exam

26. Surveys A Quantitative Assessment of Requirements Engineering Publications--1963-2008 (2009) Requirements Engineering: In Search of the Dependent Variables(2008) Ten years of Australian Workshop on Requirements Engineering (2007) Survey on the Use of Formal Languages/Models for the Specification, Verification and Enforcement of Network Access-lists (2006) Requirements Elicitation: A Survey of Techniques, Approaches, and Tools (2005) Role of Requirements Engineering in Software development Process (2003) Abbas Rasoolzadegan rasoolzadegan@aut.ac.ir Oral Comprehensive Exam Intelligent Systems Lab http://ceit.aut.ac.ir/islab

27. Surveys (Cont.) Critical Success factors for the improvement of Requirements Engineering Process (2003) Research in Software Engineering: an Analysis of the literature (2002) A Survey of Practices and Problems Associated with Incomplete User Requirements Document(2001) Requirements Engineering: A Roadmap (2000) A Survey of Software Requirements Specification Practices in the New Zealand Software Industry (1999) A Tool Survey on Z Specification and Refinement(1999) Abbas Rasoolzadegan rasoolzadegan@aut.ac.ir Oral Comprehensive Exam Intelligent Systems Lab http://ceit.aut.ac.ir/islab

28. Books Dines Bjørner, From Domains to Requirements; The Triptych Approach to Software Engineering, Draft Version, Springer, June 7, 2009. Dines Bjørner,Software Engineering 2: Specification of Systems and Languages, 2006. Gerard O’Regan, Mathematical Approaches to Software Quality, Springer –Verlag London Limited, 2006, ISBN -13: 978-1-84628-242-3. Elizabeth Hull, Ken Jackson, Jeremy Dick, Requirements Engineering, Springer Verlag, Second Edition, 2005, ISBN:1-852-33577-7. Jim Davies and Jim Woodcock, Using Z: Specification, Refinement and Proof, Prentice Hall International Series in Computer Science, 1996, ISBN 0-13-948472-8. Abbas Rasoolzadegan rasoolzadegan@aut.ac.ir Oral Comprehensive Exam Intelligent Systems Lab http://ceit.aut.ac.ir/islab

29. Resource Journals Requirements Engineering Journal, Springer, ISI. Formal Aspects of Computing, Springer, ISI. IEEE Transactions on Software Engineering, ISI. ACM Computing Surveys, an ACM Journal. ACM Transactions on Software Engineering and Methodology (TOSEM). ACM SIGSOFT Software Engineering Notes IBM Journals IEEE Transactions on Software Engineering Information and Software Technology (Elsevier Inc.) International Journal of Software Engineering and Knowledge Engineering (IJSEKE) Journal of Systems and Software (Elsevier Inc.) Software Process: Improvement and Practice Abbas Rasoolzadegan rasoolzadegan@aut.ac.ir Oral Comprehensive Exam Intelligent Systems Lab http://ceit.aut.ac.ir/islab

30. Resource Conferences IEEE International Requirements Engineering Conference IEEE International Workshop on Requirements Engineering International Working Conference on Requirements Engineering: Foundation for Software Quality Fundamental Approaches to Software Engineering IEEE International Conference on Software Engineering and Formal Methods Australian Workshop on Requirements Engineering Abbas Rasoolzadegan rasoolzadegan@aut.ac.ir Oral Comprehensive Exam Intelligent Systems Lab http://ceit.aut.ac.ir/islab

31. Abbas Rasoolzadegan rasoolzadegan@aut.ac.ir Oral Comprehensive Exam 31Intelligent Systems Lab http://ceit.aut.ac.ir/islab

32. Outline IntroductiontoRequirementsEngineering Research Tree Interested Research Area Research Plan Oral Comprehensive Exam

33. Papers (Share by Main Activities) Abbas Rasoolzadegan rasoolzadegan@aut.ac.ir Oral Comprehensive Exam 33Intelligent Systems Lab http://ceit.aut.ac.ir/islab

34. Tools, Research Groups, Projects (Share by Main Topics) Abbas Rasoolzadegan rasoolzadegan@aut.ac.ir Oral Comprehensive Exam 34Intelligent Systems Lab http://ceit.aut.ac.ir/islab

35. Result Oral Comprehensive Exam

36. IntroductiontoRequirementsEngineering Research Tree Interested Research Area Research Plan Outline Oral Comprehensive Exam

37. Research Plan Activities: Completing the Requirement Specification & Verification Survey. Completing the role identification of Formalism in it. Identifying related open problems. Preparing proposal document Outputs: Submit a paper entitled “How Z helps to specify the requirements of engineering software” to 18th IEEE International Requirements Engineering Conference (RE10), September 27th – October 1st , 2010, Sydney, Australia. Submit a paper entitled “Requirements Engineering: Trends and Issues” to Requirements Engineering Journal, Springer, ISSN: 0947-3602. Formal Requirement Specification (FRS) Technical Report Oral Comprehensive Exam

38. Requirements Elicitation Elicitation / capture / discovery / acquisition The first stage in considering the problem the software system should be able to solve. After system engineering process which defines the context and goal of the software. The task: establishing of boundaries and requirements for the software system. Carried out by: interaction with stakeholders and detailed studying of corresponding knowledge domains. A human activity.  Oral Comprehensive Exam

39. Requirements Elicitation (Cont.) The most widespread techniques are: interviews, scenarios, prototypes, facilitated meetings, observation, etc.  Oral Comprehensive Exam

40. Requirements Analysis After requirements were discovered they must be analyzed to: Necessity (need for the requirement); Detect and resolve drawbacks in them (for example, consistency, conflicts, ambiguity situations, completeness, etc); Improve their quality; They must be structured and refined; Discover the bounds and properties of the system; Discover how system will interact with the environment; Another necessary analysis.  Oral Comprehensive Exam

41. Requirements Analysis (Cont.) The most widespread techniques are: Negotiation classification, conceptual modeling, Object Oriented Modeling UML prioritization, etc.  Oral Comprehensive Exam

42. Requirements Specification Software Requirements Specifications (SRS): a complete description of the behavior of the system to be developed will assist the potential users to determine if the software specified meets their needs or how the software must be modified to meet their needs Includes a set of use cases describe all of the interactions that users will have with the software, numerical values, limits and measurable attributes which may be checked on the working system.  Oral Comprehensive Exam

43. Requirements Specification (Cont.) The basic issues that the SRS writer (s) shall address: Functionality. What is the software supposed to do? External interfaces. How does the software interact with people, the system‘s hardware, other hardware, and other software? Performance. What is the speed, availability, response time, recovery time of various software functions, etc.? Attributes. What are the portability, correctness, maintainability, security, etc. considerations? Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?  Oral Comprehensive Exam

44. An SRS should be: Correct Unambiguous Complete Consistent Ranked for importance and/or stability Verifiable there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement Modifiable Traceable the origin of each of its requirements is clear and It facilitates the referencing of each requirement in future development or enhancement documentation. Requirements Specification (Cont.)  Oral Comprehensive Exam

45. Requirements Specification (Cont.) The corresponding techniques may be divided into two separate major classes: Natural Language (NL) based Drawback difficult for automated processing based on special languages universal approaches Unified Modeling Language domain dependent Z Notation, B-Method) drawback difficult for non-experts to understand Which limits their practical application.  Oral Comprehensive Exam

46. Validation & Verification Verifying a system: Building the system right: Ensuring that the system complies with the system requirements and conforms to its design. Validating a system: Building the right system: making sure that the system does what it is supposed to do in its intended environment. determines the correctness and completeness of the end product, ensures that the system will satisfy the actual needs of the stakeholders.  Oral Comprehensive Exam

47.  Oral Comprehensive Exam

48. Validation & Verification (Continue) Verifying requirements: Proving that each requirement has been satisfied. can be done by logical argument, inspection, modeling, simulation, analysis, expert review, test or demonstration.  Oral Comprehensive Exam

49. Validation & Verification (Continue) Validating requirements: Ensuring that the set of requirements is correct, complete, and consistent, a model can be created that satisfies the requirements a real-world solution can be built and tested to prove that it satisfies the requirements. If RE discovers that the customer has requested a perpetual-motion machine, the project should be stopped.  Oral Comprehensive Exam

50. Validation & Verification (Continue) Validation to ensure that the software engineer has correctly understood the customer‘s requirements and needs. for conformance with company standards To ensure that the requirements are understandable, consistent, complete. Formal notations offer the important advantage of permitting the above properties to be proven  Oral Comprehensive Exam