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

Slides:



Advertisements
Similar presentations
Object-Oriented Analysis and Design LECTURE 3: REQUIREMENTS DISCIPLINE.
Advertisements

IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
May 14, May 14, 2015May 14, 2015May 14, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University, Azusa,
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
ACTIVELY ENGAGING THE STAKEHOLDER IN DEFINING REQUIREMENTS FOR THE BUSINESS, THE STAKEHOLDER, SOLUTION OR TRANSITION Requirements Elicitation.
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
Identifying Needs and Establishing Requirements John Thiesfeld Jeff Morton Josh Edwards.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Soft. Eng. II, Spr. 2002Dr Driss Kettani, from I. Sommerville1 CSC-3325: Chapter 1 (cont ’d) Title : Client requirements (Review) Mandatory reading: I.
SE 555 Software Requirements & Specification Requirements Validation.
1 Software Requirements Specification Lecture 14.
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
1 SWE Introduction to Software Engineering Lecture 11 - Requirements Engineering Processes.
Requirements Gathering : Determining the scope of the system 1. Elicitiation – fact finding 2. Specification 3. Validation.
Software Requirements and the Requirements Engineering Process Chapters 5 and 6.
1 College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 2 Chapter 6 & 7 System.
RUP Requirements RUP Artifacts and Deliverables
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
CC20O7N - Software Engineering 1 CC2007N Software Engineering 1 Requirements Engineering Practices with Techniques.
Dineshwari Byrappa Nagraj Rashi Gupta Shreya Modi Swati Satija Magesh Panchanathan.
Software Engineering CS B Prof. George Heineman.
Requirements Analysis
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
Advanced Topics in Requirement Engineering. Requirements Elicitation Elicit means to gather, acquire, extract, and obtain, etc. Requirements elicitation.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Chapter 5: Requirement Engineering Process Omar Meqdadi SE 2730 Lecture 5 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyze and.
 To describe the principal requirements engineering activities and their relationships  To introduce techniques for requirements elicitation and analysis.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Requirements Engineering Requirements Elicitation Process Lecture-8.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
IS 466 ADVANCED TOPICS IN INFORMATION SYSTEMS LECTURER : NOUF ALMUJALLY 22 – 10 – 2011 College Of Computer Science and Information, Information Systems.
Project Analysis Course ( ) Course Overview Project ideas Presentation.
1 CS 426 Senior Projects Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2005] January 31, 2012.
Requirements Engineering Requirements Elicitation Process Lecture-9.
Chapter 9 요구사항 모델링: 시나리오 기반 방법론 Requirements Modeling: Scenario-Based Methods 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim.
Software Engineering Saeed Akhtar The University of Lahore Lecture 7 Originally shared for: mashhoood.webs.com.
Lecture 7: Requirements Engineering
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Chapter 4 Requirements Engineering (3/3) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Requirements Engineering Process
Identifying Needs and Establishing Requirements Presenters: Veronica Gasca Jennifer Rhough.
Requirements Engineering Processes. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements.
Prof. Hany H. Ammar, CSEE, WVU, and
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Requirement Engineering
1 Week 8 - Life cycle vs Methodology IT2005 System Analysis & Design.
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
CS223: Software Engineering Lecture 8: Requirement Engineering.
Chapter 3: The Requirements Workflow [Arlow and Neustadt, 2005] CS 426 Senior Projects in Computer Science University of Nevada, Reno Department of Computer.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
1 Requirements Elicitation – 2 Lecture # Requirements Engineering Process Requirements Elicitation Requirements Analysis and Negotiation Requirements.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
 The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However,
 System Requirement Specification and System Planning.
Pepper modifying Sommerville's Book slides
Software Requirements and the Requirements Engineering Process
SNS College of Engineering Coimbatore
CS 790M Project preparation (I)
Chapter 3: The Requirements Workflow
Requirements Engineering Processes
CS 426 CS 791z Topics on Software Engineering
CS 426 CS 791z Topics on Software Engineering
Presentation transcript:

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

Requirement Engineering 2

Objectives Requirement Engineering Technology Software Requirement Specification and Review 3

Technology of Requirement Engineering 4

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

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.

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

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

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

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

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

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

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

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

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

Software Requirement Specification and Review 16

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 A sample of a basic SRS outline

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

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

Questions ?? 21

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 or during the consultation hours. 22