Non-Functional Requirements for COTS Software Components

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Non-Functional Requirements for COTS Software Components"

Transcription

1 Non-Functional Requirements for COTS Software Components Ljerka Beus-Dukic School of Computing and Mathematics University of Northumbria at Newcastle Ellison Building, Newcastle upon Tyne NE1 8ST, United Kingdom ABSTRACT Commercially available software components come with the built-in functionality often offering end-user more than they need. A fact that end-user has no or very little influence on component s functionality promoted nonfunctional requirements which are getting more attention than ever before. In this paper, we identify some of the problems encountered when non-functional requirements for COTS software components need to be defined. Keywords Requirements engineering, non-functional requirements, COTS software component 1 POSITION Non-functional requirements have been neglected by the requirements engineering practice and research for a long time. However, an increasing trend to build software systems from commercial off-the-shelf (COTS) software components has highlighted the need to take non-functional requirements more seriously. Since end-user has no influence on the functionality provided by COTS software component there is little use in providing detailed functional requirements. It is more important to identify the constraints that a component must meet and the overall quality of the component. Both theory and practice of requirements engineering do not provide adequate support for non-functional requirements. This is also true for methods which are developed for purpose built software. As methods for ready-made software have just begin to emerge (OTSO [7], PORE [9]) it is early to judge them on the basis of support for non-functional requirements. We developed interest in the problem after completing the assessment of real-time operating systems for end-users from different application domains [11]. In this paper, we identify some of the problems encountered when defining non-functional requirements for a COTS software component, and matching these requirements with available component descriptions. The paper presents end-users (or component integrators ) perspective rather than of organisations which are developing COTS software components (vendors). Observations presented are based on our experience with COTS software assessment for the GUARDS project [1] and a recent survey conducted in space industry [2]. COTS Software Component Commercial off-the-shelf software component is developed by a commercial vendor for commercial purposes and is sold as is. Note that there is no universally accepted definition of a software component. Brown and Wallnau [3] talk about two types of off-the-shelf components: 1) components developed in-house (perhaps for some other project), and 2) packages purchased from external sources (e.g., database management systems and network monitors). They also state that software components have significant aggregate functionality and complexity. Scyperski [12] gives precise definition of a software component stating that software components are binary units of independent production, acquisition, and deployment that interact to form a functioning system. Here, we are concerned with COTS software components of coarse granularity, often termed software packages (e.g., operating systems, database servers) which are selfcontained and integrated with other components in a complex software system. Non-functional Requirements Non-functional requirements define the general qualities of the software product. They are usually associated with the product descriptions of type ility such as maintainability, usability, portability etc. Non-functional software requirements are notorious for being difficult to elicit, express, quantify and test. It is also known, that there are

2 many communication obstacles between requirements engineers and end-users. While software engineers are usually accused of lacking expertise in end-user domain, end-users are often criticised for being vague and ambiguous. Other issues include representation of the requirements, their prioritisation, level of detail, and relation to functional requirements. This situation is usually found when requirements are elicited from end-user for a bespoke software product being developed in-house for the same end-user. In a different situation, when requirements need to be elicited from end-user for a commercially available software component (developed by a third party for an unknown end-user), issues become more complex. The main reason for this is the introduction of a third party i.e. vendor of a software component. One could say that dealing with different vendors is not a new practice for software engineers. What is different at present, is the volume of the market of software components and the speed with which different components (or their new versions) emerge. With the introduction of the Internet market for software components, the reality of having to weed through a significant number of similar components on offer (e.g., 100 hundred real-time operating systems) will soon become a nightmare. Even if we ignore a problem of obtaining non-functional requirements from the end-user, we are still left with a number of problems to solve. How to select a component on a basis of non-functional requirements? Which component attributes we should be looking for? Can we trust vendor claims about component (e.g., performance)? Should vendors be made to describe component characteristics in a uniform way so that a valid and meaningful comparison can be performed? Why they are important for COTS software? The role of non-functional (or qualitative) requirements becomes more important because ready-made COTS software components have their functionality already builtin. As component s functionality is specified with the view of a generic customer, component s capabilities are likely to exceed the ones needed for a specific end-user. Functional requirements need to be specified too, but only to a level which enables efficient survey and evaluation of the available COTS components on the market. Once a particular subset of components is identified (in our case operating systems appropriate for use in real-time systems) non-functional requirements are called in. External constraints on a component can help to eliminate a good proportion of component candidates (e.g., POSIX standard compliance was effective discriminator for real-time operating systems). Non-functional requirements often correspond to strategic or business objectives of end-user organisation as a whole, and, therefore, are likely to have higher priority if conflicting with some of the functional requirements for the software component. It is no coincidence that non-functional requirements frequently come from managers who are ultimately responsible for taking a decision to purchase a COTS component. What are they? In a traditional divide between functional and nonfunctional requirements the later always had a back seat. This is still reflected in the way components are being described by their vendors. Non-functional characteristics are not easy to describe and quantify even for the purpose built software and a known end-user. With a generic product and an imaginary customer the task does not become easier. COTS components bring a number of additional non-functional requirements. These include architecture, domain and organisational requirements. Architecture requirements Acquired software components need to be integrated with other components into a system and together provide required functionality. As COTS components are already built, an issue of their integration has to be considered much earlier then with a purpose built software i.e. before their assessment. Component system architecture provides a proper structure for components to be plugged in. It consists of a set of platforms, component frameworks, and an interoperation (communication and interface) design for the component frameworks. The architecture needs to provide for both independence and cooperation of components [12]. Independence is required to enable components to be easily replaced by components from other sources. Non-functional requirements often associated with component independence include flexibility, portability, evolvability, scalability, genericity, reusability and integrity. Cooperation between components is essential in any architecture (composability, interoperability). Additional, often neglected, nonfunctional requirements on component architecture are performance, reliability and security. Domain Requirements COTS software components are often developed with no readily identifiable end-user and by developers who have no experience in any specific application domain and have no direct contact with the customer. Consequently, enduser is left alone with a difficult task to assess a specific component on the basis of domain-specific requirements. Some of these requirements (e.g., for specific type of hardware, timing and performance constraints, security) can be found in product descriptions. However, majority is not readily offered by vendors and have to be specifically requested (e.g., compliance to a domain standard), researched (e.g., popularity of a component in a specific domain), or tested (e.g., interoperability with other COTS 2

3 and legacy components). In an ideal world it will be useful if end-users could compare the context in which a component was designed for, and the context in which is to be used. Unfortunately, contextual assumptions made by component designers are rarely made available to endusers. Similarly, end-users have no information about the development process used to produce and maintain a component. Hence, a requirement that a component is successfully used in organisations from the same application domain becomes more and more common amongst end-users. Apart of providing some guarantees of component reliability in a similar context of deployment, this requirement gives end-user opportunity to share knowledge of other component users about the component. When there are problems with component use and maintenance, user group from a specific application domain can have more influence on component vendor than a single user. Often a fact that a component has not been used in a particular domain signals a lack of certain component properties (e.g., component is not compliant to a specific domain standard). Organisational requirements Non-functional requirements for a COTS software component need to include constraints relevant to two types of organisations concerned: a vendor (component producer) and an end-user (component consumer). Here, we are interested in end-user s point of view; therefore both types of organisational requirements originate from component consumer. Before embarking on acquisition of a COTS software component end-user has to have a clear picture of the constraints of its own organisation such as: Current hardware platform characteristics Existing software development environment Staff expertise and culture (current knowledge and skills, need for extra training) Type of legacy applications Timescale for component integration Long-term strategy for software development Business and political factors (cost-benefit, partnership with a vendor) The non-functional requirements imposed on COTS component by end-user organisation are not easy to elicit and quantify. They can not be described with the familiar ilities. Nevertheless, their importance for component selection should not be underestimated. On the other hand requirements placed by the end-user on a component vendor are more typical of any product on the market. They are much easier to describe and quantify. These include: Vendor s credentials and stability on the market Component conformance to standards (interface, framework, domain) Stability of a particular component (frequency and type of updates) Component upgrade policy (e.g., based on new features and/or bug fixes) References for component use (customer base) Long-term component support strategy User support record Vendor's software development practice (e.g., ISO 9000) Vendor s popularity in a particular application domain Vendors vested interest in a particular domain (if sufficient it provides a scope for introducing component features relevant to that domain) Contract practice (guarantees given, and obligations vendor is prepared to take on) Most of the non-functional requirements for a component vendor are related to component s maintainability. As endusers have little or no influence over the maintenance and evolution of the components it is reasonable to question vendor s record. 2 BACKGROUND Non-functional requirements for COTS software components do not always fit their existing definitions. They are usually defined as the restrictions on the software product. However, when these restrictions include the product development process [8] the distinction between bespoke products and COTS components has to be drawn. COTS software components are by definition black boxes which means that we have no knowledge or influence on component development process. Both functional and non-functional requirements for COTS software components have received little attention by researchers. However, there are few exceptions. Finkelstain [5] makes a distinction between core and peripheral requirements and points out that peripheral requirements help to distinguish between software packages. He wants to see software package requirements and procurement placed within mainstream of specification research. Requirements for COTS software packages are part of the two ongoing research projects at London s City University: ACRE (Acquisition of Requirements) is providing a framework for selection and use of diverse requirements acquisition techniques, and PORE is a method for Procurement-Oriented Requirements Engineering [9]. Off- The-Shelf Option (OTSO) method [7], developed for reusable component selection process, takes into account application specific and functional requirements, design and architecture constraints. Although it recognises the role of organisational characteristics (e.g., current practices, existing infrastructure in end-user organisation) OTSO method does not address vendor s characteristics and standard compliance. Franch [6] classifies approaches to non-functionality as process-oriented and product-oriented 3

4 and proposes a notation NoFun to define hierarchies of non-functional attributes at the component level. There is also evidence of some research on requirements engineering from a perspective of software developers who build off-the-shelf software i.e. vendors [4] [10]. It seems that restrictions imposed on component from the vendor s angle differ from the ones perceived by end-users. 3 RESEARCH Requirements engineering for COTS components clearly need a different approach. Many concepts which were valid for bespoke software are not valid any more and different activities have different priorities. Since end-users are not in a position to specify functional requirements or to control the process of component development, there is no need for detailed functional requirements. As we move the focus from functional to non-functional requirements a number of topics comes into light: Which attributes of a component are critical to its use in a particular architecture/framework? What are the requirements for the architecture/framework which are best suited for the particular component? How to describe, measure and quantify component s ilities? How to verify vendor s claims for standard compliance? How to prioritise non-functional requirements? Components are described using different vocabulary how to make comparisons between different components? How to characterise a component in a uniform way? These questions are only some of the questions that need to be answered by requirements engineering research and practice. REFERENCES 1. Beus-Dukic, L., and A. Wellings, The Requirements for a COTS Software Component: A Case Study, Requirements Engineering 3, 2, 1998, Springer- Verlag, Beus-Dukic, L, Criteria for Selection of a COTS Real- Time Operating System: a Survey, 2000, (submitted for publication). 3. Brown, A. W. (Ed), Component-Based Software Engineering, IEEE Computer Society Press, Finkelstein, A., Spanoudakis, G., and M. Ryan, Software Package Requirements & Procurement, 8th Int. Workshop on Software Specification & Design, IEEE CS Press, Franch, X, Systematic Formulation of Non-Functional Characteristics of Software, Proc. 3rd Int. Conf. on Requirements Engineering, (Colorado Springs, Colorado, USA, Apr 1998). 7. Kontio, J., Caldiera G., and V. R. Basili, Defining Factors, Goals and Criteria for Reusable Component Evaluation, Proc. of the CASCON'96 Conference, (Toronto, Canada, Nov 1996). 8. Kotonya, G., and I. Sommerville, Requirements Engineering: Processes and Techniques, John Wiley&Sons, Maiden, N. A.M., Ncube C., and A. Moore, Lessons Learned During Requirements Acquisition for COTS Systems, Communications of the ACM 40, 12 (Dec 1997). 10. Potts, C., Invented Requirements and Imagined Customers: Requirements Engineering for Off-the- Shelf Software, Proc. 2nd IEEE Int. Symposium on Requirements Engineering (York, UK, March ). 11. Powell, D., Arlat J., Beus-Dukic L., Bondavalli A., Coppola P., Fantechi A., Jenn E., Rabejac C. and A. Wellings, GUARDS: A Generic Upgradable Architecture for Real-Time Dependable Systems, IEEE Trans. on Parallel and Distributed Systems 10, 6, (June 1999), Scyperski, C., Component Software Beyond Object- Oriented Programming, ISBN , Addison- Wesley, Sinclair, I. J.. The Use of Commercial Off-the-Shelf (COTS) Software in Safety-Related Applications. HSE Contract Research Report 80/ Vidger, M. R., Gentleman, W. M., and J. Dean, COTS Software Integration: State-of-the-art, Technical Report, National Research Council Canada, Jan Deifel, B., Requirements Engineering for Complex COTS, 4th Int. Workshop on Requirements Engineering for Software Quality (REFSQ'98) (Pisa, Italy, 8-9 Jun 1998). 4

5

THE REQUIREMENTS FOR A COTS SOFTWARE COMPONENT: A CASE STUDY

THE REQUIREMENTS FOR A COTS SOFTWARE COMPONENT: A CASE STUDY THE REQUIREMENTS FOR A COTS SOFTWARE COMPONENT: A CASE STUDY Ljerka Beus-Dukic, Andy Wellings Department of Computer Science, University of York, York, YO10 5DD, United Kingdom E-mail: {ljerka,andy}@cs.york.ac.uk

More information

An Empirical Study of COTS components Persuasion, Evaluation & Selection and Integration in software houses Faisalabad, Pakistan

An Empirical Study of COTS components Persuasion, Evaluation & Selection and Integration in software houses Faisalabad, Pakistan www.ijcsi.org 165 An Empirical Study of COTS components Persuasion, Evaluation & Selection and Integration in software houses Faisalabad, Pakistan Zahid Javed 1, Ahsan Raza Sattar 2, Salman Afsar 3, Muhammad

More information

A case study of software procurement strategies in Sudanese organizations Key words Abstract INTRODUCTION

A case study of software procurement strategies in Sudanese organizations Key words Abstract INTRODUCTION A case study of software procurement strategies in Sudanese organizations Mohamed Abbas, Hisham Abu Shama and Gada Kadoda*** Department of Computer Science, University of Khartoum, P.O. Box 321, Khartoum,

More information

An Overview of Challenges of Component Based Software Engineering

An Overview of Challenges of Component Based Software Engineering An Overview of Challenges of Component Based Software Engineering Shabeeh Ahmad Siddiqui Sr Lecturer, Al-Ahgaff University, Yemen Abstract Nowadays there is trend of using components in development of

More information

A Wish List for Requirements Engineering for COTSbased Information Systems

A Wish List for Requirements Engineering for COTSbased Information Systems A Wish List for Requirements Engineering for COTSbased Information Systems Vito Perrone HOC - Hypermedia Open Center Department of Electronics and Information, Politecnico di Milano Via Ponzio 34/5 20133

More information

Process Technology Implications of Procurement Processes: Some Initial Observations

Process Technology Implications of Procurement Processes: Some Initial Observations Process Technology Implications of Procurement Processes: Some Initial Observations Ernst Ellmer, Wolfgang Emmerich and Anthony Finkelstein Dept. of Computer Science, University College London Gower Street,

More information

Organizational Requirements Engineering

Organizational Requirements Engineering Chapter 9, Non-functional Requirements Organizational Requirements Engineering Prof. Dr. Armin B. Cremers Sascha Alda Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 1 Overview of

More information

Usability metrics for software components

Usability metrics for software components Usability metrics for software components Manuel F. Bertoa and Antonio Vallecillo Dpto. Lenguajes y Ciencias de la Computación. Universidad de Málaga. {bertoa,av}@lcc.uma.es Abstract. The need to select

More information

Socio-Technical Systems

Socio-Technical Systems Software Engineering Socio-Technical Systems Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain what a socio-technical system is and the distinction between this and a

More information

Software Engineering. Introduction. Software Costs. Software is Expensive [Boehm] ... Columbus set sail for India. He ended up in the Bahamas...

Software Engineering. Introduction. Software Costs. Software is Expensive [Boehm] ... Columbus set sail for India. He ended up in the Bahamas... Software Engineering Introduction... Columbus set sail for India. He ended up in the Bahamas... The economies of ALL developed nations are dependent on software More and more systems are software controlled

More information

Requirements Engineering Processes. Feasibility studies. Elicitation and analysis. Problems of requirements analysis

Requirements Engineering Processes. Feasibility studies. Elicitation and analysis. Problems of requirements analysis Requirements engineering processes Requirements Engineering Processes The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the.

More information

Experiences with certification of reusable components in the GSN project in Ericsson, Norway

Experiences with certification of reusable components in the GSN project in Ericsson, Norway Experiences with certification of reusable components in the GSN project in Ericsson, Norway Parastoo Mohagheghi (Ph.D. Student, NTNU) Reidar Conradi Ericsson AS, Grimstad, Dept. Computer and Information

More information

Appendix B Data Quality Dimensions

Appendix B Data Quality Dimensions Appendix B Data Quality Dimensions Purpose Dimensions of data quality are fundamental to understanding how to improve data. This appendix summarizes, in chronological order of publication, three foundational

More information

Software Requirements

Software Requirements Software Engineering Software Requirements Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce the concepts of user and system requirements To describe functional and

More information

A Model for Component Based E-governance Software Systems

A Model for Component Based E-governance Software Systems A Model for Component Based E-governance Software Systems A.SHRABAN KUMAR 1, G.JAYARAO 2,B.SHANKAR NAYAK 3, KBKS. DURGA 4 A.ESWARA RAO 5 1,2,3,4 Associate Professor CSE, St.MARTIN S ENGINEERING COLLEGE,

More information

Agent-Based Commercial Off-The-Shelf Software Components Evaluation Method

Agent-Based Commercial Off-The-Shelf Software Components Evaluation Method Proceedings of ATS 2003 133 Agent-Based Commercial Off-The-Shelf Software Components Evaluation Method Tom Wanyama, Behrouz Homayoun Far Department of Electrical and Computer Engineering University of

More information

Characteristics of Computational Intelligence (Quantitative Approach)

Characteristics of Computational Intelligence (Quantitative Approach) Characteristics of Computational Intelligence (Quantitative Approach) Shiva Vafadar, Ahmad Abdollahzadeh Barfourosh Intelligent Systems Lab Computer Engineering and Information Faculty Amirkabir University

More information

Design with Reuse. Building software from reusable components. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 1

Design with Reuse. Building software from reusable components. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 1 Design with Reuse Building software from reusable components. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 1 Objectives To explain the benefits of software reuse and some reuse

More information

Software Engineering. Software Engineering. Component-Based. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. Software Engineering. Component-Based. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering Component-Based Software Engineering Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain that CBSE is concerned with developing standardised components

More information

Software Engineering UNIT -1 OVERVIEW

Software Engineering UNIT -1 OVERVIEW UNIT -1 OVERVIEW The economies of ALL developed nations are dependent on software. More and more systems are software controlled. Software engineering is concerned with theories, methods and tools for

More information

Software Components and COTS in Software System Development

Software Components and COTS in Software System Development Chapter 15 59 Software Components and COTS in Software System Development Joakim Fröberg Department of Computer Science Mälardalen University Västerås, Sweden joakim.froberg@mdh.se Abstract: The component-based

More information

Requirements Engineering: A Roadmap

Requirements Engineering: A Roadmap Requirements Engineering: A Roadmap Bashar Nuseibeh & Steve Easterbrook Department of Computing Imperial College of Science, Technology & Medicine London SW7 2BZ, UK Email: ban@doc.ic.ac.uk http://www-dse.doc.ic.ac.uk/~ban/

More information

Systems Engineering. Designing, implementing, deploying and operating systems which include hardware, software and people

Systems Engineering. Designing, implementing, deploying and operating systems which include hardware, software and people Systems Engineering Designing, implementing, deploying and operating systems which include hardware, software and people Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 1 Objectives

More information

ehealth Architecture Principles

ehealth Architecture Principles ehealth Architecture Principles Version 3.0 June 2009 Document Control Details Title: ehealth Architecture Principles Owner: Head of Architecture and Design, Scottish Government ehealth Directorate Version:

More information

On Non-Functional Requirements

On Non-Functional Requirements On Non-Functional Requirements Martin Glinz Department of Informatics, University of Zurich, Switzerland glinz@ifi.uzh.ch Abstract Although the term non-functional has been in use for more than 20 years,

More information

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. CS 389 Software Engineering Lecture 2 Chapter 2 Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. Topics covered Software process models Process activities Coping

More information

Aerospace Software Engineering

Aerospace Software Engineering 16.35 Aerospace Software Engineering Software Architecture The 4+1 view Patterns Prof. Kristina Lundqvist Dept. of Aero/Astro, MIT Why Care About Software Architecture? An architecture provides a vehicle

More information

Component-based Development Process and Component Lifecycle Ivica Crnkovic 1, Stig Larsson 2, Michel Chaudron 3

Component-based Development Process and Component Lifecycle Ivica Crnkovic 1, Stig Larsson 2, Michel Chaudron 3 Component-based Development Process and Component Lifecycle Ivica Crnkovic 1, Stig Larsson 2, Michel Chaudron 3 1 Mälardalen University, Västerås, Sweden, ivica.crnkovic@mdh.se 2 ABB Corporate Research,

More information

Theme 8: Commercial off-the-shelf software components evaluation method using multiagent technology

Theme 8: Commercial off-the-shelf software components evaluation method using multiagent technology Theme 8: Commercial off-the-shelf software components evaluation method using multiagent technology Abstract In the last decade, the world of software development has evolved rapidly. This evolution has

More information

1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java. The Nature of Software...

1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java. The Nature of Software... 1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering Software is intangible Hard to understand

More information

Software Requirements. Descriptions and specifications of a system. Ian Sommerville 2000 Software Engineering, 6th edition.

Software Requirements. Descriptions and specifications of a system. Ian Sommerville 2000 Software Engineering, 6th edition. Software Requirements Descriptions and specifications of a system Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Objectives To introduce the concepts of user and system To describe

More information

DEVELOPMENT OF CONSTRUCTION BEST PRACTICE EXPERT SYSTEM

DEVELOPMENT OF CONSTRUCTION BEST PRACTICE EXPERT SYSTEM DEVELOPMENT OF CONSTRUCTION BEST PRACTICE EXPERT SYSTEM Joanna Poon, Keith Potts and Patricia Cooper School of Engineering and the Built Environment University of Wolverhampton Wolverhampton WV1 1SB UK

More information

Market-Driven Requirements Engineering Processes for Software Products - a Report on Current Practices

Market-Driven Requirements Engineering Processes for Software Products - a Report on Current Practices Market-Driven Requirements Engineering Processes for Software Products - a Report on Current Practices Åsa G. Dahlstedt 1, Lena Karlsson 2, Anne Persson 1, Johan Natt och Dag 2 and Björn Regnell 2 1 Department

More information

Engineering Process Software Qualities Software Architectural Design

Engineering Process Software Qualities Software Architectural Design Engineering Process We need to understand the steps that take us from an idea to a product. What do we do? In what order do we do it? How do we know when we re finished each step? Production process Typical

More information

SOFTWARE QUALITY MODELS: A COMPARATIVE STUDY

SOFTWARE QUALITY MODELS: A COMPARATIVE STUDY SOFTWARE QUALITY MODELS: A COMPARATIVE STUDY Mrs. Manisha L. Waghmode Assistant Professor Bharati Vidyapeeth Deemed University, Institute of Management and Rural Development Administration, Sangli Dr.

More information

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. February 2013 1 Executive Summary Adnet is pleased to provide this white paper, describing our approach to performing

More information

Traceability Patterns: An Approach to Requirement-Component Traceability in Agile Software Development

Traceability Patterns: An Approach to Requirement-Component Traceability in Agile Software Development Traceability Patterns: An Approach to Requirement-Component Traceability in Agile Software Development ARBI GHAZARIAN University of Toronto Department of Computer Science 10 King s College Road, Toronto,

More information

AN EMPIRICAL REVIEW ON FACTORS AFFECTING REUSABILITY OF PROGRAMS IN SOFTWARE ENGINEERING

AN EMPIRICAL REVIEW ON FACTORS AFFECTING REUSABILITY OF PROGRAMS IN SOFTWARE ENGINEERING AN EMPIRICAL REVIEW ON FACTORS AFFECTING REUSABILITY OF PROGRAMS IN SOFTWARE ENGINEERING Neha Sadana, Surender Dhaiya, Manjot Singh Ahuja Computer Science and Engineering Department Shivalik Institute

More information

Open Source Software in the Defence Industry

Open Source Software in the Defence Industry Open Source Software in the Defence Industry Anthony Harrison Thales anthony.harrison@uk.thalesgroup.com Abstract: There are an increasing number of defence programmes incorporating open source software

More information

City Research Online. Permanent City Research Online URL: http://openaccess.city.ac.uk/250/

City Research Online. Permanent City Research Online URL: http://openaccess.city.ac.uk/250/ Gacek, C. (2004). An interdisciplinary perspective of dependability in Open Source Software. BUILDING THE INFORMATION SOCIETY, 156, pp. 685-691. ISSN 1571-5736 City Research Online Original citation: Gacek,

More information

Socio technical Systems. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 2 Slide 1

Socio technical Systems. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 2 Slide 1 Socio technical Systems Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 2 Slide 1 Objectives To explain what a socio technical system is and the distinction between this and a computer

More information

AN ONTOLOGICAL APPROACH TO WEB APPLICATION DESIGN USING W2000 METHODOLOGY

AN ONTOLOGICAL APPROACH TO WEB APPLICATION DESIGN USING W2000 METHODOLOGY STUDIA UNIV. BABEŞ BOLYAI, INFORMATICA, Volume L, Number 2, 2005 AN ONTOLOGICAL APPROACH TO WEB APPLICATION DESIGN USING W2000 METHODOLOGY ANNA LISA GUIDO, ROBERTO PAIANO, AND ANDREA PANDURINO Abstract.

More information

Week 3. COM1030. Requirements Elicitation techniques. 1. Researching the business background

Week 3. COM1030. Requirements Elicitation techniques. 1. Researching the business background Aims of the lecture: 1. Introduce the issue of a systems requirements. 2. Discuss problems in establishing requirements of a system. 3. Consider some practical methods of doing this. 4. Relate the material

More information

Weaving the Software Development Process Between Requirements and Architectures

Weaving the Software Development Process Between Requirements and Architectures Weaving the Software Development Process Between and s Bashar Nuseibeh Computing Department The Open University Walton Hall Milton Keynes MK7 6AA, U.K. Email:B.A.Nuseibeh@open.ac.uk ABSTRACT This position

More information

Verification and Validation of Software Components and Component Based Software Systems

Verification and Validation of Software Components and Component Based Software Systems Chapter 5 29 Verification and Validation of Software Components and Component Based Christina Wallin Industrial Information Technology Software Engineering Processes ABB Corporate Research christina.wallin@mdh.se

More information

A Common Criteria Based Approach for COTS Component Selection

A Common Criteria Based Approach for COTS Component Selection A Common Criteria Based Approach for COTS Selection Wes J. Lloyd Computer Science Colorado State University Fort Collins, Colorado 80523 wlloyd@acm.org Abstract. -based software engineering (CBSE) endeavors

More information

SERVICE ORIENTED ARCHITECTURES (SOA) AND WORKFLOWS NEED FOR STANDARDISATION?

SERVICE ORIENTED ARCHITECTURES (SOA) AND WORKFLOWS NEED FOR STANDARDISATION? SERVICE ORIENTED ARCHITECTURES (SOA) AND WORKFLOWS NEED FOR STANDARDISATION? J-P. Evain European Broadcasting Union (EBU), Switzerland ABSTRACT This paper is an insight into what the EBU, the collective

More information

Home Page. Title Page. Contents. UK Government open source policy. Sebastian Rahtz January 14th 2005. Page 1 of 15. Go Back. Full Screen. Close.

Home Page. Title Page. Contents. UK Government open source policy. Sebastian Rahtz January 14th 2005. Page 1 of 15. Go Back. Full Screen. Close. Page 1 of 15 UK Government open source policy Sebastian Rahtz January 14th 2005 Page 2 of 15 Welcome Open Source: national frameworks Sebastian Rahtz Our aim today: to get a better understanding of the

More information

Accounting for Non-Functional Requirements in Productivity Measurement, Benchmarking & Estimating

Accounting for Non-Functional Requirements in Productivity Measurement, Benchmarking & Estimating Accounting for Non-Functional Requirements in Productivity Measurement, Benchmarking & Estimating Charles Symons President The Common Software Measurement International Consortium UKSMA/COSMIC International

More information

A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT

A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT Cléver Ricardo Guareis de Farias, Marten van Sinderen and Luís Ferreira Pires Centre for Telematics and Information Technology (CTIT) PO Box

More information

NFRs: Fact or Fiction

NFRs: Fact or Fiction Worcester Polytechnic Institute DigitalCommons@WPI Computer Science Faculty Publications Department of Computer Science 1-1-2002 NFRs: Fact or Fiction Janet Burge Worcester Polytechnic Institute, jburge@cs.wpi.edu

More information

Roadmap to a Sustainable Pan-European Certification of EHR Systems A deliverable of the European project EHR-Q TN

Roadmap to a Sustainable Pan-European Certification of EHR Systems A deliverable of the European project EHR-Q TN Roadmap to a Sustainable Pan-European Certification of EHR Systems A deliverable of the European project EHR-Q TN François Wisniewski CRP Henri Tudor SANTEC, Luxembourg Regional Conference: EHR Systems

More information

COTS Product Selection for Safety-Critical Systems

COTS Product Selection for Safety-Critical Systems COTS Product Selection for Safety-Critical Systems Fan Ye, Tim Kelly High Integrity Systems Engineering Group Department of Computer Science University of York, York YO10 5DD, UK {fan.ye, tim.kelly}@cs.york.ac.uk

More information

A Semi-Structured Structured Tailoring-Driven Approach for ERP Selection

A Semi-Structured Structured Tailoring-Driven Approach for ERP Selection A Semi-Structured Structured Tailoring-Driven Approach for ERP Selection Abdelilah Khaled 1 and Mohammed Abdou Janati Idrissi 2 1 TIME Research Team, ENSIAS/UM5 Souissi University, Rabat, Morocco 2 TIME

More information

Five High Order Thinking Skills

Five High Order Thinking Skills Five High Order Introduction The high technology like computers and calculators has profoundly changed the world of mathematics education. It is not only what aspects of mathematics are essential for learning,

More information

Outline. Definitions. Course schedule

Outline. Definitions. Course schedule SENG480A/CSC576A Topics in Software Engineering Software Development, Architecture & Evolution Lectures, Sep 17, 20, 2001 Hausi A. Müller University of Victoria Outline Assignment 1 due Sep 27 Last week

More information

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali Software development life cycle Software life cycle: Software Engineering - II ITNP92 - Object Oriented Software Design Dr Andrea Bracciali Module Co-ordinator 4B86 abb@cs.stir.ac.uk Spring 2014 (elicitation)

More information

Overview. System Definition Webster s Dictionary. System Engineering Hierarchy. System Engineering. Computer-Based Systems [PRE2005]

Overview. System Definition Webster s Dictionary. System Engineering Hierarchy. System Engineering. Computer-Based Systems [PRE2005] IF2261 Software Engineering Engineering Program Studi Teknik Informatika STEI ITB Overview Before software can be engineered: the system it is part of must be understood, the overall objective of the system

More information

Systems Integration: Co C mp m onent- t bas a e s d s o s ftw ft a w r a e r e ngin i eeri r n i g

Systems Integration: Co C mp m onent- t bas a e s d s o s ftw ft a w r a e r e ngin i eeri r n i g Systems Integration: Component-based software engineering Objectives To explain that CBSE is concerned with developing standardised components and composing these into applications To describe components

More information

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Charlie Abela Department of Artificial Intelligence charlie.abela@um.edu.mt Last Lecture Web Ontology Language Problems? CSA 3210 Service Oriented Architecture 2 Lecture Outline

More information

Investigate Requirements for Software Solutions

Investigate Requirements for Software Solutions Unit 29: Investigate Requirements for Software Solutions Learning Outcomes A candidate following a programme of learning leading to this unit will be able to: Gather and analyse appropriate and relevant

More information

SOFTWARE REQUIREMENTS

SOFTWARE REQUIREMENTS SOFTWARE REQUIREMENTS http://www.tutorialspoint.com/software_engineering/software_requirements.htm Copyright tutorialspoint.com The software requirements are description of features and functionalities

More information

Managing Software Product Line

Managing Software Product Line * F 2 - Rules for Qualification of Developing and Managing Software Product Line F. Ahmed Electrical & Computer Engineering University of Western Ontario London Ontario, Canada, N5A5B9 sgraha5@uwo.ca L.F.

More information

BCS 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 BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 EXAMINERS REPORT Friday 2 nd October 2015 Answer any THREE

More information

White Paper What Solutions Architects Should Know About The TOGAF ADM

White Paper What Solutions Architects Should Know About The TOGAF ADM White Paper What Solutions Architects Should Know About The TOGAF ADM WP0015 October 2011 The Open Group Architecture Framework 1 (TOGAF) is the most widely referenced architecture framework currently

More information

Conceptual Fit: A Criterion for COTS Selection

Conceptual Fit: A Criterion for COTS Selection Conceptual Fit: A Criterion for COTS Selection Antoni Olivé Department of Service and Information System Engineering Universitat Politècnica de Catalunya Barcelona Tech antoni.olive@upc.edu Abstract. COTS

More information

Selecting a Standard Bidding Document for IT Procurement

Selecting a Standard Bidding Document for IT Procurement The World Bank Operational Policy and Country Services Vice Presidency Procurement Unit IT Procurement Guidance Note 8 Selecting a Standard Bidding Document for IT Procurement CONTENTS I. Background on

More information

Web Application Development Processes: Requirements, Demands and Challenges

Web Application Development Processes: Requirements, Demands and Challenges Web Application Development Processes: Requirements, Demands and Challenges THAMER AL-ROUSAN 1, BASEM HADIDI 2, SHADI ALJAWARNEH 3 1, 3 Faculty of Science and Information Technology, Isra University, Amman,

More information

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.)

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.) The Software Process Xiaojun Qi 1 The Unified Process Until recently, three of the most successful object-oriented methodologies were Booch smethod Jacobson s Objectory Rumbaugh s OMT (Object Modeling

More information

Requirements Analysis Concepts & Principles. Instructor: Dr. Jerry Gao

Requirements Analysis Concepts & Principles. Instructor: Dr. Jerry Gao Requirements Analysis Concepts & Principles Instructor: Dr. Jerry Gao Requirements Analysis Concepts and Principles - Requirements Analysis - Communication Techniques - Initiating the Process - Facilitated

More information

System Development and Life-Cycle Management (SDLCM) Methodology. Approval CISSCO Program Director

System Development and Life-Cycle Management (SDLCM) Methodology. Approval CISSCO Program Director System Development and Life-Cycle Management (SDLCM) Methodology Subject Type Standard Approval CISSCO Program Director A. PURPOSE This standard specifies content and format requirements for a Physical

More information

Syllabus. REQB Certified Professional for Requirements Engineering. Foundation Level

Syllabus. REQB Certified Professional for Requirements Engineering. Foundation Level Syllabus REQB Certified Professional for Requirements Engineering Version 2.1 2014 The copyright to this edition of the syllabus in all languages is held by the Global Association for Software Quality,

More information

Overview Component-based Software Engineering State of the Art Report

Overview Component-based Software Engineering State of the Art Report Overview Component-based Software Engineering State of the Art Report Ivica Crnkovic 1, Magnus Larsson 2 1 Mälardalen University, Department of Computer Engineering, 721 23 Västerås, Sweden, Ivica.Crnkovic@mdh.se

More information

A Semi-Structured Structured Tailoring-Driven Approach for ERP Selection

A Semi-Structured Structured Tailoring-Driven Approach for ERP Selection www.ijcsi.org 71 A Semi-Structured Structured Tailoring-Driven Approach for ERP Selection Abdelilah Khaled 1 and Mohammed Abdou Janati Idrissi 2 1 TIME Research Team, ENSIAS/UM5 Souissi University, Rabat,

More information

Software Engineering Reference Framework

Software Engineering Reference Framework Software Engineering Reference Framework Michel Chaudron, Jan Friso Groote, Kees van Hee, Kees Hemerik, Lou Somers, Tom Verhoeff. Department of Mathematics and Computer Science Eindhoven University of

More information

ESPRIT 29938 ProCure. ICT at Work for the LSE ProCurement Chain:

ESPRIT 29938 ProCure. ICT at Work for the LSE ProCurement Chain: ESPRIT 29938 ProCure ICT at Work for the LSE ProCurement Chain: Putting Information Technology & Communications Technology to work in the Construction Industry The EU-funded ProCure project was designed

More information

Rapid software development. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1

Rapid software development. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1 Objectives To explain how an iterative, incremental development process leads to faster delivery of

More information

Using Requirements Traceability Links At Runtime A Position Paper

Using Requirements Traceability Links At Runtime A Position Paper Using Requirements Traceability Links At Runtime A Position Paper Alexander Delater, Barbara Paech University of Heidelberg, Institute of omputer Science Im Neuenheimer Feld 326, 69120 Heidelberg, Germany

More information

Implementing XML-based Role and Schema Migration Scheme for Clouds

Implementing XML-based Role and Schema Migration Scheme for Clouds Implementing XML-based Role and Schema Migration Scheme for Clouds Gurleen Kaur 1, Sarbjeet Singh 2 Computer Science and Engineering, UIET Panjab University, Chandigarh, India 1 gurleenturka@gmail.com

More information

Exploiting software supply chain business architecture: a research agenda

Exploiting software supply chain business architecture: a research agenda Exploiting software supply chain business architecture: a research agenda Barbara Farbey & Anthony Finkelstein University College London, Department of Computer Science, Gower Street, London WC1E 6BT,

More information

Issues in Implementing Service Oriented Architectures

Issues in Implementing Service Oriented Architectures Issues in Implementing Service Oriented Architectures J. Taylor 1, A. D. Phippen 1, R. Allen 2 1 Network Research Group, University of Plymouth, United Kingdom 2 Orange PCS, Bristol, United Kingdom email:

More information

Configuration Management

Configuration Management 83 Chapter 6 Configuration Management Published as: Configuration Management in Component Based Product Populations, Rob van Ommering, 10th International Workshop on Software Configuration Management,

More information

Component Based Software Engineering: A Broad Based Model is Needed

Component Based Software Engineering: A Broad Based Model is Needed Component Based Software Engineering: A Broad Based Model is Needed Allen Parrish (parrish@cs.ua.edu) Brandon Dixon (dixon@cs.ua.edu) David Hale (dhale@alston.cba.ua.edu) Department of Computer Science

More information

An Improved Model for Component Based Software Development

An Improved Model for Component Based Software Development Software Engineering 2012, 2(4): 138-146 DOI: 10.5923/j.se.20120204.07 An Improved Model for Component Based Software Development Asif Irshad Khan 1,*, Noor-ul-Qayyum 2, Usman Ali Khan 2 1 Department of

More information

PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3)

PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3) PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3) 1st February 2006 Version 1.0 1 P3M3 Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce This is a Value

More information

Elicitation and Modeling Non-Functional Requirements A POS Case Study

Elicitation and Modeling Non-Functional Requirements A POS Case Study Elicitation and Modeling Non-Functional Requirements A POS Case Study Md. Mijanur Rahman and Shamim Ripon, Member IACSIT Abstract Proper management of requirements is crucial to successful development

More information

Software Engineering in a Nutshell

Software Engineering in a Nutshell Overview of Software Engineering Principles 1 Software Engineering in a Nutshell Development of software systems whose size/ complexity warrants a team or teams of engineers multi-person construction of

More information

Achieve Economic Synergies by Managing Your Human Capital In The Cloud

Achieve Economic Synergies by Managing Your Human Capital In The Cloud Achieve Economic Synergies by Managing Your Human Capital In The Cloud By Orblogic, March 12, 2014 KEY POINTS TO CONSIDER C LOUD S OLUTIONS A RE P RACTICAL AND E ASY TO I MPLEMENT Time to market and rapid

More information

Reusability of WSDL Services in Web Applications

Reusability of WSDL Services in Web Applications 599 Reusability of WSDL Services in Web Applications 1 Jaspreet Singh, 2 Sandeep Saini 1 Assistant Professor Department Of Computer Science & Engineering, Chandigarh University Gharuan, Punjab, India 2

More information

Adventures in Estimating Open Source, Component Systems, Agile, and SOA Projects

Adventures in Estimating Open Source, Component Systems, Agile, and SOA Projects Open Source, Component Systems, Agile, and SOA Projects Terry Vogt Lead Associate Booz Allen Hamilton Sept 13, 2011 Ready for what s next 1 Booz Allen Hamilton 1 Agenda Background Open Source Component

More information

Software Requirements Specification

Software Requirements Specification 1 of 7 17.04.98 13:32 Software Requirements Specification The sub-sections : 1. What is a Software Requirements Specification 2. Why is a Software Requirement Specification Required 3. What is Contained

More information

European Security Standards Reference Implementation Initiative (ESSRII)

European Security Standards Reference Implementation Initiative (ESSRII) European Security Standards Reference Implementation Initiative (ESSRII) A Proposal for Action in Europe on International Information Security Standards Brian Gladman, European Technical Director, Trusted

More information

The Impact of Release Management and Quality Improvement in Open Source Software Project Management

The Impact of Release Management and Quality Improvement in Open Source Software Project Management Applied Mathematical Sciences, Vol. 6, 2012, no. 62, 3051-3056 The Impact of Release Management and Quality Improvement in Open Source Software Project Management N. Arulkumar 1 and S. Chandra Kumramangalam

More information

QUALITY MODEL BASED ON COTS QUALITY ATTRIBUTES

QUALITY MODEL BASED ON COTS QUALITY ATTRIBUTES QUALITY MODEL BASED ON COTS QUALITY ATTRIBUTES Khaled Musa 1 and Jawad Alkhateeb 2 1 Department of Software Engineering, Alzaytoonah University of Jordan, Amman, Jordan Informatics, University of Huddersfield,

More information

Scrum, User Stories, and More! CSCI 5828: Foundations of Software Engineering Lecture 22 11/06/2014

Scrum, User Stories, and More! CSCI 5828: Foundations of Software Engineering Lecture 22 11/06/2014 Scrum, User Stories, and More! CSCI 5828: Foundations of Software Engineering Lecture 22 11/06/2014 1 Goals Cover Material from our User Stories Book Chapter 15: Using Stories With Scrum Chapter 16: Additional

More information

CONFIGURATION MANAGEMENT TECHNOLOGY FOR LARGE-SCALE SIMULATIONS

CONFIGURATION MANAGEMENT TECHNOLOGY FOR LARGE-SCALE SIMULATIONS SCS M&S Magazine. Vol 3. Issue 3. A. Sekiguchi, K. Shimada, Y. Wada, A. Ooba, R. Yoshimi, and A. Matsumoto. CONFIGURATION MANAGEMENT TECHNOLOGY FOR LARGE-SCALE SIMULATIONS Atsuji Sekiguchi, Kuniaki Shimada,

More information

COST EFFECTIVE MODERNISATION OF SYSTEMS IMPORTANT TO SAFETY (CEMSIS)

COST EFFECTIVE MODERNISATION OF SYSTEMS IMPORTANT TO SAFETY (CEMSIS) COST EFFECTIVE MODERNISATION OF SYSTEMS IMPORTANT TO SAFETY (CEMSIS) D. Pavey (British Energy, Gloucester), R. Bloomfield (Adelard, London), P-J. Courtois (AVN, Brussels), P. Caspall-Askew (BNFL, Risley),

More information

Managing Variability in Software Architectures 1 Felix Bachmann*

Managing Variability in Software Architectures 1 Felix Bachmann* Managing Variability in Software Architectures Felix Bachmann* Carnegie Bosch Institute Carnegie Mellon University Pittsburgh, Pa 523, USA fb@sei.cmu.edu Len Bass Software Engineering Institute Carnegie

More information

Software Package Requirements & Procurement

Software Package Requirements & Procurement Software Package Requirements & Procurement Anthony Finkelstein & George Spanoudakis Department of Computer Science, City University, UK {acwf, gespan@cs.city.ac.uk} Mark Ryan School of Computer Science,

More information

The IFPUG Counting Practices On-Going Effort in Sizing Functional Requirements. Janet Russac

The IFPUG Counting Practices On-Going Effort in Sizing Functional Requirements. Janet Russac The IFPUG Counting Practices On-Going Effort in Sizing Functional Requirements Janet Russac 2009 IFPUG s method for function point analysis is an ISO standard and must be conformant to ISO/IEC 14143-1:2007.

More information