RE Activities, Bespoke RE, Stakeholders. Lecture 2, DAT230, Requirements Engineering Robert Feldt,
|
|
|
- Coral Barker
- 6 years ago
- Views:
Transcription
1 RE Activities, Bespoke RE, Stakeholders Lecture 2, DAT230, Requirements Engineering Robert Feldt,
2 Recap Software Engineering is more than technology RE mistakes very costly Constant battle - never enough time/resources RE is more than writing requirements Req = desired, observable characteristic RE in particular: human-centered => multi-disciplinary No matter which process: Requirements still key Engineers focus on solutions - RE on problem domain Types: Functional, Quality/NFR, Dev Constraints
3 Basic concepts and activities
4
5 SWEBOK
6 SWEBOK
7 SWEBOK Purpose: Consensus definition of what SE is and is not
8
9
10
11
12
13 SWEBOK KA1.1.1 Definition
14 SWEBOK KA1.1.1 Definition Req = property a SW must exhibit to solve real-world problem
15 SWEBOK KA1.1.1 Definition Req = property a SW must exhibit to solve real-world problem Reqs must be verifiable
16 SWEBOK KA1.1.1 Definition Req = property a SW must exhibit to solve real-world problem Reqs must be verifiable Reqs often have other attributes like priority rating
17 SWEBOK KA1.1.1 Definition Req = property a SW must exhibit to solve real-world problem Reqs must be verifiable Reqs often have other attributes like priority rating Reqs have unique identifier for configuration control and management throughout lifecycle
18 SWEBOK KA1.1.2 Product & Process Reqs
19 SWEBOK KA1.1.2 Product & Process Reqs Product Req = req on software to be developed
20 SWEBOK KA1.1.2 Product & Process Reqs Product Req = req on software to be developed Process Req = development constraint
21 SWEBOK KA1.1.2 Product & Process Reqs Product Req = req on software to be developed Process Req = development constraint SWEBOK KA1.1.3 FR & NFR Functional Req describes functions of SW Non-Functional Reqs constrain the solution (also called Constraints or Quality Reqs)
22 SWEBOK KA1.1.4 Emergent Properties
23 SWEBOK KA1.1.4 Emergent Properties Some reqs represent Emergent Properties
24 SWEBOK KA1.1.4 Emergent Properties Some reqs represent Emergent Properties EPs cannot be satisfied by single component, determined by how all components interoperate
25 SWEBOK KA1.1.4 Emergent Properties Some reqs represent Emergent Properties EPs cannot be satisfied by single component, determined by how all components interoperate SWEBOK KA1.1.5 Quantifiable Reqs stated clearly, unambiguously & quantitatively
26 SWEBOK KA1.1.5 Quantifiable
27 SWEBOK KA1.1.5 Quantifiable Reqs stated clearly, unambiguously & quantitatively
28 SWEBOK KA1.1.5 Quantifiable Reqs stated clearly, unambiguously & quantitatively Should not rely on subjective judgment
29 SWEBOK KA1.1.5 Quantifiable Reqs stated clearly, unambiguously & quantitatively Should not rely on subjective judgment The software shall be reliable
30 SWEBOK KA1.1.5 Quantifiable Reqs stated clearly, unambiguously & quantitatively Should not rely on subjective judgment The software shall be reliable The software should be user-friendly
31 SWEBOK KA1.1.5 Quantifiable Reqs stated clearly, unambiguously & quantitatively Should not rely on subjective judgment The software shall be reliable The software should be user-friendly The call center software must increase the center s throughput by 20%
32 SWEBOK KA1.1.5 Quantifiable Reqs stated clearly, unambiguously & quantitatively Should not rely on subjective judgment The software shall be reliable The probability of a fatal error during one hour of operation should be less than 10^-8 The software should be user-friendly The call center software must increase the center s throughput by 20%
33 SWEBOK KA1.1.6 System & Software Reqs
34 SWEBOK KA1.1.6 System & Software Reqs System = interacting combination of elements to accomplish a given objective
35 SWEBOK KA1.1.6 System & Software Reqs System = interacting combination of elements to accomplish a given objective Elements include hardware, software, firmware, people, information, techniques, facilities, services and other support elements
36 SWEBOK KA1.1.6 System & Software Reqs System = interacting combination of elements to accomplish a given objective Elements include hardware, software, firmware, people, information, techniques, facilities, services and other support elements System reqs are for the system as a whole
37 SWEBOK KA1.1.6 System & Software Reqs System = interacting combination of elements to accomplish a given objective Elements include hardware, software, firmware, people, information, techniques, facilities, services and other support elements System reqs are for the system as a whole A system with software components has software requirements
38
39
40 SWEBOK KA1.2.1 Process Models
41 SWEBOK KA1.2.1 Process Models Req Process is NOT discrete front-end activity
42 SWEBOK KA1.2.1 Process Models Req Process is NOT discrete front-end activity Req Process configuration manages all reqs
43 SWEBOK KA1.2.1 Process Models Req Process is NOT discrete front-end activity Req Process configuration manages all reqs Req Process needs adaptation to organization and project context
44 SWEBOK KA1.2.1 Process Models Req Process is NOT discrete front-end activity Req Process configuration manages all reqs Req Process needs adaptation to organization and project context Req Process includes input activities like marketing and feasability studies
45 SWEBOK KA1.2.2 Process Actors
46 SWEBOK KA1.2.2 Process Actors Req specialist must mediate between domain of stakeholder and that of SE
47 SWEBOK KA1.2.2 Process Actors Req specialist must mediate between domain of stakeholder and that of SE User = operates the software
48 SWEBOK KA1.2.2 Process Actors Req specialist must mediate between domain of stakeholder and that of SE User = operates the software Customer = commisioned software or is target market
49 SWEBOK KA1.2.2 Process Actors Req specialist must mediate between domain of stakeholder and that of SE User = operates the software Customer = commisioned software or is target market Market analysts = establish market or are proxy customers
50 SWEBOK KA1.2.2 Process Actors Req specialist must mediate between domain of stakeholder and that of SE User = operates the software Customer = commisioned software or is target market Market analysts = establish market or are proxy customers Regulators = establish regulations sw must comply with
51 SWEBOK KA1.2.2 Process Actors Req specialist must mediate between domain of stakeholder and that of SE User = operates the software Customer = commisioned software or is target market Market analysts = establish market or are proxy customers Regulators = establish regulations sw must comply with SW Engs job to negotiate trade-offs; not all stakeholders can be perfectly satisfied
52 SWEBOK KA1.2.3 Process Support & Mngmnt
53 SWEBOK KA1.2.3 Process Support & Mngmnt Link to other SE Management KA
54 SWEBOK KA1.2.3 Process Support & Mngmnt Link to other SE Management KA SWEBOK KA1.2.4 Process Q & Improvement
55 SWEBOK KA1.2.3 Process Support & Mngmnt Link to other SE Management KA SWEBOK KA1.2.4 Process Q & Improvement Link to SE Quality KA & SE Process KA
56 Bespoke Software Development Single Customer User User User Buyer User Rep. Maintenance Other Stakeholders Negotiations RE SW Dev Org Sales Proj. Manager Dev Dev Dev
57 Bespoke Software Development Also known as: Custom/Traditional Software Development RE primarily startup activity Pre-study/Feasibility study, Contract SW Req Specification (SRS) Changes require negotiations Project focus (RE, Analysis, Design, Impl, V&V, Release) Domain knowledge from customers/users Success = contractual fulfillment & customer satisfaction
58 Bespoke Software Development - RE steps 1. Customer states need in general terms in Request for Proposals (RFP) 2. Dev company creates proposal = approach, prelim requirements, schedule, budget 3. Customer selects best proposal 4. Dev company prepares SRS & presents 5. Changes => prioritization & negotiations 6. Budget/Schedule problems => prioritization & negotiations
59 Market-Driven Software Development Many Customers Buyer Buyer User User User User Negotiations SW Vendor Sales RE Proj. Manager Marketing Prod. Mngmnt Dev Dev
60 Market-Driven Software Development Many potential customers (companies and/or end users) No negotiation, rather elicitation, evaluation, prediction, innovation Domain expertise primarily internally Success = Sales volume, ROI, Market share, growth
61 MD Software Development - RE steps 1. Decide what business you are in 2. Select a target market 3. Market research to determine size, competitors, customers, pains/needs, market message 4. Draft high-level features in Market Req Doc (MRD) = desired price, intro date, prioritization 5. Test MRD on potential customers 6. Detailed SRS written 7. Change => internal triage/re-prioritize 8. Budget/Schedule problems => internal triage/reprioritize
62 Stakeholder Identification [Sharp1999]
63 Stakeholder Identification [Sharp1999] Baseline
64 Stakeholder Identification [Sharp1999] Baseline affect System
65 Stakeholder Identification [Sharp1999] Baseline Support affect System
66 Stakeholder Identification [Sharp1999] info & tasks Baseline Support affect System
67 Stakeholder Identification [Sharp1999] info & tasks Baseline Support affect Client System
68 Stakeholder Identification [Sharp1999] info & tasks products Support Baseline affect Client System
69 Stakeholder Identification [Sharp1999] Satellites info & tasks products Support Baseline affect Client System
70 Stakeholder Identification [Sharp1999] Satellites interacts info & tasks products Support Baseline affect Client System
71 Stakeholder Identification [Sharp1999] Baseline
72 Stakeholder Identification [Sharp1999] Baseline
73 Stakeholder Identification [Sharp1999] Users - operate the SW Developers - develop the SW Baseline Legislators - constrains the SW Decision-makers - takes decisions
74 Stakeholder Identification [Sharp1999] Users - operate the SW Frequent users, occasional users, future & past users, users of products from sw Developers - develop the SW Baseline Legislators - constrains the SW Decision-makers - takes decisions
75 Baseline Stakeholder Identification [Sharp1999] Users - operate the SW Frequent users, occasional users, future & past users, users of products from sw Developers - develop the SW Developers, Analysts, Designers, QA, Maintainers, Trainers, Project managers Legislators - constrains the SW Decision-makers - takes decisions
76 Stakeholder Identification [Sharp1999] Users - operate the SW Frequent users, occasional users, future & past users, users of products from sw Developers - develop the SW Developers, Analysts, Designers, QA, Maintainers, Trainers, Project managers Baseline Legislators - constrains the SW Government, Community, Trade unions, Legal representatives, Standard bodies (ISO, IEEE), Auditors (TUV) Decision-makers - takes decisions
77 Stakeholder Identification [Sharp1999] Users - operate the SW Frequent users, occasional users, future & past users, users of products from sw Developers - develop the SW Developers, Analysts, Designers, QA, Maintainers, Trainers, Project managers Baseline Legislators - constrains the SW Government, Community, Trade unions, Legal representatives, Standard bodies (ISO, IEEE), Auditors (TUV) Decision-makers - takes decisions Dev & user managers, Financial managers/controllers
78 Stakeholder Identification 1. Identify all relevant groups of baseline stakeholders 2. Identify all relevant roles within each baseline group 3. For each baseline role: [Sharp1999] 1. Who supplies information to this role? Who performs supporting tasks? => Support stakeholders 2. Who processes or inspects products from this role? => Client 3. Who interacts with this role in other ways? => Satellite 4. Repeat 3 above for newly found stakeholders 5. Consider relations between identified stakeholders: in charge of, supports, is crucial to, provides info for,...
79 Stakeholder Analysis Who are the stakeholders? Do we have access to them? What are their expectations and interests? What are their influence and role in project?
80 Stakeholder Analysis Rainbow diagram
81 Stakeholder Analysis Expectations and interests Personal: Work or Family focus, Job satisfaction, Org satisfaction, Improving knowledge, Sufficient appreciation, Workload/Responsibility Social: Peer recognition, Cover incompetence, Sponsorships, Undermining, On the move, Power hierarchies Material: Money, Tools, Office, Travels
Requirements Specification with Models
Requirements Specification with Models Lectures 4, DAT230, Requirements Engineering Robert Feldt, 2011-09-12 Recap Elicitation to find/gather/create/refine/specify reqs & understand stakeholder needs Many
version NDIA CMMI Conf 3.5 SE Tutorial RE - 1
Requirements Engineering SE Tutorial RE - 1 What Are Requirements? Customer s needs, expectations, and measures of effectiveness Items that are necessary, needed, or demanded Implicit or explicit criteria
Software Requirements. CSCE Lecture 4-08/30/2016
Software Requirements CSCE 740 - Lecture 4-08/30/2016 Today s Goals What are requirements? Understand the requirements problem Why are requirements so important? Get a feel for the structure of a requirements
! To solve problems. ! To take up new opportunities. ! Requirements - descriptions of. " Behavior. " Data. " Constraints (eg. cost and schedule)
COMP3110/6311, Software Analysis and Design Why do we Develop Software? To solve problems To take up new opportunities The value of Requirements "#$"%&'(%)#*+"%#)&),'$&+)& '()#-&)'$./,0.&+%/&.%1"*(%2.%#
Requirements Basics. CSCE Lecture 4-09/02/2015
Requirements Basics CSCE 740 - Lecture 4-09/02/2015 This Week s Goals Understand the requirements problem Why are requirements so important? Get a feel for the structure of a requirements document What
REQUIREMENTS ENGINEERING
1 REQUIREMENTS ENGINEERING Chapter 4- by Ian Sommerville TOPICS COVERED Functional and non-functional requirements The software requirements document Requirements specification Requirements engineering
CSE 435 Software Engineering. Sept 14, 2015
CSE 435 Software Engineering Sept 14, 2015 What is Software Engineering Where Does the Software Engineer Fit In? Computer science: focusing on computer hardware, compilers, operating systems, and programming
Critical Skills for Writing Better Requirements (Virtual Classroom Edition)
Critical Skills for Writing Better Requirements (Virtual Classroom Edition) Eliminate Costly Changes and Save Time by Nailing Down the Project Requirements the First Time! Critical Skills for Writing Better
PART THREE: Work Plan and IV&V Methodology (RFP 5.3.3)
PART THREE: Work Plan and IV&V Methodology (RFP 5.3.3) 3.1 IV&V Methodology and Work Plan 3.1.1 NTT DATA IV&V Framework We believe that successful IV&V is more than just verification that the processes
CMMI for Technical Staff
CMMI for Technical Staff SES CMMI Training Series April 7, 2009 Audio Conference #: Dial - 1-877-760-2042 Pass code - 147272 SM SEI and CMM Integration are service marks of Carnegie Mellon University CMM
Software Requirements and Organizational Culture: 10 Lessons Learned
Software Requirements and Organizational Culture: 10 Lessons Learned Sponsored by: Karl Wiegers Principal Consultant, Process Impact www.processimpact.com Sponsor: IREB CPRE CERTIFIED PROFESSIONAL FOR
Requirement Management, Agile RE. Lecture 8, DAT230, Requirements Engineering Robert Feldt,
Requirement Management, Agile RE Lecture 8, DAT230, Requirements Engineering Robert Feldt, 2011-09-27 Notes about course Student course evaluators: We need 2-3 of you! There is compensation (Cremona/book
Support Product Lifecycle Management (PLM) on software packages
Overview This unit is about controlling the information going into and coming out of PLM packages in order to support processes throughout the product lifecycle. Applicable NOS Unit SSC/ N 4303 Unit Code
Software Product Line Engineering
Software Product Line Engineering L8: Transitioning to SPL Robert Feldt - robert.feldt@gmail.com Transitioning/Adopting SPLs If we decide to adopt SPLs and transition to SPLE, HOW should we make the transition?
SOFTWARE SYSTEM ENGINEERING: A TUTORIAL
SOFTWARE SYSTEM ENGINEERING: A TUTORIAL Richard H. Thayer 발표자 : 이동아 INTRODUCTION Specific of software Getting Large Getting complex System A collection of elements related in a way that allows the accomplishment
Who Am I? Project Basics. Project. Why Project? Alternative (names) Poloya s Method. Computer Science program ISD Datasystem AB (6 years)
Project Basics Anders Hessel Department of Information Technology Uppsala University Who Am I? Computer Science program ISD Datasystem AB (6 years) Developer Technical Project Manager 1 ½ year Ericsson
Requirements elicitation: Finding the Voice of the Customer
Requirements elicitation: Finding the Voice of the Customer Establishing customer requirements for a software system Identify sources of user requirements on your project Identify different classes of
What are Requirements? SENG1031 Software Engineering Workshop 1. My Notes. System Overview: The Big Picture
What are Requirements? SENG1031 Software Engineering Workshop 1 Requirements, An Overview Peter Ho CSE, UNSW 5 Aug 2010 Requirements are a collection of statements defined by the System Stakeholders. These
SE420 Software Quality Assurance
SE420 Software Quality Assurance Lecture 2 Software Specification Part-1 January 16, 2017 Sam Siewert SQA LO s (Learning Objectives) Theory and Principles 1. Coverage of Current SQA Theory and Practice
Introduction to Software Engineering
Introduction to Software Engineering 2. Requirements Collection Mircea F. Lungu Based on a lecture by Oscar Nierstrasz. Roadmap > The Requirements Engineering Process > Functional and non-functional requirements
Engineering Management Manual
Engineering Management Manual Configuration Management ED0014 Document Category: DMS: Document Control: Procedure CRN-EPR-ENG-014 Version Date Author/discipline Reviewer Approver Remarks 1.0 13/12/2011
CSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding Requirements Engineering
CSEB233: Fundamentals of Software Engineering Software Requirements Part 1 Understanding Requirements Engineering Objectives Discuss the concept of requirements and the types of requirements Explain what
Dr. Aldo Dagnino ABB, Inc. US Corporate Research Center October 21 st, Requirements Engineering
Dr. Aldo Dagnino ABB, Inc. US Corporate Research Center October 21 st, 2003 Requirements Engineering Class Objectives Students will be able to define the two process areas associated with the Requirements
Agile Systems Development In a Medical Environment
Agile Systems Development In a Medical Environment 2016 Jama Software, Inc Meet Jama Requirements & Test Management Cary Bryczek Jama Software Simplify Complex Product Development https://www.jamasoftware.com/
Session-2: Deep Drive into Non Functional Requirements (NFRs)
Session-2: Deep Drive into Non Functional Requirements (NFRs) Important Points to Note All Participating colleges are requested to mute your telephone lines during the webinar session. Participants are
IES 6, Assessment of Professional Competence
International Accounting Education Standards Board AGENDA ITEM 5-4 Exposure Draft April 2011 Proposed Revised International Education Standard IES 6, Assessment of Professional Competence 1 PROPOSED INTERNATIONAL
Version 1.0. The Contract Management Standard Final Edition. Version 1.0
The Management Standard Final Edition 1 Purpose of the Management Standard The purpose of the Management Standard is to describe the nature of contract management in terms of the contract management processes
USING PILOTS TO ASSESS THE VALUE AND APPROACH OF CMMI IMPLEMENTATION. Goddard Space Flight Center (GSFC)
USING PILOTS TO ASSESS THE VALUE AND APPROACH OF CMMI IMPLEMENTATION Goddard Space Flight Center (GSFC) Sally Godfrey, James Andary, Linda Rosenberg SEPG 2003 2/03 Slide 1 Agenda! Background " NASA Improvement
Immunization Information System (IIS) Trainer Sample Role Description
Immunization Information System (IIS) Trainer Sample Role Description March 2016 0 Note: This role description is meant to offer sample language and a comprehensive list of potential desired responsibilities
ETASS II SKILL LEVEL AND LABOR CATEGORY DESCRIPTIONS. Skill Levels
ETASS II SKILL LEVEL AND LABOR CATEGORY DESCRIPTIONS Skill Levels Level Entry I Intermediate II Senior III Principal IV Knowledge/Skill Description Applies fundamental concepts, processes, practices, and
Version 1.0. The Contract Management Standard Final Edition. Version 1.0
The Management Standard Final Edition 1 Purpose of the Management Standard The purpose of the Management Standard is to describe the nature of contract management in terms of the contract management processes
It will also enable you to manage the expectations of your clients or management, as they will know exactly what to expect.
Functional Specification / Requirement Document (FSD / FRD) The Functional Specification Document (FSD) in software development is a formal document that describes the functions of the software/system
RAPID ECONOMIC JUSTIFICATION. Building a Business Case
RAPID ECONOMIC JUSTIFICATION Building a Business Case Rapid Economic Development A proven business case framework and process guide that has a complete set of step-by-step instructions including associated
Requirements Engineering and Software Architecture Project Description
Requirements Engineering and Software Architecture Project Description Requirements Engineering Project Description This project is student-driven. There will be external sponsors, users, and others that
Fundamentals of Requirements Engineering
- interfaces system seen as black box inputs functions quantified characteristics outputs restrictions, prerequisites boundaries, exceptions standards, regulations Frogs vei 41 P.O. Box 235, NO-3603 Kongsberg
Requirements Engineering: Part I. Software Requirements & Project Management CITS3220
Requirements Engineering: Part I Software Requirements & Project Management CITS3220 The Problems of Requirements What goal(s) are we trying to satisfy? How do we identify the scope and properties of the
Requirements Engineering Unit 4: Requirements modeling, specification & prioritization
Unit 4: Requirements modeling, specification & prioritization Department of Computer Science / Rijksuniversiteit Groningen (RUG) http://www.cs.rug.nl/~liangp/teaching/courses/re2009fall/ 9/29/2009 1 9/29/2009
About Corporate Goals Corporate Values Top Management Obligations... 6
Jan 5, 2018 Table of Contents About... 3 Corporate Goals... 4 Corporate Values... 5 Top Management Obligations... 6 2 About Itransition Group (Company) is a leading provider of digital solutions and IT
Global Journal of Engineering Science and Research Management
SW REQUIREMENT ENGINEERING IN PRACTICE Smita Raj* * C-204, Shiksha Niketan, Vasundhara, Sec-5, Ghaziabad 201012 DOI: 10.5281/zenodo.199474 KEYWORDS: Requirement, Requirement engineering, process models,
Requirements Engineering. Massimo Felici Room 1402, JCMB, KB
Requirements Engineering Massimo Felici Room 1402, JCMB, KB 0131 650 5899 mfelici@inf.ed.ac.uk Administration SEOC1 Tutorials start in week 3 SEOC1 Communications: Mailing List: seoc1-students@inf.ed.acuk
Change is constant. Obstacle to RE: Why requirement study? Limitation of the designers Different knowledge domains Not expertise Ubiquitous nature
Design the right thing! Fang Chen Change is constant Requirement Design Creation What makes the change? Human nature Society Organization i Competitors Human nature: never satisfy ) 4 Why requirement study?
CMMI for Acquisition Quick Reference
AGREEMENT MANAGEMENT PROJECT MANAGEMENT (ML2) The purpose of Agreement Management (AM) is to ensure that the supplier and the acquirer perform according to the terms of the supplier agreement. SG 1 The
Software Quality Engineering Courses Offered by The Westfall Team
Building Skills is a 3-day course that is a subset of our course. The course is designed to provide a fundamental knowledge base and practical skills for anyone interested in implementing or improving
Software Quality Engineering Courses Offered by The Westfall Team
Courses is a 2-day course that is a subset of our course. The course is designed to provide an overview of techniques and practices. This course starts with an overview of software quality engineering
Lecture 7 Software Product Design and Project Overview
Lecture 7 Software Product Design and Project Overview Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 16, 2008
Introduction. Scope Management Approach. Roles and Responsibilities. Processes included in Scope Management are:
Introduction Scope Management involves the management of techniques that make sure that the project comprises a Processes included in Scope Management are: 1. Collect Requirements In this process, project
QUALIFICATIONS PACK - OCCUPATIONAL STANDARDS FOR IT-ITeS INDUSTRY. SUB-SECTOR: Engineering and R&D. OCCUPATION: Product Marketing
QUALIFICATIONS PACK - OCCUPATIONAL STANDARDS FOR IT-ITeS INDUSTRY Contents 1. Introduction and Contacts.......P.1 2. Qualifications Pack....P.2 3. Glossary of Key Terms.......P.3 4. NOS Units...P.5 OS
Next Generation Design and Verification Today Requirements-driven Verification Methodology (for Standards Compliance)
Next Generation Design and Verification Today Requirements-driven Verification Methodology (for Standards Compliance) Mike Bartley, TVS Agenda Motivation - Why Requirements Driven Verification? Introduction
Knowledge Base for Writing Test Cases (Part 1)
Knowledge Base for Writing Test Cases (Part 1) Name: Charles Gundlach Date: July 19, 2008 Version #: 2.0 Template Version 1.0 Course Description: The purpose of this training is to present a knowledge
Systems Engineering Concept
Systems Engineering Concept WHITE PAPER February 2017 The Systems Engineering Concept provides practical hands-on methods and tools, that enable companies to meet today s global business challenges through
WCS CRM Consultancy. High-Level CRM Implementation Planning Guidance
WCS CRM Consultancy High-Level CRM Implementation Planning Guidance High-Level CRM Implementation Planning Guidance This document is intended to provide an overview for discussion on CRM implementation
Requirement Engineering. L3 The requirement study. Change is constant. Communication problem? People are hard to understand!
Requirement Engineering L3 The requirement study Fang Chen Requirement are ubiquitous part of our lives Understand the requirement through communication Requirement Creation Communication problem? People
MIS 2101/2901 EXAM 1 REVIEW SESSION. Michelle Purnama Diamond Peer
MIS 2101/2901 EXAM 1 REVIEW SESSION Michelle Purnama Diamond Peer michelle.purnama@temple.edu EXAM FORMAT 25 Multiple Choice Questions First 5 from assigned readings Next 10 from assigned videos & lectures
Requirements-driven Verification Methodology for Standards Compliance Serrie-justine Chapman (TVS) Dr Mike Bartley (TVS)
Requirements-driven Verification Methodology for Standards Compliance Serrie-justine Chapman (TVS) Dr Mike Bartley (TVS) in collaboration with Test and Verification Solutions Ltd Infineon Technologies
1. Introduction Purpose Scope Definitions and Acronyms References Documents Figures and models 4
Table of Contents 1. Introduction 2 1.1. Purpose 2 1.2. Scope 2 1.3. Definitions and Acronyms 3 1.4. References 3 1.4.1 Documents 3 1.4.2 Figures and models 4 2. Overall Description 5 2.1. Product perspective
Flexibility Stability
Risk-Based Control Balancing Flexibility with Stability By Linda Westfall www.westfallteam.com There is a dichotomy in software configuration management. On one side, individual developers need the flexibility
TECHNICAL GUIDE. How to manage the transition successfully AUTOMOTIVE MANAGEMENT SYSTEM TRANSITION FROM ISO/TS TO IATF EDITION OCT 2017
How to manage the transition successfully AUTOMOTIVE MANAGEMENT SYSTEM TRANSITION FROM ISO/TS 16949 TO IATF 16949 TECHNICAL GUIDE EDITION OCT 2017 Move Forward with Confidence IATF HAS PUBLISHED THE NEW
EVALUATING CONTRACT LIFECYCLE MANAGEMENT SOLUTIONS: BEST-IN-CLASS FEATURES
EVALUATING CONTRACT LIFECYCLE MANAGEMENT SOLUTIONS: BEST-IN-CLASS FEATURES INTRODUCTION INTRODUCTION CONTRACTS FORM THE FOUNDATION OF ALL BUSINESSES AND EVERY BUSINESS RELATIONSHIP. THEY DEFINE EVERY ASPECT
ASIS Standards: Auditing for. Improvement. Security, Risk and Resilience. Auditing. Value Added. Auditing
Opportunities for Improvement ANSI/ASIS SPC.1 2009 Planning an Audit Value Added Auditing Evaluating Effectiveness Implementing a Successful Audit ASIS Standards: Auditing for Improvement Security, Risk
9. Project Quality Management- Introduction
Construction Project Management (CE 110401346) 9. Project Quality Management- Introduction Dr. Khaled Hyari Department of Civil Engineering Hashemite University Content Quality: What? (The concept of quality)
A Guide to Calculating the ROI of Application Lifecycle Management Tools
A Guide to Calculating the ROI of Application Lifecycle Management Tools Why work with integrated ALM? With regards to tooling questions, software developers in a lot of companies have traditionally taken
After the Audit. What s s Next?? Corrective Action. Theresa McCarthy ASQ-Granite State 18 November 2009
After the Audit What s s Next?? Corrective Action Theresa McCarthy ASQ-Granite State 18 November 2009 Agenda ISO19011:2002 ISO 9001:2000 Corrective Action Systems (IA input) CAPA Plans Follow Up Effectiveness
National Occupational Standard
SSC/N3023 Undertake biometric data entry and processing. National Occupational Standard Overview This unit is about dealing with biometric data entry and processing. Applicable OS Unit SSC/N3023 Undertake
PART THREE - WORK PLAN AND IV&V METHODOLOGY WORK PLAN. FL IT IV&V Work Plan
WORK PLAN FL IT IV&V Work Plan PART THREE - WORK PLAN AND IV&V METHODOLOGY ID Task Name Duration 1 FL IT IV&V Project Work Plan 261 days 2 DDI / SI Contract Award 0 days 3 Project Initiation and Planning
Enterprise Availability Management
Statement of Work Enterprise Availability Management This Statement of Work ( SOW ) is between the Customer (also called you and your ) and the IBM legal entity referenced below ( IBM ). This SOW is subject
Core Competency Education Objectives and Testing Parameters for VMA and CVS
Core Competency Testing for Value Methodology Associate () and Certified Value Specialist () assume that the exam and exam are now separate tests, where a examinee has previously passed the exam. examinees
Sommerville Chapter 4. Requirements Basics The Document and The Requirements
Sommerville Chapter 4 Requirements Basics The Document and The Requirements 2 Announcements You should have formed your Team of 2 for the coursework and informed the TA by email Correction - No C++ knowledge
[Company] [Company Address] [Project Name] [Sub-Project, phase, etc.]
![[Company] [Company Address] [Project Name] [Sub-Project, phase, etc.]](/thumbs/82/85120602.jpg "[Company] [Company Address] [Project Name] [Sub-Project, phase, etc.]")
This template is downloaded from project-management.magt.biz [Company] [Company Address] Tel: Fax: [Company Phone] [Company Fax] [Company E-mail] May 16, 2015 [Ref. number] Marc Arnecke, PMP [Sub-Project,
Product Requirements. Requirements. Get it Right ASAP. Why Requirements are Difficult. Types of S/W Requirements. Levels of S/W Requirements
Requirements Overview importance of getting right difficulty of getting right types and levels of characteristics of good the Requirements Development Process inception gathering, classification evaluation
PMP. Processexam.com. PMI Project Management Professional. Exam Summary Syllabus Questions
PMP PMI Project Management Professional Processexam.com Exam Summary Syllabus Questions Table of Contents Keys to success in PMP Exam on PMI Project Management Professional... 2 PMI PMP Certification Details:...
WORK PLAN AND IV&V METHODOLOGY Information Technology - Independent Verification and Validation RFP No IVV-B
1. Work Plan & IV&V Methodology 1.1 Compass Solutions IV&V Approach The Compass Solutions Independent Verification and Validation approach is based on the Enterprise Performance Life Cycle (EPLC) framework
Question 2: Requirements Engineering. Part a. Answer: Requirements Engineering Process
Question 2: Requirements Engineering Part a. Answer: Requirements Engineering Process The requirements engineering process varies from domain to domain. But the general activities involved are: Elicitation
Chapter 1: Introduction
Chapter 1: Introduction Engineering Engineering 1 Objectives In this chapter, you will learn about: The importance of requirements The role of RE in Software Development Lifecycle Gus Engineering 2 Problem
WESTERN AUSTRALIAN LOCAL GOVERNMENT ASSOCIATION POSITION DESCRIPTION
WESTERN AUSTRALIAN LOCAL GOVERNMENT ASSOCIATION POSITION DESCRIPTION Position Title: Procurement Specialist Reports to: Procurement Manager Unit: Business Solutions Date Reviewed: September 2017 1 POSITION
Construction Project Management Training Curriculum Integration Map
Construction Project Management Training Curriculum Integration Map Value of the Project Management is being recognized all over the world. Most businesses manage their business by successfully implementing
MABAAT-MG-RWP-V0.1--Requirements_work_Plan Page 1 of 7
Project Business Analysis Knowledge Appraisal Tool Document Requirements Work Plan Created By Perry McLeod Created October 29, 2007 Version V0.1 State Draft MABAAT-MG-RWP-V0.1--Requirements_work_Plan Page
IIS Competency Domain Model
IIS Competency Domain Model Knowledge, Skills and Abilities for IIS Job Roles PHII Academy 18 November 2015 www.informaticsacademy.org Standards and Interoperability Applies informatics standards to ensure
Improving the Test Process with TMMi
Improving the Test Process with TMMi BCS SIGiST 19 th September 2012 Presented by Geoff Thompson Listen Challenge Understand Interpret Create Experimentus Ltd 17a Dorset Square London NW1 6QB T: +44 (0)207
Chapter 1. Contents. 1.1 What is Software Engineering! Solving Problems. Objectives. What is Software Engineering
Chapter 1 What is Software Engineering Shari L. Pfleeger Joanne M. Atlee 4 th Edition Contents 1.1 What is Software Engineering? 1.2 How Successful Have We Been? 1.3 What Is Good Software? 1.4 Who Does
Software Quality Engineering where to find it in Software Engineering Body of Knowledge (SWEBOK)
Software Quality Engineering where to find it in Software Engineering Body of Knowledge (SWEBOK) Witold Suryn 1, Anabel Stambollian 2, Jean-Charles Dormeux 3, Luc Bégnoche 4 1 Software and Information
Role Profile. Role Title: Head of Compliance. Directorate: Housing Services. Department: Property Services. Team: Compliance.
Role Profile Role Title: Head of Compliance Directorate: Housing Services Department: Property Services Team: Compliance Role Identifiers: - Career Ladder: Management - Level: Manager Level 3 - Function:
CITY OF KOTZEBUE REQUEST FOR PROPOSAL ADMINISTRATION IT SERVICES FOR FY18 REQUEST FOR PROPOSAL INFORMATION TECHNOLOGY SUPPORT SERVICES
CITY OF KOTZEBUE REQUEST FOR PROPOSAL 18-01 ADMINISTRATION IT SERVICES FOR FY18 REQUEST FOR PROPOSAL INFORMATION TECHNOLOGY SUPPORT SERVICES Vendors are required to provide as much detail as possible in
Conformity assessment systems and schemes for accessibility requirements
BT WG 185 eaccessibility BT WG 101-5 Usability and safety of electrical products with reference to people with special needs Conformity assessment systems and schemes for accessibility requirements CEN
CERT Resilience Management Model, Version 1.2
CERT Resilience Management Model, Organizational Process Focus (OPF) Richard A. Caralli Julia H. Allen David W. White Lisa R. Young Nader Mehravari Pamela D. Curtis February 2016 CERT Program Unlimited
Biometrics Enterprise Architecture Systems Engineering Management Plan (BMEA SEMP)
Biometrics Enterprise Architecture Systems Engineering Management Plan (BMEA SEMP) Version 1.0 Prepared by: Date: November 24, 2009 Revision History Purpose Revision Date Level 11/17/2009 First Draft 1.0
CMMI V2.0 MODEL AT-A-GLANCE. Including the following views: Development Services Supplier Management. CMMI V2.0 outline BOOKLET FOR print.
CMMI V.0 MODEL AT-A-GLANCE Including the following views: Development Services Supplier Management CMMI V.0 outline BOOKLET FOR print.indd CMMI V.0 An Integrated Product Suite Designed to meet the challenges
Project Report Template (Sem 1)
1. Introduction & Problem Statement Project Report Template (Sem 1)
Project Management: A Systems Approach to Planning, Scheduling, and Controlling Twelfth Edition
Project Management: A Systems Approach to Planning, Scheduling, and Controlling Twelfth Edition Chapter Ten Working with Executives Type of Sponsor Involvement Micromanagement Effectiveness Invisibility
Estimating the Cost of Enterprise Software System Implementations: It s Often Buyer Beware. White Paper. Ben Harrison, MAVERICK Technologies
Estimating the Cost of Enterprise Software System Implementations: It s Often Buyer Beware White Paper Ben Harrison, Introduction... 3 Cost of Ownership...3 Software Price, Discounting and Maintenance...4
Powerful Mechanism for Deployment. November 2004 Copyright 2004 Raytheon Company. All rights reserved.
Team-of of-four Powerful Mechanism for Deployment Author contact info Laurie Haack Senior Principal Software Engineer Engineering Process Group Network Centric Systems Raytheon Company Fullerton, CA lahaack@raytheon.com
Solutions Manual. Object-Oriented Software Engineering. An Agile Unified Methodology. David Kung
2 David Kung Object-Oriented Software Engineering An Agile Unified Methodology Solutions Manual 3 Message to Instructors July 10, 2013 The solutions provided in this manual may not be complete, or 100%
Defining Composite Critical Scenarios for the Development of Large Scale System Architecture Using an SEI's ADDbased. Aldo Dagnino
Defining Composite Critical Scenarios for the Development of Large Scale System Architecture Using an SEI's ADDbased Framework Aldo Dagnino ABB Inc. US Corporate Research Center Raleigh, NC ABB, ISS USCRC
A Continuous Improvement Approach for Medical Device Software Development Companies. Dr. Özden Özcan-Top - Dr. Fergal Mc Caffery
A Continuous Improvement Approach for Medical Device Software Development Companies Dr. Özden Özcan-Top - Dr. Fergal Mc Caffery 12/07/2017 Lero 2015 1 Dr. Özden Özcan - Top Dr. Fergal Mc Caffery Dundalk
GUIDE TO THE CHANGES IN PMP simpl learn i
GUIDE TO THE CHANGES IN PMP- 2015 simpl learn i Table of contents Introduction the purpose of this manual 1 New Tasks: Initiating 3 New Tasks: Planning 4 New Tasks: Executing 6 New Tasks: Monitoring and
1 Management Responsibility 1 Management Responsibility 1.1 General 1.1 General
1 Management Responsibility 1 Management Responsibility 1.1 General 1.1 General The organization s management with executive The commitment and involvement of the responsibility shall define, document
Software Engineering Fall 2014
Software Engineering Fall 2014 (CSC 4350/6350) Mon.- Wed. 5:30 pm 7:15 pm ALC : 107 Rao Casturi 09/17/2014 What is next Deliverable? Due: 09/19/2014 1. Problem Statement with Shall statements 2. RTM (4
copyright Value Chain Group all rights reserved
About the VCG VCG Mission Statement Goal Value Proposition Member View Process Transformation Framework (VRM) Value Reference Model (XRM) X Reference Model (VLM) Value Lifecycle Model (SOA-IM) Service
Job Description. Senior Procurement Contract Specialist. Job title. Existing Post) Department. Background Information
Job Description Job title Reports to Senior Procurement Contract Specialist Financial Controller Job Holder Section Vacant (Upgrade Existing Post) Procurement Department Background Information The Cayman
Safety Perception / Cultural Surveys
Safety Perception / Cultural Surveys believes in incorporating safety, health, environmental and system management principles that address total integration, thus ensuring continuous improvement, equal