DOCSLIB.ORG

Requirements Analysis

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Requirements Analysis A Framework for the Requirements Analysis of Safety-Critical Computing Systems Amer Saeed Ph.D Thesis The University of Newcastle upon Tyne Computing Laboratory September 1990 N~ STEE UNIVERSIT Abstract Abstract Digital computers are increasingly being used in safety-critical applications (e.g., avionics, chemical plant and railway systems). The main motivations for introducing computers into such environments are to increase performance, flexibility and efficiency. However, the cost to safety in achieving these benefits using computing systems is unclear. The general class of systems considered in this thesis are process control systems. More specifically the thesis examines the class of safety-critical computing systems which are a component of a process control system that could cause or allow the overall system to enter into a hazardous state. This thesis investigates the role oiformal methods in safety-critical computing systems. The phase of system development considered is requirements analysis. Experience in safety-critical systems has shown that errors in the identified requirements are one of the major causes of mishap. It is argued that to gain a complete understanding of such computing systems, the requirements of the overall system and the properties of the environment must be analyzed in a common formal framework. A system development model based on the separation of safety and mission issues is discussed, which highlights the essential specifications that must be produced during requirements analysis. A formal model for the representation of these essential specifications is presented. The semantics of this formal model are based on the notion of a system history. To structure the specifications expressed by this formal model the concept of a mode is introduced. This thesis suggests that for a formal model to be useful during requirements analysis a related systematic methodology, which provides comprehensive guidelines for the analysts who use the model must be made available. An appropriate methodology, based upon the system development model, which incorporates some traditional system safety techniques is described. Overall, the thesis presents a framework for requirements analysis by providing a system development model, formal model and related development methodology. An example of how this framework can support requirements analysis is presented in the appendices Band C. Acknowledgements Acknowledgements Firstly, my thanks go to my supervisor, Professor Tom Anderson, who introduced me to the area of safety-critical systems, and in addition made many helpful comments upon the content of this thesis. I would also like to thank Professor Brian Randell and Dr Maciej Koutny for their help in the early years of my research. In particular I would like to thank Dr Maciej Koutny for his suggestions on the formal notation. Thanks must also go to my colleague Mr R de Lemos for our discussions on safety-critical systems. Many other members of the Computing Laboratory too numerous to mention individually have also made my tenure here more pleasant. Thanks to you all. Finally the support and patience of my parents throughout the years of this research deserves a special mention. Financial support for the work described in this thesis was provided by a grant from the UK Science and Engineering Research Council and an Alvey grant in software reliability (Alvey Software Reliability Project SE/072). II Table of Contents Table of Contents 1 Introduction . 1 1.1. Background 1 1.2. Safety 3 1.2.1. System Safety 5 1.2.2. Regulation and Legislation. 6 1.3. Process Control Systems 7 1.3.1. Operator 8 1.3.2. Physical Process 8 1.3.3. Controller 9 1.3.4. Controller Components 9 1.4. Safety in Computer Based Systems. 11 1.4.1. Reliability. 12 1.4.2. Safety 12 1.4.3. Safety-critical Computing Systems . 13 1.5. Obstacles to Computers in Safety-Critical Systems 13 1.5.1. Intrinsic Obstacles 14 1.5.2. Application Obstacles 17 1.6. System Lifecycle . 19 1.7. Aims.. .. .. .. .. .. ... .. .. 22 1.8. Overview...................................... 23 2 Requirements Analysis 25 2.1. Introduction 25 2.2. Role of Requirements Specification . 26 2.2.1. Requirements Specification Viewpoints...................... 28 2.3. Structured Requirements Analysis 30 2.3.1. Development Model....................... 30 2.3.1.1. Separation of Issues 30 2.3.1.2. Safety-Critical System Structure . 32 2.3.1.3. Requirements Phases '" . .. 37 2.3.2. Formal Model . 40 2.3.2.1.Advantages of Formal Models 40 2.3.3. Development Programme.. .. .. .. .. .. .. .. 46 m Table of Contents 2.3.3.1.DevelopmentMethodology.................................. 47 2.3.3.2.Requirements AnalysisTeam 48 2.4. Working Example 51 2.5. Summary....................................... 53 3 Basic Concepts .................................. 55 3.1. Time 55 3.1.1. Time Points 58 3.1.2. Time Intervals . 58 3.1.3. System Lifetime ···· 61 3.2. State Variables. 61 3.2.1. Variable Ranges ······· 63 3.3. Variable Categories . 65 3.4. SystemHistory. 68 3.4.1. History Function. 69 3.5. History Descriptions 70 3.5.1. Variable Class Relations. 71 3.5.2. Invariant Relations. 74 3.5.3. History Relations 77 3.5.4. Comparison of Relations 80 3.5.5. History Description Sets . 81 3.6. Clocks . 82 3.7. Real-time Satisfaction Conditions 83 3.7.1. System Predicates. 83 3.7.2. Point Satisfaction 84 3.7.3. Interval Satisfaction. 85 3.7.4. Events. 87 3.7.5. Time Bound Constraints................................... 90 3.7.6. 'Iermination Predicate....................... 91 3.8. Summary. 92 4 Mode Theory .................................... 94 4.1. Modes. 94 4.1.1. History Graphs 97 4.1.2. Mode Properties . 98 4.1.3. Mode Relationships 100 lV Table of Contents 4.1.4. Mode Categories 101 4.1.5. Mode Consistency. 103 4.1.6. Mode Limitations......................................... 106 4.1.7. Mode Benefits 107 4.2. Mode Sequences 108 4.2.1. Mode Sequence Properties. 109 4.2.2. Mode Sequence Relationships.............................. 111 4.2.3. Mode Sequence Consistency 111 4.2.4. Mode Sequence Example . 114 4.2.5. Mode Sequence Set . 115 4.2.6. Mode Sequence Limitations. 116 4.3. Mode Graphs . 118 4.3.1. Mode Graph Properties 121 4.3.2. Mode Graph Components 121 4.3.3. Complete Mode Graphs .. 123 4.3.4. Consistent Mode Graphs 124 4.3.5. Mode Graph Relationships. 126 4.3.6. Mode Graph Categories 127 4.3.7. Predicate Mode Graph.................................... 130 4.4. Summary. 131 5 Real World Specifications . 133 5.1. Disaster Set 133 5.2. Safety Real World Description. 134 5.3. Hazard Specification 135 5.4. Safety Real World Specification 138 5.5. Mission Real World Description. 139 5.6. Mission Real World Specification. 140 5.6.1. Mission Phase Specification. 141 5.7. Summary. 144 6 Controller Specifications. 146 6.1. Safety Environment Description 146 6.2. Safety Controller Specification . 148 6.2.1. Safety Controller Behaviour Structure 148 6.2.2. Start Up Phase 150 v Table of Contents 6.2.3. Monitor Phase 151 6.2.4. Recovery Phase 152 6.2.5. Reset Phase . 155 6.2.6. Shut Down Phase . 156 6.2.7. End Phase............................................... 156 6.3. Mission Environment Description 158 6.3.1. Relation Classes. 158 6.3.2. Monitor Relations 160 6.4. Mission Controller Specification 161 6.4.1. Mission Controller Behaviour Structure. 162 6.5. Summary and Conclusions 169 7 Real World Analysis 171 7.1. Introduction 171 7.2 Initial Real World Description Analysis 174 7.2.1. Production Guidelines. 174 7.3. Disaster Analysis 180 7.3.1 Disaster Identification 180 7.3.2. Validation Guidelines 181 7.4. Hazard Specification Analysis. 182 7.4.1 Hazard Identification 182 7.4.2. Validation Guidelines 184 7.4.3 Hazard Elimination........................................ 185 7.4.4. Complete Hazard Assumption. 185 7.5. Safety Real World Description Analysis. 186 7.5.1. Construction Guidelines. 186 7.5.2. Validation Guidelines 188 7.6. Safety Real World Specification Analysis. 189 7.7. Mission Real World Specification Analysis. 190 7.7.1. Mission Phase Specification Analysis. 190 7.7.2. Mission Real World Specification Analysis............. 195 7.8. Mission Real World Description Analysis 199 7.8.1. Construction Guidelines. 199 7.8.2. Mission Real World Specification Checks 201 7.8.3. Mission Validation........................................ 202 7.9. Combination of Analysis. 203 7.10. Summary. 203 VI Table of Contents 8 Controller Analysis ............................... 206 8.1. Introduction 206 8.2. Safety Environment Description Analysis 208 8.3. Safety Controller Specification Analysis 210 8.3.1. Safety Verification. .. 211 8.3.2 Safety Controller Specification Development Methodology. 215 8.3.3. Safety Controller Specification Methodology Theorems 226 8.4. Mission Environment Description Analysis . 229 8.5. Mission Controller Specification Analysis. 231 8.5.1 Mission Verification. 234 8.5.2. Mission Controller Development Strategy 245 8.5.3. Mission Controller Specification Theorems 249 8.6. Summary and Conclusions 251 9 Summary and Conclusions. 254 9.1. Thesis Summary. 254 9.2. Evaluation and Conclusions. 261 9.3. Future Work . 263 9.3.1. Extensions to the Framework 264 9.3.2. Investigation of Other Formalisms 266 References Appendix A AppendixB AppendixC vu List of Figures List of Figures Figure 1.1. Process Control System Components 8 Figure 1.2. Controller Components 9 Figure 1.3. Controller Interfaces. 11 Figure 1.4. Simplified System Life Cycle 19 Figure 2.1. Role of Requirements Specification . 28 Figure 2.2. Safety-Critical System Structure 32 Figure 2.3. Safety-Critical Controller Components. 34 Figure. 2.4. Safety-Critical Controller Interfaces 35 Figure 2.5. Requirement Analysis Phases. 37 Figure 2.6. Reaction Vessel 53 Figure 3.1. An Evolution . 68 Figure 3.2.
Load more

Recommended publications
  • Geo-DB Requirement Analysis
    2.1.1. Overview Lifecycle 2 Conceptual Database Design 2.1 Requirement analysis -> Text 2.2 Modeling languages Requirement analysis -> Conceptual Model 2.1.1 Overview Conceptual Design 2.1.2 Requirement Analysis (case study) 2.2.1 Basic Modeling Primitives 2.2.2 Modeling Languages: UML and CREATE TABLE Studentin (SID INTEGER PRIMARY KEY, -> Database schema VName CHAR(20) Name CHAR(30)CREATE NOT TABLENULL, Kurs Entity-Relationship Model (ERM) Logical Schema Design Email Char(40));(KID CHAR(10) PRIMARY KEY, Name CHAR(40) NOT NULL, Dauer INTEGER); CREATE TABLE Order 2.2.3 Conceptual DB design: basics ODate DATE soldBy INTEGER FOREIGN KEY REFEREBCES Peronal(PID) 2.2.4 From Requirements to Models CID INTEGER FOREIGN KEY REFERENCES Customer (CID)); Physical Schema Design -> Access paths References: Kemper / Eickler chap 2, Elmasri / Navathe chap. 3 Administration Garcia-Molina / Ullmann / Widom: chap. 2 © HS-2009 Redesign 02-DBS-Conceptual-2 Database Design:Terminology 2.1.2 Requirement Analysis Most important: talk with your customers! Def.: Database Design The process of defining the overall structure of a database, Tasks during RA: i.e. the schema, on different layers of abstraction. Identify essential "real world" information (e.g. Design levels: Conceptual, logical, physical interviews) Remove redundant, unimportant details Includes "Analysis" and "Design" from SE Clarify unclear natural language statements DB Modeling: defining the "static model" using formal or visual languages Fill remaining gaps in discussions Distinguish data and operations DB SE Requirements Requirements Conceptual modeling Analysis Requirement analysis & Conceptual Design aims at Logical modeling Design focusing thoughts and discussions ! Physical modeling Implementation © HS-2009 02-DBS-Conceptual-3 © HS-2009 02-DBS-Conceptual-4 Example: Geo-DB Requirement Analysis The database we develop will contain data about countries, cities, Clarify unclear statements organizations and geographical facts.
    [Show full text]
  • Design and Implementation of a Standards Based Ecommerce Solution in the Business-To-Business Area
    Design and implementation of a standards based eCommerce solution in the business-to-business area Thesis of Andreas Junghans Department of Computer Science Karlsruhe University of Applied Sciences, Germany Written at ISB GmbH, Karlstrasse 52-54, 76133 Karlsruhe 03/01/2000 to 08/31/2000 Supervisor at Karlsruhe University of Applied Sciences: Prof. Klaus Gremminger Co-supervisor: Prof. Dr. Lothar Gmeiner Supervisor at ISB GmbH: Dipl.Inform. Ralph Krause Declaration I have written this thesis independently, solely based on the literature and tools mentioned in the chapters and the appendix. This document - in the current or a similar form - has not and will not be submitted to any other institution apart from the Karlsruhe University of Applied Sciences to receive an academical grade. I would like to thank Ralph Krause and Gerlinde Wiest of ISB GmbH for their support over the last six month, as well as Peter Heil and Frank Nielsen of Heidelberger Druckmaschinen AG for providing informa- tion and suggestions for the requirements analysis. Acknowledgements also go to Christian Schenk for his MiKTEX distribution and the Apache group for their XML tools. Finally, I would like to thank Professor Klaus Gremminger of the Karlsruhe University of Applied Sciences for his supervision of this thesis. Karlsruhe, 3rd of September, 2000 (Andreas Junghans) Contents 1 Introduction 1 1.1 Document conventions ...................................... 1 1.2 Subject of this thesis ....................................... 1 1.3 Rough schedule .......................................... 2 2 Requirements analysis 3 2.1 Tools used ............................................. 3 2.2 Domain requirements ....................................... 3 2.2.1 Clarification of terms ................................... 3 2.2.2 Specific requirements on ”Business to Business” applications ............
    [Show full text]
  • Requirements Phase
    Requirements Phase • Chance of a product being on time and within budget is very slim unless the development team knows what the product should do • To achieve this level the development team must analyze the needs of the client as precisely as possible Ch10 Copyright © 2004 by Eugean 1 Hacopians Requirements Phase • After a clear picture of the problem the development teams can answer the question: – What should the product do? • The process of answering this question lies within the requirements phase Ch10 Copyright © 2004 by Eugean 2 Hacopians Requirements Phase • Common misconceptions are: – During requirement phase the developer must determine what the client wants – The client can be unclear as to what they want – The client may not be able to communicate what they want to the developer • Most clients do not understand the software development process Ch10 Copyright © 2004 by Eugean 3 Hacopians Requirements Elicitation • This process is finding out a client’s requirements • Members of the requirements team must be familiar with the application domain • Requirement analysis is the process of: – Understanding the initial requirements – Refining requirements – Extending requirements Ch10 Copyright © 2004 by Eugean 4 Hacopians Requirements Elicitation • This process starts with several members of the requirements analysis team meeting with several members of the client’s team • It is essential to use the correct terminology or settle on an agreed set – Misunderstanding terminology can result in a faulty product – This could result in
    [Show full text]
  • Data Quality Requirements Analysis and Modeling December 1992 TDQM-92-03 Richard Y
    Published in the Ninth International Conference of Data Engineering Vienna, Austria, April 1993 Data Quality Requirements Analysis and Modeling December 1992 TDQM-92-03 Richard Y. Wang Henry B. Kon Stuart E. Madnick Total Data Quality Management (TDQM) Research Program Room E53-320 Sloan School of Management Massachusetts Institute of Technology Cambridge, MA 02139 USA 617-253-2656 Fax: 617-253-3321 Acknowledgments: Work reported herein has been supported, in part, by MITís Total Data Quality Management (TDQM) Research Program, MITís International Financial Services Research Center (IFSRC), Fujitsu Personal Systems, Inc. and Bull-HN. The authors wish to thank Gretchen Fisher for helping prepare this manuscript. To Appear in the Ninth International Conference on Data Engineering Vienna, Austria April 1993 Data Quality Requirements Analysis and Modeling Richard Y. Wang Henry B. Kon Stuart E. Madnick Sloan School of Management Massachusetts Institute of Technology Cambridge, Mass 02139 [email protected] ABSTRACT Data engineering is the modeling and structuring of data in its design, development and use. An ultimate goal of data engineering is to put quality data in the hands of users. Specifying and ensuring the quality of data, however, is an area in data engineering that has received little attention. In this paper we: (1) establish a set of premises, terms, and definitions for data quality management, and (2) develop a step-by-step methodology for defining and documenting data quality parameters important to users. These quality parameters are used to determine quality indicators, to be tagged to data items, about the data manufacturing process such as data source, creation time, and collection method.
    [Show full text]
  • Business Requirements Analysis Document (BRAD) - Trading Partner Performance Management, Release 1.0.0
    Business Requirements Analysis Document (BRAD) - Trading Partner Performance Management, Release 1.0.0 Business Requirements Analysis Document (BRAD) For Trading Partner Performance Management BRAD: 1.0.0 BRG: Trading Partner Performance Management Work Group Date: 7-Nov-2008, Approved 7-Nov-2008, Approved All contents copyright © GS1 2008 Page 1 of 81 Business Requirements Analysis Document (BRAD) - Trading Partner Performance Management, Release 1.0.0 Document Summary Document Item Current Value Document Number 10713 Document Title Business Requirements Analysis Document (BRAD) Date Last Modified 7-Nov-2008 Status Approved Work Group / Chairperson Trading Partner Performance Management / Matt Johnson BRAD Template Version 2.4 Change Request Reference Date of CR Submission to GSMP: CR Submitter(s): Refer to Change Request (CR) Number(s): 13 - Jul – 2007 John Ryu, GS1 07-000283 Document Change History Date of Vers Changed By Reason for Summary of CR # Model Change ion Change Change Build # 31–Oct-2007 0.1.0 John Ryu Initial Draft Section 15 07-000283 N/A 3-Mar–2008 0.2.0 John Ryu Added agreed measures Section 15 Not N/A Matt Johnson Applicable 25-Mar-2008 0.2.2 John Ryu Based on Dallas F2F meeting Section 15 N/A N/A 9-Apr-2008 0.3.0 John Ryu Finalizing for GSMP Meeting on 20080414 Section 15 N/A N/A 11-Apr-2008 0.3.1 John Ryu Based on 20080409 teleconference Section 15 N/A N/A Matt Johnson 22-Apr-2008 0.3.2 John Ryu Based on Brussels F2F Meeting Section 15 N/A N/A 1-May-2008 0.3.3 John Ryu Posting for 60 Day Public Review Section 15 N/A N/A Start May 1 and End on June 30.
    [Show full text]
  • Fault-Based Analysis: How History Can Help Improve Performance and Dependability Requirements for High Assurance Systems
    Fault-Based Analysis: How History Can Help Improve Performance and Dependability Requirements for High Assurance Systems Jane Huffman Hayes David M. Pruett Elizabeth Ashlee Holbrook Geocontrol Systems Inies Raphael C.M. Incorporated University of Kentucky Dept. of Computer Science [email protected] [email protected], {ashlee|irchem2}@uky.edu Abstract Related work is discussed in Section 3. Our position is outlined in Section 4 as well as some Performance and dependability requirements are preliminary results. Finally, conclusions and future key to the development of high assurance systems. work round out the paper in Section 5. Fault-based analysis has proven to be a useful tool for detecting and preventing requirement faults 2. Fault-based analysis early in the software life cycle. By tailoring a generic fault taxonomy, one is able to better “The IEEE standard definition of an error is a prevent past mistakes and develop requirements mistake made by a developer. An error may lead to specifications with fewer overall faults. Fewer one or more faults [13]. To understand Fault- faults within the software specification, with Based Analysis (FBA), a look at a related respect to performance and dependability technique, Fault-Based Testing (FBT), is in order. requirements, will result in high assurance systems Fault-based testing generates test data to of improved quality. demonstrate the absence of a set of pre-specified faults. There are numerous FBT techniques. These 1. Introduction use a list of potential faults to generate test cases, generally for unit- and integration-level testing One needs only look to the increasing [20,3].
    [Show full text]
  • Requirements Analysis Software Requirements
    Requirements Analysis Software Requirements AA softwaresoftware (product)(product) requirementrequirementisis aa feature,feature, function,function, capability,capability, oror propertyproperty thatthat aa softwaresoftware productproduct mustmusthave.have. Software Design AAsoftwaresoftware designdesignisis aa specificationspecification ofof aa softwaresoftware systemsystem thatthat programmersprogrammers cancan implementimplement inin code.code. What vs How The traditional way to distinguish requirements from design: What a system is supposed to do is requirements How a system is supposed to do it is design What vs How Problems The what vs. how criterion is probably unworkable: •Other design disciplines do not make this distinction •Understanding needs and constraints must always be the first step in design •The what vs. how criterion does not hold up in practice Requirements vs Design Determining requirements is really the first step of design. RequirementsRequirementsstatestate clientclient needsneeds andand solutionsolution constraints.constraints. DesignsDesignsstatestate problemproblem solutions.solutions. Requirements Phase Activities Problem or requirements analysis Working with clients to understand their needs and the constraints on solutions Requirements Specification Documenting the requirements These activities are logically distinct but usually occur together. Requirements Phase Problems The requirements phase is HARD! There are several reasons for this: • requirements volatility • requirements elicitation problems • language
    [Show full text]
  • Dependability Attributes for Space Computer Systems
    DEPENDABILITY ATTRIBUTES FOR SPACE COMPUTER SYSTEMS Romani, M.A.S., [email protected] Lahoz, C.H.N., [email protected] Institute of Aeronautics and Space (IAE), São José dos Campos, São Paulo, Brazil Yano, E.T., [email protected] Technological Institute of Aeronautics (ITA), São José dos Campos, São Paulo, Brazil Abstract. Computer systems are increasingly used in critical applications in the space area where a failure can have serious consequences such as loss of mission, properties or lives. One way to improve quality of space computer projects is through the use of dependability attributes such as reliability, availability, safety, etc. to assist the identification of non-functional requirements. This work presents and discusses a minimum set of dependability attributes, selected for software applications, to be used in space projects. These attributes resulted from a research carried out on factors extracted from practices, standards and safety models both from international institutions of the aerospace field such as ESA, NASA and MOD (UK Ministry of Defense), as well as renowned authors in the area. An example illustrates the use of dependability attributes to identify dependability requirements. Keywords: dependability, requirements specification, software quality, space systems 1. INTRODUCTION Computer systems are increasingly used in space, whether in launch vehicles, satellites, and ground support and payload systems. Due to this fact, the software applications used in these systems have become more complex, mainly due to the high number of features to be met, thus contributing to a greater probability of hazards occurrence in a project. Pisacane (2005) emphasizes that spacecraft computer systems require space-qualified microcomputers, memories, and interface devices.
    [Show full text]
  • Defining and Managing Requirements: a Framework for Project Success and Beyond Requirements Are Critical As Project Managers Try to Control Project Failure Rates
    RG Perspective Defining and Managing Requirements: A Framework for Project Success and Beyond Requirements Are Critical as Project Managers Try to Control Project Failure Rates 11 Canal Center Plaza Alexandria, VA 22314 HQ 703-548-7006 Fax 703-684-5189 teamRG.com © 2017 Robbins-Gioia, LLC Defining and Managing Requirements Conventional wisdom says you will never reach Get at the true requirements your destination if you don’t know where you’re Enforce tracking and management of going. However, all too often, that’s exactly how requirements throughout the life-cycle projects are implemented, most often as a result Allow for a structured approach to the of the business and technical staff being unable to review and approval process communicate their needs to each other. This Contribute to future projects so that communication gap usually occurs early in a valuable assets are not lost project, and the negative impacts manifest Each of these four critical success factors is themselves throughout the entire life-cycle. discussed next. Extensive re-work, scope creep, missed deadlines, low morale, and required features being dropped Critical Success Factor #1: Eliciting from product releases are just some of the issues the True Requirements that are costly and can be traced back to a The key to uncovering real requirements (and by fundamental lack of understanding of the business that we mean those that meet true needs) is needs. three-fold. You must have an efficient and For the project manager, unclear requirements are effective process to guide the way requirements the cause of mounting frustration throughout the are gathered and documented; your process must life cycle.
    [Show full text]
  • Requirement Analysis Method of E- Commerce Websites Development for Small- Medium Enterprises, Case Study: Indonesia
    International Journal of Software Engineering & Applications (IJSEA), Vol.5, No.2, March 2014 REQUIREMENT ANALYSIS METHOD OF E- COMMERCE WEBSITES DEVELOPMENT FOR SMALL- MEDIUM ENTERPRISES, CASE STUDY: INDONESIA Veronica S. Moertini1, Suhok2, Silvania Heriyanto3 and Criswanto D. Nugroho4 Informatics Department, Parahyangan Catholic University, Indonesia ABSTRACT Along with the growth of the Internet, the trend shows that e-commerce have been growing significantly in the last several years. This means business opportunities for small-medium enterprises (SMEs), which are recognized as the backbone of the economy. SMEs may develop and run small to medium size of particular e-commerce websites as the solution of specific business opportunities. Certainly, the websites should be developed accordingly to support business success. In developing the websites, key elements of e-commerce business model that are necessary to ensure the success should be resolved at the requirement stage of the development. In this paper, we propose an enhancement of requirement analysis method found in literatures such that it includes activities to resolve the key elements. The method has been applied in three case studies based on Indonesia situations and we conclude that it is suitable to be adopted by SMEs. KEYWORDS Software Requirements Analysis, E-Commerce Website Development, Resolving Key Elements of E- Commerce Business Model 1. INTRODUCTION It is well recognized that small-medium enterprises (SMEs) are significant to the worldwide socio-economic development. It is even viewed that SMEs are the backbone of the economy. SMEs have also contributed significantly in higher growth of employment, output, promotion of exports, and fostering entrepreneurship [5, 7].
    [Show full text]
  • Requirements and Design for Dependable Systems
    COURSE DESCRIPTION – ACADEMIC YEAR 2019/2020 Course title Requirements and Design for Dependable Systems Course code 76052 Scientific sector INF/01 Degree Master in Software Engineering for Information Systems (LM-18) Semester 1 Year 1 Credits 6 Modular No Total lecturing hours 40 Total exercise hours 20 Not compulsory. Non-attending students have to contact the lecturer Attendance at the start of the course to agree on the modalities of the independent study. Prerequisites Basic courses in Programming and Software Engineering. Familiarity with UML and software modelling. Course page https://ole.unibz.it/ Specific educational The course belongs to the type caratterizzanti – discipline informatiche objectives and is part of the Foundations in Software Engineering. The course objective is to familiarize students with tools and techniques to acquire and analyze software requirements, and to define and design a software-based system with the focus on dependability as the key concern. Emphasis is given to traceability of requirements to architecture, to justification of design decisions based on collected requirements, to consequences of design decisions for dependable systems. Students will acquire skills and competencies resulting from the conception, negotiation, documentation and maintenance of dependability requirements in a specific domain and environment. Requirements analysis aims at reviewing, assessing, prioritizing, and balancing the requirements by developing technical specifications (functional and non-functional) for building a system that will meet the needs of the stakeholders. The design of dependable software- based systems aims at identifying or building software components that define the characteristics and quality of such a system. The students are exposed to problem-solving techniques that allow the synthesis of software solutions satisfying the requirements of the system.
    [Show full text]
  • A Tutorial for Requirements Analysis
    Project Scope Management Prof. Dr. Daning Hu Department of Informatics University of Zurich Some of the contents are adapted from “System Analysis and Design” by Dennis, Wixom, &Tegarden. Course Review: What do Project Managers Manage? The Triple Constraint of Project Management •Scope &Quality •Time •Cost 2 Course Review: Project Objectives Scope & Quality (fitness for purpose) Budget (to complete it within the budget) Time (to complete it within the given time) It is clear that these objectives are not in harmony! 3 3 Course Review: Requirements Analysis and System Specification Why is it one of first activities in (software) project life cycle? Need to understand what customer wants first! Goal is to understand the customer’s problem. Though customer may not fully understand it! Requirements analysis says: “Make a list of the guidelines we will use to know when the job is done and the customer is satisfied.” Also called requirements gathering or requirements engineering System specification says: “Here’s a description of what the program/system will do (not how) to satisfy the requirements.” Distinguish requirements gathering & system analysis? A top-level exploration into the problem and discovery of whether it can be done and how long it will take. 4 Learning Objectives: Project Scope Management Explain what scope management is and the related processes Discuss methods for collecting and documenting requirements Explain the scope definition process and describe the contents of a Project Scope Statement Discuss the process of constructing a Work Breakdown Structure (WBS) using various approaches Explain the importance of scope verification and control and how to avoid scope problems 5 What is Project Scope Management? Scope refers to all the work involved in creating the products of the project and the processes used to create them.
    [Show full text]