IT607 – Software Engineering Requirements Engineering

Slides:



Advertisements
Similar presentations
Software Requirements
Advertisements

Software Requirements
Software Requirements
Introduction to Software Engineering Dr. Basem Alkazemi
Introduction to Software Engineering
SWE Introduction to Software Engineering
Capturing the requirements
Software Requirements
Unit 211 Requirements Phase The objective of this section is to introduce software system requirements and to explain different ways of expressing these.
7M701 1 Software Engineering Software Requirements Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 5
CS 425/625 Software Engineering Software Requirements
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements.
Software Requirements
Overview of Software Requirements
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements 2.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
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
BSBIMN501A QUEENSLAND INTERNATIONAL BUSINESS ACADEMY.
المحاضرة الثالثة. 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.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Dr. Tom WayCSC Software Requirements CSC 4700 Software Engineering Lecture 2 Based on Sommerville, Chapter 6.
Software Requirements Presented By Dr. Shazzad Hosain.
소프트웨어공학 강좌 1 Chap 4. Software Requirements - Descriptions and specifications of a system - Soo-Mi Choi
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.
Lecture 7: Requirements Engineering
Requirements Reference: Chapters 5, 6, & 8. CMSC 345, Fall Objectives To introduce the concepts of user and system requirements To explain functional.
Requirement Elicitation Process Lesson 3. Requirements Elicitation  Is the process to find out the requirements for an intended software system by communicating.
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
Requirements Collection By Dr. Gabriel. Requirements A requirement is any function, constraint, or property that the system must provide, meet, or satisfy.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
CMSC 345 Fall 2000 Requirements Overview. Work with customers to elicit requirements by asking questions, demonstrating similar systems, developing prototypes,
Capturing the requirements  Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the.
Chapter 4 Software Requirements
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.
Systems Development Life Cycle
Requirements Validation
Week 3: Requirement Analysis & specification
Software Requirements Specification Document (SRS)
Requirements Analysis
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
1 The Software Development Process ► Systems analysis ► Systems design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance.
Software Requirements. Objectives: l To introduce the concepts of user and system requirements l To describe functional / non-functional requirements.
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.
5. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Describe the activities of the requirements discipline  Describe the difference.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
1 Software Requirements Descriptions and specifications of a system.
 System Requirement Specification and System Planning.
Software Engineering, COMP201 Slide 1 Software Requirements.
Classifications of Software Requirements
Chapter 4 – Requirements Engineering
Software Requirements
Presentation on Software Requirements Submitted by
Chapter 4 Requirements Engineering (1/3)
Chapter 5 – Requirements Engineering
Objectives Importance of Requirement Engineering
Software Requirements
SNS College of Engineering Coimbatore
Software Requirements
Software Requirements analysis & specifications
Requirements Reference: Software Engineering, by Ian Sommerville, 6th edition, Chapters 5, 6, & 8.
Software Requirements
Requirements Analysis
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Presentation transcript:

IT607 – Software Engineering Requirements Engineering Kavi Arya M. Mohan

Objectives Introduce the concepts User and System Requirements Describe functional and non-functional requirements Explain how to document software requirements

Railway reservation system Who are the users of this system ? Financial Gateway (bank) Reservation System Traveler IVR system Travel Agent System administrator Reservation Clerk

Quiz 0 Assume, you are analyzing an existing railway reservation system for devising enhancements. Answer the following questions with reference to any railway reservation system you are familiar with. Please write your assumptions clearly. i) Who are the various kinds of users of the system? What are their expectations of the system? ii) Will a system administrator who manages the system be a user? Justify your answer ? iii) List as many functional requirements of the system as possible ? iv) Write down five non-functional requirements of the system ?

Quiz 0 (contd.) v) Write down any additional requirements you would like to add to the system? (mention clearly whether they are functional or non-functional requirements)   vi) Suppose, the system under study has no facility for making reservations using SMS. The customer wants this feature to be implemented. Is this requirement functional? If no, can you think of a way of implementing this non-functional requirement in terms of any existing functional requirements ? vii) What process model would you adopt in building the system? Explain why and give two other models you would not use, explaining why.

Users expectations : Traveler What are the Travelers expectations of the System ? Expects reservation, cancellation, adjustment, and enquiry facilities. Above facilities offered online and telephonic are highly appreciated

Users expectations : Travel Agent Travel Agents expectations of the System Bulk reservation, cancellation, adjustment facilities. Enquiry facilities. Above facilities offered online and telephonic are highly appreciated Wants to be notified of important events like introduction of new / seasonal trains.

Users expectations : Reservation Clerk Reservation Clerks expectations of the System Reservation, cancellation, adjustment, and enquiry facilities. Season ticket issuing facility Concession handling facility like handling concessions given to senior citizens, Army personnel, students etc. Report generation facility. Ex: for generating daily sales reports etc.

Users expectations : System administrator System administrator’s expectations of the System A data backup facility An error recovery facility Adding, removing new trains to the system Modifying train schedules and fares

Users expectations : Financial Gateway Financial gateway’s expectations of the System Communication with the system should be safe to safeguard the integrity of the payment data. System should be using EDI or any other standard data interchange formats that the financial gateway understands. Note : Most of the external systems expectations are interoperability requirements.

Product requirements The reservation system product requirements High availability ( less MTBF ) High throughput: handle more number of transactions per second Reliability Scalability Security etc.

External requirements External requirements include: Interoperability requirements. Ex: Syntax and semantics of the messages to be used to communicate with the external systems. Legislative requirements. Ex: Personal information of a client should not be revealed to a third party without his consent.

Overall system requirements User Requirements Product Requirements External Requirements

Requirements Engineering The process of establishing services that the customer requires from a system and the constraints under which it operates and is developed. The requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process. Running example : Indian Railway Reservation System.

Users The stakeholders of the system, who interact with the system to accomplish their tasks. A user may be any entity that is interested in the services offered by the system. Eg : Traveler, Travel Agent, Reservation Clerk, Financial Gateway, System Administrator etc.

User Requirements Different users have different expectations of the system behavior, and all these combined together constitute the overall system requirements Ex :- Traveler expects an easy to use online system for booking tickets. A reservation clerk expects a good user interface and response time for serving the customers efficiently. A payment gateway expects the communication with the system be very secure, to ensure the integrity of the payment data.

Types of Requirements Functional Requirements ( Application requirements ) Eg: Cancellation, Reservation, enquiry etc. Non-Functional Requirements ( Quality Requirements ) Eg: Reservation at counter should be closed by 8 p.m. every day. Online reservations should be allowed till 11 p.m. etc.,

Functional VS Non-functional requirements Describes an interaction between the system and its environment Functional requirements change less frequently Non-functional Requirements Describes a restriction or constraint that limit our choices for constructing a solution Most of the changing requirements fall in to this category Ex:- Some time later, Indian railway may decide to provide online reservation facility round the clock.

Classification of Non-functional requirements Product Requirements: defines product characteristics Ex: Execution speed, Reliability, Security, Scalability etc. Organizational Requirements: requirements which are a consequence of organizational policies and procedures. Ex: Operational time in railway reservation time External Requirements: requirements which arise from factors external to the system. Ex: interoperability requirements, legislative requirements etc.

Characteristics of Requirements Are they correct ? Are they Consistent ? Are they Complete ? Are they Realistic ? Are they verifiable ? Are they traceable ?

Characteristics of Requirements . . Realistic Requirements : Are the requirements technically, financially, and operationally feasible ? Verifiable requirements : Should be able to verify whether a requirement is implemented correctly or not Traceable requirements : traceability is the ability to describe and follow the life of a requirement throughout the software development life cycle. This is a very useful feature used in change management.

Requirement Elicitation techniques Traditional Techniques Group elicitation techniques Prototyping

Requirement Elicitation techniques Traditional Techniques Use of questionnaires and surveys Interviewing stakeholders Analyzing existing systems and processes

Requirement Elicitation techniques Group elicitation techniques A small group is formed, including some of the stakeholders also, to elicit requirements. This group brainstorms to define the requirements for the new system. This requirement gathering technique is very effective as the end users take active part in requirement definition. Group size should be reasonably small. Group composition: at least one representative from every group of end-users should be present in the group. This eliminates any bias in defining requirements.

Requirement Elicitation techniques Prototyping Used when there is a great deal of uncertainty about the requirements, or where early feedback from stakeholders is needed. A prototype is: Built rapidly from initial requirements Analyzed to refine the requirements New prototype is developed from these new requirements. Process continues until requirements defined satisfactorily.

Why document requirements ? It will help clarify what you think It is necessary to communicate with the users It is necessary to communicate with the development team It could form a basis for a contractual relationship

How to write it down ? Natural Language Structured Natural Language Graphical Notations ex. Use cases Mathematical Specifications ex. finite state machines

Problems with natural language Lack of Clarity : precision is difficult without making the document difficult to read. Requirements Confusion: functional and non-functional requirements tend to be mixed-up. Requirements Amalgamation: several different requirements may be expressed together. Ambiguity: the readers and writers of the requirement must interpret the same words in the same way. Natural language is ambiguous so this is very difficult. Lack of Modularization: natural language structures are inadequate to structure system requirements.

Structured Natural Language A predefined template is used for documenting the requirements. All the requirements are written in a standard way. Each template defines a unique function (reqmt) or entity. Describes inputs and where they come from. Describes outputs and where they go to. Indicates other entities involved. Pre and Post conditions (if appropriate). The side effects (if any) of the function.

Structured Natural Language XYZ software/SRS/1.2.4 Function: Description: Inputs: Source: Outputs: Destination: Action: Requires: Pre-condition: Post-condition: Side-effects:

Structured Natural Language contd… Indian railway reservation software/SRS/1.2.4 Function: reservation Description: makes a reservation on behalf of a customer, reservation clerk, or travel agent. Inputs: journey date, source station, destination station, train code etc. Source: customer / reservation clerk / travel agent Outputs: printed ticket or non-availability status message Destination: customer / reservation clerk / travel agent

Structured Natural Language Indian railway reservation software/SRS/1.2.4 Action: if seats/berths are available reserve them, otherwise send a non-availability status message to the user Requires: Pre-condition: required seats/berths are unreserved Post-condition: required seats/berths are reserved and no more available for reservation. Side-effects: None

Analysis Models Use cases, Sequence Diagrams, Class Diagrams, Object Diagrams, Collaboration Diagrams etc. to be discussed in the next class