IE 366 Requirements Development
|
|
- Emil Haynes
- 6 years ago
- Views:
Transcription
1 IE 366 Requirements Development Developing and Managing Requirements
2 IE 366 Requirements Definition: A requirement describes something that is needed or desired in a system (or product or process) that is to be designed and implemented. Form: generally, a written statement. Examples: see term project Statement of Need handout Requirements vs. Specifications Requirements state what is needed/desired. [Design] Specifications state how that is to be accomplished in the system. Sometimes the word specifications is used as a general term to refer to both cases.
3 Some Requirements Development Activities IE 366 Inception Elicitation Elaboration Negotiation Specification Validation Management 3
4 IE 366 Inception: Getting Started Context free questions to understand: basic problem at hand people who want the solution nature of the solution that is desired Some questions that need answers: Who is behind the request for this work? Who will use the solution? How would you characterize good output of a solution? What problems will this solution address? Should I be asking you anything else? Am I asking too many questions? Major source of answers (esp. IE 366): Statement of Need 4
5 Elicitation: Getting Requirements Out Of the Customer and Other Sources IE 366 Goals: To establish Tools scope of the problem. overall perception of the solution of the problem, i.e., the product the re-engineered system To understand the system. parts of the environment that surround the system. other objects that are to be produced by the system. objects that are used by the system to perform its functions. processes or functions that manipulate or interact with the objects. constraints (i.e. cost, size, business rules). performance criteria (i.e. speed accuracy). requirements volatility. Interviews with Subject Matter Experts (SMEs) & stakeholders Observations Internet research Thinking through the system/process 5
6 IE 366 Elaboration: Refining, Adding Detail Goals: To refine information gathered from inception and elicitation. To develop system models. To identify features of the system. To identify constraints for the system. Tools Interviews with SMEs User scenarios (use cases) System models Personnel Descriptions Environment Descriptions Equipment & Facilities Models Drawings, Layouts Functional or process models, e.g., (Flow) process charts Flow Diagrams IDEF0 models Task analyses 6
7 Negotiation: Compromising the Ideal and the Real IE 366 Considerations Technical Limitations Economic Limitations Design Team Limitations Tool Limitations Time Constraints Space, Capacity Limitations etc. 7
8 Specification: Representing the Requirements IE 366 Guidelines for a Requirements Document: Requirements state something: Necessary Verifiable Attainable and they state it clearly. Common Problems: Making bad assumptions Writing implementation (HOW) instead of requirements (WHAT) Describing operations instead of writing requirements Using incorrect terms Using incorrect sentence structure or bad grammar Missing requirements Over-specifying 8
9 IE 366 Making bad assumptions No access to appropriate information Solution: Make information available to all authors by, e.g., Notebook Website Information does not exist Solution: Authors should document all assumptions 9
10 Writing implementation (HOW) instead of requirements (WHAT) IE 366 Example: The workstation shall include an RDM hydraulic lift, adjustable-height work table. (IMPLEMENTATION) The requirement should state WHAT is needed not HOW it is to be provided. Solution: Ask the question: WHY do you need the requirement? 10
11 Writing implementation (HOW) instead of requirements (WHAT) IE 366 Answers: Workers of various sizes will use the workstation. A typical workpiece requires handwork about four inches above the surface supporting it. By ergonomic guidelines, the workpiece should be slightly below elbow level. This is real requirement: The workstation shall be adjustable so that the work surface is 4 in below the elbow level of the worker. It leaves lots of options open for implementation. 11
12 Describing operations instead of writing requirements IE 366 Similar to the implementation problem Examples: Tools shall be returned to dedicated storage spaces when they are no longer needed. (OPERATION) Workers shall place the parts needed for each widget in a separate container for temporary storage and transportation. (OPERATION) Real Requirements: A dedicated storage space shall be provided for each tool. A means shall be provided for temporary storage and transportations of the parts required for each widget. 12
13 IE 366 Using Incorrect Terms Use of Terms: Requirements use the word shall. Statements of fact use will. Goals use should. Terms to avoid: support but not limited to etc. and/or 13
14 Using incorrect sentence structure or bad grammar IE 366 Requirements should be easy to read and understand. Format: The work system shall provide means to The work system shall be capable of Subsystem #1 shall provide means to... Subsystem #2 shall weigh no more than Note: The name of the system and subsystem appears in these locations, if the system name is complex, use acronyms. Guidelines: Each shall should be followed by a single predicate, not by a list. Should not be complicated by explanation of operations, design or other information. 14
15 IE 366 Unverifiable Requirements Avoid ambiguous terms: Minimize Maximize Rapid User-friendly Easy Sufficient Adequate Quick Be specific. How rapid? 10 per hour, 5 per hour. What is sufficient? 10 units, 100 units. What is user-friendly? If you are not sure yet, enclose the term in asterisks (e.g., *rapid*, *userfriendly*). 15
16 Unverifiable Requirements vs. Verifiable Requirements IE 366 There is a time for unverifiable requirements: in the preliminary stages of requirements development. May be important to capture the idea for a requirement even if it cannot be made verifiable yet. e.g., The system shall be *user-friendly*. Unverifiable requirements are sometimes call Customer Requirements (often stated by and in the language of the customer). 16
17 Unverifiable Requirements vs. Verifiable Requirements (continued) IE 366 Engineers should strive to make all requirements verifiable e.g., All display fonts shall be 12-point or larger. All controls shall be labeled.... (others required to make *user-friendly* verifiable) Verifiable requirements are sometimes call Engineering Requirements.
18 IE 366 Missing requirements Use the elaboration tools to make sure every aspect of the system is specified. Requirements Drivers (i.e., things to think about): Functionality Performance Interface Environment Facility Transportation Deployment Training Personnel Reliability Maintainability Operability Safety Regulations Security Privacy Design constraints Usability 18
19 IE 366 Over-specifying Major cause of cost overruns and delivery time delays. Ask the question why it is needed before writing it as a requirement. Be aware of over stringent requirements Allow for tolerances (i.e. if height of a work table is specified to be 48, allow for variations, e.g., 48 + ½ ) 19
20 Validation: Making Sure the Requirements Are Correct IE 366 Examine the requirements for: Ambiguity Inconsistencies Omissions Errors Validation reviewers: Engineers Users Customers Other stakeholders 20
21 IE 366 SMART: Requirements Checklist S Specific? Well defined and clear to anyone involved in the product/process. M Measurable? Have a way of quantifiable measurement to know when the requirement is reached, or at least the potential for that. Some flexibility in initial Requirements. A Agreed Upon? Agreement between both you and your customer. R Realistic? Within the availability of resources and knowledge. T Time Based? Enough time to produce the desired result. 21
22 IE 366 Requirements Management IE 366 Requirements Management Organize requirements by work system processes (IDEF0 model) Record in [Requirements] worksheet of WSE workbook: Requirement Number Requirement (text) A#: IDEF0 A# of task/subtask to which requirement applies ( A0 for now) Task/Subtask: filled in automatically from HTA worksheet Author Requirement Status preliminary: not yet verifiable i.e., Customer Requirement unmet: verifiable but not yet met i.e., Engineering Requirement (unmet) met: verifiable and met i.e, ER (met) Design Features (that satisfy requirement) Comment 22
23 Some Requirements Development Activities IE 366 Inception Elicitation Elaboration Negotiation Specification Validation Management 23
24 IE 366 Requirements Examples Pre-Reflow Inspection Station 24
Requirements Engineering
Requirements Engineering Developing and Managing Requirements 1 Requirements Engineering Tasks Inception Elicitation Elaboration Negotiation Specification Validation Management 2 Inception: Getting Started
More informationWriting Good Requirements. (A Requirements Working Group Information Report)
Writing Good Requirements Page 1 of 11 Published in the Proceedings of the Third International Symposium of the NCOSE - Volume 2, 1993. Prepared by the Requirements Working Group of the International Council
More informationRequirements Engineering
Requirements Engineering Software Engineering Andreas Zeller Saarland University Requirements Engineering The Real World Requirements Engineering A description of what the system should do (but not how)
More informationChapter 8 Understanding Requirements
Chapter 8 Understanding Requirements Software Engineering: A Practitioner s Approach, 8th edition by Roger S. Pressman 1 Outline What is RE? RE Tasks RE Process Eliciting Requirements( 需求获取 ) Developing
More informationBCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2
BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 Friday 30 th September 2016 - Morning Answer any THREE questions
More informationRequirements 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
More informationDr. 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
More informationRequirements Engineering
Requirements Engineering Professor Ray Welland Department of Computing Science University of Glasgow E-mail: ray@dcs.gla.ac.uk The Importance of Requirements Identifying (some) requirements is the starting
More informationOi Requirements Communication in New Product Development
Steer Your Development! Goal-Oriented Oi Requirements Communication in New Product Development September 9, 2008 Samuel Fricker, Tony Gorschek, Martin Glinz Product Manager in Context: Simplified, Stylized
More informationDr. Ken Funk From: Will Secor
To: Dr. Ken Funk From: Will Secor cc: Mike Lee Subject: PRIS Progress Report 1 Date: 13 January 2012 This memo describes our progress on the Pre-Reflow Inspection Station (PRIS) project. We are to design
More informationRequirements Definition
16.842 Fundamentals of Systems Engineering Session 3 Fall 2009 Requirements Definition How we should (attempt to) specify exactly what is needed before we start designing Prof. Olivier de Weck 1 V-Model
More informationIntroduction to Systems Analysis and Design
Introduction to Systems Analysis and Design What is a System? A system is a set of interrelated components that function together to achieve a common goal. The components of a system are called subsystems.
More informationDEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING Software Engineering Third Year CSE( Sem:I) 2 marks Questions and Answers
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING Software Engineering Third Year CSE( Sem:I) 2 marks Questions and Answers UNIT 1 1. What are software myths Answer: Management myths: We already have a book
More informationL2 The requirement study. Requirement Engineering. Fang Chen
L2 The requirement study Fang Chen Requirement Engineering Requirement are ubiquitous part of our lives Understand the requirement through communication People are hard to understand! Requirement Creation
More informationThe Enterprise Systems Engineering Center Requirements Management Guide - Analysis
The Enterprise Systems Engineering Center Requirements Management Guide - The Enterprise Requirements Management Guide - Introduction Innumerable studies have concluded that requirements problems are the
More informationCritical 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
More informationAgenda. Introduction. The Impact of Requirement Issues on Testing. Introduction. What are common requirements issues? What is the impact on testing?
The Impact of Requirement Issues on Testing Presented by Kirsten Kiefer, Software Education Associates Ltd Agenda Introduction What are common requirements issues? What is the impact on testing? What can
More informationLCS International, Inc. PMP Review. Chapter 3 Developing the Project Scope Statement. Presented by David J. Lanners, MBA, PMP
PMP Review Chapter 3 Developing the Project Scope Statement Presented by David J. Lanners, MBA, PMP These slides are intended to be used only in settings where each viewer has an original copy of the Sybex
More informationStage 1 Scoping (concept formation)
Stage 1 Scoping (concept formation) A quick assessment of the technical merits of the project and its market prospects Forming a team Define key attributes of product Technical feasibility Market prospects
More informationCOSC 735: Software Engineering Test 1 Sample Solution
COSC 735: Software Engineering Test 1 Sample Solution QUESTION 1: 1. (a) Define Software Engineering. Software engineering is the establishment and use of sound engineering principles in order to obtain
More informationSistemi ICT per il Business Networking
Corso di Laurea Specialistica Ingegneria Gestionale Sistemi ICT per il Business Networking Requirements Engineering Docente: Vito Morreale (vito.morreale@eng.it) 17 October 2006 1 UP Phases 1. Inception
More informationRequirement 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
More informationDarshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1
Failure Rate Darshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1 SOFTWARE (What is Software? Explain characteristics of Software. OR How the software product is differing than
More informationREQUIREMENTS ENGINEERING
1 REQUIREMENTS ENGINEERING Chapter 4- by Ian Sommerville TOPICS COVERED Functional and non-functional requirements The software requirements document Requirements specification Requirements engineering
More informationRequirements Engineering. Andreas Zeller Saarland University
Requirements Engineering Software Engineering Andreas Zeller Saarland University Communication project initiation requirements gathering Planning estimating scheduling tracking Waterfall Model (1968) Modeling
More informationScope Management. 2. Meetings 2. Requirements Management Plan 3. EEF 4.OPA
Scope Management 5.1 Plan Scope Management: The process of creating scope management plan that documents how project scope will be defined, validated and controlled # Requirement: Condition or capability
More informationIntroduction 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
More informationRequirements Engineering with Use Cases
Requirements Engineering with Use Cases Csaba Veres Outline What are use cases? What do they tell us? How can you write them (properly)? What is a use case? A use case specifies the behavior of a system
More informationTest Workflow. Michael Fourman Cs2 Software Engineering
Test Workflow Michael Fourman Introduction Verify the result from implementation by testing each build Plan the tests in each iteration Integration tests for every build within the iteration System tests
More informationRequirements Verification and Validation
SEG3101 (Fall 2010) Requirements Verification and Validation SE502: Software Requirements Engineering 1 Table of Contents Introduction to Requirements Verification and Validation Requirements Verification
More informationChapter One PROJECT MANAGEMENT OVERVIEW
Chapter One PROJECT MANAGEMENT OVERVIEW Project management itself is not a new concept. It has been practiced for hundreds, even thousands of years. Any large undertaking requires a set of objectives,
More informationCHAPTER 2 LITERATURE SURVEY
10 CHAPTER 2 LITERATURE SURVEY This chapter provides the related work that has been done about the software performance requirements which includes the sub sections like requirements engineering, functional
More informationCHAPTER 2: IMPLEMENTATION PHASES AND OFFERINGS
CHAPTER 2: IMPLEMENTATION PHASES AND OFFERINGS Objectives Introduction The objectives are: Describe the purpose of the phase planning activity, preconditions, and deliverables in the implementation methodology.
More informationAnalysing client requirements
Analysing client requirements Before you can start to analyse the information you have gathered you should think about what you are trying to achieve . The client has presented you with a business problem.
More informationChapter 2 Analyzing the Business Case
Chapter 2 Analyzing the Business Case Explain the concept of a business case and how a business case affects an IT project Describe the strategic planning process and why it is important to the IT team
More informationPROJECT MANAGEMENT OVERVIEW
Chapter One PROJECT MANAGEMENT OVERVIEW Project management itself is not a new concept. It has been practiced for hundreds, even thousands of years. Any large undertaking requires a set of objectives,
More informationComp435 Object-Oriented Design. Requirements and Use Cases. Requirements Analysis. Outline. Requirements Analysis. Requirements change
Comp435 Object-Oriented Design Requirements and Use Cases Week 2 Computer Science PSU HBG 1 3 Outline Requirements Analysis Types of Requirements Requirements in Iterative Development Requirements Artifacts
More informationSystems Analysis and Design in a Changing World, Fourth Edition
Systems Analysis and Design in a Changing World, Fourth Edition Learning Objectives Describe the activities of the systems analysis life cycle phase Explain the effect of business process reengineering
More informationChapter 3 Prescriptive Process Models
Chapter 3 Prescriptive Process Models - Generic process framework (revisited) - Traditional process models - Specialized process models - The unified process Generic Process Framework Communication Involves
More informationThinking Ahead to System Verification and System Validation Louis S. Wheatcraft Requirement Experts (281)
Thinking Ahead to System Verification and System Validation Louis S. Wheatcraft Requirement Experts (281) 486-9481 louw@reqexperts.com Note: [Feb 2016] This is an update to this paper which was originally
More informationWhat is Software Engineering?
COSC 3351 Software Software Life Cycle (I) Spring 2008 What is Software Engineering? Real world problems are large and complex. Solving problems requires multiple steps Analyzing: Break the problems into
More information! 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.%#
More informationNEW! The Project Manager & The Business Analyst. by Barbara A. Carkenord, CBAP, PMP, PMI-ACP
NEW! The Project Manager & The Business Analyst by Barbara A. Carkenord, CBAP, PMP, PMI-ACP A White Paper from RMC Project Management, Inc. www.rmcproject.com 10953 Bren Road East, Minnetonka, Minnesota
More informationCMMI-DEV V1.3 CMMI for Development Version 1.3 Quick Reference Guide
processlabs CMMI-DEV V1.3 CMMI for Development Version 1.3 Quick Reference Guide CMMI-DEV V1.3 Process Areas Alphabetically by Process Area Acronym processlabs CAR - Causal Analysis and Resolution...
More informationNormalization of Requirements Specification Document on Software Project Management
Normalization of Requirements Specification Document on Software Project Management Rachida Hassani*, Younès EL Bouzekri EL Idrissi bn Tofail University, National School of Applied Sciences, Kenitra, Morocco.
More informationWhat are requirements? Basics of Requirement Engineering. Definition of a Stakeholder. Stated Vs. Real Requirements. Stated Vs.
What are requirements? Basics of Requirement Engineering Muzaffar Iqbal Farooqi A requirement is a necessary attribute in a system, a statement that identifies a capability, characteristic, or quality
More informationChange 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?
More informationUnit 9 Information Systems
Unit 9 Information Systems Computer Concepts 2016 ENHANCED EDITION 9 Unit Contents Section A: Information System Basics Section B: Enterprise Applications Section C: Systems Analysis Section D: Design
More informationPROFESSIONAL REVIEW GUIDANCE FOR CANDIDATES
PROFESSIONAL REVIEW GUIDANCE FOR CANDIDATES 1 CONTENTS These guidance notes will assist you in structuring your submission to attain Chartered Membership of the CIOB. They comprise: Page 3 3 3 Applying
More informationCSEB233: 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
More informationPROFESSIONAL REVIEW GUIDANCE FOR CANDIDATES
PROFESSIONAL REVIEW GUIDANCE FOR CANDIDATES 1 CONTENTS These guidance notes will assist you in structuring your submission to attain Chartered Membership of the CIOB. They comprise: Page 3 3 3 Applying
More informationDefine and Initiate SubPhase
Project Management Methodology Project Management Methodology Training Define and Initiate SubPhase Course Purpose Familiarize team members with the Start Project Sub-Phase processes. Understand process
More informationA TUTORIAL ON ERGONOMIC AND PROCESS MODELING USING QUEST AND IGRIP. Deidra L. Donald
Proceedings of the 1998 Winter Simulation Conference D.J. Medeiros, E.F. Watson, J.S. Carson and M.S. Manivannan, eds. A TUTORIAL ON ERGONOMIC AND PROCESS MODELING USING QUEST AND IGRIP Deidra L. Donald
More informationInternational Diploma in Project Management. (Level 4) Course Structure & Contents
Brentwood Open Learning College (Level 4) Page 1 Unit 1 Overview of Project Management The unit 1 covers the following topics: What is A Project? What is Project Management? Project Constraints Tools and
More informationProject Report Template (Sem 1)
1. Introduction & Problem Statement Project Report Template (Sem 1)
More informationPROJECT NAME SECTION GENERAL COMMISSIONING REQUIREMENTS
PART 1 - GENERAL 1.1 SUMMARY A. The Owner has contracted an independent Commissioning Authority. The Commissioning Authority is an independent and knowledgeable third party, hired to verify that the systems
More informationAn Introduction to Influence Maps: Foundations, Construction, and Use
An Introduction to Influence Maps: Foundations, Construction, and Use Jim Smith NDIA Systems Engineering Conference October 29, 2009 Overview This presentation will provide an overview of Influence Maps
More informationIt 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
More informationBusiness Process Oriented Requirements Engineering Process
Process Oriented Requirements Engineering Process Tomoyuki Arao, Eiji Goto, Tomoko Nagata Nomura Research Institute, Ltd. tarao@alumni.cmu.edu, e-gotou@nri.co.jp, t-nagata@nri.co.jp Abstract Although requirements
More informationDeveloping Successful Multimedia Projects
Developing Successful Multimedia Projects Agenda Introduction Overview Phases Summary Introduction Who I am Who you are Why we re here What you re going to learn Why Multimedia? Print Why Multimedia? Print
More informationSkills and competencies
The proper planning and estimating is required to measure the cost of your application development project Sometimes, software development projects fail. When they do, it's not much fun and in most cases,
More informationversion 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
More informationGLP SOPs for Equipment Calibration and Maintenance. Part 5: SOP Templates and SOP on SOPs
GLP SOPs for Equipment Calibration and Maintenance. Part 5: SOP Templates and SOP on SOPs Irina Colligon 1, and Michelle Rosa 2 1 Downingtown, PA, USA 2 Bethlehem, PA, USA Summary Document templates are
More informationContents 5. Building and Maintaining an Effective Team 6. An Overview of Planning and Estimating
TEAMFLY vi Contents 5. Building and Maintaining an Effective Team 77 The Mechanics of Building a Team 78 Team Leadership Starts on Day One! 83 Fostering Teamwork and Synergism 88 Getting the Most from
More informationRequirements Specification
Ambulance Dispatch System Submitted to: Dr. Chung Submitted by: Chris Rohleder, Jamie Smith, and Jeff Dix Date Submitted: February 14, 2006 TABLE OF CONTENTS 1.0 INTRODUCTION...1 1.1 PURPOSE...1 1.2 SCOPE...1
More informationRequirements Analysis and Design Definition. Chapter Study Group Learning Materials
Requirements Analysis and Design Definition Chapter Study Group Learning Materials 2015, International Institute of Business Analysis (IIBA ). Permission is granted to IIBA Chapters to use and modify this
More informationSoftware Engineering (CSC 4350/6350) Rao Casturi
Software Engineering (CSC 4350/6350) Rao Casturi Recap UML Introduction Basic UML concepts 2 Basic Notations of UML Requirement Phase Analysis Phase Design Phase Object Design Phase 1. Use Case Diagrams
More informationIDEF0 Activity Modeling
IDEF0 Activity Modeling What is an Activity Model? A representation of the activities and the relationships between and among those activities in an existing or planned system. A collection of diagrams,
More informationIntroduction to Software Engineering
UNIT I SOFTWARE PROCESS Introduction S/W Engineering Paradigm life cycle models (water fall, incremental, spiral, WINWIN spiral, evolutionary, prototyping, objects oriented) -system engineering computer
More informationThe good news. 34% of software projects succeed. Standish Group, CHAOS Report, 2003
The good news 34% of software projects succeed. Standish Group, CHAOS Report, 2003 1 The bad news That means 66% failed! Standish Group, CHAOS Report, 2003 2 Best Practices Develop Iteratively Manage Requirements
More informationSoftware Engineering II - Exercise
Software Engineering II - Exercise April 29 th 2009 Software Project Management Plan Bernd Bruegge Helmut Naughton Applied Software Engineering Technische Universitaet Muenchen http://wwwbrugge.in.tum.de
More informationVerification and Validation
System context Subject facet Usage facet IT system facet Development facet Validation Core activities Elicitation Negotiation Context of consideration Execution of RE activities Created requirements artefacts
More informationBA Productivity Pack
2011 CVR/IT Consulting LLC All Rights Reserved 1 www.cvr-it.com info@cvr-it.com Overview BA Productivity Pack A collection of tools for the Business Analyst CVR/IT Consulting LLC 2011 CVR/IT Consulting
More informationMotivations. Case Study. Reference documents for the presentation
Case Study Basic V Introduction &V Case Engineering Study Engineering approach for the design of commercial aircraft AGENDA Motivation SYSTEMS ENGINEERING concerns Presentation of the INCOSE document describing
More informationCHAPTER 3 Use Cases. 3. Use Cases
CHAPTER 3 Use Cases Introduction When, Why, Where, What Iteratively Developing Use Cases Inception + Scope Definition + Risk Identification + Actors & Use cases + Project Plan Elaboration + Primary & Secondary
More informationCHAPTER 3 Use Cases. 3. Use Cases
CHAPTER 3 Use Cases Introduction When, Why, Where, What Iteratively Developing Use Cases Inception + Scope Definition + Risk Identification + Actors & Use cases + Project Plan Elaboration + Primary & Secondary
More informationRequirements engineering
Requirements engineering Paul Jackson School of Informatics University of Edinburgh What are requirements? Traditional to distinguish functional from non-functional requirements. Functional requirements
More informationEngaging Stakeholders in the Definition of Requirements for New Technology Systems
Engaging Stakeholders in the Definition of for New Technology Systems Lori Colangelo Delcan Corporation Vienna, VA Many transit agencies face the challenge of deploying new technology systems into in-service
More informationProject Plan Version 1.0
Project Plan Version 1.0 1. Individual tasks breakdown 1.1 Inception phase The inception phase would involve development of a prototype that would display the feasibility of the project and also give an
More informationObject-Oriented Software Engineering Practical Software Development using UML and Java. Chapter 11: Managing the Software Process
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 11: Managing the Software Process 11.1 What is Project Management? Project management encompasses all the
More informationSMART Goals Model. Specific. Measureable. Achievable. Relevant. Time-bound. Talent Management Learning Series 2
SMART Goals 101 SMART Goals Model S M A R T Specific Measureable Achievable Relevant Time-bound Talent Management Learning Series 2 SMART Goals Model in Detail Specific Define expectations and explain
More informationCharting and Diagramming Techniques for Operations Analysis. How to Analyze the Chart or Diagram. Checklist of Questions - Example
Chapter 9 Charting and Diagramming Techniques for Operations Analysis Sections: 1. Overview of Charting and Diagramming Techniques 2. Network Diagrams 3. Traditional Engineering Charting and Diagramming
More informationSafety First OH&S in the Office
VEA Bringing Learning to Life Program Support Notes Safety First OH&S in the Office 24 mins Program Support Notes by Amy Nieuwenhuis, B.Ed (secondary), Cert IV in Workplace Training and Assessment, Cert
More informationBiometrics 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
More informationRequirements 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
More informationRisk-Based Approach to SAS Program Validation
Paper FC04 Risk-Based Approach to SAS Program Validation Keith C. Benze SEC Associates, Inc. 3900 Paramount Parkway, Suite 150 South Morrisville, NC 27560 ABSTRACT SAS is widely used throughout the FDA
More informationUniversity of Portland School of Engineering Establishing Criteria and Evaluating Alternatives
University of Portland School of Engineering Establishing Criteria and Evaluating Alternatives Defining criteria and evaluating alternatives are aspects of design that students have had little experience
More informationFundamentals of Business Analysis
Fundamentals of Business Analysis Welcome! This course = everything you need to get started as a BA. Requirements Interviewing More Requirements Observation Even more requirements Analysis A little about
More informationThinking Ahead to Verification and Validation
Thinking Ahead to Verification and Validation Louis S. Wheatcraft Requirement Experts (281) 486-9481 louw@reqexperts.com Abstract Second only to re-work, a project s largest costs are involved in verification
More informationCMMI-SVC V1.3 CMMI for Services Version 1.3 Quick Reference Guide
processlabs CMMI-SVC V1.3 CMMI for Services Version 1.3 Quick Reference Guide CMMI-SVC V1.3 Process Areas Alphabetically by Process Area Acronym processlabs CAM - Capacity and Availability Management...
More informationFunctional requirements and acceptance testing
Functional requirements and acceptance testing Lecture 3 Software Engineering TDDC88/TDDC93 autumn 2007 Department of Computer and Information Science Linköping University, Sweden Message from the course
More informationTesting the Requirements By Karl Wiegers
Testing the Requirements By Karl Wiegers S omeone once asked me when to begin testing your software. As soon as you ve written your first requirement, I replied. It s hard to visualize how a system will
More informationEstimating 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
More informationSoftware Engineering Fall 2014
Software Engineering Fall 2014 (CSC 4350/6350) Mon.- Wed. 5:30 pm 7:15 pm ALC : 107 Rao Casturi 11/05/2014 Student Registration System (SRS) RC University Management Board approved a new Student Registration
More informationMODPROD 2017, Linköping February 8, 2017
The Need for Comprehensive Whole-life-cycle Systems Engineering Tool Support for Cyber- Physical Systems MODPROD 2017, Linköping February 8, 2017 Daniel Bouskela, EDF, France daniel.bouskela@edf.fr Peter
More informationContinuous Improvement Toolkit. Project Charter. Continuous Improvement Toolkit.
Continuous Improvement Toolkit Project Charter The Continuous Improvement Map Managing Risk FMEA Check Sheets Data Collection PDPC RAID Log* Risk Assessment* Fault Tree Analysis Traffic Light Assessment
More informationModule 1 Introduction. IIT, Bombay
Module 1 Introduction Lecture 1 Need Identification and Problem Definition Instructional objectives The primary objective of this lecture module is to outline how to identify the need and define the problem
More informationManaging Requirements
Managing Requirements by Ivy F. Hooks Several years ago, I called upon an old acquaintance who had recently assumed management of a troubled program. I told him that I would like to help him manage his
More informationInternational Conference of Software Quality Assurance. sqadays.com. The Backbone of the Performance Engineering Process
Software quality assurance days International Conference of Software Quality Assurance sqadays.com Alexander Podelko Oracle. Stamford, CT, USA Minsk. May 25 26, Performance 2018 Requirements 1 Introduction
More informationGlobal 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,
More information