1. IS 466 ADVANCED TOPICS IN INFORMATION SYSTEMS LECTURER : NOUF ALMUJALLY 22 – 10 – 2011 College Of Computer Science and Information, Information Systems Department

2. Requirement Engineering 2

3. Objectives What is Requirement Engineering? Task and Process of Requirement Engineering Requirement Engineering Technology Software Requirement Specification and Review 3

4. Questions? If you are required to develop a library information software system, what will you do firstly? What functions that the system may have? What behaviors that the system may have? What performances that the system may have? What is the scope and boundary of the software? ……. Etc. 4

5. Software Requirement To understand customers’ requirements about the software to be developed is extremely important Software requirement Customers’ needs about the developed software, including functions, performance, design constraints, schedule, etc. Sample of software requirements Function: borrow book, renew book, … Performance: the time of query book must be lower 1second Constraints: software should be deployed and run under windows OS Schedule: development period is 6 months 5

6. Requirement Engineering What is requirement engineering ? The process to obtain customers or end-users requirements of software includes a set of tasks that lead to an understanding of software requirements Helps software engineers to better understand the problem they will work to solve 6

7. Who Does IT? Stakeholders : are individuals who affect or are affected by the software product Customers: request, purchase, and/or pay for the software product in order to meet their business objectives. End-users: use the product directly or use the product indirectly by receiving reports, outputs, or other information generated by the product The requirements analyst: responsible for eliciting the requirements from the customers, users, and other stakeholders, analyzing the requirements, writing the requirements specification, and communicating the requirements to development and other stakeholders 7

8. Who Does IT? The designers: responsible for translating the requirements into the software’s architectural and detailed designs that specify how the software will be implemented. The developers: responsible for implementing the designs by creating the software products. The project managers: responsible for planning, monitoring, and controlling the project and guiding the software development team to the successful delivery of the software 8

9. Importance of Requirement Engineering Basis and precondition of software development If you do not know what the problems are, you will have no way to know how to solve Without it, the resulting software has a high possibility of not meeting customers’ needs Establishes a solid base for design and construction Standard to check whether the developed software meets customers or end-users’ requirements 9

10. Importance of Requirement Engineering 10

11. Complexity of Requirement Engineering Customers are unable to express requirements explicitly  Typically, they can not tell you what they want clearly The requirements that customers or end-users present are often  incomplete  inaccurate  inconsistent Software requirements are often extremely complex and large scale 11

12. Problems and Challenges If the above problems can not be solved, the developed software will be incorrect  Lost the desired functions of customers  Implemented functions are not the right ones that customers or end-users want Therefore, technologies and methods are necessary to support requirement engineering 12

13. Task and Process of Requirement Engineering 13

14. Task of Requirement Engineering Obtain and understand software requirements in a complete, consistent and accurate way, and generate software requirement specification (SRS) document. 14

15. Process of Requirement Engineering Requirement engineering is completed through the following seven activities: Inception Elicitation Elaboration Negotiation Specification Validation Management 15

16. Inception (1/2) Purpose Identify and discuss with stakeholders Anyone who benefits in a direct or indirect way from the system which is being developed: Customers, end-users, consultants, product engineers, software engineers Approach Find and create stakeholders list Ask: “who else do you think I should talk to?” to find more Result A list of stakeholders 16

17. Inception (2/2) Questions when interacting with stakeholders: Who is behind the request for this work? Who will use the solution? What will be the economic benefit of a successful solution Is there another source for the solution that you need? 17

18. Elicitation (1/3)  requirements gathering Purpose Elicit requirements from all stakeholders Identify the problem Define the scope of problem Propose elements of the solution Negotiate different approaches, and Specify a preliminary set of solution requirements 18

19. Elicitation (2/3) Approach Meetings are conducted and attended by both software engineers and customers Rules for preparation and participation are established An agenda is suggested A "facilitator" (can be a customer, a developer, or an outsider) controls the meeting 19

20. Elicitation (3/3) Result: elicitation work products A statement of need and feasibility A bounded statement of scope for the system or product A list of stakeholders who participated in requirements elicitation A description of the system’s technical environment A list of requirements and the domain constraints that apply to each A set of usage scenarios that provide insight into the use of the system or product under different operating conditions Any prototypes developed to better define requirements 20

21. Elaboration (1/2) Purpose Create a refined analysis model of software functions, features, and constraints for analyzing Approach Modelling, refinement Scenario-based Use-case - descriptions of the interaction between an “actor” and the system 21

22. Use-case 22

23. Elaboration (2/2) Approach Behaviour-based: state diagram Flow-oriented: data flow diagram Result Requirement analysis model of software, which defines the informational, functional and behavioral domain of problem 23

24. Negotiation Purpose Conflict requirements Unpractical requirements with limited resources Agree on a deliverable system that is realistic for developers and customers Approach Identify the potential conflict and unpractical requirements Rank requirements and discuss conflicts Reconcile these conflicts through negotiation Eliminate, combined and modified requirements Resu lt : agreed software requirements 24

25. Specification Purpose Create the documents of software requirements Approach A written document A set of models A formal mathematical A collection of user scenarios (use-cases) A prototype Result Software requirement specification (SRS) 25

26. Validation (1/3) Purpose To find the errors or missing information in SRS A review mechanism that looks for Errors in content or interpretation Areas where clarification may be required Missing information Inconsistencies (a major problem when large products or systems are engineered) Conflicting or unrealistic (unachievable) requirements. Result Validated software requirement specification 26

27. Validation (2/3) Questions when validating Is each requirement consistent with the overall objective for the system/product? Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? Is each requirement bounded and unambiguous? 27

28. Validation (3/3) Questions when validating (cont.) Do any requirements conflict with other requirements? Is each requirement achievable in the technical environment that will house the system or product? Is each requirement testable, once implemented? Does the requirements model properly reflect the information, function and behavior of the system to be built? 28

29. Management Requirement management is a set of activities that help the project team identify, control, and track requirements and changes to requirements at any time as the project proceeds Each requirement is assigned a unique identifier 29

30. Technology of Requirement Engineering 30

31. Requirements Elicitation Techniques Interviewing and questionnaires Requirements workshops Brainstorming Storyboards Use Cases Prototyping 31

32. Requirement Modelling and Analyzing Problem Decomposition Abstract Modelling Multiple Viewpoints Prototype 32

33. Problem Decomposition What is problem decomposition? Decompose big problem into small problems Decrease and control problem complexity Sample of problem decomposition Reader management Book management Book borrow 33

34. Abstract (1/2) What is abstract? Catch the related parts and discard the unrelated parts To grasp the essence and core of problem 34

35. Abstract (2/2) Abstract of reader (related parts) Name Department Photo Type Email Telephone Mobile Abstract of reader (unrelated parts)  Height  Age  Thesis  Father  Blood  Supervisor 35

36. Modelling (1/3) What is model of system Model is the simplification of the real system and it encompasses the related parts of system, ignores the unrelated parts of system Software requirement model describes the requirement of system to be developed in an accurate way Why modelling Simplify the description and analysis of software requirement Specify the software requirements from multiple viewpoints and different levels 36

37. Modelling (2/3) Methods for requirement modeling Data flow requirement modelling Object-oriented modelling 37

38. Modelling (3/3) Sample of modeling: Data Flow Diagram 38

39. Multiple Viewpoint What is multiple viewpoint To describe and analyze software requirements from multiple viewpoints and different levels To grab the customers’ requirements in a complete and clear way 39

40. Prototyping What is prototype? Prototype is the intuitive and simple model of systems to be developed. It mainly focuses on the operation style, process and interface. Why prototype? Prototype as interaction media between developers and customers Prototype can easily find the problems of software requirements 40

41. Software Requirement Specification and Review 41

42. Software Requirement Specification (SRS) Software requirements should be written as a Document The SRS fully describes what the software will do and how it will be expected to perform. Functions and Behaviours E.g., borrow book, renew book Performances Response time should be less than 1 second Design constraints Running under Windows XP Others Schedule: 6 months 42

43. Review of SRS Reviews is necessary before SRS is to be submitted formally to designers Who participate in the reviews Customers and end-users Requirement analysts Software designer 43

44. Attributes of a Good Requirement Specification Verifiability: Can the requirements be checked? Consistency: Are there any requirements conflicts? Completeness: Are all functions required by the customer included? Comprehensibility: Is the requirement properly understood? Adaptability: Can the requirement be changed without a large impact on other requirements? Traceable: Is the origin of the requirement clearly stated? 44

45. Questions ?? 45

46. What should you do this week ? Review the lectures. Monday is review lecture, please print the slides. If you have any question related to the assignment please ask me during the tutorial, by email or during the consultation hours. 46