Lecture 6: Requirements Engineering
|
|
- Lynette Ursula Watkins
- 5 years ago
- Views:
Transcription
1 Lecture 6: Requirements Engineering Software System Design and Implementation ITCS/ITIS 6112/ Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Sept. 11, 2008
2 Classification of Requirements Functional vs. non-functional domain User vs. System 2
3 Goals vs. Non-functional Requirements Difficult to state non-functional requirements precisely Imprecise requirements are difficult to verify! May result in expression of a goal A general intention of the user e.g., ease of use, reasonable performance, maintainability Want verifiable non-functional requirements Using some measure that can be objectively tested Quantifiable! Goals can help convey the intentions of the system users Should warn user that difficult to validate 3
4 Examples A system goal The system should be easy to use by experienced air traffic controllers and should be organized in such a way that user errors are minimized. A verifiable non-functional requirement Experienced air traffic controllers shall be able to use all the system functions after a total of two hours training; after this training, the average number of errors made by experienced users shall not exceed two per day. 4
5 Turning Goals into Requirements: System Property Metrics Property Speed Size Ease of use Reliability Robustness Portability Measure Processed transactions/second User/Event response time Screen refresh time M Bytes Number of ROM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems 5
6 Non-functional Requirements Interaction Conflicts between different non-functional requirements are common Spacecraft system To minimize weight, the number of separate chips in the system should be minimized. To minimize power consumption, lower power chips should be used. Conflict! Why? Which is most critical? 6
7 Domain Requirements Describe system characteristics and features that reflect application domain May be new functional or non-functional requirements May be constraints on existing requirements May define specific computations If domain requirements are not satisfied, the system may be unworkable! Why do we separate these kinds of requirements out? Reuse! 7
8 Domain Requirements Example: Train Protection System The deceleration of the train shall be computed as: D train = D control + D gradient where D gradient = 9.81m/s 2 * compensated gradient/alpha and where the values of 9.81ms 2 /alpha are known for different types of trains. 8
9 Domain Requirements Issues Understandability Requirements expressed in language of the application domain (jargon) Not understood by software engineers developing the system Implicitness Domain specialists do not make domain requirements explicit 9
10 Classification of Requirements Functional vs. non-functional User vs. System 10
11 User Requirements Describe both functional and non-functional requirements in a way understandable to system users Example The software must provide a means of representing and accessing external files created by other tools 11
12 System Requirements More detailed specifications of system functions services constraints Intended as basis for designing the system Example The user should be provided with facilities to define the type of external file Each external file type may have an associated tool which may be applied to the file Each external file type may be represented as a specific icon When a user selects an icon representing an external file, the effect is to apply the tool associated with the type of external file to the file represented by the selected icon 12
13 Requirements Engineering Activities Inception Elicitation Elaboration/Analysis Negotiation Specification Validation 13
14 Inception Goal is to develop a very basic understanding of: Problem People that want a solution Nature of desired solution Effectiveness of initial communication between customer and developer Results in Statement of business need for software to be developed Feasibility of developing software 14
15 Inception Actions Identify stakeholders Anyone that benefits from system to be developed Typical examples Marketing Customer End-user Software engineers Identify and organize viewpoints Further classify stakeholders according to perspectives Broadly: Interactor Indirect Domain 15
16 Viewpoint Example Interactor Indirect Domain Library manager Finance Publishers User Faculty Student Library staff Classification standards Copyright regulations 16
17 Inception Actions (2) Ask context-free questions: Regarding stakeholders Who requested this system? Who will use it? What is the economic benefit? Is there another source for the desired solution? Regarding the problem What would be good output generated by the solution? What problem does the solution address? What kind of business environment will this be used in? Are there performance issues or constraints? 17
18 Inception Actions (3) Ask context-free questions: Regarding communication Are you the right person to answer these questions? Is this answer official? Are my questions relevant? Can anyone else provide additional information? Should I be asking you anything else? 18
19 Requirements Engineering Activities Inception Elicitation Elaboration/Analysis Negotiation Specification Validation 19
20 Elicitation Goal is to understand the system that is to be developed More specific information is elicited from the stakeholders Approaches to elicitation Research Observation Documentation studies Comparative product studies Guided Meetings Interview Focus groups Elicitation workshops Prototype demonstrations Scenarios and Use Cases More detailed and pointed questions May propose some services, features 20
21 Scenarios Real-life examples of how a system can be used They should include A description of the involved stakeholders A description of the starting situation A description of the normal flow of events A description of what can go wrong Information about other concurrent activities A description of the state when the scenario finishes 21
22 Scenario Example Ask the SafeHome user: How would you use the home security function? 22
23 Use Cases Scenario-based descriptions of how an actor interacts with the system Actor (UML terminology) Represents role people or device play when using the system External to system (system is not an actor) Captures functional requirements Captures functional requirements Abstraction of a scenario A scenario is one specific path Use case captures multiple related paths of interaction Serve as basis for developing more detailed models Supports traceability of requirements and design 23
24 Capturing Use Cases Two forms of use case specification Full textual description Name Actors Preconditions Trigger Scenario Description Exceptions (a.k.a. Extensions) Postconditions Associated non-functional requirements (optional) UML graphical description We ll see this later 24
25 Use Case Example Ask the SafeHome user: How would you use the home security function? 25
26 Requirements Engineering Activities Inception Elicitation Elaboration/Analysis Negotiation Specification Validation 26
27 Elaboration/Analysis Refine models of requirements Organize requirements according to: Stakeholders Viewpoints Service Preliminary decomposition of the system Prioritize requirements (and risks) Update cost estimates Negotiate requirements Customers may ask for more than can be achieved Prioritization information may be in conflict 27
28 Requirements Engineering Activities Inception Elicitation Elaboration/Analysis Negotiation Specification Validation 28
29 Approaches to Specifying Requirements Structured natural language Rules guide specification of requirements Graphical modeling notations Easy to understand graphical representations Mathematical specifications Based on mathematical concepts such as sets or finite state machines 29
30 Problems with Natural Language Ambiguity Readers and writers of the requirement must interpret the same words in the same way Over-flexibility The same thing may be said in a number of different ways Lack of modularization Natural language structures doesn t capture hierarchical requirement relationships 30
31 Guidelines for Using Structured Natural Language Rules for writing user and system requirements: Use standard structured format Write complete, simple sentences Use active voice Define terms, use them consistently Group related requirements hierarchically Express all requirements using must or shall Write requirements in a verifiable manner Write atomic requirements States a single product function, feature, or characteristic Helps with requirements traceability 31
32 Structured Natural Language for Scenarios Rules for writing scenarios: All of the previous rules Format: Initial assumption Normal execution Exceptional execution State on completion 32
33 Structured Natural Language for Use Cases Rules for writing scenarios: All of the previous natural language rules Format: Use-Case Name Actors Pre-conditions Post-conditions Trigger Basic Flow Extensions Non-functional Requirements 33
34 Use Cases with UML Basic Notation Bank Customer Withdraw Money More on use cases and UML use case notation coming soon 34
35 Requirements Engineering Activities Inception Elicitation Elaboration/Analysis Negotiation Specification Validation 35
Lecture 8 Requirements Engineering
Lecture 8 Requirements Engineering Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 18, 2008 Lecture Overview
More informationLecture 9 Requirements Engineering II
Lecture 9 Requirements Engineering II Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 23, 2008 Announcements
More informationIan Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 1
Software Requirements Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 1 Objectives To introduce the concepts of user and system requirements To describe functional and non-functional
More informationSE351a: Software Project & Process Management. 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa
SE351a: Software Project & Process Management W4.1: Requirements Engineering 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa SE351 Roadmap Introduction to Software Project Management Project Management
More informationRequirements Engineering. Version October 2016
Requirements Engineering Version 1.11 26 October 2016 Maurizio Morisio, Marco Torchiano, 2016 Software development Customer Needs Acceptance testing Requirements Analysis System testing System Design Integration
More informationRequirements. Requirements. Types of Requirement. What Is a Requirement?
Beatrice Åkerblom beatrice@dsv.su.se Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan... What Is a Requirement?!
More informationSoftware Engineering. Lecture 10
Software Engineering Lecture 10 1. What is software? Computer programs and associated documentation. Software products may be: -Generic - developed to be sold to a range of different customers - Bespoke
More informationRequirements Engineering. Establishing what the customer requires from a software system. Requirements Engineering. What is a Requirement?
Engineering Establishing what the customer requires from a software system Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 5 and 6 Slide 1 Engineering
More informationRequirements Engineering: Specification & Validation. Software Requirements and Design CITS 4401 Lecture 18
Requirements Engineering: Specification & Validation Software Requirements and Design CITS 4401 Lecture 18 The Problems of Requirements What goal(s) are we trying to satisfy? How do we identify the scope
More informationCh 4: Requirements Engineering. What are requirements?
Ch 4: Engineering What are? Functional and non-functional The software document specification engineering processes elicitation and analysis validation management The descriptions of what the system should
More informationChapter 4 Requirements Engineering
Chapter 4 Requirements Engineering Chapter 4 Requirements Engineering Slide 1 Topics covered Why RE is hard... Functional and non-functional requirements Product vs. organizational vs. external requirements
More informationRequirements engineering
engineering Chapter 4 1 Engineering in the textbook 4.1 Functional and non-functional 4.2 The software document 4.4 engineering processes 4.5 elicitation and analysis 4.3 specification 4.6 validation 4.7
More informationSoftware Requirements and the Requirements Engineering Process. Chapters 5 and 6
Software Requirements and the Requirements Engineering Process Chapters 5 and 6 References Software Engineering. Ian Sommerville. 6th edition. Pearson. Code Complete. Steve McConnell. (CC) The art of triage.
More informationNatural Language Specification
REQUIREMENTS ENGINEERING LECTURE 2017/2018 Dr. Jörg Dörr Natural Language Specification Most Requirements are Described in Natural Language Free Text (Prose) In Word In Excel (Tabular) In RM-Tools In Sys-ML
More informationSoftware specification and modelling. Requirements engineering
Software specification and modelling Requirements engineering Requirements engineering (RE) Requirements engineering is the process of establishing the services that a customer requires from a system and
More informationLecture 17 Engineering Design Resolution: Generating and Evaluating Architectures
Lecture 17 Engineering Design Resolution: Generating and Evaluating Architectures Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at
More informationLecture 16: (Architecture IV)
Lecture 16: (Architecture IV) Software System Design and Implementation ITCS/ITIS 6112/8112 091 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Oct.
More informationRequirement Analysis
Requirement Analysis Requirements Analysis & Specification Objective: determine what the system must do to solve the problem (without describing how) Done by Analyst (also called Requirements Analyst)
More informationVragen. Use case analysis. Use-Cases: describing how the user will Use cases
Vragen Use case analysis Welke problemen kunnen optreden bij het expliciet maken van het impliciete model bij conceptueel modelleren? Wat is het doel van elicitatie? Noem een aantal elicitatie technieken?
More informationScenario-Based Analysis. Scenario-Based Analysis (example) Form analysis
Scenario-Based Analysis Scenario-Based Analysis (example) Provides a more user-oriented view perspective on the design and development of an interactive system. The defining property of a scenario is that
More informationLecture 13 Introduction to Software Architecture
Lecture 13 Introduction to Software Architecture Software Systems Design and Implementation ITCS/ITIS 6112/8112 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at
More informationSEG3201 Basics of the Requirements Process
SEG3201 Basics of the Requirements Process Based on material from: I Bray: An introduction to Requirements Engineering Gerald Kotonya and Ian Sommerville: Requirements Engineering Processes and Techniques,
More informationcopyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Software Engineering: A Practitioner s Approach, 6/e Chapter 7 Requirements Engineering copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student
More informationLecture 8: Goals and Scenarios. Pohl K., Requirements Engineering: Fundamentals, Principles, and Techniques, Springer, 2010, 814p.
Lecture 8: Goals and Scenarios Pohl K., Requirements Engineering: Fundamentals, Principles, and Techniques, Springer, 2010, 814p. 2 Documenting Goals 3 Documenting Goals 1. Each goal must have a unique
More informationUNIT-II REQUIREMENTS ANALYSIS AND SPECIFICATION
UNIT-II REQUIREMENTS ANALYSIS AND SPECIFICATION The for a system are the descriptions of what the system should do the services that it provides and the constraints on its operation. User are statements,
More informationLesson 06. Requirement Engineering Processes
Lesson 06 Requirement Engineering Processes W.C.Uduwela Department of Mathematics and Computer Science Objectives To describe the principal requirements engineering activities and their relationships To
More informationQuality Software Requirements By J. Chris Gibson
Quality Software Requirements By J. Chris Gibson The information contained within this document has been gathered from a variety of sources and practices observed by the development team at Protera Software
More informationSofware Requirements Engineeing
Sofware Requirements Engineeing Three main tasks in RE: 1 Elicit find out what the customers really want. Identify stakeholders, their goals and viewpoints. 2 Document write it down (Requirements Specification).
More informationRequirements Validation and Negotiation
REQUIREMENTS ENGINEERING LECTURE 2015/2016 Eddy Groen Requirements Validation and Negotiation AGENDA Fundamentals of Requirements Validation Fundamentals of Requirements Negotiation Quality Aspects of
More informationLecture 4: Goals and Scenarios. System context. Usage facet. IT system facet. Core activities. Negotiation. Requirements artefacts
Lecture 4: Goals and Scenarios Stakeholders Identifying the problem owners Goals Identifying the success criteria Scenarios Identifying how it works 1 System context Subject facet Usage facet IT system
More informationIntroduction to Software Specifications and Data Flow Diagrams. Neelam Gupta The University of Arizona
Introduction to Software Specifications and Data Flow Diagrams Neelam Gupta The University of Arizona Specification A broad term that means definition Used at different stages of software development for
More informationRequirements Validation and Negotiation
REQUIREMENTS ENGINEERING LECTURE 2017/2018 Joerg Doerr Requirements Validation and Negotiation AGENDA Fundamentals of Requirements Validation Fundamentals of Requirements Negotiation Quality Aspects of
More informationFundamentals: Software Engineering. Objectives. Last lectures. Unit 2: Light Introduction to Requirements Engineering
Fundamentals: Software Engineering Dr. Rami Bahsoon School of Computer Science University of Birmingham r.bahsoon@cs.bham.ac.uk Unit 2: Light Introduction to Requirements Engineering Dr R Bahsoon 1 Objectives
More informationREQUIREMENTS. Michael Weintraub Spring, 2016
REQUIREMENTS Michael Weintraub Spring, 2016 Unit Objective Understand what requirements are Understand how to acquire, express, validate and manage requirements Definitions A thing demanded or obligatory
More informationREQUIREMENTS ENGINEERING LECTURE 2017/2018. Dr. Jörg Dörr. Conceptual Modelling. Fraunhofer IESE
REQUIREMENTS ENGINEERING LECTURE 2017/2018 Dr. Jörg Dörr Conceptual Modelling AGENDA Analysis & Specification with Conceptual Models 2 Requirements Specification ANALYSIS & SPECIFICATION WITH CONCEPTUAL
More informationDarshan Institute of Engineering & Technology for Diploma Studies
REQUIREMENTS GATHERING AND ANALYSIS The analyst starts requirement gathering activity by collecting all information that could be useful to develop system. In practice it is very difficult to gather all
More informationRequirements Engineering
Dr. Michael Eichberg Software Engineering Department of Computer Science Technische Universität Darmstadt Software Engineering Engineering The following slides are primarily based on the contents of the
More informationLecture 19 Engineering Design Resolution: Generating and Evaluating Architectures
Lecture 19 Engineering Design Resolution: Generating and Evaluating Architectures Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at
More informationSOFT 423: Software Requirements
SOFT 423: Software Requirements Week 1 Class 3 Requirements Process SOFT 423 Winter 2015 1 Last Class What are Requirements Requirements Eng vs. System Analysis Requirements Eng vs. Design Classes of Custom
More informationPESIT Bangalore South Campus Hosur road, 1km before Electronic City, Bengaluru -100 Department of MCA
USN 1 P E PESIT Bangalore South Campus Hosur road, 1km before Electronic City, Bengaluru -100 Department of CA INTERNAL ASSESSENT TEST II Date : 20/09/2016 ax.arks: 50 Subject & Code: Software Engineering
More informationRequirements Engineering. Version November 2012
Requirements Engineering Version 1.8 11 November 2012 Maurizio Morisio, Marco Torchiano, 2012 Attribution-NonCommercial-NoDerivs 2.5 You are free: to copy, distribute, display, and perform the work Under
More informationModeling Issues Modeling Enterprises. Modeling
Modeling Issues Modeling Enterprises SE502: Software Requirements Engineering Modeling Modeling can guide elicitation: It can help you figure out what questions to ask It can help to surface hidden requirements
More informationSE351a: Software Project & Process Management. 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa
SE351a: Software Project & Process Management W4.2: Requirements Engineering 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa SE351 Roadmap Introduction to Software Project Management Project Management
More informationRequirements Engineering. Csaba Veres
Requirements Engineering Csaba Veres utline What is requirements engineering? Why is it important? How can you do it (properly)? an Requirements engineering, P11 overview quality evaluation (validation)
More informationRequirements. CxOne Standard
Requirements CxOne Standard CxStand_Requirements.doc November 3, 2002 Advancing the Art and Science of Commercial Software Engineering Contents 1 INTRODUCTION... 1 1.1 OVERVIEW... 1 1.2 GOALS... 1 1.3
More informationRestricted Use Case Modeling Approach
RUCM TAO YUE tao@simula.no Simula Research Laboratory Restricted Use Case Modeling Approach User Manual April 2010 Preface Use case modeling is commonly applied to document requirements. Restricted Use
More informationSystem context. Usage facet. IT system facet. Core activities
System context Subject facet Usage facet IT system facet Development facet Validation Core activities Observe Documentation the system context to Elicitation detect context changes Manage the execution
More informationTopic # 03. Requirements to Software System: An Overview (Ch. 5 and partially Ch. 6)
Topic # 03 Requirements to Software System: An Overview (Ch. 5 and partially Ch. 6) 1 Understanding Requirements: An Overview This topic is an overview of Requirements Engineering (RE), and RE is the initial
More informationChapter 1: Programming Principles
Chapter 1: Programming Principles Object Oriented Analysis and Design Abstraction and information hiding Object oriented programming principles Unified Modeling Language Software life-cycle models Key
More informationSoftware architecture in ASPICE and Even-André Karlsson
Software architecture in ASPICE and 26262 Even-André Karlsson Agenda Overall comparison (3 min) Why is the architecture documentation difficult? (2 min) ASPICE requirements (8 min) 26262 requirements (12
More informationChapter 1: Principles of Programming and Software Engineering
Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without
More informationSoftware Engineering Unit 4- Requirement Analysis and Specification
Software Engineering Unit 4- Requirement Analysis and Specification Requirement Engineering The process to gather the software requirements from client, analyze and document them is known as requirement
More informationRequirements Elicitation
Requirements Elicitation Introduction into Software Engineering Lecture 4 25. April 2007 Bernd Bruegge Applied Software Engineering Technische Universitaet Muenchen 1 Outline Motivation: Software Lifecycle
More informationOutline of UML and Unified Process. Object Oriented Analysis/Design/Programming UML1.5. Koichiro Ochimizu, JAIST. UML&UP outline 1.
Outline of UML and Unified Process Koichiro OCHIMIZU School of Information Science JAIST Schedule Feb. 27th 13:00 Scope and Goal 14:30 Basic Concepts on Representing the World (object, class, association,
More informationSRM ARTS AND SCIENCE COLLEGE SRM NAGAR, KATTANKULATHUR
SRM ARTS AND SCIENCE COLLEGE SRM NAGAR, KATTANKULATHUR 603203 DEPARTMENT OF COMPUTER SCIENCE & APPLICATIONS QUESTION BANK (2017-2018) Course / Branch : M.Sc-CST Semester / Year : Even / II Subject Name
More informationRequirements Engineering
Requirements Engineering An introduction to requirements engineering Gerald Kotonya and Ian Sommerville G. Kotonya and I. Sommerville 1998 Slide 1 Objectives To introduce the notion of system requirements
More informationSoftware Design Models, Tools & Processes. Lecture 2: Inception Phase Cecilia Mascolo
Software Design Models, Tools & Processes Lecture 2: Inception Phase Cecilia Mascolo Inception Phase This is the phase when most of the system requirements are identified. Discover and reach agreement
More informationCS3205: Task Analysis and Techniques
CS3205: Task Analysis and Techniques CS3205: Task Analysis and Techniques Readings (same as before): 1) ID-Book Chapter Establishing Requirements, Ch. 10 (Ch. 9 in course ebook) 2) Chapter 2 from Task-Centered
More information350 Index 2005 GOAL/QPC
Index abstract testing, 274 acceptance criteria, 270 acceptance tests, 270 activity diagrams, 113, 114, 174-175, 321 actor catalog, 144 actor description, 144 actor hierarchy, 148 actor map, 59, 114, 144,
More informationOutline of Unified Process
Outline of Unified Process Koichiro OCHIMIZU School of Information Science JAIST Schedule(3/3) March 12 13:00 Unified Process and COMET 14:30 Case Study of Elevator Control System (problem definition,
More informationSoftware Architecture
Software Architecture Does software architecture global design?, architect designer? Overview What is it, why bother? Architecture Design Viewpoints and view models Architectural styles Architecture asssessment
More informationCIS 890: Safety Critical Systems
CIS 890: Safety Critical Systems Lecture: Requirements Introduction Copyright 2011, John Hatcliff. The syllabus and all lectures for this course are copyrighted materials and may not be used in other course
More informationLecture 5 Safety Analysis FHA, HAZOP
Lecture 5 Safety Analysis FHA, HAZOP Introduction While designing a safety-critical system usually several safety analysis techniques are applied The idea is to achieve completeness of safety requirements,
More informationAn end-user s perspective What system? I haven t seen a new system
References 1. Object-Oriented Software Engineering---Practical software development using UML and Java, T.C. Lethbridge and R. Laganiere, McGraw-Hill, 2005. 2. Object-Oriented Systems Analysis and Design
More informationSoftware Architecture. Lecture 5
Software Architecture Lecture 5 Roadmap of the course What is software architecture? Designing Software Architecture Requirements: quality attributes or qualities How to achieve requirements : tactics
More informationRequirements Validation and Negotiation (cont d)
REQUIREMENTS ENGINEERING LECTURE 2017/2018 Joerg Doerr Requirements Validation and Negotiation (cont d) REQUIREMENTS VALIDATION AND NEGOTIATION Requirements Validation Techniques 2 Techniques Overview
More informationMei Nagappan. How the programmer wrote it. How the project leader understood it. How the customer explained it. How the project leader understood it
Material and some slide content from: - Software Architecture: Foundations, Theory, and Practice - Elisa Baniassad - Reid Holmes How the customer explained it How the project leader understood it How the
More informationAC63/AT63/AC114/AT114 SOFTWARE ENGINEERING DEC 2015
Q.2 a. What is System Engineering? Explain in detail. (12) Systems engineering is the activity of specifying, designing, implementing, validating, deploying and maintaining socio technical systems. Concerned
More informationIntroduction to Software Engineering
Introduction to Software Engineering Gérald Monard Ecole GDR CORREL - April 16, 2013 www.monard.info Bibliography Software Engineering, 9th ed. (I. Sommerville, 2010, Pearson) Conduite de projets informatiques,
More informationSoftware Engineering I (02161)
Software Engineering I (02161) Week 2 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2017 Contents What are software requirements? Requirements Engineering Process Domain
More informationXIV. The Requirements Specification Document (RSD)
XIV. The Requirements Specification Document (RSD) What is a RSD? What to include/not include in a RSD? Attributes of a Well-Written RSD Organization of a RSD Sample Table of Contents An Example 2002 John
More informationUnit 1 Introduction to Software Engineering
Unit 1 Introduction to Software Engineering João M. Fernandes Universidade do Minho Portugal Contents 1. Software Engineering 2. Software Requirements 3. Software Design 2/50 Software Engineering Engineering
More informationProduct. e ss. P roc. so get the right requirements. Garbage in garbage out,
If software is simply for automation, what would a washing machine be like? 1 RE Process Lawrence Chung Department of Computer Science The University of Texas at Dallas 2 RE Process: What is a Process?
More informationAdministrivia. Wednesday: Requirements and Specification. CS169 Lecture 4. We assign teams and you start on Monday. Determining Stakeholders and Needs
Administrivia Requirements and Specification CS169 Lecture 4 Wednesday: Groups and one-sentence idea(s) due at class One per group If you have a small group, still submit so that you will be kept together.
More informationLecture 5 STRUCTURED ANALYSIS. PB007 So(ware Engineering I Faculty of Informa:cs, Masaryk University Fall Bühnová, Sochor, Ráček
Lecture 5 STRUCTURED ANALYSIS PB007 So(ware Engineering I Faculty of Informa:cs, Masaryk University Fall 2015 1 Outline ² Yourdon Modern Structured Analysis (YMSA) Context diagram (CD) Data flow diagram
More informationSoftware Architectures. Lecture 6 (part 1)
Software Architectures Lecture 6 (part 1) 2 Roadmap of the course What is software architecture? Designing Software Architecture Requirements: quality attributes or qualities How to achieve requirements
More informationQuality Software Requirements By J. Chris Gibson
Quality Software Requirements By J. Chris Gibson It has been stated that deficiencies in software requirements are the leading cause of failure in software projects. 1 If this is true then the contrapositive
More informationRefresher: Lifecycle models. Lecture 22: Moving into Design. Analysis vs. Design. Refresher: different worlds. Analysis vs. Design.
Analysis vs. Design Why the distinction? Design Processes Logical vs. Physical Design System vs. Detailed Design Architectures System Architecture Software Architecture Architectural Patterns (next lecture)
More informationMethods for building a knowledge base for automatic communication in shipping
Scientific Journals of the Maritime University of Szczecin Zeszyty Naukowe Akademii Morskiej w Szczecinie 2016, 47 (119), 176 180 ISSN 1733-8670 (Printed) Received: 29.04.2016 ISSN 2392-0378 (Online) Accepted:
More information1: Specifying Requirements with Use Case Diagrams
Outline UML Design Supplement 1: Specifying Requirements with Use Case Diagrams Introduction Use Case Diagrams Writing Use Cases Guidelines for Effective Use Cases Slide adapted from Eran Toch s lecture
More informationThe software lifecycle and its documents
The software lifecycle and its documents Supplementary material for Software Architecture course B. Meyer, May 2006 Lifecycle models Origin: Royce, 1970, Waterfall model Scope: describe the set of processes
More informationRules of Writing Software Requirement Specifications
Short Note. Version 1a, FGCU April 10, 2018 A properly written Software Requirements Specification should adhere to a number of rules that can be expressed as matching the following properties: 1) Clarity
More informationDrexel Chatbot Requirements Specification
Drexel Chatbot Requirements Specification Hoa Vu Tom Amon Daniel Fitzick Aaron Campbell Nanxi Zhang Shishir
More informationAuthors: Andrei Kapustin, Vadim Chirikov, Marina Farr Cybernetic Intelligence GmbH, Zug, Switzerland Requirement analysis: Methodology
Authors: Andrei Kapustin, Vadim Chirikov, Marina Farr Cybernetic Intelligence GmbH, Zug, Switzerland Requirement analysis: Methodology P-RAM-2002-10-1-0 September 10, 2002 Contents CONTENTS...2 1 OVERVIEW...4
More informationLecture 5: Requirements Specifications
Lecture 5: Requirements Specifications Why we need to write specifications Purpose and audience Choosing an appropriate size and formality Desiderata for Specifications Properties of good specifications
More informationSecurity Engineering for Software
Security Engineering for Software CS996 CISM Jia An Chen 03/31/04 Current State of Software Security Fundamental lack of planning for security Most security issues come to light only after completion of
More informationRecommended Practice for Software Requirements Specifications (IEEE)
Recommended Practice for Software Requirements Specifications (IEEE) Author: John Doe Revision: 29/Dec/11 Abstract: The content and qualities of a good software requirements specification (SRS) are described
More informationSE 1: Software Requirements Specification and Analysis
SE 1: Software Requirements Specification and Analysis Lecture 4: Basic Notations Nancy Day, Davor Svetinović http://www.student.cs.uwaterloo.ca/ cs445/winter2006 uw.cs.cs445 U Waterloo SE1 (Winter 2006)
More informationUse C ases Cases 7/09
Use Cases 7/09 Groups of 3 Recorder/Timekeeper Participation checker Devil s Advocate Motivation One way to describe a system is to create a story, y, the interaction between a user and the system This
More informationBusiness Analysis for Practitioners - Requirements Elicitation and Analysis (Domain 3)
Business Analysis for Practitioners - Requirements Elicitation and Analysis (Domain 3) COURSE STRUCTURE Introduction to Business Analysis Module 1 Needs Assessment Module 2 Business Analysis Planning Module
More informationVETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS6403 SOFTWARE ENGINEERING II year/ IV sem CSE (Regulation 2013) UNIT 1- SOFTWARE PROCESS AND PROJECT
More informationRE Process. Lawrence Chung Department of Computer Science The University of Texas at Dallas
1 RE Process Lawrence Chung Department of Computer Science The University of Texas at Dallas 2 RE Process: What is a Process? Given input, transforms it into output Consist of a set of activities Process
More informationUNIT-4 Behavioral Diagrams
UNIT-4 Behavioral Diagrams P. P. Mahale Behavioral Diagrams Use Case Diagram high-level behaviors of the system, user goals, external entities: actors Sequence Diagram focus on time ordering of messages
More informationLecture 8: Use Case -Driven Design. Where UML fits in
Lecture 8: Use Case -Driven Design The Role of UML in the Software Process E.g. ICONIX Domain Models Use Cases 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution
More informationUnified Modeling Language - UML
Eshcar Hillel Unified Modeling Language - UML A specification language for object modeling Industry-standard Simplifies the complex process of design Create a "blueprint" for construction Visualize the
More informationPrototyping. Lecture # 21
Prototyping Lecture # 21 1 Prototyping It is the technique of constructing a partial implementation of a system so that customers, users, or developers can learn more about a problem or a solution to that
More informationSynergy Distributed Meeting Scheduler. Project Plan. Revision 2.0. CS 6361 Advance Requirements Engineering Fall 2008
Synergy Distributed Meeting Scheduler Project Plan Revision 2.0 CS 6361 Advance Requirements Engineering Fall 2008 Team Members: Name Email Phone Student ID Animesh Roy animesh.roy@student.utdallas.edu
More informationTonight s Agenda. CSC340: Requirements Engineering. Course Objectives. Requirements Engineering. Software Engineering. What is Software Engineering?
Tonight s Agenda CSC340: Engineering Jennifer Campbell Lecturer Part 1 Introduction to course content Course information Changes to the SE courses/program Part 2 What are requirements? CSC340 University
More informationCS350 Lecture 2 Requirements Engineering. Doo-Hwan Bae
CS350 Lecture 2 Requirements Engineering Doo-Hwan Bae bae@se.kaist.ac.kr Contents Overview of Requirements Engineering OO Analysis: Domain modeling, Use-case, sequence, class Structured Analysis: Dataflow
More informationSE 2730 Final Review
SE 2730 Final Review 1. Introduction 1) What is software: programs, associated documentations and data 2) Three types of software products: generic, custom, semi-custom Why is semi-custom product more
More information