IBM Software Group. Mastering Requirements Management with Use Cases Module 8: Refine the System Definition
|
|
- Godfrey Booth
- 5 years ago
- Views:
Transcription
1 IBM Software Group Mastering Requirements Management with Use Cases Module 8: Refine the System Definition 1
2 Objectives Describe design constraints. Identify methods of specifying functional requirements. Describe techniques for writing and structuring use cases. Detail the use case flows. Flows of Events Pre- and postconditions Use case structure Specify nonfunctional requirements. Usability, Reliability, Performance, Supportability 2
3 Where Are We in the Requirements Discipline? 3
4 Refine the System Definition: Activities and Artifacts 4
5 Review: What Do Software Requirements Specify? Inputs System Outputs Functions Performance Environments 5
6 What About Design Constraints? A requirement that includes information about the system design or architecture is a design constraint. Distinguish it from other requirements. Place in a special section of your software requirements. Identify the source of each. Document the rationale for each. Examples. An algorithm that is required to be used. A database system that is required to be used. A language that must be used in the implementation. 6
7 The What-Versus-How Dilemma Question: How can you tell a requirement from design? Answer: It depends on your point of view. One man s ceiling is another man s floor. Davis, 1993 What How What How What How Stakeholder Needs Product or System Features Software Requirements Specification (Use Cases) Design Spec Test Procedures Documentation Plans 7
8 A Closer Look at the F of FURPS Functionality Usability Reliability Performance Feature set capabilities, security, generality Human factors aesthetics, consistency, documentation Frequency/severity of failure, recoverability, predictability, accuracy, MTBF Speed efficiency, resource usage, throughput, response time Supportability Testability Adaptability Compatibility Serviceability Localizability 8 Extensibility Maintainability Configurability Installability Robustness Grady, 1992
9 How to Specify Functional Requirements? Use both use cases and declarative statements. Both are necessary to understand any system of significant complexity. Give preference to use cases, where appropriate. Use Cases + The system shall The system must The system shall... Declarative Statements? Which one to choose? 9
10 What About Requirements NOT in Use Cases? Write a declarative statement to describe the software requirement. Use a keyword to aid identification, for example shall. Number and title each requirement. Group related requirements. Use language the team easily understands. Use simple sentence structure. Subject + active verb. Be concise and thorough. State the requirement in 1 to 3 sentences. Make the requirement complete. Use terms from the glossary. 10
11 Functional Requirements in Declarative Statements Some functional requirements are easier to state declaratively. Example: RU e-st System 1. Localization: SUPL120: The RU e-st system screens shall support switching to another language for all messages and menus in the user s preferred language at any time. The languages supported shall include English, Spanish, French, German, and Swedish. 11
12 Where Are Declarative Statements Specified? Does the requirement apply to a use case? Specify in the Use-Case Specification In Special Requirements property Does the requirement apply to the whole system? Specify in the Supplementary Specifications RUCS8: Supplementary Specification 12
13 Variations for Functional Requirements System with little externally observable behavior. System with lots of externally observable behavior. 13
14 Detail Each Use Case 1. Identify actors and use cases. Brief Description. 2. Outline each use case. Basic Flow of Events. Alternative Flows of Events. 3. Detail each use case. Detail the flow of events. Structure each use case flows of events. Add detail. Pre- and postconditions, special requirements, relationships, use-case diagrams, and so on. 14
15 Why Detail Use Cases? Specify the software requirements. Create a specification that can be implemented. Clarify important details in flow of events. What the actor does. What the system does in response. What information is exchanged. Describe additional information. Preconditions Postconditions 15
16 Detail a Use Case 1. Find the actors and use cases. 2. Detail the use cases. Brief Outline <Use-Case Name> Brief Description Flow of of Events Basic Flow of of Events Alternative Flows of of Events Special Requirements Preconditions Postconditions Extension Points Relationships Use-Case Diagrams Other Diagrams/Enclosures Add Detail RUCS6: Get Quote Use-Case Description 16
17 Detail the Basic Flow of Events Get Quote 1.1 Basic Flow 1. Customer Logs On The use case starts when the Trading Customer logs on. The system validates the customer id and password. The system presents a list of available functions. 2. Customer Selects Get Quote Function The Trading Customer chooses to get a quote. The system displays the list of trading symbols and names of securities. 3. Customer Selects Security The Trading Customer selects from the list of securities or enters the trading symbol for a security. 4. System Gets Quote from Quote System The system sends the trading symbol to the Quote System, and receives the Quote System Response. The system presents the corresponding Quote Display (see fields to display in Supplementary Specifications) to the Trading Customer. Structure the flow into steps Number and title each step Make each step a roundtrip of events Describe steps (completely and concisely) 17
18 Manage the Detail Black Box White Box Know your audience. Strive for black box. Some white box text may improve understandability because it makes the use case more concrete. 18
19 Structure the Use Case Flows Internal organization of the use case. Increase readability. Make the requirements more understandable. Document acceptable styles in the Use- Case-Modeling Guidelines. RUCS11: Use-Case Modeling Guidelines 19
20 Review: Flows of Events (Basic and Alternative) One Basic Flow Happy day scenario Successful scenario from start to finish Many Alternative Flows Regular variants Odd cases Exceptional (error) flows Flow: A sequential set of steps. 20
21 Detail Alternative Flows Alternative Flows A3 Request Additional Quotes In Step 3, Customer Gets Quote, in the Basic Flow, if the customer wants additional quotes. The use case continues at Step 3. A4 Quit If at any time the Trading Customer decides to quit. The use case ends. A5 Unknown Trading Symbol In Step 3, Customer Gets Quote, in the Basic Flow, if the system cannot recognize the trading symbol, the system notifies the Trading Customer that the trading symbol is not recognizable. The use case continues at the beginning of Step 3. Describe what happens Location Condition Actions Resume location 21
22 Avoid Inline Conditional Behavior Make identifying scenarios difficult. Harder to test and implement. Preference should be for alternative flows. 22
23 Avoid Inline Repetitive Behavior Make identifying scenarios difficult. Harder to test and implement. Preference should be for alternative flows. 23
24 Visualize Alternative Behavior Trading System Quote System Customer 24
25 Subflows Increase clarity. Allow internal reuse of requirements. Unlike an alternative flow, are explicitly called. Always return to the line after they were called. Alternative Flows Subflow 25
26 Example Subflow RUCS6.2: Execute Trade UC Spec 26
27 Leave the User Interface Out of the Use Case Text is not good at describing visual things. Use cases are user-interface agnostic. Describe user Interfaces during Analysis and Design with: User-experience model or prototypes Words to AVOID Click Drag Form Open Close Drop Button Field Drop-down Pop-up Scroll Browse Record Window Words to Use Prompts Chooses Initiates Specifies Submits Selects Starts Displays Informs RUCS11: Use-Case Modeling Guidelines 27
28 Use the Glossary Effectively Use Case 5. Enter Customer Info The system prompts the Customer to enter their Customer Details. The Customer enters the Customer Details. The Customer creates the account. Implementation Glossary Customer Details: Information that uniquely identifies and provides contact information for a customer located in the U.S.A. The information consists of: Name, two address lines, city, state, zip code, and daytime phone number. 28
29 Preconditions Describes the state the system must be in before the use case can start. Not the event that starts the use case. Optional: Use only if needed for clarification. Get Quote Precondition The RU e-st system must have a connection to the Quote System in order to begin this use case. 29
30 Postconditions Describes the state of the system at the end of the use case. Guaranteed true when use case ends. May contain variants. Optional: Use only if needed for clarification. Execute Trade Postcondition At the end of this use case all accounts have been updated to reflect the transactions that have occurred. 30
31 Sequence Use Cases with Pre and Post Conditions Use Cases do not interact. 31
32 Use Case Tips Describe only the events visible to the actor: What the actor does. What the system does in response. Make use cases provide value to an actor. Use Cases may have differing levels of precision. Detail until each stakeholder has a common understanding of the requirements from their perspective, then stop. Use agreed-upon terms and vocabulary. Use precise language. 32
33 Use Case Checkpoints Are the actor interactions and exchanged information clear? Does the communication sequence between actor and use case conform to the user's expectations? Is it clear how and when the use case's flow of events starts and ends? Is the subflow in a use case modeled accurately? 33
34 What About Nonfunctional Requirements? The URPS of FURPS Usability Reliability Performance Supportability Compliance with Legal and Regulatory requirements FCC FDA DOD ISO Design Constraints Operating Systems Environments Compatibility Application Standards Functionality Usability Reliability Performance Supportability Feature set Capabilities Human factors Aesthetics Frequency/Severity of failure Recoverability Speed Efficiency Resource usage Testability Extensibility Adaptability Maintainability Compatibility Generality Security Consistency Documentation Predictability Accuracy MTBF Throughput Response time Configurability Serviceability Installability Localizability Robustness 34
35 Example: Nonfunctional Requirements The RU e-st System The system must provide price quotes that are no more than 15 minutes delayed. What are some others? Where should each of these be specified? 35
36 Specify Usability Requirements Usability is the ease with which software can be learned and operated by the intended users. Usability requirements include: Training time requirements, measurable task times. User abilities (beginner/advanced). Comparison to other systems that users know and like. Online help systems, tool tips, documentation needs. Conformity with standards. Examples: Windows, style guides, GUI Standards All user documentation must conform to the Microsoft Manual of Style for Technical Publications. 36
37 Specify Reliability Requirements Reliability is the the ability for the software to behave consistently in a user-acceptable manner. Reliability requirements include: Availability (xx.xx%) Accuracy MTBF (xx hrs) Max. bugs per/kloc (0-x) Reporting of velocity for the Mars Lander must be in units of meters per second and accurate to 1 in 1e6. Davis Workshop,
38 Specify Performance Requirements Performance is a measure of speed or efficiency of the running system. Performance requirements include: Capacity Throughput Response time Memory Degradation modes Use of scarce resources Processor, memory, disk, network bandwidth There must be no more than four protocol exchanges, of no greater size than 512k bytes each, between the client and the server for each user action. Davis Workshop,
39 Specify Supportability Requirements Supportability is the ability of the software to be easily modified to accommodate enhancements and repairs. Supportability requirements include: Languages, DBMS, tools, and so on. Programming standards. Error handling and reporting standards. Often difficult to specify If not measurable or observable, it is not a requirement. Is it a design constraint? Is it an intent or goal? Davis Workshop,
40 Review: Refine the System Definition 1. When are use cases used to specify requirements? 2. When are declarative statements used? 3. What is the difference between black and whitebox use cases? Which is better? Why? 4. What are some alternatives for expressing conditional behavior? What are the benefits and drawbacks of each alternative? 5. When would you use a subflow? 6. How should you handle describing forms or data types in a use case? 7. What are the benefits of using pre- and postconditions? 40
<Name of the project> Software Requirement Specification
Software Requirement Specification Project Code: Document Code: v RECORD OF CHANGE *A -
More informationIBM Software Group. Mastering Requirements Management with Use Cases Module 10: Structure the Use-Case Model
IBM Software Group Mastering Requirements Management with Use Cases Module 10: Structure the Use-Case Model 1 Objectives Simplify the maintenance of the requirements without sacrificing clarity or comprehension
More information<Project Name> Use Case Specification: <Use-Case Name> Version <1.0>
1 z 5 2007-02-26 15:57 Use Case Specification: Version [Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square
More information<Project Name> Supplementary Specification
Version [Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=infoblue) is included
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 informationIndividual Project. Agnieszka Jastrzębska Władysław Homenda Lucjan Stapp
Individual Project Individual Project Target: 1. Improvement of software development skill 2. to industrial method of building application in practical way Individual Project Slide 2/50 Individual Project
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 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 informationMega International Commercial bank (Canada)
Mega International Commercial bank (Canada) Policy and Procedures for Clear Language and Presentation Est. Sep. 12, 2013 I. Purposes: The Mega ICB (C) distributes a limited range of retail banking services,
More informationRequirements Specifications & Standards
REQUIREMENTS ENGINEERING LECTURE 2014/2015 Dr. Jörg Dörr Requirements Specifications & Standards AGENDA Standards & Templates Natural Language Requirements Specification with Conceptual Models Suitable
More informationAn Integrated Approach to Documenting Requirements with the Rational Tool Suite
Copyright Rational Software 2002 http://www.therationaledge.com/content/dec_02/t_documentreqs_kd.jsp An Integrated Approach to Documenting Requirements with the Rational Tool Suite by Kirsten Denney Advisor
More informationQA Best Practices: A training that cultivates skills for delivering quality systems
QA Best Practices: A training that cultivates skills for delivering quality systems Dixie Neilson QA Supervisor Lynn Worm QA Supervisor Maheen Imam QA Analyst Information Technology for Minnesota Government
More informationNon Functional Product Requirements (illeties)
Non Functional Product Requirements (illeties) MANAGEMENT SUMMARY This whitepaper list several Non functional, Illeties or Quality Requirements Non Functional Product Requirements (illeties) ImQuSo White
More informationDay 1 summary for day 2. Addison, TX
Technical Interoperability Day 1 summary for day 2 April 12, 2007 Addison, TX Overview Summary of day 1 Top 5 issues Other topics discussed Issues for the future (day 2) Main Issues (1) Title: Adopt /
More informationINTRODUCTION TO SOFTWARE ENGINEERING
INTRODUCTION TO SOFTWARE ENGINEERING Introduction to Software Testing d_sinnig@cs.concordia.ca Department for Computer Science and Software Engineering What is software testing? Software testing consists
More informationModeling Crisis Management System With the Restricted Use Case Modeling Approach
Modeling Crisis Management System With the Restricted Use Case Modeling Approach Gong Zhang 1, Tao Yue 2, and Shaukat Ali 3 1 School of Computer Science and Engineering, Beihang University, Beijing, China
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 informationEBSCOhost Web 6.0. User s Guide EBS 2065
EBSCOhost Web 6.0 User s Guide EBS 2065 6/26/2002 2 Table Of Contents Objectives:...4 What is EBSCOhost...5 System Requirements... 5 Choosing Databases to Search...5 Using the Toolbar...6 Using the Utility
More informationACT476 Professional Project II Test Case Development Team Name Project Tester
unique-test-case-id: User-Login and Permissions Check Purpose: Short sentence or two about the aspect of the system is being tested. If this gets too long, break the test case up or put more information
More informationIntroduction to Architecture. Introduction to Architecture 1
Introduction to Architecture Introduction to Architecture 1 Content What is architecture? Motivation for architecture Non-functional requirements Introduction to Architecture 2 What is architecture? The
More informationSoftware Requirements Specification. <Project> for. Version 1.0 approved. Prepared by <author> <organization> <date created>
Software Requirements Specification for Version 1.0 approved Prepared by Copyright 2002 by Karl E. Wiegers. Permission is granted to use, modify, and distribute
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 informationCMSC 447: Software Engineering I
CMSC 447: Software Engineering I General Instructions System Requirements Specification Template (Adapted from Susan Mitchell and Michael Grasso) 1. Provide a cover page that includes the document name,
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 information<Company Name> <Project Name> Software Requirements Specification For <Subsystem or Feature> Version <1.0>
For Version [Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed
More informationIndex. brief description section (Use Case Specification documents), 138 Browser window (Rational Rose), 257 Business Rules document, 212
Index A abstract requirements, 10 activity diagram section (Use Case -144 actors identifying, 130-131 relationships, generalization between, 137 use cases, 133-135 Actual completion date attribute actual
More informationDevice Partner Center
Device Partner Center Quick Start Guide Getting Started with Brand Assets Device Partner Center (DPC) houses content previously hosted on the OEM Marketing Assets Portal (OMAP). By registering for Brand
More informationInterface (API) Design
Interface (API) Design Architect s Perspective R. Kuehl/J. Scott Hawker p. 1 What is an API? Exposes the public facing functionality of a software component Operations, inputs, and outputs Exposes functionality
More informationUsability. Daniela Rosner. Web Architecture, October 9, School of Information UC Berkeley
Usability Daniela Rosner Web Architecture, 290-03 October 9, 2007 School of Information UC Berkeley Outline Introduction what is usability Best Practices common solutions Design Patterns shared languages
More informationDimensions for the Separation of Concerns in Describing Software Development Processes
Dimensions for the Separation of Concerns in Describing Software Development Processes Pavel Hruby Navision Software Frydenlunds Allé 6 DK-2950 Vedbæk, Denmark ph@navision.com http://www.navision.com,
More information<Project Name> Vision
Version [Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=infoblue) is included
More informationSoftware Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.
Software Design Patterns Jonathan I. Maletic, Ph.D. Department of Computer Science Kent State University J. Maletic 1 Background 1 Search for recurring successful designs emergent designs from practice
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 informationSoftware Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 09/17/2015
Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm Rao Casturi 09/17/2015 http://cs.gsu.edu/~ncasturi1 Requirement Elicitation 2 Requirement Engineering First step for understanding the
More informationGENERATION TOOL FOR DBMS FOCUSED APPLICATIONS
GENERATION TOOL FOR DBMS FOCUSED APPLICATIONS Carlos del Cuvillo Universidad Politecnica de Madrid Ctra. de Valencia km. 7 E28031 Madrid Hector Garcia Universidad Politecnica de Madrid Ctra. de Valencia
More informationSolution Architecture Template (SAT) Design Guidelines
Solution Architecture Template (SAT) Design Guidelines Change control Modification Details Version 2.0.0 Alignment with EIRA v2.0.0 Version 1.0.0 Initial version ISA² Action - European Interoperability
More informationCPSC 444 Project Milestone III: Prototyping & Experiment Design Feb 6, 2018
CPSC 444 Project Milestone III: Prototyping & Experiment Design Feb 6, 2018 OVERVIEW... 2 SUMMARY OF MILESTONE III DELIVERABLES... 2 1. Blog Update #3 - Low-fidelity Prototyping & Cognitive Walkthrough,
More informationAbout Dean Leffingwell
Lean Practices for Foreword by Don Nonfunctional (System Qualities) Agile Style Reinertsen Development Series By and Ryan Shriver Agile 2010 Orlando, FL Lean Practices for Foreword by Don Reinertsen Development
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 informationFORMATTING GUIDELINES FOR RESEARCH REPORTS (for 2011submissions)
FORMATTING GUIDELINES FOR RESEARCH REPORTS (for 2011submissions) The following guidelines apply to research reports that are produced for the Great Lakes Maritime Research Institute (GLMRI). Following
More informationSoftware Design. Levels in Design Process. Design Methodologies. Levels..
Design Software Design Design activity begins with a set of requirements Design done before the system is implemented Design is the intermediate language between requirements and code Moving from problem
More informationWhat are the elements of website design?
Contents What is a website?...1 Why does design matter?...1 What are the elements of website design?...1 What guidelines can help direct the design?...2 What physical objects are most similar to a web
More informationSoftware Requirements Specification Version 1.1 August 29, 2003
Software Requirements Specification Version 1.1 August 29, 2003 Web Accessible Alumni Database Michael J. Reaves Submitted in partial fulfillment Of the requirements of Masters Studio Project Table of
More informationChapter 4 Requirements Elicitation
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 4 Requirements Elicitation Outline Today: Motivation: Software Lifecycle Requirements elicitation challenges Problem statement
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 informationReliability Coordinator Procedure PURPOSE... 1
No. RC0550 Restriction: Table of Contents PURPOSE... 1 1. RESPONSIBILITIES... 2 1.1.1. CAISO RC... 2 1.1.2. RC Working Groups... 2 1.1.3. Operationally Affected Parties... 2 1.1.4. RC Oversight Committee...
More informationStandard Operating Procedures. Fit for Human Use
Standard Operating Procedures Fit for Human Use Agenda: The background behind Ximedica s decision The process of re-designing The results and benefits Applying usability to Standard Operating Procedures
More informationAKENEOPIM User Guide Version 1.3. End-user role USER GUIDE END-USER ROLE. Version 1.3. Copyright AKENEO SAS The Open Source PIM
USER GUIDE END-USER ROLE CONTENTS Glossary 6 Key Concepts 7 Channel 7 Connector 7 Family 7 Category 8 Completeness 9 Variant group 9 First steps into Akeneo PIM 11 Login 11 Recover password 11 Change your
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 informationProduct Quality Engineering. RIT Software Engineering
Product Quality Engineering Q vs q Quality includes many more attributes than just absence of defects Features Performance Availability Safety Security Reusability Extensibility Modifiability Portability
More information2.5.1: Reforms in Continuous Internal Evaluation (CIE) System at the Institutional Level
D Y Patil Institute of Engineering and Technology, Ambi, Pune Address:Sr.No.124 & 126, A/p- Ambi, Tal-Maval, MIDC Road, TalegaonDabhade, Pune-410506, Maharashtra, India Tel: 02114306229, E-mail : info@dyptc.edu.in
More informationIntroduction To Software Testing. Brian Nielsen. Center of Embedded Software Systems Aalborg University, Denmark CSS
Introduction To Software Testing Brian Nielsen bnielsen@cs.aau.dk Center of Embedded Software Systems Aalborg University, Denmark CSS 1010111011010101 1011010101110111 What is testing? Testing Testing:
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 informationLecture Chapter 2 Software Development
Lecture Chapter 2 Software Development Large Software Projects Software Design o Team of programmers o Cost effective development Organization Communication Problem Solving Analysis of the problem Multiple
More informationSenior Project: Calendar
Senior Project: Calendar By Jason Chin June 2, 2017 Contents 1 Introduction 1 2 Vision and Scope 2 2.1 Business Requirements...................... 2 2.1.1 Background........................ 2 2.1.2 Business
More informationEDITING & PROOFREADING CHECKLIST
EDITING & PROOFREADING CHECKLIST TABLE OF CONTENTS 1. Conduct a First Pass... 2 1.1. Ensure effective organization... 2 1.2. Check the flow and tone... 3 1.3. Check for correct mechanics... 4 1.4. Ensure
More informationAgile Model-Driven Development with UML 2.0 SCOTT W. AM BLER. Foreword by Randy Miller UNIFIED 1420 MODELING LANGUAGE. gile 1.
THE OBJECT PRIMER THIRD EDITION Agile Model-Driven Development with UML 2.0 SCOTT W. AM BLER Foreword by Randy Miller UNIFIED 1420 MODELING LANGUAGE gile 1 odeling Contents Acknowledgments Foreword Preface
More informationGoal: build an object-oriented model of the realworld system (or imaginary world) Slicing the soup: OOA vs. OOD
Domain analysis Goal: build an object-oriented model of the realworld system (or imaginary world) Slicing the soup: OOA vs. OOD OOA concerned with what, not how OOA activities focus on the domain layer
More informationDesign Rules. increasing generality. increasing authority. Guide lines. Standards. increasing authority. increasing generality
increasing generality increasing generality Design Rules 0 Design rules 0 suggest how to increase usability 0 Principles 0 abstract design rules 0 an interface should be easy to navigate 0 Guidelines 0
More informationGuidelines for Coding of SAS Programs Thomas J. Winn, Jr. Texas State Auditor s Office
Guidelines for Coding of SAS Programs Thomas J. Winn, Jr. Texas State Auditor s Office Abstract This paper presents a set of proposed guidelines that could be used for writing SAS code that is clear, efficient,
More informationUser Interface Design. Lecture 6 Lecture 6 Design Guidance
User Interface Design Lecture 6 Lecture 6 Design Guidance C. Patanothai 2110646:06 Design Guidance 2 Design Guidance standards guidelines style guides design principles simplicity structure consistency
More informationLearning objectives. Documenting Analysis and Test. Why Produce Quality Documentation? Major categories of documents
Learning objectives Documenting Analysis and Test Understand the purposes and importance of documentation Identify some key quality documents and their relations Understand the structure and content of
More informationHow To Write Maintainable Engineering Specifications. Forrest Warthman
1 How To Write Maintainable Engineering Specifications Forrest Warthman 2 Outline Motivations and audience Editing and vector-graphics tools Document formats and templates Inserting figures and tables
More informationSoftware Testing TEST CASE SELECTION AND ADEQUECY TEST EXECUTION
Software Testing TEST CASE SELECTION AND ADEQUECY TEST EXECUTION Overview, Test specification and cases, Adequacy criteria, comparing criteria, Overview of test execution, From test case specification
More informationBusiness Requirements Document (BRD) Template
Business Requirements Document (BRD) Template Following is a template for a business requirements document (BRD). The document includes many best practices in use today. Don t be limited by the template,
More informationSmart Driver Assistant Software Requirements Specifications
2016 Software Requirements Specifications SEYMUR MAMMADLI SHKELQIM MEMOLLA NAIL IBRAHIMLI MEHMET KURHAN MIDDLE EAST TECHNICAL UNIVERSITY Department Of Computer Engineering Preface This document contains
More informationSystem Analysis and Design
System Analysis and Design Svatopluk Štolfa Department of Computer Science VŠB-TU Ostrava 2007 svatopluk.stolfa@vsb.cz Course Objectives After completing this course you will be able to: Perform all roles
More informationre3data.org - Making research data repositories visible and discoverable
re3data.org - Making research data repositories visible and discoverable Robert Ulrich, Karlsruhe Institute of Technology Hans-Jürgen Goebelbecker, Karlsruhe Institute of Technology Frank Scholze, Karlsruhe
More informationKindle Previewer User Guide. v3.21 English March 12, 2018
Kindle Previewer User Guide v3.21 English March 12, 2018 Revision History Revision Number Revision Notes 3.21 Updated section 1.1.2, Scanning through Your ebook, to clarify the function of the page size
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 information8 Golden Rules. C. Patanothai :04-Knowledge of User Interface Design 1
8 Golden Rules Strive for consistency Enable frequent users to use shortcuts Offer informative feedback Design dialog to yield closure Offer simple error handling Permit easy reversal of actions Support
More informationFor the purposes of this course, the following coding guidelines are in effect.
Changes 2014/02/01 reorganized to put project related items at the top, added clarification to #1, added new item #12 2014/02/02 Clarified zip file naming requirement 2014/02/08 Variable, method, class
More informationHuman Computer Interaction Lecture 16. User Support
Human Computer Interaction Lecture 16 User Support User Support Main Types of user support quick reference, task specific help, full explanation, tutorial Issues different types of support at different
More informationUser Interface Programming OOP/Java Primer. Step 3 - documentation
User Interface Programming OOP/Java Primer Step 3 - documentation Department of Information Technology Uppsala University What is the documentation? Documentation about program in the program Clearly written
More informationUser Interface Design. Model Hierarchy/Succession. User Interfaces aren t easy. Why User Interfaces are critical. Elements of good U/I design
Model Hierarchy/Succession User Interface Design architecture high level user interface design specifications component architecture functional interface definitions data architecture external data definitions
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 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 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 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 informationJennifer Nip, P.Eng. Portfolio
Jennifer Nip, P.Eng Portfolio Jennifer Nip Portfolio Jennifer has over 10 years experience in web design and usability analysis Being the Lead User Experience Designer, she has leading edge web design
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 informationATTENTION TO COME/ISE 491/492 STUDENT
ATTENTION TO COME/ISE 491/492 STUDENT 151 As a part of your requirement analysis section in your final report, you should write a requirement analysis document (RAD). The details of the document, and a
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 informationTASC CONFERENCES & TRAINING EVENTS
TASC is sponsored by the Administration on Developmental Disabilities (ADD), the Center for Mental Health Services (CMHS), the Rehabilitation Services Administration (RSA), the Social Security Administration
More informationBlackboard Learn 9.1 Last updated: March 2010
Blackboard Learn 9.1 Last updated: March 2010 2010 Blackboard Inc. All rights reserved. The content of this manual may not be reproduced or distributed without the express written consent of Blackboard
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 informationSoftware Testing and Maintenance
Software Testing and Maintenance Testing Strategies Black Box Testing, also known as Behavioral Testing, is a software testing method in which the internal structure/ design/ implementation of the item
More informationAgilix Buzz Accessibility Statement ( )
Agilix Buzz Accessibility Statement (08 30 2016) Voluntary Product Accessibility Template (VPAT) Software Applications and Operating Systems (Section 1194.21) Web based intranet and Internet information
More informationTASC CONFERENCES & TRAINING EVENTS
TASC is sponsored by the Administration on Developmental Disabilities (ADD), the Center for Mental Health Services (CMHS), the Rehabilitation Services Administration (RSA), the Social Security Administration
More informationRequirements Reuse: Fantasy or Feasible?
Requirements Reuse: Fantasy or Feasible? Sponsored by: Karl Wiegers Principal Consultant, Process Impact www.processimpact.com Source Book Software Requirements, 3 rd Edition by Karl Wiegers and Joy Beatty
More informationCS 577A Team 1 DCR ARB. PicShare
CS 577A Team 1 DCR ARB PicShare Team and Project Review (DEN) Project Evaluation Positives Resilient Agile detailed design promotes thoroughness before any code is written Development time should be reduced
More informationProject Brief 2012 Managing Content with Tags and Workflow
INFO-445: Advanced Database Design, Management, and Maintenance 1 5 Project Brief 2012 Managing Content with Tags and Workflow Please note: The project should be completed in groups of 4. Learning objective
More informationIntroduction to Software Engineering: Requirements
Introduction to Software Engineering: Requirements John T. Bell Department of Computer Science University of Illinois, Chicago Based on materials from Bruegge & DuToit 3e and Robertson & Robertson 3e.
More informationCSE 403. Requirements
CSE 403 Requirements There are only two hard problems in software engineering (tip of the day) Naming Cache invalidation/coherency Off-by-one errors Class announcements Requirements due at 11:59PM on Monday
More informationBarchard Introduction to SPSS Marks
Barchard Introduction to SPSS 22.0 3 Marks Purpose The purpose of this assignment is to introduce you to SPSS, the most commonly used statistical package in the social sciences. You will create a new data
More informationComputing and compilers
Computing and compilers Comp Sci 1570 to Outline 1 2 3 4 5 Evaluate the difference between hardware and software Find out about the various types of software Get a high level understanding of how program
More informationQuestionnaire Specification Database for Blaise Surveys
Questionnaire Specification Database for Blaise Surveys Lilia Filippenko, Valentina Grouverman, Joseph Nofziger, RTI International 1 Introduction Developing large scale, complex Computer Assisted Interview
More informationGuide for Researchers: Online Human Ethics Application Form
Ethics & Integrity Research Office HUMAN RESEARCH ETHICS ONLINE APPLICATION October 2016/V1.03 Guide for Researchers: Online Human Ethics Application Form ENQUIRIES Senior Human Ethics Officer University
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 informationPrivacy Policy I. COOKEVILLE COMMUNICATIONS PRIVACY POLICY II. GENERAL PRIVACY GUIDELINES
Privacy Policy I. COOKEVILLE COMMUNICATIONS PRIVACY POLICY Cookeville Communications Media is committed to maintaining robust privacy protections for its users. Our privacy policy is designed to help you
More information