Requirements Engineering process
|
|
- Peregrine Ray
- 5 years ago
- Views:
Transcription
1 Requirements Engineering process Used to discover, analyze, validate and manage requirements Varies depending on the application domain, the people involved and the organization developing the requirements However, there are a number of generic activities common to all processes: feasibility study requirements elicitation and analysis requirements specification requirements validation requirements management UniRoma2 - Service-oriented Software Engineering 1
2 Feasibility study A short focused study that checks If the product contributes to organizational objectives If the product can be engineered using current technology and within budget If the product can be integrated with other products that are used Based on a concise description of the product and the user needs Produces a report that decides whether or not the proposed product is worthwhile UniRoma2 - Service-oriented Software Engineering 2
3 Feasibility study (2) The required info are collected by interviewing: client manager software engineers with skills in the specific application domain experts of technology to be used end users Example typical questions: What if the product wasn t implemented? What are current process problems? How will the proposed product help? What will be the integration problems? Is new technology needed? What skills? What facilities must be supported by the proposed product? UniRoma2 - Service-oriented Software Engineering 3
4 Requirements elicitation and analysis Sometimes called requirements discovery Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system s operational constraints May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders (i.e., people who may have a direct or indirect interest in the product requirements) UniRoma2 - Service-oriented Software Engineering 4
5 Problems of requirements analysis Stakeholders don t know what they really want Stakeholders express requirements in their own terms Different stakeholders may have conflicting requirements Organizational and political factors may influence the product requirements The requirements change during the analysis process New stakeholders may emerge and the business environment change UniRoma2 - Service-oriented Software Engineering 5
6 Requirements elicitation and analysis process UniRoma2 - Service-oriented Software Engineering 6
7 Req. elicitation and analysis (2) Requirements elicitation techniques Ethnography Use cases (scenarios-based) Prototyping Requirements analysis (and specification) techniques semi-formal, based on system models and used by structured analysis methods or object-oriented analysis methods formal (based on formal languages, such Petri Net, FSM, Z, etc.) UniRoma2 - Service-oriented Software Engineering 7
8 Requirements validation Concerned with demonstrating that the requirements define the product that the customer really wants Very important to avoid costly requirements reworks in later lifecycle phases Checks include: 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 verifiability: can the requirements be checked? UniRoma2 - Service-oriented Software Engineering 8
9 Requirements validation techniques Informal reviews Formal reviews walkthroughs inspections Prototyping Test-case generation Automated consistency analysis (for requirements specified in formal languages) UniRoma2 - Service-oriented Software Engineering 9
10 Requirements management The process of managing changing requirements during the requirements engineering process and product development Classification of requirements in terms of evolution: enduring requirements (low probability of change) volatile requirements (high probability of change): mutable requirements (requirements that change due to the system s environment) emergent requirements (requirements that emerge as understanding of the product improves) consequential requirements (requirements that result from the introduction of the computer system) compatibility requirements (requirements that depend on other systems or organizational processes) UniRoma2 - Service-oriented Software Engineering 10
11 Requirements management planning During the requirements engineering process, you have to plan: requirements (unique) identification change impact analysis in terms of costs and feasibility traceability policies relationships between requirements, their sources and the system design CASE tool support the tool support required to help manage requirements change UniRoma2 - Service-oriented Software Engineering 11
12 Formal vs. informal specification UniRoma2 - Service-oriented Software Engineering 12
13 Formal specification with Petri Net Transition Place UniRoma2 - Service-oriented Software Engineering 13
14 Marked Petri Net (1) Token UniRoma2 - Service-oriented Software Engineering 14
15 Marked Petri Net (2) after firing transition t 1 UniRoma2 - Service-oriented Software Engineering 15
16 Marked Petri Net (3) after firing transition t 2 UniRoma2 - Service-oriented Software Engineering 16
17 Petri Net: example Inhibitor arc UniRoma2 - Service-oriented Software Engineering 17
18 Formal specification with Finite State Machine (FSM): example Input State UniRoma2 - Service-oriented Software Engineering 18
19 Formal specification with Z Consists of a set of schemas Schema template: UniRoma2 - Service-oriented Software Engineering 19
20 The Z language state specification example Abstract Initial State Button_init := [Button_State pushed = Æ] UniRoma2 - Service-oriented Software Engineering 20
21 The Z language operation specification example UniRoma2 - Service-oriented Software Engineering 21
22 Semi-formal specs: system models A system model is an abstract representation of a system, produced to facilitate the understanding of the system behavior and properties at system development time System models are produced by requirements analysis (specification) methods that make use of semi-formal techniques Such requirements analysis methods can be: structured (or procedural) analysis methods object-oriented analysis methods For a complete system description it is necessary to represent various aspects (data, behavior and control) UniRoma2 - Service-oriented Software Engineering 22
23 Model types data model: to represent the static and structural aspects (data requirements) ERD (not UML) class diagram (UML) behavioral model: to represent the functional aspects (functional requirements) data flow diagram (not UML) use case diagram (UML) activity diagram (UML) interaction diagram (UML) dynamic model: to represent the control aspects, as well as how the functions of the behavioral model modify the data of the data model state diagram (UML) UniRoma2 - Service-oriented Software Engineering 23
24 Entity Relationship Diagram (ERD) one-to-many relations UniRoma2 - Service-oriented Software Engineering 24
25 ERD many-to-many relations UniRoma2 - Service-oriented Software Engineering 25
26 Data Flow Diagram (DFD) UniRoma2 - Service-oriented Software Engineering 26
27 DFD example first refinement UniRoma2 - Service-oriented Software Engineering 27
28 DFD example second refinement process orders expansion UniRoma2 - Service-oriented Software Engineering 28
29 Structured System Analysis (SSA) (structured analysis method) Introduced by Gane and Sarson (1979) Composed of 9 steps Based on step-wise refinement Other structured analysis methods: DeMarco (1978) Yourdon and Constantine (1979) UniRoma2 - Service-oriented Software Engineering 29
30 SSA Step 1 Draw the DFD Use the requirements document (or the prototype) to: Identify data flows Identify source and destinations of data (where data flows starts and ends, respectively) Identify processes that transform data Refine the DFD by adding new flows of data or by adding details to existing data flows UniRoma2 - Service-oriented Software Engineering 30
31 SSA Step 2 Decide what Sections to Computerize and How Use cost-benefits analysis to decide which sections of the DFD to automate Decide how to computerize: Batch operations On-line processing Example: Automate order placement in batch Automate order validation online The next 3 steps are the stepwise refinement of data flows, processes and data stores UniRoma2 - Service-oriented Software Engineering 31
32 SSA Step 3 Determine the details of the data flows Decide what data items must go into the various data flows Example: the data flow order can be refined as follows: order_identification customer_details package_details Then, refine each flow stepwise: order_identification is a 12-digit integer customer_details consists of customer_name, customer_address, etc. UniRoma2 - Service-oriented Software Engineering 32
33 SSA Step 4 Define the logic of processes Example: build the decision tree for a give_educational_discount process UniRoma2 - Service-oriented Software Engineering 33
34 SSA Step 5 Determine the data stores Define the exact contents of each store and its representation (specific format in a given programming language) Define the level of access by use of data-immediateaccess diagram (DIAD) Example: UniRoma2 - Service-oriented Software Engineering 34
35 SSA Step 6 Define the physical resource Examples: For each file, specify: file name, organization (sequential, indexed, etc.), storage medium, records, down to the field level If a DBMS is to be used, then the relevant information for each table is specified UniRoma2 - Service-oriented Software Engineering 35
36 SSA Step 7 Determine the Input/Output specifications The input forms must be specified (components and layout) The output screens must similarly be determined The printed output also must be specified (estimated length and details) UniRoma2 - Service-oriented Software Engineering 36
37 SSA Step 8 Determine the sizing Compute: volume of input (daily or hourly) frequency of each printed report and its deadline size and number of records that are to pass between the CPU and mass storage size of each file UniRoma2 - Service-oriented Software Engineering 37
38 SSA Step 9 Determine the hardware requirements From sizing information specified at step 8, determine: Mass storage requirements Mass storage requirements for backup Characteristics of user terminals Characteristics of output devices Adequacy of existing hardware Costs of hardware to be purchased UniRoma2 - Service-oriented Software Engineering 38
39 SSA Output Step 9 is the last step of SSA After approval by the client, the resulting specification document is handed to the design team, and the software process continues Drawbacks: SSA cannot be used to determine response times CPU size and timing cannot be determined with any degree of accuracy UniRoma2 - Service-oriented Software Engineering 39
UNIT-II REQUIREMENTS ANALYSIS AND SPECIFICATION
UNIT-II REQUIREMENTS ANALYSIS AND SPECIFICATION The for a system are the descriptions of what the system should do the services that it provides and the constraints on its operation. User are statements,
More informationLesson 06. Requirement Engineering Processes
Lesson 06 Requirement Engineering Processes W.C.Uduwela Department of Mathematics and Computer Science Objectives To describe the principal requirements engineering activities and their relationships To
More informationSoftware specification and modelling. Requirements engineering
Software specification and modelling Requirements engineering Requirements engineering (RE) Requirements engineering is the process of establishing the services that a customer requires from a system and
More informationSlide Hard real-time constraints must be satisfied Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 12.1 CHAPTER 12 Slide 12.2 Object-Oriented and Classical Software Engineering CLASSICAL ANALYSIS Eighth Edition, WCB/McGraw-Hill, 2011 Stephen R. Schach Overview Slide 12.3 Overview (contd) Slide
More informationCh 4: Requirements Engineering. What are requirements?
Ch 4: Engineering What are? Functional and non-functional The software document specification engineering processes elicitation and analysis validation management The descriptions of what the system should
More informationObject-Oriented and Classical Software Engineering
Slide 11.1 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vanderbilt.edu CHAPTER 11 Slide 11.2 SPECIFICATION PHASE Overview Slide 11.3
More information(c) Addison Wesley Chapter 3. ! Interviewing customers and domain experts. ! Questionnaires. ! Observation. ! Study of documents and software systems
MACIASZEK, L.A. (2001): Analysis and System Design. Developing Information Systems with UML, Addison Wesley elicitation Domain Expert Customer Chapter 3 Determination Domain Knowledge Business Analyst
More informationRequirements Engineering Process
Requirements Engineering Process Requirement A description of a service that the system is expected to provide and the constraints under which it must operate. 1 Requirement Types Functional Requirement
More informationAdministrivia. Wednesday: Requirements and Specification. CS169 Lecture 4. We assign teams and you start on Monday. Determining Stakeholders and Needs
Administrivia Requirements and Specification CS169 Lecture 4 Wednesday: Groups and one-sentence idea(s) due at class One per group If you have a small group, still submit so that you will be kept together.
More informationPESIT Bangalore South Campus Hosur road, 1km before Electronic City, Bengaluru -100 Department of MCA
USN 1 P E PESIT Bangalore South Campus Hosur road, 1km before Electronic City, Bengaluru -100 Department of CA INTERNAL ASSESSENT TEST II Date : 20/09/2016 ax.arks: 50 Subject & Code: Software Engineering
More informationLecture 8 Requirements Engineering
Lecture 8 Requirements Engineering Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 18, 2008 Lecture Overview
More informationRequirements Analysis
Requirements Analysis Software Requirements A software (product) requirement is is a feature, function, capability, or property that a software product must have. Software Design A software design is is
More informationStructured Modeling Methods. Lecture 15: Advantages and Disadvantages. University of Toronto Department of Computer Science.
Lecture 15: Structured Modeling Methods Basics of Structured Analysis Notations used Modeling Process Variants SADT SASS SSADM SRD Advantages and Disadvantages 2001, Steve Easterbrook CSC444 Lec15 1 Definition
More informationRequirements. Requirements. Types of Requirement. What Is a Requirement?
Beatrice Åkerblom beatrice@dsv.su.se Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan... What Is a Requirement?!
More informationRequirement Analysis
Requirement Analysis Requirements Analysis & Specification Objective: determine what the system must do to solve the problem (without describing how) Done by Analyst (also called Requirements Analyst)
More information1. i. What are the 3 major components of a information system and show their relationship input output
Higher National Diploma in Information Technology First Year, Second semesterexamination-2011 IT2005: System Analysis and Design Answer Script No. of pages: 11 1. i. What are the 3 major components of
More informationThe requirements engineering process
3 rd Stage Lecture time: 8:30-12:30 AM Instructor: Ali Kadhum AL-Quraby Lecture No. : 5 Subject: Software Engineering Class room no.: Department of computer science Process activities The four basic process
More informationSystems Analysis and Design in a Changing World, Fourth Edition
Systems Analysis and Design in a Changing World, Fourth Edition Systems Analysis and Design in a Changing World, 4th Edition Learning Objectives Explain the purpose and various phases of the systems development
More informationRequirements Engineering: Specification & Validation. Software Requirements and Design CITS 4401 Lecture 18
Requirements Engineering: Specification & Validation Software Requirements and Design CITS 4401 Lecture 18 The Problems of Requirements What goal(s) are we trying to satisfy? How do we identify the scope
More informationRequirements Validation and Negotiation
REQUIREMENTS ENGINEERING LECTURE 2015/2016 Eddy Groen Requirements Validation and Negotiation AGENDA Fundamentals of Requirements Validation Fundamentals of Requirements Negotiation Quality Aspects of
More informationSE 1: Software Requirements Specification and Analysis
SE 1: Software Requirements Specification and Analysis Lecture 4: Basic Notations Nancy Day, Davor Svetinović http://www.student.cs.uwaterloo.ca/ cs445/winter2006 uw.cs.cs445 U Waterloo SE1 (Winter 2006)
More informationStructured Analysis and Design
1 st Cut - Creating... 14:10 A Actors... 2:11 Additional Notations... 11:17 Alternative Names for the System... 13:15 Analysis - Overview... 1:9 Analysis and Design - Goals... 1:6 Analysis and Design -
More informationDatabase Systems: Design, Implementation, and Management Tenth Edition. Chapter 9 Database Design
Database Systems: Design, Implementation, and Management Tenth Edition Chapter 9 Database Design Objectives In this chapter, you will learn: That successful database design must reflect the information
More informationRequirements Analysis. Requirement analysis. Requirements analysis 3/11/14. Advanced Programming
Requirements Analysis Advanced Programming 11 March 2014 Barbara Russo 11 Requirement analysis Understanding which services are required from the system and identifying the constraints on the system s
More informationThe software lifecycle and its documents
The software lifecycle and its documents Supplementary material for Software Architecture course B. Meyer, May 2006 Lifecycle models Origin: Royce, 1970, Waterfall model Scope: describe the set of processes
More informationIntroduction to Software Engineering p. 1 The Scope of Software Engineering p. 3 Historical Aspects p. 4 Economic Aspects p. 7 Maintenance Aspects p.
Preface p. xv Introduction to Software Engineering p. 1 The Scope of Software Engineering p. 3 Historical Aspects p. 4 Economic Aspects p. 7 Maintenance Aspects p. 8 Specification and Design Aspects p.
More informationTASKS IN THE SYSTEMS DEVELOPMENT LIFE CYCLE
SUMMARY AND REFERENCE ACTG 313 TASKS IN THE SYSTEMS DEVELOPMENT LIFE CYCLE PREPARATION PHASE 1. Identification of the Need for a new Information System 2. Initial Feasibility Study (always flawed because
More informationSRM ARTS AND SCIENCE COLLEGE SRM NAGAR, KATTANKULATHUR
SRM ARTS AND SCIENCE COLLEGE SRM NAGAR, KATTANKULATHUR 603203 DEPARTMENT OF COMPUTER SCIENCE & APPLICATIONS QUESTION BANK (2017-2018) Course / Branch : M.Sc-CST Semester / Year : Even / II Subject Name
More informationWe move from a general information system to a Computer Based Information System
Introduction to Information Systems: In this section of the course we start to think of the computer as just being a component in a system which may contain one or many computers linked together. An Information
More informationIntroduction to Software Specifications and Data Flow Diagrams. Neelam Gupta The University of Arizona
Introduction to Software Specifications and Data Flow Diagrams Neelam Gupta The University of Arizona Specification A broad term that means definition Used at different stages of software development for
More informationRequirements engineering
engineering Chapter 4 1 Engineering in the textbook 4.1 Functional and non-functional 4.2 The software document 4.4 engineering processes 4.5 elicitation and analysis 4.3 specification 4.6 validation 4.7
More informationProcess Modeling. Chapter 7. Class 05: Process Modeling 1
Process Modeling Chapter 7 Class 05: Process Modeling 1 Process Design Seldom the responsibility of the database designer or DBA However, understanding the basics aids communication with the process designers
More informationProcess Modeling. Business Process Example. Process Design
Process Modeling Chapter 7 Class 05: Process Modeling 1 Process Design Seldom the responsibility of the database designer or DBA However, understanding the basics aids communication with the process designers
More informationSystem Analysis & design
Assiut University Faculty of Computers and Information System Analysis & design Year 2 Academic Year 2014/ 2015 Term (2) 5 A PICTURE IS WORTH A 1,000 WORDS A process model is a graphical way of representing
More informationCS350 Lecture 2 Requirements Engineering. Doo-Hwan Bae
CS350 Lecture 2 Requirements Engineering Doo-Hwan Bae bae@se.kaist.ac.kr Contents Overview of Requirements Engineering OO Analysis: Domain modeling, Use-case, sequence, class Structured Analysis: Dataflow
More informationManaging Design Processes
Managing Design Processes Managing Design Processes Organizational Design to Support Usability The Three Pillars of Design Development Methodologies Ethnographic Observation Participatory Design Scenario
More informationFIT1004 Database Topic 2: Database Design Life Cycle
FIT1004 Database Topic 2: Database Design Life Cycle Learning Objectives: Describe the 3 level ANSI SPARC Database Architecture and the advantages which its inherent data abstraction provide to the database
More informationFunctional Modeling with Data Flow Diagrams
Functional Modeling with Data Flow Diagrams Amasi Elbakush 5771668 Teaching Assistant : Daniel Alami Utrecht University 1 Introduction Data Flow Diagrams (DFDs) are a visual representation of the flow
More informationUser-centered design in technical communication
User-centered design in technical communication Information designer & information architect Sharing knowledge is better than having it. Tekom - TC Europe November 19-20, 2003 Nov. 19-20, 2003 User-centered
More informationThe Analysis and Proposed Modifications to ISO/IEC Software Engineering Software Quality Requirements and Evaluation Quality Requirements
Journal of Software Engineering and Applications, 2016, 9, 112-127 Published Online April 2016 in SciRes. http://www.scirp.org/journal/jsea http://dx.doi.org/10.4236/jsea.2016.94010 The Analysis and Proposed
More informationAdvanced Software Engineering: Software Testing
Advanced Software Engineering: Software Testing COMP 3705(L4) Sada Narayanappa Anneliese Andrews Thomas Thelin Carina Andersson Web: http://www.megadatasys.com Assisted with templates News & Project News
More informationRequirements Validation and Negotiation (cont d)
REQUIREMENTS ENGINEERING LECTURE 2017/2018 Joerg Doerr Requirements Validation and Negotiation (cont d) REQUIREMENTS VALIDATION AND NEGOTIATION Requirements Validation Techniques 2 Techniques Overview
More informationRequirements Analysis. SE 555 Software Requirements & Specification
Requirements Analysis Goals of Requirements Analysis Create requirements containing sufficient detail and of high enough quality to allow realistic project planning as well as successful design and implementation.
More informationSystems Analysis and Design
Systems Analysis and Design Michael Brydon Summer 2003 Slide 1 Introduction to the Course Course structure Lectures: material from the Dennis text Labs: in-lab assignments, demonstrations, and consulting
More informationSE 2730 Final Review
SE 2730 Final Review 1. Introduction 1) What is software: programs, associated documentations and data 2) Three types of software products: generic, custom, semi-custom Why is semi-custom product more
More informationChapter 6 Architectural Design
Chapter 6 Architectural Design Chapter 6 Architectural Design Slide 1 Topics covered The WHAT and WHY of architectural design Architectural design decisions Architectural views/perspectives Architectural
More informationBasics : the Requirements Engineering Process
SEG3101 (Fall 2010) Basics : the Requirements Engineering Process Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides prepared by Gunter Mussbacher with material from: Sommerville & Kotonya
More informationASSIGNMENT- I Topic: Functional Modeling, System Design, Object Design. Submitted by, Roll Numbers:-49-70
ASSIGNMENT- I Topic: Functional Modeling, System Design, Object Design Submitted by, Roll Numbers:-49-70 Functional Models The functional model specifies the results of a computation without specifying
More informationBuilding the User Interface: The Case for Continuous Development in an Iterative Project Environment
Copyright Rational Software 2002 http://www.therationaledge.com/content/dec_02/m_uiiterativeenvironment_jc.jsp Building the User Interface: The Case for Continuous Development in an Iterative Project Environment
More informationAnswer: D. Answer: B. Answer: B
1. Management information systems (MIS) A. create and share documents that support day-today office activities C. capture and reproduce the knowledge of an expert problem solver B. process business transactions
More informationConcepts of Usability. Usability Testing. Usability concept ISO/IS What is context? What is context? What is usability? How to measure it?
Concepts of Usability Usability Testing What is usability? How to measure it? Fang Chen ISO/IS 9241 Usability concept The extent to which a product can be used by specified users to achieve specified goals
More informationREQUIREMENTS. Michael Weintraub Spring, 2016
REQUIREMENTS Michael Weintraub Spring, 2016 Unit Objective Understand what requirements are Understand how to acquire, express, validate and manage requirements Definitions A thing demanded or obligatory
More informationProduct. e ss. P roc. so get the right requirements. Garbage in garbage out,
If software is simply for automation, what would a washing machine be like? 1 RE Process Lawrence Chung Department of Computer Science The University of Texas at Dallas 2 RE Process: What is a Process?
More informationIncremental development A.Y. 2018/2019
Incremental development A.Y. 2018/2019 Incremental development Interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with
More informationService Description: CNS Federal High Touch Technical Support
Page 1 of 1 Service Description: CNS Federal High Touch Technical Support This service description ( Service Description ) describes Cisco s Federal High Touch Technical support (CNS-HTTS), a tier 2 in
More informationSupporting Systems Engineering with Methods and Tools: A Case Study
Supporting Systems Engineering with Methods and Tools: A Case Study Jock Rader and Leslie Haggerty Hughes Aircraft Company and H&A System Engineering Abstract Many projects have applied the Hatley-Pirbhai
More informationSoftware Development Methodologies
Software Development Methodologies Lecturer: Raman Ramsin Lecture 3 Seminal Object-Oriented Methodologies: A Feature-Focused Review 1 Responsibility-Driven Design (RDD) Introduced in 1990; a UML-based
More informationArchitectural Design
Architectural Design Topics i. Architectural design decisions ii. Architectural views iii. Architectural patterns iv. Application architectures Chapter 6 Architectural design 2 PART 1 ARCHITECTURAL DESIGN
More informationComputational Paradigms and Process Frameworks. State-Oriented Models. Toggle Switch State Diagram
Computational Paradigms and Process Frameworks State-Oriented Models Examples: Automata (DFAs, NFAs, PDAs) Turing Machines A finite state machine is a hypothetical machine that can be in only one of a
More informationSoftware Processes. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1
Software Processes Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be
More informationChapter 4. Capturing the Requirements. 4th Edition. Shari L. Pfleeger Joanne M. Atlee
Chapter 4 Capturing the Requirements Shari L. Pfleeger Joanne M. Atlee 4th Edition It is important to have standard notations for modeling, documenting, and communicating decisions Modeling helps us to
More information350 Index 2005 GOAL/QPC
Index abstract testing, 274 acceptance criteria, 270 acceptance tests, 270 activity diagrams, 113, 114, 174-175, 321 actor catalog, 144 actor description, 144 actor hierarchy, 148 actor map, 59, 114, 144,
More informationRequirement Engineering within an Agile Environment BY KEJI GIWA. Digital Bananas Technology
Requirement Engineering within an Agile Environment BY KEJI GIWA HLR Workshop Requirement Catalogue Product Planning Sprint Planning Meeting Keyscreens Use Case / Epic Stories Implement Wireframes DBT
More informationChapter 3. Organizational Design and Support Usability. Organizational Design and Support Usability (cont.) Managing Design Processes
1 Chapter 3 Managing Design Processes Organizational Design and Support Usability Design is inherently creative and unpredictable. Interactive system designers must blend knowledge of technical feasibility
More informationLecture 9 Requirements Engineering II
Lecture 9 Requirements Engineering II Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 23, 2008 Announcements
More informationSpecifying and Prototyping
Contents Specifying and Prototyping M. EVREN KIYMAÇ 2008639030 What is Specifying? Gathering Specifications Specifying Approach & Waterfall Model What is Prototyping? Uses of Prototypes Prototyping Process
More informationMeltem Özturan misprivate.boun.edu.tr/ozturan/mis515
Meltem Özturan misprivate.boun.edu.tr/ozturan/mis515 1 2 1 Selecting the Best Alternative Major Activities in the Analysis Phase Gather information Define system requirements Prototype for feasibility
More informationRequirements Analysis
Requirements Analysis Based on K. E Wiegers Software Requirements, Chap 5, 14 D. Leffingwell & D. Widrig, Managing Software Requirements A use case approach, Chap 5 Requirements Analysis The process of
More informationLecture 6: Requirements Engineering
Lecture 6: Requirements Engineering Software System Design and Implementation ITCS/ITIS 6112/8112 001 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte
More informationProcess of Interaction Design and Design Languages
Process of Interaction Design and Design Languages Process of Interaction Design This week, we will explore how we can design and build interactive products What is different in interaction design compared
More informationStructured Analysis and Structured Design
Structured Analysis and Structured Design - Introduction to SASD - Structured Analysis - Structured Design Ver. 1.5 Lecturer: JUNBEOM YOO jbyoo@konkuk.ac.kr http://dslab.konkuk.ac.kr References Modern
More informationSystems Analysis & Design
Systems Analysis & Design Dr. Ahmed Lawgali Ahmed.lawgali@uob.edu.ly Slide 1 Systems Analysis & Design Course Textbook: Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition
More informationRequirements. CxOne Standard
Requirements CxOne Standard CxStand_Requirements.doc November 3, 2002 Advancing the Art and Science of Commercial Software Engineering Contents 1 INTRODUCTION... 1 1.1 OVERVIEW... 1 1.2 GOALS... 1 1.3
More informationRequirements Validation and Negotiation
REQUIREMENTS ENGINEERING LECTURE 2017/2018 Joerg Doerr Requirements Validation and Negotiation AGENDA Fundamentals of Requirements Validation Fundamentals of Requirements Negotiation Quality Aspects of
More informationChapter 8. Database Design. Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel
Chapter 8 Database Design Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel 1 In this chapter, you will learn: That successful database design must reflect the information
More informationCHAPTER 19: Building a Preliminary Behavioral Model
1 z 7 CHAPTER 19: Building a Preliminary Behavioral Model Things are always at their best in their beginning. Blaise Pascal Lettres Provinciales, 1656-1657, no. 4 IN THIS CHAPTER, YOU WILL LEARN: Why a
More informationBusiness Analysis for Practitioners - Requirements Elicitation and Analysis (Domain 3)
Business Analysis for Practitioners - Requirements Elicitation and Analysis (Domain 3) COURSE STRUCTURE Introduction to Business Analysis Module 1 Needs Assessment Module 2 Business Analysis Planning Module
More informationFull file at https://fratstock.eu
TEACHING TIPS Chapter 2 SYSTEMS TECHNIQUES AND DOCUMENTATION I normally introduce flowcharting symbols with simple examples on the board. I first introduce a very simple manual flowchart involving only
More informationRequirements Engineering. Contents. Functional requirements. What is a requirement?
Contents Ø Introduction 4 Ø Engineering Ø Project Management Ø Software Design Ø Detailed Design and Coding Ø Quality Assurance Engineering Ø What is a Requirement? Ø RE Activities Ø Documentation Ø RE
More informationAnalysis Modeling Week 5
Analysis Modeling Week 5 Announcement Midterm I Monday March, 7 th Scope Ch. 1, 2, 3, 4 and Ch. 6 of the text book Ch. 1, 2 and 3 of the lab book Analysis modeling dli Agenda (Lecture) Agenda (Lab) Weekly
More informationRequirement KANOKWATT SHIANGJEN COMPUTER SCIENCE SCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY UNIVERSITY OF PHAYAO
Requirement KANOKWATT SHIANGJEN COMPUTER SCIENCE SCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY UNIVERSITY OF PHAYAO Contents What is requirement? Software Requirement Specification (SRS) Requirements
More informationRequirements Engineering. Establishing what the customer requires from a software system. Requirements Engineering. What is a Requirement?
Engineering Establishing what the customer requires from a software system Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 5 and 6 Slide 1 Engineering
More informationDesign of Embedded Systems
Design of Embedded Systems José Costa Software for Embedded Systems Departamento de Engenharia Informática (DEI) Instituto Superior Técnico 2015-01-02 José Costa (DEI/IST) Design of Embedded Systems 1
More informationExamination Questions Time allowed: 1 hour 15 minutes
Swedish Software Testing Board (SSTB) International Software Testing Qualifications Board (ISTQB) Foundation Certificate in Software Testing Practice Exam Examination Questions 2011-10-10 Time allowed:
More informationSystem context. Usage facet. IT system facet. Core activities
System context Subject facet Usage facet IT system facet Development facet Validation Core activities Observe Documentation the system context to Elicitation detect context changes Manage the execution
More informationPractical Database Design Methodology and Use of UML Diagrams Design & Analysis of Database Systems
Practical Database Design Methodology and Use of UML Diagrams 406.426 Design & Analysis of Database Systems Jonghun Park jonghun@snu.ac.kr Dept. of Industrial Engineering Seoul National University chapter
More informationUnit 1 Introduction to Software Engineering
Unit 1 Introduction to Software Engineering João M. Fernandes Universidade do Minho Portugal Contents 1. Software Engineering 2. Software Requirements 3. Software Design 2/50 Software Engineering Engineering
More informationOracle Data Modeling and Relational Database Design
Oracle University Contact Us: +632 976 8896, 1800 16516277 Oracle Data Modeling and Relational Database Design Duration: 4 Days What you will learn This Oracle Data Modeling and Relational Database Design
More informationArchitectural Design
Architectural Design Topics i. Architectural design decisions ii. Architectural views iii. Architectural patterns iv. Application architectures PART 1 ARCHITECTURAL DESIGN DECISIONS Recap on SDLC Phases
More informationModelling as a Communication Tool: Introduction to Process Modelling. Modelling. Simplification in modelling. Representation in modelling
CSE104 - Information Systems 1 Modelling as a Communication Tool: Introduction to Process Modelling The requirements specification document Must be communicated to key stakeholders Should contain: Functions
More informationSoftware Modeling & Analysis. - Introduction to SASD - Structured Analysis. Lecturer: JUNBEOM YOO
Software Modeling & Analysis - Introduction to SASD - Structured Analysis Lecturer: JUNBEOM YOO jbyoo@konkuk.ac.kr References Modern Structured Analysis, Edward Yourdon, 1989. Introduction to System Analysis
More informationLevel 4 Diploma in Computing
Level 4 Diploma in Computing 1 www.lsib.co.uk Objective of the qualification: It should available to everyone who is capable of reaching the required standards It should be free from any barriers that
More informationSoftware Engineering - I
Software Engineering - I An Introduction to Software Construction Techniques for Industrial Strength Software Chapter 3 Requirement Engineering Copy Rights Virtual University of Pakistan 1 Requirement
More informationModeling Issues Modeling Enterprises. Modeling
Modeling Issues Modeling Enterprises SE502: Software Requirements Engineering Modeling Modeling can guide elicitation: It can help you figure out what questions to ask It can help to surface hidden requirements
More informationBusiness Process Modelling
CS565 - Business Process & Workflow Management Systems Business Process Modelling CS 565 - Lecture 2 20/2/17 1 Business Process Lifecycle Enactment: Operation Monitoring Maintenance Evaluation: Process
More informationInformation Technology Engineers Examination. Database Specialist Examination. (Level 4) Syllabus. Details of Knowledge and Skills Required for
Information Technology Engineers Examination Database Specialist Examination (Level 4) Syllabus Details of Knowledge and Skills Required for the Information Technology Engineers Examination Version 3.1
More informationIdentify the guidelines for system development. Discuss the purpose of the activities performed in the analysis phase
Discovering Computers 2010 Living in a Digital World Objectives Overview Define system development and list the system development phases Identify the guidelines for system development Discuss the importance
More informationMethods for requirements engineering
Methods for requirements engineering Objectives To explain the role of methods and techniques in requirements engineering To introduce data-flow modelling To introduce semantic data modelling To introduce
More informationh(p://ihm.tumblr.com/post/ /word- cloud- for- hci- human- computer- interacbon CS5340 Human-Computer Interaction ! January 31, 2013!
h(p://ihm.tumblr.com/post/105778492/word- cloud- for- hci- human- computer- interacbon CS5340 Human-Computer Interaction January 31, 2013 Today s Class Administrivia User-centered Design Establishing Requirements
More informationSoftware Requirements Specification. <Project> for. Version 1.0 approved. Prepared by <author(s)> <Organization> <Date created>
Software Requirements Specification for Version 1.0 approved Prepared by Software Requirements Specification for Page 2 Table of Contents Revision
More information