Requirements Engineering Processes. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements.

Slides:



Advertisements
Similar presentations
Requirements Engineering Process
Advertisements

Requirements Engineering Process
SWE Introduction to Software Engineering
Soft. Eng. I, Spring 07Dr Driss Kettani, from I. Sommerville1 CSC-3324: Chapter 5 Requirements Engineering Reading: Chap. 6, 7 + annex.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Requirements Engineering Processes
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
©Ian Sommerville 2000Software Engineering, 6/e, Chapter 61 Requirements Engineering Processes l Processes used to discover, analyse and validate system.
Overview of Software Requirements
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
1 SWE Introduction to Software Engineering Lecture 11 - Requirements Engineering Processes.
Chapter 4 Capturing the Requirements 4th Edition Shari L. Pfleeger
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes 1.
Dr Suad AlRamouni. ◦ Understand some key terms used in software requirements engineering. ◦ Distinguish requirements development from requirements management.
©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.
7. Requirements Engineering Processes
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
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.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 The requirements engineering process.
Requirements Engineering Requirements Elicitation Requirements Analysis Requirements Validation Requirements Management.
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
 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.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
Chapter 4 Requirements Engineering Processes Objectives l To describe the principal requirements engineering activities and their relationships l To.
Requirements Engineering Requirements Elicitation Process Lecture-9.
Lecture 7: Requirements Engineering
IS2210: Systems Analysis and Systems Design and Change Twitter:
Requirements Engineering Overview Senior Design Don Evans.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Chapter 4 Software Requirements
Software Engineering, 8th edition. Chapter 7 1 Courtesy: ©Ian Sommerville 2006 March 20 th, 2008 Lecture # 12 Requirements Engineering Processes.
©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.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Requirements Validation
Requirements Engineering. Requirements engineering processes The processes used for RE vary widely depending on the application domain, the people involved.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Requirements Engineering Process
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Requirement Engineering
Requirements Analysis
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
CS223: Software Engineering Lecture 8: Requirement Engineering.
Chapter 4 – Requirements Engineering Part 2 1Chapter 4 Requirements engineering.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Requirements Engineering Processes, York EngD Programme, 2009Slide 1 Requirements engineering processes Prof Ian Sommerville.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
1 Requirements Analysis Lecture # Recap of Requirements Elicitation - 1 Requirements elicitation deals with discovering requirements for a software.
 The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However,
CHAPTER 5 REQUIREMENTS ENGINEERING PROCESSES 1. Objectives  To describe the principal requirements engineering activities and their relationships  To.
REQUIREMENTS ENGINEERING PROCESSES Chapter 6. Activities in Requirements Engineering processes  Requirements elicitation;  Requirements analysis; 
Requirements Engineering Processes
Chapter 4 Requirements engineering
Requirements Engineering Process
SNS College of Engineering Coimbatore
EKT 421 SOFTWARE ENGINEERING
Requirements Engineering Process
Requirements Engineering Processes
Requirements Validation – I
SNS College of Engineering Coimbatore
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
INTRODUCTION OF REQUIREMENT ENGINEERING Chapter- one.
Presentation transcript:

Requirements Engineering Processes

Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements elicitation and analysis Requirements validation Requirements management l Techniques for Requirements Elicitation

Definitions l Requirements are the descriptions of the services provided by a system for the customer and The constraints under which it operates and is developed. l REP is the process of Discovering, Analyzing, Documenting and Validating the requirements of the system; Each software development process goes through the phase of requirements engineering

Requirements engineering processes l The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.

The requirements engineering process Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation Feasibility report System models User and system requirements Requirements document

Phases of Requirements Engineering Process

Feasibility study l A feasibility study decides whether or not the proposed system is worthwhile. l A short focused study that checks If the system contributes to organisational objectives; If the system can be engineered using current technology and within budget; If the system can be integrated with other systems that are used.

Elicitation and analysis l Sometimes called requirements elicitation or requirements discovery. l A people-intensive process. l Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. l May involve end-users, managers, engineers involved in maintenance, domain experts, etc. These are called stakeholders.

Problems of requirements analysis l Stakeholders don’t know what they really want. l Stakeholders express requirements in their own terms. l Different stakeholders may have conflicting requirements. l Organisational and biased factors may influence the system requirements. l The requirements change during the analysis process. New stakeholders may emerge and the business environment change.

Requirements validation l Concerned with demonstrating that the requirements define the system, that the customer really wants. l Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

Requirements checking l Validity. Does the system provide the functions which best support the customer’s needs? l Consistency. Are there any requirements conflicts? l Completeness. Are all functions required by the customer included? l Realism. Can the requirements be implemented given available budget and technology l Verifiability. Can the requirements be checked?

Requirements management l Requirements management is the process of managing changing requirements during the requirements engineering process and system development. l Requirements are inevitably incomplete and inconsistent New requirements emerge during the process as business needs change and a better understanding of the system is developed; Different viewpoints have different requirements and these are often contradictory.

Techniques for Requirements Elicitation l Interviewing l Brainstorming l Prototyping l Requirement Workshop l “When people talk, listen completely. Most people never listen.”

Interviewing Interviews are the commonly used and most popular method for requirements elicitation. In this method the analyst and the engineers of the requirements engineering process discuss with the different types of stake holders to understand the requirements of the system and the objective they have to fulfil in the system. There are typically 2 main types of interviews 1. Closed Interview: In this interview the requirements engineer prepare some predefined questions and he tries to get the answers for these questions from the stake holders. 2. Open interview: In this interview the requirements engineer does not prepare any predefined questions, and he tries to get the information from the stakeholders in open discussions. He mostly concentrates on finding the stake holders expectations on the system.

Brainstorming l Brainstorming is a techniques used to generate new ideas and find the solution to a specific issue. l This is conducted as a conference with six to ten members. l The members are from the different departments and domain experts are also included. l This conference is headed by the organizer, who states the issue to be discussed. l The conference is generally held in a round table fashion. l Every member person is allotted with certain time interval to explain their ideas. l Notepads are provided to all members to write their ideas and suggestions. l The team of brainstorming will then decide the best idea by voting from the group and that idea is selected as the solution to the issue discussed in the conference.

Brainstorming can be used to answer the following questions What exactly the system should provide ? What are the business and organization rules required to follow ? What type of questions should be there in the interviews and questionnaires? What are the risk factors effect the proposed system development and what to do avoid that?

Prototyping l The Prototype is the representations or visualizations of the actual system parts. l The prototype is designed in the early stages of the implementation of the project. It provides the General idea of the actual system functions and the work flow. Prototyping is used to gather the requirements from the users by presenting GUI based system functions. l Main aim of Requirements Elicitation is to gather the requirements before the product is developed. But it is difficult to discover the additional requirements until it comes in to usage or some body is actually using it. l The process of gathering the requirements from the stakeholders and the end users is limited and it is difficult to discover their expectations and the requirements on the new product with out providing some model that resembles the appearance of the real product.

l A prototype represents the actual product in both functional and graphical sense. l It provides the flexibility to the users and the stake holders to work with the initial version of the product to understand the system and discuss them to think of the additional and missed requirements. l Prototyping is a most expensive than the all other methods of requirements elicitation

Requirements workshop l A requirements workshop is a structured, facilitated event in which a carefully selected group of stakeholders work together to discover, create, verify, and document predefined requirements deliverables, or work products. l The group is comprised a balanced mix of business and IT people and is led by a neutral facilitator.

l The most successful workshops are collaborative. This means that the group joins together to create work products designed to achieve their common goal. l These workshop participants are productive because collectively they have the right mix of skills and knowledge to create the work products. l Members of the group act interdependently, relying on one other’s knowledge, experience, skills, and perspectives – they are motivated to act together.

Key points l The requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements management. l Requirements elicitation and analysis is iterative involving domain understanding, requirements collection, classification, structuring, prioritisation and validation. l Systems have multiple stakeholders with different requirements.

Key points l Social and organisation factors influence system requirements. l Requirements validation is concerned with checks for validity, consistency, completeness, realism and verifiability. l Business changes inevitably lead to changing requirements. l Requirements management includes planning and change management.