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 Requirement Engineering Technology Software Requirement Specification and Review 3

4. Technology of Requirement Engineering 4

5. Requirements Elicitation Techniques Interviewing and questionnaires Interviews are in-person meetings where the business analyst asks questions to get information from the stakeholder. Requirements workshops Workshops are facilitated meetings with multiple stakeholders to draw out and document requirements Brainstorming  are used to let the stakeholders come up with creative ideas or new approaches to a problem Observation  Observation is when the business analyst watches the users performing their daily tasks and asks questions about the tasks and work 5

6. Requirements Elicitation Techniques (con.) 6 Use Case Use-cases are a scenario based technique which identify the actors in an interaction and which describe the interaction itself. Storyboards helps you take an idea and translate it into a visual story Prototyping This is the use of partially finished versions of the software that have been created to help validate requirements  A good business analyst should have excellent skills in eliciting good requirements and using the right elicitation technique for each situation.

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

8. 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 8

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

10. 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 10

11. 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 11

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

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

14. 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 14

15. 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 15

16. Software Requirement Specification and Review 16

17. 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 17

18. 18 A sample of a basic SRS outline

19. 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 19

20. 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? 20

21. Questions ?? 21

22. What should you do this week ? Review the lectures. If you have any question related to the assignment please ask me during the tutorial, by email or during the consultation hours. 22