is 466 Advanced topics in information Systems Lecturer : Nouf Almujally 22 – 10 – 2011

1. is 466Advanced topics in information SystemsLecturer : Nouf Almujally22 – 10 – 2011 College Of Computer Science and Information, Information Systems Department

2. Requirement Engineering

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

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.

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

6. Requirement Engineering • What is requirement engineering ? • The process to obtain customers or end-usersrequirements 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

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

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

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

10. Importance of Requirement Engineering

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

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

13. Task and Process of Requirement Engineering

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

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

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

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?

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

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

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

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

22. Use-case

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

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 Result: agreed software requirements

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)

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

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?

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?

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

30. Technology of Requirement Engineering

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

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

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

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

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

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

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

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

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

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

41. Software Requirement Specification andReview

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

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

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?

45. Questions ??

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.