Chapter 4 Requirements engineering Chapter 4 – Requirements Engineering Lecture 1 1.

Slides:



Advertisements
Similar presentations
Software Requirements
Advertisements

Software Requirements
Software Requirements
Introduction to Software Engineering Dr. Basem Alkazemi
Software Engineering COMP 201
Chapter 7 – Requirements Engineering
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
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements.
Software Requirements
1 To introduce the concepts of user and system requirements To introduce the concepts of user and system requirements To describe functional and non- functional.
Soft. Eng. II, Spr. 2002Dr Driss Kettani, from I. Sommerville1 CSC-3325: Chapter 1 (cont ’d) Title : Client requirements (Review) Mandatory reading: I.
1 CSC-3324: Chapter 4 Title: What is a requirement? Mandatory reading: Sommerville 6, 7 th ed., Chap.: 7.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 5 Slide 1 Software Requirements l Descriptions and specifications of a system.
Software Requirements
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
Chapter 4 – Requirements Engineering
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Software Requirements l Descriptions and specifications of a system.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements.
Dr. Tom WayCSC Software Requirements CSC 4700 Software Engineering Lecture 2 Based on Sommerville, Chapter 6.
AGU COE/COC Software Engineering CSE 402 / CSC 308 Slide 1 Requirements engineering l The process of establishing the services that the customer requires.
Adaptive Processes © Adaptive Processes Simpler, Faster, Better Software Requirements.
Software Requirements Presented By Dr. Shazzad Hosain.
소프트웨어공학 강좌 1 Chap 4. Software Requirements - Descriptions and specifications of a system - Soo-Mi Choi
Chapter 4 – Requirements Engineering 1Chapter 4 Requirements engineering.
Software Requirements Descriptions and specifications of a system.
 Dr. Syed Noman Hasany.  Review of known methodologies  Analysis of software requirements  Real-time software  Software cost, quality, testing and.
Software Requirements Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn Lecture 4 & 5.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 6 Slide 1 Software Requirements.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements.
Requirements Engineering Overview Senior Design Don Evans.
Chapter 4 – Requirements Engineering Lecture 1 Chapter 4 Requirements engineering1.
IS550: Software requirements engineering Dr. Azeddine Chikh 2. Functional and non-functional requirements.
L To identify the services that the customer requires from a system and the constraints under which it operates and is developed.
Software Engineering C h a p t e r 4 Requirements E n g i n e e r i n g Dr.Doaa Sami Modified from Sommerville’s originals.
Requirements Engineering Lesson 2. Terminologies:  Software Acquisition is where requirement engineering significantly meets business strategy.  Software.
Week 3: Requirement Analysis & specification
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 6: Requirement Engineering.
Chapter 4 – Requirements Engineering Lecture 1 The hardest part of the software task is arriving at a complete and consistent specification, and much of.
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.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
Chapter 4 – Requirements Engineering 1Chapter 4 Requirements engineering.
Chapter 3 – Requirements Engineering Lecture 1 1Chapter 4 Requirements engineering.
Requirement Classification Nisa’ul Hafidhoh Teknik Informatika
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 1 Chapter 4 – Requirements Engineering.
Software Engineering, COMP201 Slide 1 Software Requirements.
EKT 421 SOFTWARE ENGINEERING
Chapter 4 – Requirements Engineering
Software Requirements
Presentation on Software Requirements Submitted by
Chapter 4 Requirements Engineering (1/3)
Chapter 4 – Requirements Engineering
Chapter 5 – Requirements Engineering
SNS College of Engineering Coimbatore
Software Requirements
Software Requirements
CS310 Software Engineering Lecturer Dr.Doaa Khafaga
Software requirements
Chapter 3 Requirements Engineering
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Software Design and Development Processes
Presentation transcript:

Chapter 4 Requirements engineering Chapter 4 – Requirements Engineering Lecture 1 1

Chapter 4 Requirements engineering Topics covered  Functional and non-functional requirements  The software requirements document  Requirements specification  Requirements engineering processes  Requirements elicitation and analysis  Requirements validation  Requirements management 2

Chapter 4 Requirements engineering Requirements Engineering  The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.  The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. 3

Chapter 4 Requirements engineering 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.  This is inevitable as requirements may serve a dual function  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. 4

Chapter 4 Requirements engineering Requirements Abstraction (Davis) “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.” 5

Chapter 4 Requirements engineering Types of Requirements  User requirements  Statements in natural language plus diagrams of the services the system provides and its operational constraints.  Written for customers.  System requirements  A structured document setting out detailed descriptions of the system’s functions, services and operational constraints.  Defines what should be implemented so may be part of a contract between client and contractor.  Whom do you think these are written for?  These are higher level than functional and non-functional requirements, which these may subsume. 6

Chapter 4 Requirements engineering User and System Requirements 7

Chapter 4 Requirements engineering Functional and Non-functional requirements  Functional requirements  Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.  May state what the system should not do.  Non-functional requirements  Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.  Often apply to the system as a whole rather than individual features or services.  Domain requirements  Constraints on the system from the domain of operation 8

Chapter 4 Requirements engineering Functional Requirements  Describe functionality or system services.  Depend on the type of software, expected users and the type of system where the software is used.  Functional user requirements may be high-level statements of what the system should do.  Functional system requirements should describe the system services in detail.  Essentially, these are the ‘whats’ of the system that we often refer to. These are not ‘all that there is,’ but these should describe the overall functionality of the system. 9

Chapter 4 Requirements engineering Non-functional Requirements  These define system properties and constraints e.g. reliability, response time, maintainability, scalability, portability, and storage requirements.  Constraints are I/O device capability, system representations, etc.  Process requirements may also be specified mandating a particular IDE, programming language or development method.  (Often internal to an organization or required for fit / compatibility with other comparable systems.)  Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless. 10

Chapter 4 Requirements engineering Types of Nonfunctional Requirements 11

Chapter 4 Requirements engineering Non-functional Requirements Implementation  Non-functional requirements may affect the overall architecture of a system rather than the individual components.  For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components.  A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required.  It may also generate requirements that restrict existing requirements. 12

Chapter 4 Requirements engineering Metrics for specifying nonfunctional requirements PropertyMeasure SpeedProcessed transactions/second User/event response time Screen refresh time SizeMbytes Number of ROM chips Ease of useTraining time Number of help frames ReliabilityMean time to failure (MTTF) Probability of unavailability Rate of failure occurrence Availability RobustnessTime to restart after failure (MTTR) Percentage of events causing failure Probability of data corruption on failure PortabilityPercentage of target dependent statements Number of target systems 13

Chapter 4 Requirements engineering Domain requirements problems  Understandability  Requirements are expressed in the language of the application domain;  Application written for mortgage banking people need to express functionality in terms of home loans, mortgage balances, escrow, investor accounting, foreclosure, etc.  This is often not understood by software engineers developing the system.  Implicitness  Domain specialists understand the area so well that they do not think of making the domain requirements explicit.  And this is often a major problem in communications!!! 14

Chapter 4 Requirements engineering Key points  Requirements for a software system set out what the system should do and define constraints on its operation and implementation.  Functional requirements are statements of the services that the system must provide or are descriptions of how some computations must be carried out.  Non-functional requirements often constrain the system being developed and the development process being used.  They often relate to the emergent properties of the system and therefore apply to the system as a whole. 15