Business Process Oriented Requirements Engineering Process

Size: px
Start display at page:

Download "Business Process Oriented Requirements Engineering Process"

Transcription

1 Process Oriented Requirements Engineering Process Tomoyuki Arao, Eiji Goto, Tomoko Nagata Nomura Research Institute, Ltd. Abstract Although requirements engineering techniques and tools have become gradually recognized as ideas, it is still rare to see these ideas implemented in real projects especially for service business information systems in Japan. Through our research project, we found that there are some specific causes that prevent the requirements engineering process from being implemented in real projects and that eliminating these causes can improve the quality and productivity of the requirements engineering process. In this paper, we first present our analysis of the causes that prevent the implementation of the requirements engineering process and approaches to eliminate them. Then, we demonstrate the results from real pilot projects in which these approaches were applied. Finally, we present our ideas about the possibility of applying the approaches to other projects. 1. Introduction Requirements engineering techniques and tools have gradually become popular in Japan nowadays. However, there are still hardly few examples to be seen of these techniques or tools being adapted to real information systems development, especially in service business systems. Nomura Research Institute, Ltd (NRI) is a system integrator company that mainly deals with service business information systems such as distribution systems and financial systems. Being ordinarily responsible for the upstream of a systems development life cycle, NRI strongly recognizes that requirements engineering processes, such as requirement elicitation and verification, are essential for successful projects. However, given that, as indicated in our in-house report, the biggest reason for project failures is that people start designing and developing systems before requirements are clearly defined, we are still struggling with improving the requirements engineering process. We also found in our project research that most Japanese companies are fraught with the same unsolved problems[1]. We can no longer leave these problems unsolved because customers require more complex systems that cannot be defined without stating explicitly the requirements, and explicit requirements definition also becomes inevitable for division of labor necessary for larger, complex systems development. We started a research project in 2003 to take up this problem. In this paper, we first present our analysis of the causes that prevent the implementation of the requirements engineering process and approaches to eliminate these causes. Then, we demonstrate the results from real pilot projects in which these approaches were applied. Finally, we present possible lessons to be learned from applying the approaches to other projects. 2. Problem Analysis In order to elucidate the problems in current requirement processes, we briefly introduce in this section our assumptions, what the to-be requirement process is, what the as-is process is in our real projects and present an analysis of the gap between them. 2.1 To-be requirement processes What is the ideal requirements engineering process? Simply put, it would be a process that establishes and manages accurate requirements that are sufficient for building information systems satisfied by customers. In reality, however, since it is impossible to establish requirements at one time for both customers and vendors, a requirement process must be continuous and interactive to some degree to make requirements clear and accurate. We assume that the following four-step process is one of the patterns of to-be requirement processes from business problem analysis to system/software design. First, customers and vendors agree to a new business process to realize project goals. Second, vendors elicit and define accurate customer requirements for system/software functions according to the agreed new business process. Third, vendors define detailed system/software specifications that satisfy the customer requirements for system/software functions. Fourth, vendors manage requirement

2 changes quickly and accurately according to requirement changes from customers. 2.2 As-is requirement processes In many projects, however, the To-be process is just an empty theory. We found from real projects that the as-is requirement process of many real software projects is as follows. First, customers and vendors remain ambiguous about the new business process. Second, vendors define customer requirements to some degree but not to a detailed level. Third, vendors elicit customer requirements on the spur of the moment while they design system/software specifications. Fourth, vendors cannot manage requirement changes quickly and accurately because there are too many requirement changes. In the interviews conducted with participants in real projects to clarify the as-is process, project members said that customers tend to decide system/software specifications without verifying what is going on in the real business process or it is hard but inevitable to change the requirement elicitation process, including customers behaviors. To-Be Process Agree with New Process Elicit and Define Accurate Customer Requirements Define s According to Requirements Manage Requirement Change Quickly and Efficiently As-Is Process Leave New Process Ambiguous Approximate Customer Requirements Definitions Elicit Customer Requirements along with Defining s Cannot Manage Requirement Change within the Time Limit Figure 1: As-is and To-be requirement processes Customer Dissatisfaction Continuous Reworking and Bad Quality Cost & Schedule Overrun 2.3 Gap analysis between the to-be and the as-is People recognize the importance of requirements and no one aims directly at the as-is process. This begs the question: why is there such a huge gap between the to-be and the as-is processes? The popular idea is that people cannot know what they require before knowing the real thing. Based on the interviews we conducted, however, we assume that there are other reasons that explain the gap. First, the viewpoints of user business processes differ from those of system functions, especially in the business application systems area, because many customer requirements depend on the business process while system/software functions are basically independent from the business process. The following matrix of the business process requirements and system/software functions from a real project describes how one business process is related to several system functions and vice versa. Figure 2: Matrix of business process and functions Why do viewpoints of the business process differ from those of the system function? Let s think about a business process such as looking at business performance of the past one week before ordering in a retail shop. This process will require a point of sales system to store records of sales data for the past one week. The ordering system should display past performance. And, if a customer wants to know the profit, a financial system will be involved. As can be seen from this case, one business process relates to many system functions. Second, no simple and practical engineering techniques that express both viewpoints exist. Certain requirements engineering techniques by which customers (users) can understand the relationships between the business process and system/software functions and by which vendors can describe system/software specifications accurately along with customer requirements based on the business process is required. Using references is one of the ways to express both viewpoints, but it requires complicated management and will not last long. Some modeling languages cannot satisfy these techniques because many customers only understand what is written in their concrete business terminology and process. Third, people who have responsibility for building information systems tend to give priority to creating outputs from a systems/software functions viewpoint. When a customer defines software requirements about the process, e.g. looking at business performance of the past one week before ordering, it would be better to break down the requirements from the viewpoint of the business process, because a user can decide what s/he wants the information system to do from a

3 ProcessFlow familiar business environment viewpoint. However, people give priority to documents that have formats written from system functions viewpoints only because system functions viewpoints are inevitable for building systems. On the other hand, business process viewpoints tend to be given less weight. As a result, requirement specifications of the business process viewpoint tend to be found here and there in system functions specifications. Sometimes people omit the writing requirement from the business point of view. Project Goal Requirement Viewpoints (Customer s viewpoints) Process Scenarios Process Scenarios Rules Constraints Rules Constraints Viewpoints 3. Approaches to fill the gap In this section, we present our approach to fill the gap between the as-is and to-be processes. In our research project, we tried to make a requirement information model and support the requirements engineering process and tool that will make it possible to elicit detailed requirements from the business point of view and concurrently describe system/software specifications along with that. 3.1 Requirement information model To realize a technique by which customers (users) can understand the relationship between the business process and system/software functions, we defined a requirement information model that contains both viewpoints. We assumed the requirements for the requirements information model to be as follows. The model should have requirement elements that cover business process requirements to system/software specifications. The requirement level is divided into adequate layers from business process requirements to system/software specifications. The model should have a structure that describes system/software specifications from both the system function and business process points of view and makes the relationships between business process and system/software functions visible. The model should have a simple structure that is comprehensible for people who do not have software engineering backgrounds. All relationships should be defined as 1:n relationship to make traceability simple and manageable. The number of traces should be minimized as long as relationships between the business process and system/software functions can be expressed. Based on these requirements, we defined our requirement information model. Process Scenarios Rules Constraints Figure 3: Requirement Information Model The information model can be defined as a matrix that has business process requirement lines and system/software function rows. That is, business process requirement lines represent customers viewpoints. Each business process requirement line represents each basic requirement by a business process such as Stock Taking or Delivery of Reserved Goods (Customer s viewpoint). All requirement elements, such as business detailed requirements, scenarios, business rules and system/software requirements, are managed and grouped under each business process requirement. Each system/software function row represents system/software functions such as Receiving Shipment Data or Issuing Temporary Statements of Delivery. We define each system/software specification at a point of intersection between a business process requirement and a system function. Each software specification of one system/software function should be written separately for each business process. In other words, a specification is a specification of one function to realize requirements from one business process requirement. Hence, each specification is separated by business process requirements. It is possible to sum up software specifications from both a business process and system/software functions viewpoint. That means we could make requirement specification documents from both a user s and software engineer s point of view. (See [2] for more about modeling requirements) 3.2 Requirements Engineering Process Next, we defined the requirements engineering process based on the requirement information model. The most important point is to merge the process of eliciting business requirements and functional requirements into one along with the information

4 model. We assumed the prerequisites for the requirements engineering process to be as follows. The process should clearly define requirements for each business process in the first place to make clear customers viewpoints. The process should elicit detailed requirements for each business process along with customers viewpoints. The process should define system/software requirements as point of intersection of a business process requirement and a software/system function. Based on the prerequisites for the requirements engineering model we defined the phases of the requirements engineering process. Phase 1 (Eliciting and Verifying Process Requirements Viewpoints) You should define business process requirements viewpoints along with goals of a project and agree among stakeholders including customers, users and vendors. Phase 2 (Eliciting and Verifying Process Requirements) You should elicit detailed customer business process requirements. Every elicited requirement should be managed under each business process requirement. Using a scenario is effective to let stakeholders visualize the business process. Phase 3 (Eliciting and Verifying ) You should elicit and verify system/software specifications. The verification should include consistency with related business requirements. You can use the matrix when you verify specifications with customers. 3.3 Requirements Engineering Tool We also developed a repository tool that can manage all the requirements based on the information model. Although we tried to implement market tools at first, we ultimately created it ourselves using Microsoft Access and Excel because it seemed that a lot of customization was required to satisfy our requirements for our support tool. With the tool, all the requirements can be stored in a database, and requirement specifications can be generated from both the business and system/software points of views. 4. Implementation in the Pilot Project We implemented this model and process and these tools to a real project involving a distribution center information system and were able to obtain remarkable results. 4.1 The Pilot Project The pilot project was an enhancement project that adds functions for handling new kinds of products and interfaces for new vendors to an existing distribution center information system. The project lasted three months and cost 40man/month. The main stakeholders included members of the distribution department and information systems department at the customer s company who were able to participate at most of the meetings where requirements were elicited and verified. We elicited requirements throughout the meetings and summarized them into requirement specification documents. The approaches described in section 3 were implemented with tailored modifications and adjustments, and we were able to get excellent results. 4.2 Results of the Pilot Project It seems real to us that many requirements are elicited and fixed in earlier phases than with the former process. In Phase 2 of the process, we felt that wasted efforts commonly found in the past decreased. There was a huge drop in the number of repetitions of the same discussions or state of confusion. Since we analyzed every discussion and requirement according to business process requirements using scenarios and put them into the repository tool, we were able to discuss the requirements constructively based on past discussions and agreements. Also in Phase 3 of the process, we were able to map out every requirement and defined system/software specifications according to the requirements without fail. Next, we present quantitative effects, how requirements are elicited earlier and accurately and how this affects the quality of design by implementing the model and process. The comparison project is a project before implementing the model and process with the same customer and project members. Requirements Eliciting Speed and Accuracy We tried to verify that we could elicit requirements more quickly and accurately than ever. However, since it was impossible to list numbers for the comparison project because it has no status or requirements number tracking, we substituted figures for the minutes of meetings for the number of requirements and allocated them according to process and time. As a result, we found that in the pilot project 80% of requirements are elicited in earlier requirement analysis phases and few additional requirements

5 are elicited in later design phases, while a lot of requirements are elicited in the design phases in the comparison project. Figure 4. Requirements Quantity in time scale Design Quality Improvement In order to see the design improvement, we compared the number of errors and recovery costs in acceptance tests by process for those for which the error causes were stated. As you can see in the figure, errors with causes attributed in the SRS phase decreased dramatically. That indicates that the quality of the SRS phase improved dramatically relative to programming development and unit tests. Requirements Requirements Unit Design Unit Design Before Unit Test & Development After Unit Test & Development Figure 5. Errors by causal process # of Errors Recovery Cost(MH) Number of errors in SRS phase decreased relatively in the pilot project when the new RE process was implemented. 5. Lessons learned from other projects We are now trying to expand the implementation of this model and process to other in-house projects and also trying to make the process an organizational standard process. From the trial, we were able to take away several lessons. You cannot start this process until business viewpoints are almost fixed. In the pilot project, the new business process is relatively clear from the starting point of this project. However, for bigger and new projects, the goal of a project tends to be ambiguous and furthermore the business process requirements unit unstable. If you cannot wait until business process requirements are fixed, you cannot arrange the requirements alongside the business process requirements units. You should share the requirement model with every stakeholder. Although the main stakeholders in the pilot project could participate in most of the meetings, many projects do not proceed in such a manner. If you cannot share the requirement matrix with every project member, you should cut down the matrix into a size that can be shared with the people who are actually involved in the project. Requirements engineering process planning is inevitable for tailoring the model to each project. Although the matrix structure is common for all business application systems, the precision or number of requirement layers varies according to the characteristics of each project. Especially in the case of tailoring the system to a big project with a new customer, you should construct a detailed requirements engineering plan, because sharing the requirements engineering concept and plan is inevitable for implementation. Without training project members and leaders, implementation will fail. The most important part of this process is prioritizing the customer s viewpoints. This idea sometimes encounters resistance among project members. Hence, a project leader should understand and promote adapting the process to the project team s needs. 6. Conclusion Through the research project, we found that having both the customer and system viewpoints integrated in the information model and engineering process is effective for improving the quality of requirements. Although more work and research needs to be done to implement this concept, we believe that this idea will expand as an organizational process in our company and free us from project failures stemming from the requirements engineering process. In addition to that, we hope that this model and process will evolve as a foundation for other requirements engineering technologies and other processes. References [1] Tomoyuki Arao, Expectations for Requirements Engineering, SEC journal, IPA Vol.2, [2] Robertson, James & Suzanne, Mastering the Requirements Process, Addison-Wesley, 1999

6

KEY WORDS analytical, chemical analysis, procurement, management

KEY WORDS analytical, chemical analysis, procurement, management CHEMICAL ANALYSES: HOW TO GET THEM DONE RIGHT (CUSTOMER-ANALYST INTERACTIONS) M.D. Erickson, Environmental Research Division, Argonne National Laboratory, Argonne, IL 60439 ABSTRACT The practical application

More information

Volere Requirements: How to Get Started

Volere Requirements: How to Get Started Requirements: How to Get Started Since its introduction in 1995, the approach to requirements has been adopted by thousands of organizations around the world. We felt that it was time to summarize some

More information

Chapter 2: Requirements Elicitation. Requirements Engineering

Chapter 2: Requirements Elicitation. Requirements Engineering Chapter 2: Requirements Elicitation Requirements Engineering Objectives In this chapter, you will learn about: Eliciting Requirements Your Stakeholders Sample stakeholder s analysis template Case Study

More information

Introduction to Software Engineering

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

More information

Defining Requirements

Defining Requirements Defining Requirements The scope of any project should represent the minimum amount of work needed to fulfil the customer s, or end user s requirements. Doing more work is wasteful; doing less means the

More information

SOFTWARE DEVELOPMENT STANDARD

SOFTWARE DEVELOPMENT STANDARD SFTWARE DEVELPMENT STANDARD Mar. 23, 2016 Japan Aerospace Exploration Agency The official version of this standard is written in Japanese. This English version is issued for convenience of English speakers.

More information

Requirements Change Management Practices

Requirements Change Management Practices Report on Requirements Change Management Practices Qure Tapani Aaltio Version 1.0 Published on June 28, 2002 Table of Contents 1 Introduction 3 2 Why Requirements Change Management? 3 3 Models of Requirements

More information

TAKING CONTROL with MultiTRANS TM Translation Mangement System

TAKING CONTROL with MultiTRANS TM Translation Mangement System TAKING CONTROL with MultiTRANS TM Translation Mangement System IT IS TIME TO TAKE CONTROL As big data grows even bigger, a power shift is happening in the world of translation management. Thanks to new

More information

A Business Oriented Architecture. Combining BPM and SOA for Competitive Advantage

A Business Oriented Architecture. Combining BPM and SOA for Competitive Advantage Combining BPM and SOA for Competitive Advantage Phil Gilbert Introduction In a recent survey of 1,400 CIOs by Gartner Executive Programs, the top business priority identified by CIOs was business process

More information

The i Competency Dictionary Framework for IT Engineering Education

The i Competency Dictionary Framework for IT Engineering Education The i Competency Dictionary Framework for IT Engineering Education Eiji Hayashiguchi IT Human Resource Development Information-technology Promotion Agency, Japan (IPA) Tokyo, Japan ei-haya@ipa.go.jp Osamu

More information

Organising Requirements

Organising Requirements Requirements Organisation, Analysis and Evolution Software Requirements and Design CITS 4401 Lecture 20 CITS4401 Software Requirements and Design 2 Viewpoints Organising Requirements Interactor viewpoints:

More information

TOGAF Foundation Exam

TOGAF Foundation Exam TOGAF Foundation Exam TOGAF 9 Part 1 (ESL) Time Limit 90 minutes Number of questions 40 Pass-through 22 1. Which of the following best describes the meaning of "Initial Level of Risk" in Risk Management?

More information

making money from customer use of kiosk attracting more customers to the store saving money if the kiosk replaces manual operations

making money from customer use of kiosk attracting more customers to the store saving money if the kiosk replaces manual operations Business Requirements Business requirements collected from multiple sources might conflict. For example, consider a kiosk product with embedded software that will be sold to retail stores and used by the

More information

7. Model based software architecture

7. Model based software architecture UNIT - III Model based software architectures: A Management perspective and technical perspective. Work Flows of the process: Software process workflows, Iteration workflows. Check Points of The process

More information

BABOK v3 Task to Technique Mapping

BABOK v3 Task to Technique Mapping BABOKv3 Task Technique # Technique Name Knowledge Area Business Planning and Monitoring Plan Business Approach 10.18 Document 10.20 Financial Plan Stakeholder Engagement 10.9 Business Rules 10.18 Document

More information

Software Development

Software Development Software Development Requirement Analysis 1 Process Step: Requirements Requirements define the function of the system from the client's viewpoint. The requirements establish the system's functionality,

More information

CSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding Requirements Engineering

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

More information

Requirements Analysis and Design Definition. Chapter Study Group Learning Materials

Requirements 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 information

Chapter 12. Sample Surveys. Copyright 2010 Pearson Education, Inc.

Chapter 12. Sample Surveys. Copyright 2010 Pearson Education, Inc. Chapter 12 Sample Surveys Copyright 2010 Pearson Education, Inc. Background We have learned ways to display, describe, and summarize data, but have been limited to examining the particular batch of data

More information

Operations and Supply Chain Management Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology, Madras

Operations and Supply Chain Management Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology, Madras Operations and Supply Chain Management Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology, Madras Lecture - 24 Sequencing and Scheduling - Assumptions, Objectives and Shop

More information

Using a Validation Model to Measure the Agility of Software Development in a Large Software Development Organization

Using a Validation Model to Measure the Agility of Software Development in a Large Software Development Organization Using a Validation Model to Measure the Agility of Software Development in a Large Software Development Organization Mikio Ikoma 1 Masayuki Ooshima 1 Takahiro Tanida 1 Michiko Oba 1 Sanshiro Sakai 2 1

More information

Lean Thinking Works Everywhere!

Lean Thinking Works Everywhere! Work Force 2006 Jacksonville, Florida January 10, 2006 Lean Thinking Works Everywhere! James P. Womack President, Lean Enterprise Institute The Context of Today s Event You ve looked at the world and discovered

More information

Operations and Supply Chain Management Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology, Madras

Operations and Supply Chain Management Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology, Madras Operations and Supply Chain Management Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology, Madras Lecture - 23 Safety Stock Reduction Delayed Product Differentiation, Substitution

More information

Requirements Engineering

Requirements Engineering Requirements Engineering Minsoo Ryu Hanyang University Topics covered Requirements Engineering Requirements Elicitation Requirements Validation Requirements Management 2 2 Requirement Engineering The goal

More information

Software configuration management

Software configuration management Software configuration management Bởi: Hung Vo Introduction A system can be defined as a collection of components organized to accomplish a specific function or set of functions. The configuration of a

More information

Requirements elicitation: Finding the Voice of the Customer

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

More information

Passit4Sure.OG Questions. TOGAF 9 Combined Part 1 and Part 2

Passit4Sure.OG Questions. TOGAF 9 Combined Part 1 and Part 2 Passit4Sure.OG0-093.221Questions Number: OG0-093 Passing Score: 800 Time Limit: 120 min File Version: 7.1 TOGAF 9 Combined Part 1 and Part 2 One of the great thing about pass4sure is that is saves our

More information

TRANSPORTATION PROBLEM AND VARIANTS

TRANSPORTATION PROBLEM AND VARIANTS TRANSPORTATION PROBLEM AND VARIANTS Introduction to Lecture T: Welcome to the next exercise. I hope you enjoyed the previous exercise. S: Sure I did. It is good to learn new concepts. I am beginning to

More information

Lessons Learned Through Leadership

Lessons Learned Through Leadership Thomas Jefferson University Jefferson Digital Commons Department of Rehabilitation Medicine Faculty Papers Department of Rehabilitation Medicine 7-2014 Lessons Learned Through Leadership John L. Melvin,

More information

Lessons Learned Through Leadership

Lessons Learned Through Leadership Thomas Jefferson University Jefferson Digital Commons Department of Rehabilitation Medicine Faculty Papers Department of Rehabilitation Medicine 7-2014 Lessons Learned Through Leadership John L. Melvin,

More information

REQUIREMENTS DOCUMENTATION

REQUIREMENTS DOCUMENTATION REQUIREMENTS DOCUMENTATION Project Title: Date Prepared: Stakeholder Requirement Category Priority Acceptance Criteria REQUIREMENTS DOCUMENTATION Project Title: Date Prepared: Stakeholder Requirement Category

More information

Avoiding Knowledge Management Pitfalls. Ten Common Mistakes and How to Avoid Them

Avoiding Knowledge Management Pitfalls. Ten Common Mistakes and How to Avoid Them Avoiding Knowledge Management Pitfalls Ten Common Mistakes and How to Avoid Them Table of Contents Introduction... 1 1. Failure to Set and Track Specific Goals... 1 2. Doing Too Much at Once... 2 3. Starting

More information

Business Analysis Essentials

Business Analysis Essentials Understand the business analyst's role and responsibilities in a successful project. In this introductory course, you'll delve into the role and responsibilities of the business analyst (BA)- the communication

More information

Verification of Quality Requirement Method Based on the SQuaRE System Quality Model

Verification of Quality Requirement Method Based on the SQuaRE System Quality Model American Journal of Operations Research, 2013, 3, 70-79 http://dx.doi.org/10.4236/ajor.2013.31006 Published Online January 2013 (http://www.scirp.org/journal/ajor) Verification of Requirement Method Based

More information

Evolutionary Differences Between CMM for Software and the CMMI

Evolutionary Differences Between CMM for Software and the CMMI Evolutionary Differences Between CMM for Software and the CMMI Welcome WelKom Huan Yín Bienvenue Bienvenido Wilkommen????S???S??? Bienvenuto Tervetuloa Välkommen Witamy - 2 Adapting an An Integrated Approach

More information

Lecture 8 Agile Software Development

Lecture 8 Agile Software Development Lecture 8 Agile Software Development Includes slides from the companion website for Sommerville, Software Engineering, 10/e. Pearson Higher Education, 2016. All rights reserved. Used with permission. Topics

More information

Before You Start Modelling

Before You Start Modelling Chapter 2 Before You Start Modelling This chapter looks at the issues you need to consider before starting to model with ARIS. Of particular importance is the need to define your objectives and viewpoint.

More information

Lecture 1. In practice, most large systems are developed using a. A software process model is an abstract representation

Lecture 1. In practice, most large systems are developed using a. A software process model is an abstract representation Chapter 2 Software Processes Lecture 1 Software process descriptions When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing

More information

Chapter 1: Introduction

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

More information

from ocean to cloud PROJECT MANAGEMENT FOR CAPACITY UPGRADE OF SUBMARINE CABLE SYSTEMS

from ocean to cloud PROJECT MANAGEMENT FOR CAPACITY UPGRADE OF SUBMARINE CABLE SYSTEMS PROJECT MANAGEMENT FOR CAPACITY UPGRADE OF SUBMARINE CABLE SYSTEMS Kenichi Yoneyama, Yukihiko Kameyama, Mikio Yoshioka (NEC Corporation) Email: k-yoneyama@bc.jp.nec.com NEC Corporation, 29-23 Shiba 5-chome

More information

The Enterprise Systems Engineering Center Requirements Management Guide - Analysis

The 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 information

CMMI SM Model Measurement and Analysis

CMMI SM Model Measurement and Analysis Carnegie Mellon University Software Engineering Institute CMMI SM Model CMMI SM is a Service Mark of Carnegie Mellon University Carnegie Mellon University Software Engineering Institute CMMI Staged Representation

More information

NEW! 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 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 information

PART THREE: Work Plan and IV&V Methodology (RFP 5.3.3)

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

More information

version NDIA CMMI Conf 3.5 SE Tutorial RE - 1

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

More information

Requirements Organisation, Analysis. Software Requirements & Project Management CITS3220

Requirements Organisation, Analysis. Software Requirements & Project Management CITS3220 Requirements Organisation, Analysis and Negotiation Software Requirements & Project Management CITS3220 Organising Requirements Viewpoints Interactor viewpoints: people or other systems that interact

More information

CHAPTER 2 LITERATURE SURVEY

CHAPTER 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 information

Cost reductions through standardization and automation at company X. Heini Guldmyr

Cost reductions through standardization and automation at company X. Heini Guldmyr Cost reductions through standardization and automation at company X Heini Guldmyr November 2015 Abstract 16.11.2015 Author(s) Heini Guldmyr Degree programme Bachelor of Business Administration Report/thesis

More information

IE 366 Requirements Development

IE 366 Requirements Development IE 366 Requirements Development Developing and Managing Requirements IE 366 Requirements Definition: A requirement describes something that is needed or desired in a system (or product or process) that

More information

Project Scope Management

Project Scope Management Project Scope Management Understand the importance of good project scope management. Discuss methods for collecting and documenting requirements in order to meet stakeholder needs and expectations. Explain

More information

Systems Engineering Concept

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

More information

CHAPTER 2: ITEM RESERVATIONS AND ORDER TRACKING

CHAPTER 2: ITEM RESERVATIONS AND ORDER TRACKING Chapter 2: Item Reservations and Order Tracking CHAPTER 2: ITEM RESERVATIONS AND ORDER TRACKING Objectives Introduction The objectives are: Reserve items on inventory or inbound. Track from demand to matching

More information

Analysis & Recommendations for the Management of COTS - Computer Off The Shelf - Software Projects

Analysis & Recommendations for the Management of COTS - Computer Off The Shelf - Software Projects Proceedings of the 11th WSEAS International Conference on COMPUTERS, Agios Nikolaos, Crete Island, Greece, July 26-28, 2007 531 Analysis & Recommendations for the Management of COTS - Computer Off The

More information

Applying PSM to Enterprise Measurement

Applying PSM to Enterprise Measurement Applying PSM to Enterprise Measurement Technical Report Prepared for U.S. Army TACOM by David Card and Robert MacIver Software Productivity Consortium March 2003 SOFTWARE PRODUCTIVITY CONSORTIUM Applying

More information

A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0 Skillport

A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0 Skillport A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0 by The International Institute of Business Analysis (IIBA) International Institute of Business Analysis. (c) 2009. Copying

More information

Session 2: A Phased Life Cycle for a modern system development project. COMP 377/477 Spring 2016 Conrad Weisert

Session 2: A Phased Life Cycle for a modern system development project. COMP 377/477 Spring 2016 Conrad Weisert Session 2: A Phased Life Cycle for a modern system development project COMP 377/477 Spring 2016 Conrad Weisert COMP 377 / 477 1 Spring, 2016 Concepts and Terminology We already know what these are: Project

More information

Eliciting and Elaborating Requirements with Developers in Mind. TODAY S MOTTO: If you wanted it yesterday, why didn t you wait until tomorrow to ask?

Eliciting and Elaborating Requirements with Developers in Mind. TODAY S MOTTO: If you wanted it yesterday, why didn t you wait until tomorrow to ask? Eliciting and Elaborating Requirements with Developers in Mind TODAY S MOTTO: If you wanted it yesterday, why didn t you wait until tomorrow to ask? in advance Thank you for your participation! David De

More information

Requirements for an MDM Solution

Requirements for an MDM Solution Requirements for an MDM Solution A proven approach for how to gather, document, and manage requirements for a Master Data Management solution from Inception through Implementation by Vicki McCracken Copyright

More information

Software Requirements. CSCE Lecture 4-08/30/2016

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

More information

8/30/2010. Lecture 1. Topics covered. Functional and non-functional requirements The software requirements document Requirements specification

8/30/2010. Lecture 1. Topics covered. Functional and non-functional requirements The software requirements document Requirements specification Topics covered Functional and non-functional requirements The software requirements document Chapter 4 Requirements Engineering Requirements specification Requirements engineering processes Lecture 1 Requirements

More information

Software Processes 1

Software Processes 1 Software Processes 1 Topics covered Software process models Process activities Coping with change 2 The software process A structured set of activities required to develop a software system. Many different

More information

REQUIREMENTS ENGINEERING

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

More information

NCOVER. ROI Analysis for. Using NCover. NCover P.O. Box 9298 Greenville, SC T F

NCOVER. ROI Analysis for. Using NCover. NCover P.O. Box 9298 Greenville, SC T F NCOVER ROI Analysis for Test Coverage Using NCover NCover P.O. Box 9298 Greenville, SC 29601 T 864.990.3717 F 864.341.8312 conversation@ncover.com www.ncover.com Table of Contents Executive Summary 2 Cost

More information

Implementing an Automated Testing Program

Implementing an Automated Testing Program Implementing an Automated Testing Program An Innosphere Ritepaper INNOSPHERE SYSTEMS DEVELOPMENT GROUP LTD. 147 WYNDHAM ST. NORTH, SUITE 306 GUELPH, ONTARIO, CANADA, N1H 4E9 TEL: 519.766.9726 WWW.INNOSPHERE.CA

More information

FOUNDATIONAL CONCEPTS FOR MODEL DRIVEN SYSTEM DESIGN

FOUNDATIONAL CONCEPTS FOR MODEL DRIVEN SYSTEM DESIGN FOUNDATIONAL CONCEPTS FOR MODEL DRIVEN SYSTEM DESIGN Loyd Baker, Paul Clemente, Bob Cohen, Larry Permenter, Byron Purves, and Pete Salmon INCOSE Model Driven System Interest Group Abstract. This paper

More information

Framework for Measuring the Quality of Software Specification

Framework for Measuring the Quality of Software Specification Framework for Measuring the Quality of Software Specification E.Stephen, E.Mit Faculty of Computer Science and Information Technology, Universiti Malaysia Sarawak (UNIMAS), 94300 Kota Samarahan, Sarawak.

More information

Requirements Engineering. Massimo Felici Room 1402, JCMB, KB

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

More information

PROJECT SCOPE MANAGEMENT. 1 Powered by POeT Solvers Limited

PROJECT SCOPE MANAGEMENT. 1   Powered by POeT Solvers Limited PROJECT SCOPE MANAGEMENT 1 www.pmtutor.org Powered by POeT Solvers Limited At the end of this training, our goal is for you to: Be able to define the term scope Be able to identify primary sources who

More information

CMMI for Acquisition Quick Reference

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

More information

This chapter illustrates the evolutionary differences between

This chapter illustrates the evolutionary differences between CHAPTER 6 Contents An integrated approach Two representations CMMI process area contents Process area upgrades and additions Project management concepts process areas Project Monitoring and Control Engineering

More information

CMMI-DEV v1.3 Good? Bad? Ugly?

CMMI-DEV v1.3 Good? Bad? Ugly? 1 U.S. Army Research, Development and Engineering Command CMMI-DEV v1.3 Good? Bad? Ugly? Jackie Lawrence Certified High Maturity SCAMPI Lead Appraiser Nathaniel Becker US Army Armament SEC Process Lead

More information

Requirements Basics. CSCE Lecture 4-09/02/2015

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

More information

It Is Still The Requirements Getting Software Requirements Right By James Ward

It Is Still The Requirements Getting Software Requirements Right By James Ward A StickyMinds.com Original It Is Still The Requirements Getting Software Requirements Right By James Ward Summary: Why are information systems requirements so difficult to define? What causes the yawning

More information

Software Requirements and Organizational Culture: 10 Lessons Learned

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

More information

Ten steps to effective requirements management

Ten steps to effective requirements management IBM Software Requirements definition and management July 2013 Ten steps to effective requirements management 2 Ten steps to effective requirements management Introduction Requirements definition and management

More information

BA_Leverage_Model V1.1.xlsx _ Introduction

BA_Leverage_Model V1.1.xlsx _ Introduction BA_Leverage_Model V1.1.xlsx _ Introduction This document supports the CI Leverage system in so far that it provides guidance to the practitioneers of business analysis in which field they mastered which

More information

Analyzing Software Architectures for Modifiability

Analyzing Software Architectures for Modifiability Analyzing Software Architectures for Modifiability PerOlof Bengtsson *, Nico Lassing **, Jan Bosch * and Hans van Vliet ** * Department of Software Engineering and Computer Science University of Karlskrona/Ronneby

More information

Achieving Business Analysis Excellence

Achieving Business Analysis Excellence RG Perspective Achieving Business Analysis Excellence Turning Business Analysts into Key Contributors by Building a Center of Excellence 11 Canal Center Plaza Alexandria, VA 22314 HQ 703-548-7006 Fax 703-684-5189

More information

Marketing Research to Support the Stage Gate New Product Development Process

Marketing Research to Support the Stage Gate New Product Development Process Marketing Research to Support the Stage Gate New Product Development Process Agile. Iterative. Informed. Fast. These are hallmarks of today s effective new product development, with the goal of establishing

More information

Standardized Traceability Ratings for Manufacturing

Standardized Traceability Ratings for Manufacturing Standardized Traceability Ratings for Manufacturing Robert Miklosey Aegis Software Horsham, PA Abstract Traceability and process control are no longer requirements reserved for manufacturers in regulatory

More information

How Real-time Dynamic Scheduling Can Change the Game:

How Real-time Dynamic Scheduling Can Change the Game: Iyno Advisors How Real-time Dynamic Scheduling Can Change the Game: New Software Approach to Achieving Stable Success in High-Change High-Mix Discrete Manufacturing By Julie Fraser Principal, Iyno Advisors

More information

Software Engineering Fall 2014

Software 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 information

Rational Software White Paper TP 174

Rational Software White Paper TP 174 Reaching CMM Levels 2 and 3 with the Rational Unified Process Rational Software White Paper TP 174 Table of Contents Abstract... 1 Introduction... 1 Level 2, Repeatable... 2 Requirements Management...

More information

Engineering. CMMI for Development V.1.2 Module 3. M03/Engineering/v1.2

Engineering. CMMI for Development V.1.2 Module 3. M03/Engineering/v1.2 Engineering CMMI for Development V.1.2 Module 3 M03/Engineering/v1.2 Agenda Global scope RD Development REQM Management TS Technical Solution PI Product Integration VER Verification VAL Validation SE Process

More information

Upgrade & patch Infor M3 with 100% confidence. A guide to successful delivery

Upgrade & patch Infor M3 with 100% confidence. A guide to successful delivery Upgrade & patch Infor M3 with 100% confidence A guide to successful delivery I The path to Release 13.4, including patches, is perhaps the most complex and time-consuming programme of upgrades within the

More information

Why Projects Fail and What Executives Can Do About It. The Truth About Requirements Definition and Management

Why Projects Fail and What Executives Can Do About It. The Truth About Requirements Definition and Management Why Projects Fail and What Executives Can Do About It The Truth About Requirements Definition and Management White Paper May 2008 Contents Executive summary.................................................................3

More information

ISSN: ISO 9001:2008 Certified International Journal of Engineering and Innovative Technology (IJEIT) Volume 7, Issue 6, December 2017

ISSN: ISO 9001:2008 Certified International Journal of Engineering and Innovative Technology (IJEIT) Volume 7, Issue 6, December 2017 International Journal of Engineering and Innovative Technology (IJEIT Toward Scheduling for Railway Systems Based on Max-Plus Linear Systems Extension of state equation for actual operation Yumiko Kusunoki

More information

5th World Congress for Software Quality Shanghai, China November Establishment and Optimization Methodologies for

5th World Congress for Software Quality Shanghai, China November Establishment and Optimization Methodologies for Establishment and Optimization Methodologies for (Quality Management Organization Based on CMMI ) Yukiho Isozaki Fujitsu Limited Tokyo, Japan isozaki@jp.fujitsu.com Abstract is a core organization and

More information

Requirements Engineering and Software Architecture Project Description

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

More information

StarGro: Building i* Metrics for Agile Methodologies

StarGro: Building i* Metrics for Agile Methodologies StarGro: Building i* Metrics for Agile Methodologies Colomer, Daniel 1 and Franch, Xavier 2 1 Collins GmbH, Hamburg, Germany dncolomer32@gmail.com 2 Universitat Politècnica de Catalunya (UPC) c/jordi Girona,

More information

CMMI-DEV V1.3 CMMI for Development Version 1.3 Quick Reference Guide

CMMI-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 information

a Recruitment Software Provider that fits

a Recruitment Software Provider that fits 5 Steps to Help You Win Over Key Stakeholders and Invest in a Talent Acquisition Software Suite That You Will Love. a Research ebook by: HIRING INSIGHTS WHY INVEST IN TALENT ACQUISITION? B2C technology

More information

Kanban kick- start (v2)

Kanban kick- start (v2) Kanban kick- start (v2) By Tomas Björkholm at Crisp, October 2011 INTRODUCTION... 1 AN APPROACH TO GET STARTED WITH KANBAN... 2 STEP 1 GET TO KNOW YOUR SYSTEM... 2 STEP 2 IDENTIFY YOUR SOURCES AND PRIORITIZE...

More information

Using Pilots to Assess the Value and Approach of CMMI Implementation

Using Pilots to Assess the Value and Approach of CMMI Implementation Using Pilots to Assess the Value and Approach of CMMI Implementation Godfrey, S., Andary, J., Rosenberg, L. NASA Goddard Space Flight Center, Greenbelt, Maryland, USA, 20771 Sara.H.Godfrey.1@gsfc.nasa.gov

More information

Fundamentals of Project Management, 2 nd June 2018

Fundamentals of Project Management, 2 nd June 2018 Fundamentals of Project Management, 2 nd June 2018 About our company Benefits of attending our Saturday courses Revolutionary way of learning! Eat the elephant we simplify the Project Management Body of

More information

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) 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

More information

OVERVIEW OF NISSAN S TARGET COSTING SYSTEM

OVERVIEW OF NISSAN S TARGET COSTING SYSTEM INTRODUCTION Nissan Motor Company, Ltd., founded in 1933, was considered as the most highly globalized of the Japanese automobile companies and the world s fourthlargest automobile manufacturer. It implemented

More information

Extending an Agile Method to Support Requirements Management and Development in Conformance to CMMI

Extending an Agile Method to Support Requirements Management and Development in Conformance to CMMI Extending an Agile Method to Support Requirements Management and Development in Conformance to CMMI Alexandre Lazaretti Zanatta 1, Patrícia Vilain 2 1 Instituto de Ciências Exatas e Geociências - Ciência

More information

IN COMPLEX PROCESS APPLICATION DEVELOPMENT

IN COMPLEX PROCESS APPLICATION DEVELOPMENT BUSINESS-IT ALIGNMENT IN COMPLEX PROCESS APPLICATION DEVELOPMENT TABLE OF CONTENTS 1 Introduction 2 Model-driven development in BPMS: myth and reality 3 From disparate to aligned models 4 Model traceability

More information