1 Advanced Software Test Design Techniques Use Cases Introduction The following is an excerpt from my recently-published book, Advanced Software Testing: Volume 1. This is a book for test analysts and test engineers. It is especially useful for ISTQB Advanced Test Analyst certificate candidates, but contains detailed discussions of test design techniques that any tester can and should use. In this third article in a series of excerpts, I discuss the application of use cases to testing workflows. Use Cases At the start of this series, I said we would cover three techniques that would prove useful for testing business logic, often more useful than equivalence partitioning and boundary value analysis. First, we covered decision tables, which are best in transactional testing situations. Next, we looked at state-based testing, which is ideal when we have sequences of events that occur and conditions that apply to those events, and the proper handling of a particular event/condition situation depends on the events and conditions that have occurred in the past. In this article, we ll cover use cases, where preconditions and postconditions help to insulate one workflow from the previous workflow and the next workflow. With these three techniques in hand, you have a set of powerful techniques for testing the business logic of a system. Conceptually, use case testing is a way to ensure that we have tested typical and exceptional workflows and scenarios for the system, from the point of view of the various actors who directly interact with the system and from the point of view of the various stakeholders who indirectly interact with the system. If we (as test analysts) receive use cases from business analysts or system designers, then these can serve as convenient frameworks for creating test cases. Remember that, with decision tables, we were focused on transactional situations, where the conditions inputs, preconditions, and so forth that exist at a given moment in time for a single transaction are sufficient by themselves to determine the actions the system should take. Use cases aren t quite as rigid on this point, but, generally, the assumption is that the typical workflows are independent of each other. An exceptional workflow occurs when a typical workflow can t occur, but usually we have independency from one workflow to the next. This is ensured at least for formal use cases by clearly defined preconditions and postconditions, which guarantee certain things are true at the beginning and end of the workflow. This acts to insulate one workflow from the next. Again, if we have heavy interaction of past events and
2 conditions with the way current events and conditions should be handled, we ll want to use state-based testing. The model is less formal than what we ve seen with decision tables and state-based testing. Indeed, the concept of a use case itself can vary considerably in formality and presentation. The basic idea is that we have some numbered (or at least sequential) list of steps that describes how an actor interacts with the system. The steps can be shown in text or as part of a flow chart. The use case should also show the results obtained at the end of that sequence of steps. The results obtained should benefit some party, either the actor interacting directly with the system or some other stakeholder who indirectly receives the value of the results. At the very least, the set of steps should show a typical workflow, the normal processing. This normal processing is sometimes called the primary scenario, the normal course, the basic course, the main course, the normal flow, or the happy path. However, since things are not always happy, the set of steps should also show abnormal processing, sometimes called exceptions, exceptional processing, or alternative courses. Approaches to documenting use cases that are more formal cover not only typical and exceptional workflows, but also explicit identification of the actor, the preconditions, the postconditions, the priority, the frequency of use, special requirements, assumptions, and potentially more. The formal approach might also entail the creation of a use case diagram that shows all the actors, all the use cases, and the relationship between the actors and the use cases. Now, an assumption that I m making here in fact, it s an assumption implicitly embedded within the ISTQB syllabi is that you are going to receive use cases, not create them. If you look at both the Advanced and Foundation Level syllabi, they talk about use cases as something that test analysts receive, upon which they base their tests. So, rather than trying to cover the entire gamut of use case variation that might exist in the wild and wooly world of software development, I m going to talk about using basic, informal use cases for test design, and talk about using more formalized use cases for test design, and leave out too much discussion about variations. So, assuming we receive a use case, how do we derive tests? Well, at the very least, we should create a test for every workflow, including both the typical and exceptional workflows. If the exceptional workflows were omitted, then you ll need to figure those out, possibly from requirements or some other source. Failing to test exceptions is a common testing mistake when using informal use cases. Creating tests can involve applying equivalence partitioning and boundary value analysis along the way. In fact, if you find a situation where combinations of conditions determine actions, then you might have found an embedded, implied decision table. Covering the partitions, boundaries, and business rules you discover in the use case
3 might result in two, five, ten, twenty, or more test cases per work flow, when you re all done. Remember that I said that a use case has a tangible result. So, part of evaluating the results of the test is verifying that result. That s above and beyond verifying proper screens, messages, input validation, and the like as you proceed through the workflow. Note the coverage criterion implied above: At least one test per workflow, including both typical and exceptional workflows. That s not a formal criterion, but it s a good one to remember as a rule of thumb. What is our underlying bug hypothesis? Remember in decision tables we were looking for combinations of conditions that result in the wrong action occurring or the right action not occurring. With use cases, we re a bit more coarse-grained. Here, we are looking for a situation where the system interacts improperly with the user or delivers an improper result. Figure 1: Informal Use Case Example In Figure 1, we see an example of an informal use case describing purchases from an e- commerce site, like the rbcs-us.com example shown for decision tables in the earlier article. At the top, we have the web site purchase normal workflow. This is the happy path.
4 1. Customer places one or more Items in shopping cart 2. Customer selects checkout 3. System gathers address, payment, and shipping information from Customer 4. System displays all information for User confirmation 5. User confirms order to System for delivery Note that the final result is that the order is in the system for delivery. Presumably another use case having to do with order fulfillment will describe how this order ends up arriving at the customer s home or place of business. We also see some exception workflows defined. For one thing, the Customer might attempt to checkout with an empty shopping cart. In that case, the System gives an error message. For another thing, the Customer might provide an invalid address, payment, or shipping information. On each screen if we re following the typical e-commerce flow the System gives error messages as appropriate and blocks any further processing until the errors are resolved. Finally, the Customer might abandon the transaction before or during checkout. To handle this, the System logs the Customer out after 10 minutes of inactivity. Now, let s look at deriving tests for this use case. In Figure 2, you see the body of the test procedure to cover the typical workflow. (For brevity s sake, I ve left off the typical header and footer information found on a test procedure.)
5 Figure 2: Deriving Tests Example (Typical) As you can see, each step in the workflow has mapped into a step in the test procedure. You can also see that I did some equivalence partitioning and boundary value analysis on the number of items, the payment type, and the delivery address. Because all of these selections are valid, I ve combined them. Note that space-saving approach of describing how to repeat the core steps of the test procedure with variations, rather than a complete re-statement of the test procedure, at the bottom.
6 Figure 3: Deriving Tests Example (Exception) In Figure 3, you see the body of the test procedure to cover the exception flows. You can see that I use equivalence partitioning on the points at which the customer could abandon a transaction. This is a good point to bring up an important distinction, that between logical and concrete test cases. For the ISTQB exam, you ll want to make sure you know the Glossary definitions for these terms. For our purposes here, we can say that a logical or high-level test case describes the test conditions and results. A concrete or low-level test case gives the input data to create the test conditions, and the output data observed in the results. As you just saw in Figure 2 and Figure 3, you can easily translate a use case into one or more logical test cases. However, translation of the logical test case into concrete test cases can require additional documentation. For example, what was the maximum number of items we could put in the shopping cart? We d need some further information, ideally a requirements specification, to know that. What items can we put in shopping cart? Some description of the store inventory is needed. Is it cheating to define logical test cases rather than concrete ones? No, absolutely not. However, notice that, at some point, a test case must become concrete. You have to enter specific inputs. You have to verify specific outputs. This translation from logical test case to concrete test case is considered an implementation activity in the ISTQB
7 fundamental test process. If you choose to leave implementation for the testers to handle during test execution, that s fine, but you ll need to make sure that adequate information is at hand during test execution to do so. Otherwise, you risk delays. So, what s different or additional in a formal use case? Usually, a formal use case contains more information than an informal one. Here, you can see some of the typical elements of a formal use case: ID some use case identifier number Name a short name, like E-commerce Purchase Actor the actor, such as Customer Description a short description of the use case Priority the priority, from an implementation point of view Frequency of use how often this will occur Preconditions what must be true to start the use case normally Typical workflow often like the informal use case, but sometimes broken into two columns, one for the actor actions and one for the system response Exception workflows one for each exception, often also with actor action and system response columns. Postconditions what should be true about the state of the system after the use case completes normally Notice that you can use some of this information as a test analyst. Some, like the priority and frequency of use, you might not use, except during the risk analysis process. Also, notice that the breakdown on the workflows, especially the exception workflows, is finer-grained, so your test traceability can be finer-grained, too.
8 Figure 4: Formal Use Case Example (Part 1) Figure 4 shows the header information on a formal version of the informal use case we saw earlier. Notice that some of the steps of the informal use case became preconditions. This means that the shopping portion of the use case would become its own use case, allowing this use case to focus entirely on the purchase aspects of the e- commerce site. Notice also that we didn t know about that logged in requirement before. That s important information for our testing.
9 Figure 5: Formal Use Case Example (Part 2) Figure 5 shows the main body of the formal use case, the normal workflow and the three exceptions. Notice the normal workflow is a bit shorter now because some of its steps became preconditions. Also, each exception has its own row in the table. Finally, notice that the postcondition is true only if the normal workflow is ultimately completed. Conclusion In this article, I ve shown how to apply use cases to the testing of typical and exceptional workflows. We have looked at decision tables as a way to test detailed business rules, state-based methods to test state-dependent systems, and now use cases for workflows. With these three techniques, you can perform a full range of internal business logic testing. Author Bio With a quarter-century of software and systems engineering experience, Rex Black is President of RBCS ( a leader in software, hardware, and systems
10 testing. For over a dozen years, RBCS has delivered services in consulting, outsourcing and training for software and hardware testing. Employing the industry s most experienced and recognized consultants, RBCS conducts product testing, builds and improves testing groups and hires testing staff for hundreds of clients worldwide. Ranging from Fortune 20 companies to start-ups, RBCS clients save time and money through improved product development, decreased tech support calls, improved corporate reputation and more. As the leader of RBCS, Rex is the most prolific author practicing in the field of software testing today. His popular first book, Managing the Testing Process, has sold over 40,000 copies around the world, including Japanese, Chinese, and Indian releases, and is now in its third edition. His five other books on testing, Advanced Software Testing: Volume I, Advanced Software Testing: Volume II, Critical Testing Processes, Foundations of Software Testing, and Pragmatic Software Testing, have also sold tens of thousands of copies, including Hebrew, Indian, Chinese, Japanese and Russian editions. He has written over thirty articles, presented hundreds of papers, workshops, and seminars, and given about thirty keynote speeches at conferences and events around the world. Rex is the former President of the International Software Testing Qualifications Board and the American Software Testing Qualifications Board.
Introduction Advanced Software Test Design Techniques Decision Tables and Cause-Effect Graphs The following is an excerpt from my recently-published book, Advanced Software Testing: Volume 1. This is a
6 June, 2009 The Magazine for Professional Testers ISSN 1866-5705 www.testingexperience.com free digital version print version 8,00 printed in Germany Security Testing istockphoto/alexandru_lamba istockphoto.com/kutaytanir
Introduction Metrics for Software Testing: Managing with Facts Part 4: Product Metrics In the previous article in this series, we moved from a discussion of process metrics to a discussion of how metrics
Component Outsourcing, Quality Risks, and Testing: Factors and Strategies for Project Managers More and more projects involve more integration of custom developed or commercial-off-the-shelf (COTS) components,
ISTQB Certification: Why You Need It and How to Get It By Rex Black President RBCS and President of ISTQB [Note: This article originally appeared in Software Test and Performance magazine and Testing Experience
Understanding Software Test Cases Techniques for better software testing Josh Kounitz Elementool The content of this ebook is provided to you for free by Elementool. You may distribute this ebook to anyone
1 IBM Software Group IBM Software Group Traceability From Use Cases To Test Cases Peter Zielczynski, Ph.D. The A Consulting Team PZielczynski@tact.com RM14 Agenda Overview of the requirements types Traceability
Use Cases Reference: Craig Larman, Applying UML and Patterns, Ch. 6 Use Case What it is: Text story Widely used to discover and record (mostly functional) requirements What is it about: Some actor(s) using
Test Engineering Foundation Course Outline General Description This course provides test engineers and test managers with the essential ideas, processes, tools and skills they need in order to set themselves
Hiring Great Testers Building an Excellent Test Team Hiring i Great Testers This webinar is excerpted from Managing the Test Process, Third Edition, a book for test managers How do we hire really great
Overview of A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition Overview of: A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition 1 Topics for Discussion
And How These Practices Can Help You Tp5T Top Testing Best tpractices A best practice is an approach to doing something that generally gives good results when applied appropriately and thoughtfully For
By Laura Brandenburg, CBAP Lesson Objective: After completing this lesson, you will understand the role of data modeling in the business analysis lifecycle and why it is important for business stakeholders
User Guide and Tutorial Central Stores Online Ordering System Central Stores Financial Services Western Washington University TABLE OF CONTENTS 1. Introduction... Page 3 2. Finding and Logging into Central
UML TUTORIALS THE USE CASE MODEL www.sparxsystems.com.au Sparx Systems 2004 Page 1/5 describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between
Software testing cmsc435-1 Objectives To discuss the distinctions between validation testing and defect testing To describe the principles of system and component testing To describe strategies for generating
The exam consists of four parts: 1) Testing of general knowledge 25%. Each right question counts 1. Each wrong counts 0.5. Empty counts zero 2) Planning 25%. All sub-questions count equally. 3) Requirements
Model-based Testing: Next Generation Functional Software Testing By Dr. Bruno Legeard Model-based testing (MBT) is an increasingly widely-used technique for automating the generation and execution of tests.
Advanced Test Manager E-learning Course Outline General Description This course provides test managers with advanced skills in test estimation, test planning, test monitoring, and test control. Attendees
IBSwebpro Web Design Services What to Expect From Your Web Design Team Table of Contents Introduction... 3 Glossary of Terms... 4 The Five Stages of Development... 5 Phase 1 Requirements... 6 Phase 2 Pre-Build...
Using a Test Design Tool to Become a Digital Organization Overview: Automating test design reduces efforts and increases quality Automated testing resolves most challenges created by the traditional, manual
Softjourn, Inc. s QA Process Date of Last Update: June 05, 2007 Version: 2.0 Author: Softjourn, Inc. Headquarters 39270 Paseo Padre Pkwy #251 Fremont, CA 94536 USA p: +1.510.744.1528 f: +1. 815.301.2772
Purpose The purpose of this document is to provide guidance on the practice of Modeling and to describe the practice overview, requirements, best practices, activities, and key terms related to these requirements.
BEST PRACTICE Acceptance Test Planning The acceptance test plan basically follows the practices used for developing an overall system test plan. Specifically this section will address: Acceptance Criteria
VIDEO TRANSCRIPT: Content Marketing Analyzing Your Efforts 1 Content Marketing - Analyzing Your Efforts: This is a transcript of a presentation originally given live at the Growth Powered by Risdall Fall
Microsoft Dynamics AX 2012 R3 Retail and e-commerce Licensing Guide Version 2 Updated February 2015 Effective August 2014 Microsoft Dynamics AX 2012 R3 Retail Scenarios Licensing Brief January 2015 Page
1 Data Extraction Guide One of the big advantages of process mining is that it starts with the data that is already there, and usually it starts very simple. There is no need to first set up a data collection
ISTQB Certified Tester Foundation Level Version 2015 American Copyright Notice This document may be copied in its entirety, or extracts made, if the source is acknowledged. #1 When test cases are designed
4. Test Design Techniques Hans Schaefer firstname.lastname@example.org http://www.softwaretesting.no/ 2006-2010 Hans Schaefer Slide 1 Contents 1. How to find test conditions and design test cases 2. Overview of
Mobile Tester Foundation Course Outline General Description This course provides testers and test managers with an understanding of test fundamentals for mobile applications. Attendees will get a brief
CONTINUAL SERVICE IMPROVEMENT: BRINGING IT TO LIFE Author : Gary Case Version : 0 Date : August 2009 Location : Pink Elephant Inc. 1 EXECUTIVE SUMMARY If you are thinking about implementing ITIL processes
The Dangers of Use Cases Employed as Test Cases Bernie Berger This document is intended to provide background support and additional information to the slide presentation at STARWest 2001. I don t consider
BEDIFFERENT ACE G E R M A N Y ACE Germany Implementation Best Practices Scrum Methodology Patrick Willemsen Senior Consultant ARAS Software AG Slide 3 Dilbert says Slide 4 Agenda Agile Methodology An Overview
Enabling e-commerce Creating an online store The term e-commerce refers to buying, selling or ordering goods and services on the Internet. It is a subset of e-business. So e-commerce happens when any commercial
Five Steps Towards Effective Fraud Management Merchants doing business in a card-not-present environment are exposed to significantly higher fraud risk, costly chargebacks and the challenge of securing
Object - Oriented Programming & Design Part IX - UML Use Case Diagrams CSCI 4448 - Spring 2002 Requirements / Use Case Specification Your way of echoing to the customer what you heard him/her say he/she
Test Design Strategies Louise Tamres, CSQE ASQ Software Division Webinar 18 July 2008 1 Objectives Translate requirements into test cases Improve communication by producing models Identify incomplete requirements
Information Technology Project Management by Jack T. Marchewka Power Point Slides by Jack T. Marchewka, Northern Illinois University Copyright 2006 John Wiley & Sons, Inc. all rights reserved. Reproduction
Construction Junction Inventory Management Software Requirements Specification Version 2.0 Summa Technologies October 1st, 2009 Summa Technologies, Inc. 925 Liberty Avenue 6 th Floor Pittsburgh, PA 15222
Introduction Congratulations you ve selected a top-notch e-commerce website solution. But you re not done yet. In fact, the next choice you make will be one of the most important in the process of setting
CENTER FOR QUALITY OF MANAGEMENT JOURNAL TQM, CQM, Mutual Learning and Integration Management Page 5 Thomas H. Lee Using the Methods of Fernando Flores Page 15 An Interview of Jack Reilly Comparisons between
By Carl Dunlap, Cohesion, Inc. Using Digital Signatures in SAP QM This article was provided exclusively to SearchSAP.com by SAPtips, an online, subscriptionbased publication dedicated to SAP implementation
Software Engineering Prof.N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-12 Data Modelling- ER diagrams, Mapping to relational model (Part -II) We will continue
COURSE NAME: Database Management TOPIC: Database Design LECTURE 3 The Database System Life Cycle (DBLC) The database life cycle contains six phases; 1 Database initial study. Analyze the company situation.
I. Automated Banking System Case studies: Outline Requirements Engineering: OO and incremental software development 1. case study: withdraw money a. use cases b. identifying class/object (class diagram)
Cover letter for IRMA 2007 conference Track submitted: Project management and IT Author 1: James L. Goldman Email: email@example.com Affiliation: College of Information Science and Technology, Drexel University
International Journal of Industrial Engineering and Management (), Vol.1 No 4, 2010, pp. 155-161 Available online at www.ftn.uns.ac.rs/ijiem ISSN 2217-2661 Requirements-Based Testing Process in Practice
Load Testing Scenarios Selection Abstract The purpose of Load testing is to identify and resolve all the application performance bottlenecks before they affect the application real users. If a web application
KEY PERFORMANCE INDICATORS (KPIS): DEFINE AND ACT Integrating KPIs into your company s strategy By Jacques Warren WHITE PAPER ABOUT JACQUES WARREN Jacques Warren has been working in online marketing for
Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This
NYU Used Books Marketplace Requirements and Specification Document February 16, 2005 Version 1.7 1 Project Abstract The proposed system will offer a web-based interface for NYU students to conveniently
Sample Exam ISTQB Agile Tester 2014 Foundation Level Extension Version 1.0 Copyright Notice This document may be copied in its entirety, or extracts made, if the source is acknowledged. Table of Contents
2006-672: ASYNCHRONOUS FINITE STATE MACHINE DESIGN: A LOST ART? Christopher Carroll, University of Minnesota-Duluth Christopher R. Carroll earned his academic degrees from Georgia Tech and from Caltech.
Project Initiation Project initiation is the first project management process to execute in the project lifecycle. Many project managers have minimal real-life experience with these activities, and for
Section 3.6 Design Workflow and Process Analysis for CCC This tool introduces the importance of workflow and process improvement in a community-based care coordination (CCC) program, describes the value
Advanced User Stories Reference Materials What is a User Story? THE BASICS User stories are nothing more than a placeholder for conversation. Often referred to as a plain, simple statement of a requirement,
Scope-Pak Project Planning Instructions for conducting a Planning Workshop - in Eight Simple Steps This is simple planning technique that you can use to quickly get your project up and running, organized
Processing Models Of SDLC Mrs. Nalkar Sanjivani Baban Asst. Professor, IT/CS Dept, JVM s Mehta College,Sector 19, Airoli, Navi Mumbai-400708 Nalkar_sanjivani@yahoo.co.in Abstract This paper presents an
MANAGED IT SERVICES Could a Managed Services Agreement Save Your Company Tens of Thousands of Dollars Each Year? A lot of business owners, executives, and managers have a love-hate relationship with managed
(STP) Template Items that are intended to stay in as part of your document are in bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project. This
Minnesota Health Insurance Exchange (MNHIX) 1.2 Plan September 21st, 2012 Version: FINAL v.1.0 11/9/2012 2:58 PM Page 1 of 87 T A B L E O F C O N T E N T S 1 Introduction to the Plan... 12 2 Integration
IBSwebpro Web Design Services ecommerce Website Design Projects ecommerce Website Design Projects Description of Services Our ecommerce Website design projects are ideal for businesses with a strong desire
Exploratory Testing All genuine testers do exploratory testing. Some are really good at it. A few can effectively explain and teach it. More of us can learn to do it well, and to explain and teach it Observation
Software development White paper October 2007 The role of integrated requirements Jim Heumann, requirements evangelist, IBM Rational 2 Contents 2 Introduction 2 What is integrated requirements management?
Business Process Flow and s Prepared by Alice Bouché President, January 23, 2006 Overview Business Process Flow Swim lane approach s Unified Modeling Language (UML) Textual specification Style Techniques
2010-02-01 To Be (Automated) or Not To Be (Manual): A Dilemma for Small Development Shops? Automated software testing has long been an integral part of big software development organizations but is often
Document: TR.96.03a This Version Date: October 26, 1998 Version: 2 Previous Version Date: April 26, 1996 Basic Use Case Template Alistair Cockburn email: firstname.lastname@example.org home page: http://alistair.cockburn.us
6 A User Story "It is better to take many small steps in the right direction than to make a great leap forward only to stumble backward." Chinese Proverb The triad meets to develop stories from features.
IBM SPSS Statistics How to get more value from your survey data Discover four advanced analysis techniques that make survey research more effective Contents: 1 Introduction 2 Descriptive survey research
Chapter 6: Developing a Proper Audit Trail for your EBS Environment In Chapter 2, we looked at the inherent architecture of EBS and some implications regarding the lack of a detailed audit trail. Three
9 Development methods AQA Unit 3 Section 8 When a new computer-based system is introduced by a business, it is usually to replace an old system which may be a manual system or an out-dated, computer-based
Sitecore E-Commerce Cookbook Rev: 2010-11-12 Sitecore E-Commerce Fundamental Edition 1.0.1 Sitecore E-Commerce Cookbook A marketer's guide to the Sitecore E-Commerce Fundamental Edition Sitecore E-Commerce
Homework 5: Use Cases, Sequence Diagram, and State Diagram Name : Student Number : Laboratory Time : Objectives Create a Use Case Diagram in Rational Software Development Platform Create a Sequence Diagram
Functional Test Plan Template Introduction: How to Use This Tool This tool is intended to be used as an aid in creating a functional test plan. An application s functional test plan defines how functional
Google Analytics Guide 1 We re excited that you re implementing Google Analytics to help you make the most of your website and convert more visitors. This deck will go through how to create and configure
Managing Agile Projects in TestTrack GUIDE Table of Contents Introduction...1 Automatic Traceability...2 Setting Up TestTrack for Agile...6 Plan Your Folder Structure... 10 Building Your Product Backlog...
Successful Testing on Agile Projects Ail Agile Testing Chll Challenges Agile lifecycles are becoming common Every lifecycle affects testing What test strategies work well with Agile methodologies? Risk-based
6 Software Quality Assurance/Process and Product Quality Assurance With CMM, the purpose of Software Quality Assurance is to provide management with appropriate visibility into the process being used by
SUBJET Version: 1 Which of the following statements best describes Business nalysis? Business nalysis provides the reasoning for initiating a project. Business nalysis is the strategic part of the project
4. Applying UML Subject/Topic/Focus: Case Study of a Point of Sale Summary: Use Cases Class Diagrams Interaction Diagrams Literature: Craig Larman; Applying UML and Patterns, Prentice Hall, 997 4. Case
November 5 th, 2015 How to Elaborate Requirements Through Use Cases and User Stories Mar$n Schedlbauer, Ph.D., CBAP, CSM, PSM Requirements Techniques Narrative Statements often in the form of The system/solution
Introduction to Systems Analysis and Design What is a System? A system is a set of interrelated components that function together to achieve a common goal. The components of a system are called subsystems.
D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013 The purpose of these questions is to establish that the students understand the basic ideas that underpin the course. The answers
TEXAS DEPARTMENT OF INFORMATION RESOURCES System Development Life Cycle Guide Version 1.1 30 MAY 2008 Version History This and other Framework Extension tools are available on Framework Web site. Release
Improving Software Quality: Nine Best-Practices for Test Automation The double-edged sword of go-to-market quickly with as few resources as possible causes many software development teams to cut corners
Social Return on Investment Valuing what you do Guidance on understanding and completing the Social Return on Investment toolkit for your organisation 60838 SROI v2.indd 1 07/03/2013 16:50 60838 SROI v2.indd