Fundamentals: Software Engineering. Objectives. Last lectures. Unit 2: Light Introduction to Requirements Engineering

Similar documents
Software Design Models, Tools & Processes. Lecture 2: Inception Phase Cecilia Mascolo

Software specification and modelling. Requirements engineering

Requirements. Requirements. Types of Requirement. What Is a Requirement?

Software Engineering - I

CIS 890: Safety Critical Systems

SE351a: Software Project & Process Management. 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa

Requirements Engineering

Requirement Analysis

Requirements Engineering. Version October 2016

Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 1

Requirements Engineering. Establishing what the customer requires from a software system. Requirements Engineering. What is a Requirement?

Mathematics and Computing: Level 2 M253 Team working in distributed environments

Software Engineering. Lecture 10

Software Requirements and the Requirements Engineering Process. Chapters 5 and 6

Lesson 06. Requirement Engineering Processes

Requirements Engineering: Specification & Validation. Software Requirements and Design CITS 4401 Lecture 18

Critical Systems. Objectives. Topics covered. Critical Systems. System dependability. Importance of dependability

Unit 1 Introduction to Software Engineering

Requirements Engineering Process

Rules of Writing Software Requirement Specifications

REQUIREMENTS. Michael Weintraub Spring, 2016

Lecture 6: Requirements Engineering

Human Error Taxonomy

CS3500: Object-Oriented Design Fall 2013

Natural Language Specification

Ch 4: Requirements Engineering. What are requirements?

Requirements Engineering

Lecture 7 (3-April-2013)

Requirements Engineering. Csaba Veres

IT risks and controls

Lecture 8 Requirements Engineering

Lecture 5: Requirements Specifications

Requirements. Chapter Learning objectives of this chapter. 2.2 Definition and syntax

Software Specification and Architecture 2IW80

VO Software Engineering

Intro to Software Requirements

Expression des Besoins et Identification des Objectifs de Sécurité

Chapter 8: SDLC Reviews and Audit Learning objectives Introduction Role of IS Auditor in SDLC

Introduction to Software Specifications and Data Flow Diagrams. Neelam Gupta The University of Arizona

Quality Software Requirements By J. Chris Gibson

Administrivia. Wednesday: Requirements and Specification. CS169 Lecture 4. We assign teams and you start on Monday. Determining Stakeholders and Needs

Lecture 9 Requirements Engineering II

CS350 Lecture 2 Requirements Engineering. Doo-Hwan Bae

Requirements Engineering. Objectives. System requirements. Types of requirements. FAQS about requirements. Requirements problems

The software lifecycle and its documents

Software Engineering Unit 4- Requirement Analysis and Specification

POSSIBLE DATA OBJECTS FOR A LIBRARY RFID SYSTEM

Chapter 4 Objectives

Business continuity management and cyber resiliency

Requirements Validation and Negotiation

The Systems Engineering Tool Box

The candidate has provided a brief introduction to the organisation and client

Modeling Issues Modeling Enterprises. Modeling

Delimited. Interfaced. Readable. Modifiable. Verifiable. Prioritized* Endorsed

Data Models: The Center of the Business Information Systems Universe

Software Specification 2IX20

This Policy has been prepared with due regard to the General Data Protection Regulation (EU Regulation 2016/679) ( GDPR ).

Information Security Controls Policy

Chapter 4 Requirements Engineering

Software Engineering

Rules for Operators. Version 6 / Version 6, 13 May 2011 Page 1/12

CERTIFICATION BODY (CB) APPROVAL REQUIREMENTS FOR THE IFFO RESPONSIBLE SUPPLY (IFFO RS) AUDITS AND CERTIFICATION

PESIT Bangalore South Campus Hosur road, 1km before Electronic City, Bengaluru -100 Department of MCA

Requirements Validation and Negotiation

Scheme Document SD 003

Automatic Merging of Specification Documents in a Parallel Development Environment

GDPR: Get Prepared! A Checklist for Implementing a Security and Event Management Tool. Contact. Ashley House, Ashley Road London N17 9LZ

Lecture 19 Engineering Design Resolution: Generating and Evaluating Architectures

Requirements Engineering. Materials: Pressman (chapters 8,9, 10, 11) Sommerville (Chapters 4, 5)

For many people it would appear that there is no difference between information and data.

Requirements engineering

SAMPLE REPORT. Business Continuity Gap Analysis Report. Prepared for XYZ Business by CSC Business Continuity Services Date: xx/xx/xxxx

SEG3201 Basics of the Requirements Process

Requirements Elicitation

"PPS" is Private Practice Software as developed and produced by Rushcliff Ltd.

cs465 principles of user interface design, implementation and evaluation

EXAM PREPARATION GUIDE

SE351a: Software Project & Process Management. 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa

The Analysis and Proposed Modifications to ISO/IEC Software Engineering Software Quality Requirements and Evaluation Quality Requirements

Static Analysis of Embedded Systems

1- ASECAP participation

Criteria for selecting methods in user-centred design

UNIT-II REQUIREMENTS ANALYSIS AND SPECIFICATION

Information Security Policy

Lecture 5 Safety Analysis FHA, HAZOP

IT Accessibility

Requirements Analysis

AS/NZS ISO/IEC 25030:2013

Requirements Validation and Negotiation (cont d)

In this Lecture you will Learn: Testing in Software Development Process. What is Software Testing. Static Testing vs.

Product. e ss. P roc. so get the right requirements. Garbage in garbage out,

NHS Gloucestershire Clinical Commissioning Group. Business Continuity Strategy

These special conditions supplement the general conditions of service and the special conditions of leasing a dedicated server.

Certification Guidelines IPMA Level A

Data Processing Amendment to Google Apps Enterprise Agreement

Objectives of the Security Policy Project for the University of Cyprus

AS/NZS ISO/IEC/IEEE 42010:2013

EXAM PREPARATION GUIDE

AERONAUTICAL COMMUNICATION PANEL WORKING GROUP N. PM-CPDLC Validation Report

Requirements Engineering. Version November 2012

Transcription:

Fundamentals: Software Engineering Dr. Rami Bahsoon School of Computer Science University of Birmingham r.bahsoon@cs.bham.ac.uk Unit 2: Light Introduction to Requirements Engineering Dr R Bahsoon 1 Objectives o To introduce the concepts of user and system requirements o To describe functional and non-functional requirements o To explain how software requirements may be organised in a requirements document Dr R Bahsoon 2 Last lectures Dr R Bahsoon 3 1

Requirements analysis and definition The process of establishing what services are required and the constraints on the system s operation and development. What is the system about? Requirements engineering process Feasibility study; Requirements elicitation and analysis; Requirements specification; Requirements validation. Dr R Bahsoon 4 Requirements Engineering Process Activities Coursework Output Dr R Bahsoon 5 Requirements Engineering o The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. o It may range from a high-level abstract statement of a service or of a system constraint to a detailed functional specification. Dr R Bahsoon 6 2

Requirements: General Statement o The system will maintain records of all library items including books, serials, newspapers, magazines, video and audio tapes, o No item shall be removed from the library without the details of its borrowing being recorded in the system o All items shall have a bar code containing a unique reference number Could be general statements showing how the system should achieve, interact with the user, other systems, and environment. Dr R Bahsoon 7 Requirements: Detailed Statements o Could be detailed statements of the system s functionality FUNCTIONAL REQUIREMENTS o The system shall permit all users to search for an item by title, by author, by ISBN o Borrowed items that are one day overdue shall cause a reminder e- mail to the borrower o Could be statements of the practical constraints or limitations within which the system must operate --- Non- FUNCTIONAL REQUIREMENTS o The system shall respond to a transaction requests from a user within 1.5 seconds o Could be statements on how the system to be implemented --- Implementation REQUIREMENTS o When an item is borrowed or returned, it should be scanned through a card reader Dr R Bahsoon 8 Eliciting Requirements o Process of capturing or discovering requirements o Stakeholder consultations (interviews) o Scenarios (i.e., showing state of the system and flow of activities and events) o Observations o Revising existing documentations, manual system etc. Dr R Bahsoon 9 3

Definitions and Specifications o Statements in natural language.. o Perhaps, expressed in mathematical model o Noted in Diagrams showing what the system provides and its operational constraints, showing behaviour, interaction o Perhaps, written in a formal language o Or perhaps, written in Structured English Dr R Bahsoon 10 Definitions and Specifications Language! ID Dr R Bahsoon 11 Problems with Requirements Specification o Ambiguity The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult. o Over-flexibility The same thing may be said in a number of different ways in the specification. o Lack of modularisation NL structures are inadequate to structure system requirements. o Others - inconsistency, missing requirements, stakeholders bias, incompleteness, redundancy, irrelevance, overloaded statements. Dr R Bahsoon 12 4

Functional & Non-Functional Requirements o Functional requirements Statements of services the system should provide, how the system should react to particular inputs o Non-functional requirements constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Dr R Bahsoon 13 Examples of Functional Requirements o The library system shall provide a facility for identifying the identity of a library user o The library system shall provide a reminder when the book is overdue Dr R Bahsoon 14 Non-functional Requirements o These define system properties and constraints o e.g. reliability, security, availability, etc. response time o storage requirements. Constraints are I/O device capability, distribution paradigm etc. o Use of particular systems, programming language or development methods etc. o Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless. [A constraint on how the functional requirements may be implemented] Dr R Bahsoon 15 5

Non-functional Requirements The library system shall authenticate a library customer in five seconds or less The library system shall be available 24/7 The library system shall abide to iso standards Dr R Bahsoon 16 Non-functional Classifications Product requirements Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisational requirements Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. External requirements Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc. Dr R Bahsoon 17 Non-functional Requirement Types Dr R Bahsoon 18 6

Non-functional Requirements: Dimensions of Dependability Dependability Availability Reliability Safety Security The ability of the system to deliver services when requested The ability of the system to deliver services as specified The ability of the system to operate without catastrophic failure The ability of the system to protect itelf against accidental or deliberate intrusion Dr R Bahsoon 19 Other Dependability Properties Repairability Reflects the extent to which the system can be repaired in the event of a failure Maintainability Reflects the extent to which the system can be adapted to new requirements; Survivability Reflects the extent to which the system can deliver services whilst under hostile attack; Error tolerance Reflects the extent to which user input errors can be avoided and tolerated. Dr R Bahsoon 20 Requirements Engineering Process Activities Coursework Output Dr R Bahsoon 21 7

Requirements Document o A structured document setting out detailed descriptions of the system s functions, services and operational constraints. o Should include both a definition of user requirements and a specification of the system requirements. o It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it Defines what should be implemented so may be part of a contract between client and contractor. Dr R Bahsoon 22 Users of a Requirements Document Dr R Bahsoon 23 Definitions and Specifications ID Language! Dr R Bahsoon 24 8

MoSCoW Criteria Often used in requirements prioritization and as a language for specifying requirements o M: Must have- mandatory requirements that are fundamental to the system o S: Should have important requirements that could be omitted o C: Could have optional requirements o W: Want to have these requirements really can wait (i.e. bells and whistles) Dr R Bahsoon 25 Example Format ID Functional Requirements Priority Collection 1 The system shall M 2 The system shall. Borrowing Membership Borrowing Dr R Bahsoon 26 Non-functional Requirements ID Non-functional Requirements Priority 1 The system shall M 2 The system shall. 3 4 Capacity Reliability Borrowing Performance Dr R Bahsoon 27 9

Why are Requirements Important? The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later [Fred Brooks in the Mythical Man Month ] Read this article! Dr R Bahsoon 28 Exercise o Determine a set of functional and non-functional requirements for a library system o Work in a group of two o What you have to do o Express the functional & non-functional requirements with a unique ID for traceability o Group your requirements into sensible sets (e.g., user interface, borrowing, browsing) o Prioritise your requirements Dr R Bahsoon 29 10