Lecture 5: Requirements Engineering

Slides:



Advertisements
Similar presentations
Requirements Engineering Processes – 2
Advertisements

Software Requirements
Requirements Engineering Process
Requirements Engineering Process
OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 3: Requirements Overview Module 3 - Requirements Overview.
Use Case Diagrams.
Topics covered The requirements engineering process
Software Requirements
Lecture 1: Software Engineering: Introduction
Lecture 3: Software Process Models Dr Valentina Plekhanova University of Sunderland, UK
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 27 Slide 1 Quality Management.
Lecture 8: Testing, Verification and Validation
Lecture 6: Software Design (Part I)
Lecture 7: Software Design (Part II)
25 seconds left…...
We will resume in: 25 Minutes.
Software Requirements
Introduction to Software Engineering Dr. Basem Alkazemi
Soft. Eng. I, Spring 07Dr Driss Kettani, from I. Sommerville1 CSC-3324: Chapter 5 Requirements Engineering Reading: Chap. 6, 7 + annex.
Introduction to Software Engineering
SWE Introduction to Software Engineering
Software Requirements
7M701 1 Software Engineering Software Requirements Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 5
Software Engineering General Project Management Software Requirements
Lecture 2: Software Production & Processes Dr Valentina Plekhanova University of Sunderland, UK
Software Requirements
Soft. Eng. II, Spr. 2002Dr Driss Kettani, from I. Sommerville1 CSC-3325: Chapter 1 (cont ’d) Title : Client requirements (Review) Mandatory reading: I.
Overview of Software Requirements
1 CSC-3324: Chapter 4 Title: What is a requirement? Mandatory reading: Sommerville 6, 7 th ed., Chap.: 7.
1 SWE Introduction to Software Engineering Lecture 11 - Requirements Engineering Processes.
7M822 Software Requirements Introduction 7 September 2010.
Software Requirements
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
Requirements Engineering
1 College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 2 Chapter 6 & 7 System.
The Software Development Life Cycle: An Overview
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
Chapter 4 – Requirements Engineering
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
©Ian Sommerville Software Engineering Slide 1 Software Requirements l Definition: Description and Specifications of a system l Topics covered: Functional.
Chapter 4 Requirements engineering Chapter 4 – Requirements Engineering Lecture 1 1.
Adaptive Processes © Adaptive Processes Simpler, Faster, Better Software Requirements.
Software Requirements Presented By Dr. Shazzad Hosain.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Software Requirements Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn Lecture 4 & 5.
Requirements Engineering Overview Senior Design Don Evans.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Chapter 4 Software Requirements
SOFTWARE REQUIREMENT ANALYSIS AND SPECIFICATION. What is a requirement? It may range from a high-level abstract statement of a service or of a system.
L To identify the services that the customer requires from a system and the constraints under which it operates and is developed.
Requirements Engineering Lesson 2. Terminologies:  Software Acquisition is where requirement engineering significantly meets business strategy.  Software.
Requirements / Specifications. 01/18/10CS-499G2 Requirements Determine what the customer needs (wants) the software to do  What are requirements?  An.
Week 3: Requirement Analysis & specification
Requirements Analysis
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
Chapter 4 Requirements Engineering (1/3) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
1 Software Requirements Descriptions and specifications of a system.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements (utvalgte foiler fra Kap 6 og 7 i Sommerville)
Chapter 4 – Requirements Engineering
Software Requirements
Presentation on Software Requirements Submitted by
Chapter 4 Requirements Engineering (1/3)
Chapter 5 – Requirements Engineering
Chapter 4 Software Requirements
Requirements Engineering
Requirement Engineer Terms and Conditions
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Presentation transcript:

Lecture 5: Requirements Engineering Dr Valentina Plekhanova University of Sunderland, UK http://www.cet.sunderland.ac.uk/~cs0vpl/SE-Com185.htm

What is a Requirement? [Pfleeger, 1998] A requirement is a feature of the system or a description of something the system is capable of doing in order to fulfil the system’s purpose. Lecture 5 Valentina Plekhanova

What is a Requirement? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. May be the basis for a bid for a contract - therefore must be open to interpretation. May be the basis for the contract itself - therefore must be defined in detail. Both these statements may be called requirements. Lecture 5 Valentina Plekhanova

Wicked Problems [Sommerville; Vliet] Originally this term was defined by Rittel and Webber, in 1973. A “wicked problem" is a complex problem, i.e. this problem is very difficult to define and/or identify (e.g. define related entities, definitive problems specification). In general, no one can accurately predict where/when we can expect the problem and what effect it will have on the software production, etc. The problem can be tackled after it has happened. Lecture 5 Valentina Plekhanova

Wicked Problems Most large software systems address wicked problems. Problems which are so complex that they can never be fully understood and where understanding develops during the system development. Therefore, requirements are normally both incomplete and inconsistent. Lecture 5 Valentina Plekhanova

A Stakeholder ..!!! The notion of stakeholder is used to refer to anyone who should have some influence on the system requirements, e.g. end-users, engineers, business managers, domain experts, etc. Lecture 5 Valentina Plekhanova

Some Reasons for Inconsistency Different stakeholders have different requirements and they may define these in different ways. There is a constantly shifting compromise in the requirements... Different people may negotiate different parts. Lecture 5 Valentina Plekhanova

Some Reasons for Incompleteness Requirements can be interpreted differently. Many requirements can be identified clearly only after some experience with the system. Too many details would need to be specified. Customer asks for too little. The world changes. It is difficult to define the level of precision in the requirements statements. Informal language (e.g. natural language) does not help in requirements statements. Lecture 5 Valentina Plekhanova

Requirements: Functional and Non-Functional Functional requirements describe system services or functions. Non-functional requirements is a constraint on the system or on the development process, e.g. timing constraints, standards, etc. Lecture 5 Valentina Plekhanova

Non-Functional Requirements Process Requirements: standards, delivery,etc. External Requirements: ethical, legislative Efficiency Requirements: efficiency, reliability, portability,usability Lecture 5 Valentina Plekhanova

Requirements Engineering The process of establishing the services that   the customer requires from a system … under the constraints with which it operates ... and is developed! Lecture 5 Valentina Plekhanova

The Requirements Engineering Process Feasibility Study Requirements Validation Requirements Definition 1 5 3 2 4 Requirements Analysis Requirements Specification Lecture 5 Valentina Plekhanova

1. Feasibility study 1 Find out if the current user needs can be satisfied given the available technology and budget? A definition of the problems. Alternative solutions and their expected benefits. Required resources, costs, time and delivery dates for each alternative solution. Lecture 5 Valentina Plekhanova

2. Requirements Analysis Find out what system stakeholders require from the system. Lecture 5 Valentina Plekhanova

3. Requirements Definition 4. Requirements Specification …. The ultimate purpose of the requirements-related activities is: To understand the goals of the system; To document the requirements to be met; To specify the qualities required of the software solution: functionality, performance, reliability, etc. Lecture 5 Valentina Plekhanova

3. Requirements Definition A statement in natural language plus diagrams of the services the system provides and its operational constraints. Define the requirements in a form understandable to the customer. It represent an understanding between the customer and developer of what the customer needs/wants. It is usually written jointly by the customer and developer. Written for customers. Lecture 5 Valentina Plekhanova

4. Requirements Specification A structured document setting out detailed descriptions of the system services. Define the requirements in detail. It uses technical terms to define the system services: a very precise, even mathematical description – but it must be understandable by the client. Written as a contract between client and contractor. Lecture 5 Valentina Plekhanova

Software Specification A detailed software description which can serve as a basis for a design or implementation. Written for developers. Lecture 5 Valentina Plekhanova

An Example of: Requirements Document Structure (1) Introduction Describe need for the system and how it fits with business objectives. Glossary Define technical terms used. System models Define models showing (high level architectural) system components and relationships. Lecture 5 Valentina Plekhanova

Requirements Document Structure (cont 2) Non-functional requirements definition Define constraints on the system and the development process. System evolution Define fundamental assumptions on which the system is based and anticipated changes. Requirements specification Detailed specification of functional requirements. Lecture 5 Valentina Plekhanova

Requirements Document Structure (cont 3) Appendices System hardware platform description. Database requirements (as an ER model perhaps). Index More examples of requirements document can be found in [Pfleeger, 1998; Sommerville] Lecture 5 Valentina Plekhanova

5. Requirements Validation Concerned with demonstrating the requirements define the system that the customer really wants.   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. Prototyping is an important technique of requirements validation. Lecture 5 Valentina Plekhanova

Requirements Checking Validity – Does the system provide the functions which best support the customer’s needs? Consistency – Are there any requirements conflicts? Completeness – Are all functions required by the customer included? Realism – Can the requirements be implemented given available budget and technology? Lecture 5 Valentina Plekhanova

Key Points It is very difficult to formulate a complete and consistent requirements specification. A requirements definition, a requirements specification and a software specification are ways of specifying software for different types of reader. The requirements document is a description for customers and developers. Requirements errors are usually very expensive to correct after system delivery. Reviews involving client and contractor staff are used to validate the system requirements. Stable requirements are related to core activities of the customer for the software.  Volatile requirements are dependent on the context of use for the system. Lecture 5 Valentina Plekhanova

Week 8: 24.04.2003-28.04.2003 Project Control Session Tutorial Time: 10 minutes for each Team Students will present project file, particularly Schedule, plus any project documentation. Students will describe where they are in the project and any problems encountered. During the discussion reviewers will ask to see evidence of deliverables for any tasks that are complete to determine whether they have in fact been done. Lecture 5 Valentina Plekhanova