Administrivia. Wednesday: Requirements and Specification. CS169 Lecture 4. We assign teams and you start on Monday. Determining Stakeholders and Needs
|
|
- Donna Rose
- 5 years ago
- Views:
Transcription
1 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. (better to find 6 people) We assign teams and you start on Monday Prof. Brewer CS 169 Lecture 4 1 Prof. Brewer CS 169 Lecture 4 2 Requirements Engineering The hardest single part of building a software system is deciding what to build Cripples the process if done wrong Costly to rectify later Must be adopted to the software process Elaborate requirements/specs for waterfall Partial set of user stories for iterative processes Determining Stakeholders and Needs Must determine stakeholders anyone who benefits from the system developed E.g., who s client and who s user? Try to understand what their needs are Reconcile different needs/points of view Prof. Brewer CS 169 Lecture 4 3 Prof. Brewer CS 169 Lecture 4 4 Techniques Interviewing User stories Strawmen Prototypes Interviewing One path is obvious Sit down with client/user and ask questions Listen to what they say, and don t say A less obvious path Master-apprentice relationship Have them teach you what they do Go to workplace and watch them do the task In all types of interviews, get details Ask for copies of reports, logs, s on process These may support, fill in, or contradict what the user said Prof. Brewer CS 169 Lecture 4 5 Prof. Brewer CS 169 Lecture 4 6 1
2 Extreme Programming User Stories Recall: client writes user stories Using client vocabulary Describe usage scenarios of software Title, short description Each user story has acceptance tests Clarify the story Will tell you when the customer things story is done User Story Example Title: Delete account Actors: trusted operator Preconditions: account must be empty Trigger: operator selects menu option Scenario:, confirmation dialog box, Exceptions: account not empty, unknown user Priority: important, but not for first release Frequency of use: rare Prof. Brewer CS 169 Lecture 4 7 Prof. Brewer CS 169 Lecture 4 8 Disadvantages of Talking Interviews are useful, but I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! Users/clients may not Have the vocabulary to tell you what they need Know enough about computer science to understand what is possible Or impossible Strawmen Sketch the product for the user/client Storyboards Flowcharts HTML mock-ups Illustrate major events/interfaces/actions Anything to convey ideas without writing code! Good idea to gather requirements in other ways, too Prof. Brewer CS 169 Lecture 4 9 Prof. Brewer CS 169 Lecture 4 10 Rapid Prototyping Write a prototype Major functionality, superficially implemented Falls down on moderate-to-extreme examples No investment in scaling, error handling, etc. Show prototype to users/clients Users have a real system more reliable feedback Refine requirements But, significant investment Prof. Brewer CS 169 Lecture
3 Pitfalls of Rapid Prototyping Needs to be done quickly Remember, this is just the requirements phase! Danger of spending too long refining prototype The prototype becomes the product Prototype deliberately not thoroughly thought-out Product will inherit the sub-optimal architecture Prototype serves as the spec Prototype is incomplete, maybe even contradictory When done well, extremely useful Summary of Requirements Find out what users/clients need Not necessarily what they say they want Use Interviews User stories Strawmen Rapid prototyping As appropriate... Prof. Brewer CS 169 Lecture 4 13 Prof. Brewer CS 169 Lecture 4 14 Specifications Describe the functionality of the product Precisely Covering all circumstances Move from the finite to the infinite Finite examples (requirements) to infinite set of possible computations This is not easy Views of Specifications Developer s Specification must be detailed enough to implement Unambiguous Self-consistent Client s/user s Specifications must be comprehensible Usually means: not too technical Legal Specification can be a contract Should include acceptance criteria If the software passes tests X, Y, and Z, it will be accepted Prof. Brewer CS 169 Lecture 4 15 Prof. Brewer CS 169 Lecture 4 16 Informal Specifications Written in natural language E.g., English Example and actual sales for the current month is under 5% Problems with Informal Specs Informal specs of any size inevitably suffer from serious problems Omissions Something missing Ambiguities Something open to multiple interpretations Contradictions Spec says do A and do not do A These problems will be faithfully implemented in the software unless found in the spec Prof. Brewer CS 169 Lecture 4 17 Prof. Brewer CS 169 Lecture
4 Informal Specifications Revisited Informal Specifications Revisited and actual sales for the current month is under 5% and actual sales for the current month is under 5% What are sales? Orders received but not yet paid for? Only orders paid for? Prof. Brewer CS 169 Lecture 4 19 Prof. Brewer CS 169 Lecture 4 20 Informal Specifications Revisited Informal Specifications Revisited and actual sales for the current month is under 5% Specification implies, but does not say, that there are monthly sales targets. Are there separate monthly targets, or is the monthly target e.g., 1/3 of the quarterly target? Prof. Brewer CS 169 Lecture 4 21 and actual sales for the current month is under 5% 5% of the target sales, or of the actual sales? Prof. Brewer CS 169 Lecture 4 22 Comments on Informal Specification Informal specification is universally reviled By academics By how to authors By respectable pundits Informal specification is also widely practiced Why? Why Do People Use Informal Specs? The common language is natural language Customers can t read formal specs Neither can most programmers Or most managers A least-common denominator effect takes hold Truly formal specs are very time-consuming And hard to understand And overkill for most projects Prof. Brewer CS 169 Lecture 4 23 Prof. Brewer CS 169 Lecture
5 Semi-Formal Specs Best current practice is semi-formal specs Allows more precision than natural language where desired Usually a boxes-and-arrows notation Must pay attention to: What boxes mean What arrows mean Different in different systems! Example 1: Dataflow Diagrams Old ideas Several competing models from the 70s Called Structured Systems Analysis We present one Others are similar 9 step procedure With refinements of each step Example: automating a software store Only show key steps Prof. Brewer CS 169 Lecture 4 25 Prof. Brewer CS 169 Lecture 4 26 Example: Data Flow Diagrams Step 1: Draw the DFD Show logical data flow what happens, not how it happens DOUBLE SQUARE Source or destination of data 1 st refinement (infinite # of implementations) PACKAGE DATA package details arrow Flow of data CUSTOMER order process orders rounded rectangle Process which transforms a flow of data invoice credit status OPEN-ENDED Store of data RECTANGLE Prof. Brewer CS 169 Lecture 4 27 CUSTOMER DATA Prof. Brewer CS 169 Lecture 4 28 Step 1: 2 nd refinement of DFD Step 1: Draw the DFD CUSTOMER PACKAGE DATA package details order verify order is valid credit status details of package to be ordered SOFTWARE SUPPLIER address or telephone number place order at software supplier batched order Final DFD gets larger & larger (pages) hopefully it can be understood by client Larger DFDs use hierarchy a box becomes DFD at lower level invoice CUSTOMER DATA PENDING ORDERS details of package on hand assemble orders Prof. Brewer CS 169 Lecture 4 29 Prof. Brewer CS 169 Lecture
6 Step 2: Decide What to Computerize Step 3: Refine Data Flows Spec so far says nothing about how steps are done could be a person looking up info on a card file Cost/benefit analysis could help decide this Further specify data items for each data flow Refine each flow stepwise order: order identification customer details package details Refine further this creates the data dictionary Prof. Brewer CS 169 Lecture 4 31 Prof. Brewer CS 169 Lecture 4 32 Step 4: Refine Logic of Processes Step 6: Define Physical Resources Have process give educational discount explain what this means 10% on up to 4 packages, 15% on 5 or more Translate into decision tree makes it easy to see what is missing give educational discount For each file figure out names Organization Sequential Indexed Database tables storage medium <= 4 packages: 10% Educational institution Other: 0% > 4 packages: 15% Prof. Brewer CS 169 Lecture 4 33 Prof. Brewer CS 169 Lecture 4 34 Step 7: Determine Input/Output Specs Specify UI Screens/Windows/Buttons/Menus Interactions output files created printed reports Steps 8 & 9: Perform Sizing & Hardware Requirements Look at volume of input (daily/hourly) size / frequency of reports size / number of records moving between CPU & storage size of files back-up requirements input needs output devices is existing hardware adequate? Prof. Brewer CS 169 Lecture 4 35 Prof. Brewer CS 169 Lecture
7 Entity-Relationship Diagrams Semi-formal technique Focuses on data rather than actions In contrast to dataflow diagrams Really comes out of database world Has crossed over into object-oriented analysis Author Finite State Machines Formal method State transitions Set of states Rules for moving between states Designated start and final states Safe Locked 1L 3R 2L A B Safe Unlocked 1 to many relationships 1 writes n Autobiography any other dial movement any other dial movement any other dial movement n reads n owns many to many relationships Initial state m m Reader Prof. Brewer CS 169 Lecture 4 37 Final state Prof. Brewer CS 169 Lecture 4 38 Finite State Machines Write out state transition tables Current State Safe Locked A B Dial Movement 1L 1R 2L 2R 3L 3R A B Safe Unlocked Prof. Brewer CS 169 Lecture 4 39 Finite State Machines Advantages more precise than DFDs easy to write down, validate, & convert into code some CASE tools directly generate code from FSMs makes maintenance easy -> changes spec & regenerate Disadvantages Lack of structure leads huge numbers of states fixed by Harel s Statecharts does not deal with timing issues Could use Petri nets Prof. Brewer CS 169 Lecture 4 40 Z ( zed ) Notation Formal specification language Most successful one Real skill required: set theory, functions & discrete math Z specifications consists of 4 sections given sets, data types, and constants sets that get defined in detail state definition variable declarations & predicates that constrain values initial state operations Example of Formal Specification Title: delete account named A by user U Precondition: A Accounts and U Trusted and Balance(A) = 0 Postcondition: if ConfirmDeleteDialogBox(A,U) then Accounts@after = Accounts { A } else Accounts@after = Accounts Notes: no need to consider the case when precondition is not true Prof. Brewer CS 169 Lecture 4 41 Prof. Brewer CS 169 Lecture
8 Comparison of Specification Techniques Formal methods powerful and precise difficult to learn & use could be useful where cost/safety/reliability is important computers can assist in the spec./code reviews Informal methods little power easy to learn and use Testing/Validating the Specification Specification inspection inspectors use a checklist of items to look for Are requirements clear? Can they be misinterpreted? Are all the cases handled? Are there inconsitencies? Is the requirement testable? Is the requirement traceable to project objectives? can also trace items back to requirements doc record faults found & rate of finding faults Can also measure convergence Have changes in the spec dropped below some threshold? Prof. Brewer CS 169 Lecture 4 43 Prof. Brewer CS 169 Lecture 4 44 Summary Specification document? explicitly defines functionality & constraints Ranges from informal to formal informal e.g., NL very ambiguous, but easy to understand semi-formal e.g., DFD, E-RDs easy to understand, but more precise formal e.g., FSMs, Z very precise & powerful, but hard to learn useful where safety or reliability is a concern Prof. Brewer CS 169 Lecture
Administrivia. Added 20 more so far. Software Process. Only one TA so far. CS169 Lecture 2. Start thinking about project proposal
Administrivia Software Process CS169 Lecture 2 Added 20 more so far Will limit enrollment to ~65 students Only one TA so far Start thinking about project proposal Bonus points for proposals that will be
More informationRequirements Engineering process
Requirements Engineering process Used to discover, analyze, validate and manage requirements Varies depending on the application domain, the people involved and the organization developing the requirements
More informationRequirements Engineering. Contents. Functional requirements. What is a requirement?
Contents Ø Introduction 4 Ø Engineering Ø Project Management Ø Software Design Ø Detailed Design and Coding Ø Quality Assurance Engineering Ø What is a Requirement? Ø RE Activities Ø Documentation Ø RE
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 informationSoftware Engineering Prof.N.L.Sarda IIT Bombay. Lecture-11 Data Modelling- ER diagrams, Mapping to relational model (Part -II)
Software Engineering Prof.N.L.Sarda IIT Bombay Lecture-11 Data Modelling- ER diagrams, Mapping to relational model (Part -II) We will continue our discussion on process modeling. In the previous lecture
More informationSoftware Engineering - I
Software Engineering - I An Introduction to Software Construction Techniques for Industrial Strength Software Chapter 3 Requirement Engineering Copy Rights Virtual University of Pakistan 1 Requirement
More informationLecture 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 informationCS3500: Object-Oriented Design Fall 2013
CS3500: Object-Oriented Design Fall 2013 Class 20 11.12.2013 Assignment 8 Due Friday, November 15, 2013 2 Software Process Phases of the Software Requirements Process Design Implementation Testing Maintenance
More informationRequirements. Chapter Learning objectives of this chapter. 2.2 Definition and syntax
Chapter 2 Requirements A requirement is a textual description of system behaviour. A requirement describes in plain text, usually English, what a system is expected to do. This is a basic technique much
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 informationHuman Error Taxonomy
Human Error Taxonomy The Human Error Taxonomy (HET) provides a structure for requirement errors made during the software development process. The HET can be employed during software inspection to help
More informationCS 4349 Lecture August 21st, 2017
CS 4349 Lecture August 21st, 2017 Main topics for #lecture include #administrivia, #algorithms, #asymptotic_notation. Welcome and Administrivia Hi, I m Kyle! Welcome to CS 4349. This a class about algorithms.
More informationSystem Analysis & design
Assiut University Faculty of Computers and Information System Analysis & design Year 2 Academic Year 2014/ 2015 Term (2) 5 A PICTURE IS WORTH A 1,000 WORDS A process model is a graphical way of representing
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 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 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 informationApplying ISO/IEC Quality Model to Quality Requirements Engineering on Critical Software
Applying ISO/IEC 9126-1 Quality Model to Quality Engineering on Critical Motoei AZUMA Department of Industrial and Management Systems Engineering School of Science and Engineering Waseda University azuma@azuma.mgmt.waseda.ac.jp
More informationChapter 4 Objectives
Chapter 4 Objectives Eliciting requirements from the customers Modeling requirements Reviewing requirements to ensure their quality Documenting requirements for use by the design and test teams 4.1 The
More informationData Process Modeling: Context Diagrams & Data Flow Diagrams (DFDs)
Introduction Data Process Modeling: Context Diagrams & Data Flow Diagrams (DFDs) MIS 374 When designing/building an information system for an organization, you should consider the following questions regarding
More informationStructured Analysis and Design
1 st Cut - Creating... 14:10 A Actors... 2:11 Additional Notations... 11:17 Alternative Names for the System... 13:15 Analysis - Overview... 1:9 Analysis and Design - Goals... 1:6 Analysis and Design -
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 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 information1. i. What are the 3 major components of a information system and show their relationship input output
Higher National Diploma in Information Technology First Year, Second semesterexamination-2011 IT2005: System Analysis and Design Answer Script No. of pages: 11 1. i. What are the 3 major components of
More informationCS 307: Software Engineering. Lecture 10: Software Design and Architecture
CS 307: Software Engineering Lecture 10: Software Design and Architecture Prof. Jeff Turkstra 2017 Dr. Jeffrey A. Turkstra 1 Announcements Discuss your product backlog in person or via email by Today Office
More information(Murlidhar Group of Institutions,Bhavnagar Road, Rajkot) by:-assit. Prof. Vijay Vora (SOOADM) MCA-III
Analysis Modeling What is Analysis Modeling? Analysis modeling uses a combination of text and diagrammatic forms to depict(represent) requirements for data, function, and behavior These text and diagrammatic
More information3. Introduction to Algorithm and Flowchart
3. Introduction to Algorithm and Flowchart 3.1 Algorithm An algorithm is a set of instructions, sometimes called a procedure or a function that is used to perform a certain task. This can be a simple process,
More informationObject-Oriented Analysis and Design Prof. Partha Pratim Das Department of Computer Science and Engineering Indian Institute of Technology-Kharagpur
Object-Oriented Analysis and Design Prof. Partha Pratim Das Department of Computer Science and Engineering Indian Institute of Technology-Kharagpur Lecture 06 Object-Oriented Analysis and Design Welcome
More informationSOFTWARE ENGINEERING Prof.N.L.Sarda Computer Science & Engineering IIT Bombay. Lecture #10 Process Modelling DFD, Function Decomp (Part 2)
SOFTWARE ENGINEERING Prof.N.L.Sarda Computer Science & Engineering IIT Bombay Lecture #10 Process Modelling DFD, Function Decomp (Part 2) Let us continue with the data modeling topic. So far we have seen
More informationThe Specification Phase
The Specification Phase CS427: Elements of Software Engineering Lecture 4.1 10am, 30 Jan 2012 CS427 The Specification Phase 1/16 Outline 1 Recall... The Requirements Phase 2 Phase 2: Specifications 3 Requirements
More informationRequirements Engineering. Materials: Pressman (chapters 8,9, 10, 11) Sommerville (Chapters 4, 5)
Requirements Engineering Materials: Pressman (chapters 8,9, 10, 11) Sommerville (Chapters 4, 5) Definition What is Requirement Engineering? Requirement: A function, constraint or other property that the
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 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 informationHardware versus software
Logic 1 Hardware versus software 2 In hardware such as chip design or architecture, designs are usually proven to be correct using proof tools In software, a program is very rarely proved correct Why?
More information*ANSWERS * **********************************
CS/183/17/SS07 UNIVERSITY OF SURREY BSc Programmes in Computing Level 1 Examination CS183: Systems Analysis and Design Time allowed: 2 hours Spring Semester 2007 Answer ALL questions in Section A and TWO
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 informationCS187 - Science Gateway Seminar for CS and Math
CS187 - Science Gateway Seminar for CS and Math Fall 2013 Class 6 Sep. 19, 2013 Programming and Programming Languages Why, How and What? A programming language is a formal language (vs. natural language)
More information(Refer Slide Time: 1:27)
Data Structures and Algorithms Dr. Naveen Garg Department of Computer Science and Engineering Indian Institute of Technology, Delhi Lecture 1 Introduction to Data Structures and Algorithms Welcome to data
More informationproj 3B intro to multi-page layout & interactive pdf
art 2413 typography fall 17 proj 3B intro to multi-page layout & interactive pdf objectives Students introduced to pre-made layered mockups that utilized smart art by placing vector artwork into the Photoshop
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 informationCS 451 Software Engineering
CS 451 Software Engineering Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu 1 Elaboration 2 Elaboration: Building the Analysis Model An analysis model provides a description
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 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 informationUNIT II Requirements Analysis and Specification & Software Design
UNIT II Requirements Analysis and Specification & Software Design Requirements Analysis and Specification Many projects fail: because they start implementing the system: without determining whether they
More informationIntroduction to Formal Methods
2008 Spring Software Special Development 1 Introduction to Formal Methods Part I : Formal Specification i JUNBEOM YOO jbyoo@knokuk.ac.kr Reference AS Specifier s Introduction to Formal lmethods Jeannette
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 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 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 informationLecture 6: Requirements Engineering
Lecture 6: Requirements Engineering Software System Design and Implementation ITCS/ITIS 6112/8112 001 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte
More informationSlide Hard real-time constraints must be satisfied Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 12.1 CHAPTER 12 Slide 12.2 Object-Oriented and Classical Software Engineering CLASSICAL ANALYSIS Eighth Edition, WCB/McGraw-Hill, 2011 Stephen R. Schach Overview Slide 12.3 Overview (contd) Slide
More informationSFU CMPT week 11
SFU CMPT-363 2004-2 week 11 Manuel Zahariev E-mail: manuelz@cs.sfu.ca Based on course material from Arthur Kirkpatrick, Alissa Antle and Paul Hibbits July 21, 2004 1 Analytic Methods Advantages can be
More informationVANCOUVER Chapter Study Group. BABOK Chapter 9 Techniques
VANCOUVER Chapter Study Group BABOK Chapter 9 Techniques May 27, 2015 David Ghotbi, CBAP Agenda Chapter 8 Review Pop Quiz Break Chapter 9 Review Pop Quiz Q & A 2 Chapter 9 Techniques Techniques: Alter
More informationTASKS IN THE SYSTEMS DEVELOPMENT LIFE CYCLE
SUMMARY AND REFERENCE ACTG 313 TASKS IN THE SYSTEMS DEVELOPMENT LIFE CYCLE PREPARATION PHASE 1. Identification of the Need for a new Information System 2. Initial Feasibility Study (always flawed because
More informationRecalling the definition of design as set of models let's consider the modeling of some real software.
Software Design and Architectures SE-2 / SE426 / CS446 / ECE426 Lecture 3 : Modeling Software Software uniquely combines abstract, purely mathematical stuff with physical representation. There are numerous
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 informationUsable Privacy and Security Introduction to HCI Methods January 19, 2006 Jason Hong Notes By: Kami Vaniea
Usable Privacy and Security Introduction to HCI Methods January 19, 2006 Jason Hong Notes By: Kami Vaniea Due Today: List of preferred lectures to present Due Next Week: IRB training completion certificate
More informationBy: Chaitanya Settaluri Devendra Kalia
By: Chaitanya Settaluri Devendra Kalia What is an embedded system? An embedded system Uses a controller to perform some function Is not perceived as a computer Software is used for features and flexibility
More informationUp and Running Software The Development Process
Up and Running Software The Development Process Success Determination, Adaptative Processes, and a Baseline Approach About This Document: Thank you for requesting more information about Up and Running
More informationSoftware Requirements Specification. <Project> for. Version 1.0 approved. Prepared by <author(s)> <Organization> <Date created>
Software Requirements Specification for Version 1.0 approved Prepared by Software Requirements Specification for Page 2 Table of Contents Revision
More information1. The narratives, diagrams, charts, and other written materials that explain how a system works are collectively called
CH 3 MULTIPLE CHOICE 1. The narratives, diagrams, charts, and other written materials that explain how a system works are collectively called a) documentation. b) data flows. c) flowcharts. d) schema.
More informationObject-Oriented and Classical Software Engineering
Slide 11.1 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vanderbilt.edu CHAPTER 11 Slide 11.2 SPECIFICATION PHASE Overview Slide 11.3
More informationSOFTWARE REQUIREMENTS ENGINEERING LECTURE # 7 TEAM SKILL 2: UNDERSTANDING USER AND STAKEHOLDER NEEDS REQUIREMENT ELICITATION TECHNIQUES-IV
1 SOFTWARE REQUIREMENTS ENGINEERING LECTURE # 7 TEAM SKILL 2: UNDERSTANDING USER AND STAKEHOLDER NEEDS REQUIREMENT ELICITATION TECHNIQUES-IV 12 th June, 2013 Instructor Information 2 Course Instructor:
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 informationCITS5501 Software Testing and Quality Assurance Formal methods
CITS5501 Software Testing and Quality Assurance Formal methods Unit coordinator: Arran Stewart May 1, 2018 1 / 49 Sources Pressman, R., Software Engineering: A Practitioner s Approach, McGraw-Hill, 2005
More informationThis exam is open book / open notes. No electronic devices are permitted.
SENG 310 Midterm February 2011 Total Marks: / 40 Name Solutions Student # This exam is open book / open notes. No electronic devices are permitted. Part I: Short Answer Questions ( / 12 points) 1. Explain
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 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 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 informationBusiness Process Modelling
CS565 - Business Process & Workflow Management Systems Business Process Modelling CS 565 - Lecture 2 20/2/17 1 Business Process Lifecycle Enactment: Operation Monitoring Maintenance Evaluation: Process
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 informationSoftware Verification and Validation (VIMMD052) Introduction. Istvan Majzik Budapest University of Technology and Economics
Software Verification and Validation (VIMMD052) Introduction Istvan Majzik majzik@mit.bme.hu Budapest University of Technology and Economics Dept. of Measurement and Information s Budapest University of
More informationFlow Chart & Algorithms
Flow Chart Algorithms Planning Your Code Page 1 Page 4 See Appendix A, for Licensing Attribution information by-nc-sa-3.0 https://creativecommons.org/licenses/by-nc-sa/3.0/ https://creativecommons.org/faq/#what-does-some-rights-reserved-mean
More informationSE Assignment III. 1. List and explain primitive symbols used for constructing DFDs. Illustrate the use of these symbols with the help of an example.
SE Assignment III 1. List and explain primitive symbols used for constructing DFDs. Illustrate the use of these symbols with the help of an example. There are essentially 5 different types of symbols used
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 informationWorking with Health IT Systems is available under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported license.
Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported license. Johns Hopkins University. Welcome to the Fundamentals of Health Workflow
More informationThe Analysis and Proposed Modifications to ISO/IEC Software Engineering Software Quality Requirements and Evaluation Quality Requirements
Journal of Software Engineering and Applications, 2016, 9, 112-127 Published Online April 2016 in SciRes. http://www.scirp.org/journal/jsea http://dx.doi.org/10.4236/jsea.2016.94010 The Analysis and Proposed
More informationThe requirements engineering process
3 rd Stage Lecture time: 8:30-12:30 AM Instructor: Ali Kadhum AL-Quraby Lecture No. : 5 Subject: Software Engineering Class room no.: Department of computer science Process activities The four basic process
More informationSIF8035. Events and System Requirements
SIF8035 Lecture 4 DFD and PrM Events and System Requirements Events Occurrences at a specific time and place Trigger all system processing Requirement definition Determine relevant events External events
More information06. Analysis Modeling
06. Analysis Modeling Division of Computer Science, College of Computing Hanyang University ERICA Campus 1 st Semester 2017 Overview of Analysis Modeling 1 Requirement Analysis 2 Analysis Modeling Approaches
More informationSoftware Applications What Are they? enterprise software accounting software office suites graphics software media players Databases Graphical user
An Overview Software Applications What Are they? enterprise software accounting software office suites graphics software media players Databases Graphical user interfaces Web applications or applications
More informationGame keystrokes or Calculates how fast and moves a cartoon Joystick movements how far to move a cartoon figure on screen figure on screen
Computer Programming Computers can t do anything without being told what to do. To make the computer do something useful, you must give it instructions. You can give a computer instructions in two ways:
More informationRequirements Analysis. SE 555 Software Requirements & Specification
Requirements Analysis Goals of Requirements Analysis Create requirements containing sufficient detail and of high enough quality to allow realistic project planning as well as successful design and implementation.
More informationIntroduction to User Stories. CSCI 5828: Foundations of Software Engineering Lecture 05 09/09/2014
Introduction to User Stories CSCI 5828: Foundations of Software Engineering Lecture 05 09/09/2014 1 Goals Present an introduction to the topic of user stories concepts and terminology benefits and limitations
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 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 informationSOFTWARE ENGINEERING : A MCQ BOOK CODE : RBMCQ0602. Second Edition
SOFTWARE ENGINEERING : A MCQ BOOK CODE : RBMCQ0602 Second Edition S/W Engg. Fundamental 1) Which phase of the SDLC are information needs identified? A. preliminary investigation B. system analysis C. system
More informationMarking Guidelines for MVK Projects. MVK12. Version 6.2 (PPD, URD, RURD, ADD and software demo)
Marking Guidelines for MVK Projects. MVK12 Version 6.2 (PPD, URD, RURD, ADD and software demo) 2013-02- 13 Final Grade formulas: MVK DD1365 Grade = 33% PPD + 66% URD. Bachelor s Thesis DD143X Grade = ADD
More informationChapter 3. Describing Syntax and Semantics
Chapter 3 Describing Syntax and Semantics Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the Meanings of Programs:
More informationUser Stories. Wednesday, January 23, 13
User Stories 1 User Stories and their friends: Use Cases, Scenarios, Personas, Gherkins and Kanbans 7 W s Who writes user stories? What is a user story? When is it written? Where are they seen? Why is
More informationFinal Exam CISC 475/675 Fall 2004
True or False [2 pts each]: Final Exam CISC 475/675 Fall 2004 1. (True/False) All software development processes contain at least separate planning, testing, and documentation phases. 2. (True/False) The
More informationComputer Science 520/620 Spring 2013 Prof. L. Osterweil" Use Cases" Software Models and Representations" Part 4" More, and Multiple Models"
Computer Science 520/620 Spring 2013 Prof. L. Osterweil Software Models and Representations Part 4 More, and Multiple Models Use Cases Specify actors and how they interact with various component parts
More informationComputer Science 520/620 Spring 2013 Prof. L. Osterweil" Software Models and Representations" Part 4" More, and Multiple Models" Use Cases"
Computer Science 520/620 Spring 2013 Prof. L. Osterweil Software Models and Representations Part 4 More, and Multiple Models Use Cases Specify actors and how they interact with various component parts
More information2014 Intelliware Development Inc.
What You ll Learn in this Presentation: The basics of user stories. How user stories fit into the overall Agile planning process. How to write a user story. A story card example 2 Why is it so Difficult
More informationIntroducing Computer Programming
ok4 01 f2 5/24/17 9:59 AM Page 3 Chapter 1 Introducing Computer Programming Intended Learning Outcomes After completing this chapter, you should be able to: Explain the difference between computers and
More informationGuide to IREE Certification
Guide to IREE Certification Certification Congratulations on your decision to pursue Investor Ready Energy Efficiency (IREE) Certification for your project! As a building owner, by choosing to pursue IREE
More informationUML for Managers Chapter 2 UML for Managers. Jason Gorman. Chapter 2. February 11, Jason Gorman 2005
UML for Managers Jason Gorman Chapter 2 February 11, 2005 1 Introducing the UML...3 Object Diagrams...3 Class Diagrams...4 Activity Diagrams...5 State Transition Diagrams...7 Sequence Diagrams...8 Collaboration
More information(Refer Slide Time: 00:01:30)
Digital Circuits and Systems Prof. S. Srinivasan Department of Electrical Engineering Indian Institute of Technology, Madras Lecture - 32 Design using Programmable Logic Devices (Refer Slide Time: 00:01:30)
More informationSoftware Design Fundamentals. CSCE Lecture 11-09/27/2016
Software Design Fundamentals CSCE 740 - Lecture 11-09/27/2016 Today s Goals Define design Introduce the design process Overview of design criteria What results in a good design? Gregory Gay CSCE 740 -
More informationFoundations, Reasoning About Algorithms, and Design By Contract CMPSC 122
Foundations, Reasoning About Algorithms, and Design By Contract CMPSC 122 I. Logic 101 In logic, a statement or proposition is a sentence that can either be true or false. A predicate is a sentence in
More informationHuman-Centred Interaction Design
Human-Centred Interaction Design Scoping a problem with PACT The aim of human-centred interaction design is to harmonise the PACT elements in a particular domain. Designers want to get the right mix of
More informationSample Exam Syllabus
ISTQB Foundation Level 2011 Syllabus Version 2.9 Release Date: December 16th, 2017. Version.2.9 Page 1 of 46 Dec 16th, 2017 Copyright 2017 (hereinafter called ISTQB ). All rights reserved. The authors
More information