Software Engineering Week 9 – Brief Introduction of Requirement #1 A.A. Gde Bagus Ariana, S.T.

Slides:



Advertisements
Similar presentations
Software Requirements
Advertisements

Software Requirements
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1 Software Engineering September 12, 2001 Capturing.
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
Introduction to Software Engineering Dr. Basem Alkazemi
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
Requirements Analysis CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 7, 2003.
Software Engineering COMP 201
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
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.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
7M701 1 Software Engineering Software Requirements Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 5
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements.
CS351 © 2003 Ray S. Babcock Requirements What not How “The Pizza Experiment” 1994, 350 companies, 8000 software projects. 31% were canceled before they.
Software Requirements
Overview of Software Requirements
1 Lecture 5 Introduction to Software Engineering Overview  What is Software Engineering  Software Engineering Issues  Waterfall Model  Waterfall Model.
SE 555 – Software Requirements & Specifications Introduction
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements 2.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
S R S S ystem R equirements S pecification Specifying the Specifications.
Chapter 4 Capturing the Requirements 4th Edition Shari L. Pfleeger
The Software Development Life Cycle: An Overview
Software Engineering CS B Prof. George Heineman.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
Requirements Analysis
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
ITEC224 Database Programming
CSCI 6231 Software Engineering ( Chapter 10?) Requirements Workflow Instructor: Morris Lancaster.
©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.
Adaptive Processes © Adaptive Processes Simpler, Faster, Better Software Requirements.
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
Software Requirements Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn Lecture 4 & 5.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
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
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
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.
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Software Requirements l Descriptions and specifications of a system.
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
1 CEN 4020 Software Engineering PPT4: Requirement analysis.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
1 Week 5 Software Engineering Fall Term 2015 Marymount University School of Business Administration Professor Suydam.
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)
 System Requirement Specification and System Planning.
Software Engineering, COMP201 Slide 1 Software Requirements.
Chapter 4 – Requirements Engineering
Software Requirements
Software Requirements
System Requirements Specification
Requirements Analysis
Software Engineering Furqan Rustam.
Software Engineering Lecture #3
Lecture # 7 System Requirements
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Presentation transcript:

Software Engineering Week 9 – Brief Introduction of Requirement #1 A.A. Gde Bagus Ariana, S.T.

Objectives To introduce the concepts of user and system requirements To describe functional and non-functional requirements To explain how software requirements may be organised in a requirements document

Why Important? The hardest single part of building a software system is deciding precisely what to build. No other part of 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. (Brooks 1987)

Causes of the failed projects Incomplete requirements (13.1%) Lack of user involvement (12.4%) Lack of resources (10.6%) Unrealistic expectations (9.9%) Lac of executive support (9.3%) Changing requirements and specifications (8.7%) Lack of planning (8.1%) System no longer needed (7.5%)

Requirements Engineering Domains

Boundary

The Requirements Process : 2 Documents Req. definition – Complete listing of customer’s system expectations – High-level abstract description of req. – Natural language + simple diagrams – Limitations & constraints – From customer-supplied info. – Written for customers

The Requirements Process Definition of Requirement – Feature of system – Description of system Process – Action to determine the req. Capable of doing There is a purpose

Req. specification – Restates req. definition in technical terms – For sys. designers to follow – Detailed desc.  ? system should do – Sets out sys. services in detail – A.k.a. Functional Spec. – Cust./User/Developer contract – Written as a contract between customer and developer The Requirements Process : 2 Documents

The Requirements Process S/W specification – More detailed description – Bridge req. process & design activities – S/W abstracts  basis: design & implementation

The Requirements Process ProblemAnalysisProblemDescriptionPrototyping and testing Documentation & Validation Have we captured all the user need? Are we using the right techniques or views? Is this function feasible? Have we captured what the user expects? Req n Elicitation and Analysis Req n Definition and Specification Feasibility study Req n Analysis Req n Definition Req n Specification System models Definition of req n Specification of req n Req n Document Feasibility Report

The Requirements Process Req. elicitation – Developers work with cust. : Asking questions Demonstrating similar systems Developing prototypes – Problem analysis  identify: People Processes Resources ProblemAnalysisProblemDescriptionPrototyping and testing Have we captured all the user need? Are we using the right techniques or views? Is this function feasible? Req n Elicitation and Analysis

The Requirements Process Req. definition & spec. – 3 categories of req.: Must be met Highly desirable but not necessary Possible but could be eliminated Documentation & Validation Have we captured what the user expects? Req n Definition and Specification

The Requirements Process Req. definition & specification – Doc.  formal agreement Req.  specific descriptions of functions/charateristics Req.  does not specify “how” (E.g. what DBMS or pgm. Lang. to use)

The Requirements Process 2 steps  ensuring req. fully mapped & understood: – Verification  complete, correct & consistent requirements – Validation  developers described what customer intends

Configuration Mgmt. Set of procedures that track: – Requirements – Designs – Program codes – Tests strategies & approaches – Documents

Functional & Non Functional req. – Capture the intended behavior of the system ie. tasks or functions the system is required to perform. – Use cases have quickly become a widespread practice for capturing functional requirements – E.g. engine for a vehicle & invoice generation for a Debtors accounting system

Functional & Non Functional req.

Functional & Non Non-functional req. – Describes a restriction on the system – Split into two types: performance and development. Performance Constraints – The response time for information to appear to a user. – The number of hours a system should be available. – The number of records a system should be able to hold. – The capacity for growth of the system. – The length of time a record should be held for auditing purposes.

Functional & Non For the customer records example these might be: – Information should be made available and be stored in a maximum of 3 seconds. – The system should be available from 9am to 5 pm Monday to Friday. – The system should be able to hold a 100,000 customer records initially. – The system should be able to add 10,000 records a year for 10 years. – A record should be fully available on the system for at least 7 years.

Functional & Non Development constraints: – Time - When a system should be delivered is the obvious time constraint. – Resource - How much money is available to develop the system is obvious, but a key resource would be the amount of time business staff could spend in briefing system development staff. – Quality - Any standards which are used to develop the system including project management, development methods etc.

How to Express Req.? Natural language – Problem Not precise & unambiguous Not easily separated system elements Difficult to trace back – Solution Formal notation Automated tools

A Picture Is Worth thousand Words

How to Express Req.? Additional Req n Notations – Hierarchical Techniques (Warnier-Orr Diagram) – Data Flow Diagrams (DFD) – Software Req. Engineering Methodology (SREM) – Structured Analysis & Design Technique (SADT) – Formal Specification (Z)

How to Express Req.? Data Abstraction – Describing what the data are for – Each kind of data  an object  class type – Methods identified – UML’s diamond  aggregation – UML’s horizontal arrow  association

How to Express Req.? STUDENT Student number Credit-Hours Compute Tuition IN-STATE STUDENT Student number In-State Rate Compute Tuition OUT-STATE-STUDENT Student number Out-of-State Rate Compute Tuition class name attributes methods

How to Express Req.? Object-Oriented Specification Focus on entities involved Data-abstraction elements within Objects, attributes & methods Distinguishable: – Encapsulation – Information hiding – Class hierarchies – Inheritance – Polymorphism

How to Express Req.? Data Flow Diagram (DFD) – You already know

IEEE requirements standard Defines a generic structure for a requirements document that must be instantiated for each specific system. – Introduction. – General description. – Specific requirements. – Appendices. – Index.

Requirements document structure Preface Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index

Key points Requirements set out what the system should do and define constraints on its operation and implementation. Functional requirements set out services the system should provide. Non-functional requirements constrain the system being developed or the development process. User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams.

Key points System requirements are intended to communicate the functions that the system should provide. A software requirements document is an agreed statement of the system requirements. The IEEE standard is a useful starting point for defining more detailed specific requirements standards.

Thank You Question?

Tugas Buat resume tentang Requirement yang baik. Kriteria requirement yang baik adalah SMART: – Specific / spesifik – Measurable / terukur – Attainable / dapat dicapai – Realizable / daapt direalisasikan – Traceable / dapat dilacak Jelaskan dan beri contoh masing-masing kriteria diatas