1 Business Analysis for Practitioners - Requirements Elicitation and Analysis (Domain 3)
2 COURSE STRUCTURE Introduction to Business Analysis Module 1 Needs Assessment Module 2 Business Analysis Planning Module 3 Requirements Elicitation and Analysis Module 4 Traceability and Monitoring Module 5 Solution Evaluation Module 6
3 COURSE OBJECTIVE At the end of this course, you will understand what business analysis is all about, why it is essential to the success of any project and how to perform it on your projects...
4 Business Analysis for Practitioners MODULE 4
5 MODULE OBJECTIVE
6 REQUIREMENTS ELICITATION AND ANALYSIS Requirement elicitation involves: -Drawing out information from stakeholders and other sources about the causes of the business problem or the reasons for addressing a current opportunity -Drawing out information that will be used to derive sufficient level of requirements to enable solution development and implementation
7 REQUIREMENTS ELICITATION If adequate requirements elicitation had been done, do you think the odds for that failure would have been greatly reduced? AND ANALYSIS The BA focuses highly on requirements management because this is fundamental to project success scope, cost and schedule Ever been on a project team that failed?
8 Importance of Eliciting Information Information is not only elicited to generate requirements or answer questions from the solution team, but the information becomes the basis to effectively complete other business analyst tasks, such as: Support executive decision making. Apply influence successfully. Assist in negotiation or mediation. Resolve conflict. Define problems.
9 REQUIREMENTS ELICITATION AND ANALYSIS Eliciting requirements and analysis involves: Develop the elicitation plan Prepare for elicitation Conduct elicitation activities Elicitation techniques Document outputs from elicitation activities Complete elicitation Elicitation challenges
10 REQUIREMENTS ELICITATION AND ANALYSIS Eliciting requirements and analysis involves: Plan for Elicitation - Develop the Elicitation Plan (Finding Information, Techniques for Eliciting Information and Sequencing the Elicitation Activities) Prepare for Elicitation - Determine the Objectives - Determine the Participants - Determine the Questions for the Session
11 Develop the Elicitation Plan Some of the elements in an elicitation plan include but are not limited to: What information to elicit. What does the business analyst need to know in order to define the problem, solve the problem, or answer the question? Where to find that information. Where is that information located: in what document, from what source, in whose mind? Identify who has the information or where it is located. How to obtain the information. What method will be used to acquire the information from the source? Sequencing the Elicitation Activities. In what order should the elicitation activities be sequenced to acquire the needed information?.
12 Example of Completed Elicitation Plan
13 Prepare for Elicitation Elicitation preparation is the planning performed to conduct an effective elicitation session. Preparation notes can be used to measure the progress achieved in a session against what was planned to be achieved and can be used to adjust expectations for future sessions. 1. Determine the Objectives 2. Determine the Participants 3. Determine the Questions for the Session
14 Example of Preparation Notes for an Elicitation Session
15 REQUIREMENTS ELICITATION AND ANALYSIS Eliciting requirements and analysis involves: Conduct Elicitation Activities - Introduction - Body (Types of Questions, How to Ask the Right Questions and Listening) - Close - Follow-Up
16 Conduct Elicitation Activities There are four stages during the actual elicitation activity in which information is gathered: Introduction. The introduction sets the stage, sets the pace, and establishes the overall purpose for the elicitation session. Body. The body is where the questions are asked and the answers are given. Close. The close provides a graceful termination to the particular session. Follow-Up. The follow-up is where the information is consolidated and confirmed with the participants.
17 Types of Questions The types of questions that can be asked are as follows: Open-ended question. A question that allows the respondents to answer in any way they desire. Closed-ended question. A question that calls for a response from a limited list of answer choices. Types of closed-ended questions are forced choice, limited choice, and confirmation. Contextual question. A question that requires an answer regarding the subject at hand; namely, the problem domain or the proposed solutions. Context-free question. A question that may be asked in any situation. Context-free questions are also used as lead-ins to obtain information to define the solution.
18 REQUIREMENTS ELICITATION AND ANALYSIS Eliciting requirements and analysis involves: Elicitation techniques - Brainstorming - Document Analysis - Facilitated Workshops - Focus Groups - Interviews - Observation - Prototyping - Questionnaires and Surveys
20 Interviews There are two basic types of interviews: Structured interviews. Begin with a list of prepared questions with the goal of asking and obtaining answers to every question on the list or within the allotted time. Unstructured interviews. Begin with a list of prepared questions, but the only question that is definitely asked is the first. After that, the subsequent questions are based on the answers to the previous questions. Interviews may be conducted : Synchronous Interviews. These interviews are performed live or in real time. These can be conducted in a number of ways, such as face-to-face where the business analyst and the interviewee are in the same room, or they can be conducted over the telephone, with video conferencing, internet collaboration tools, etc. The key is that the interview is being conducted with the interviewee and interviewer at the same time. Asynchronous interviews. These interviews are not conducted in real time; the business analyst or interviewer is not involved in the interview at the same time as the interviewee.
21 Observation Observation is a technique that provides a direct way of viewing people in their environment to see how they perform their jobs or tasks and carry out processes. It is particularly helpful for detailed processes when people who use the product have difficulty or are reluctant to articulate their requirements. There are four types of observation; each is used in a different situation: Passive observation Active observation. Participatory observation. Simulation.
22 Prototyping Prototyping is a method of obtaining early feedback on requirements by providing a working model of the expected product before building it. A prototype can be a mockup of the real result as in an architectural model, or it can be an early version of the product itself. The key element to prototyping is the iterative process of creating the prototype, reviewing it with the pertinent stakeholders, making adjustments and modifications to the prototype, and reviewing it again. This process continues until all parties agree that the prototype has provided the needed information to the solution team.
23 Prototyping There are two types of prototypes.: Low-Fidelity and High-Fidelity Prototype Low-fidelity prototype. Low-fidelity prototypes are completed with a pen and paper, marker and whiteboard, or modeling tool on the computer. Examples of low-fidelity prototypes include: Wireframes, Mockups of interface screens or reports, Architectural renderings of a building, Floor plans, Sketches of a new product, and Any design that is evolving.
24 Prototyping High-fidelity prototyping. High-fidelity prototypes create a representation of the final finished product There are two types of high-fidelity prototypes: throwaway and evolutionary. Throwaway prototypes are discarded once the interface has been confirmed. This is similar to the product prototypes developed by manufacturing companies. The prototype is used to help define the tools and process for manufacturing the product but the prototype itself is not sold. Evolutionary prototypes are the actual finished product in process. The first prototype that is reviewed is the earliest workable version of the final product. With each successive prototyping session, more functionality is added or the existing functionality is modified to achieve a higher level of quality. Note: With agile project teams, evolutionary development is how the product is built. The work is not considered to be a prototype but is an actual slice of the product itself.
25 Prototyping Two examples of prototyping techniques are: Storyboarding. Storyboarding is a prototyping technique showing sequence or navigation through a series of images or illustrations. Storyboards are graphical representations that represent the sequence of events. Storyboards are typically static and thrown away. Prototypes focus on what the product will look and feel like, while storyboards focus on the experience. Wireframes. A wireframe is a diagram representing a static blueprint or schematic of a user interface and is used to identify basic functionality. A wireframe separates the look and feel of a site from its function. It presents a stripped-down, simplified version of the page, devoid of distractions. The purpose of the wireframe is to illustrate the flow of specific logical and business functions by identifying all entry and exit points or actions the users will experience.
26 Difference between Wireframe, Mockup and Prototype
27 Wireframe Example
28 Mockup Example
29 Prototype Example
30 Design Process Example
31 REQUIREMENTS ELICITATION AND ANALYSIS Eliciting requirements and analysis involves: Document Outputs from Elicitation Activities Complete Elicitation Elicitation Issues and Challenges
32 REQUIREMENTS ELICITATION AND ANALYSIS Stakeholders not providing sufficient detail to develop the solution Non accessibility to appropriate stakeholders ELICITATION CHALLENGES Stakeholders having difficulties expressing their requirements clearly Stakeholders not knowing what they want
33 REQUIREMENTS ELICITATION AND ANALYSIS Eliciting requirements and analysis involves: Analyze requirements Model and refine requirements Document the solution requirements Validate Requirements Verify Requirements Approval Sessions Resolving Requirements-related conflicts
34 REQUIREMENTS ELICITATION AND ANALYSIS Eliciting requirements and analysis involves: Analyze Requirements - Plan for Analysis (Analysis Defined, Thinking Ahead about Analysis and What to Analyze)
35 REQUIREMENTS ELICITATION AND ANALYSIS Eliciting requirements and analysis involves: Model and refine requirements - Description of Models - Purpose of Models - Categories of Models - Selection of Models - Use of models to refine requirements - Modelling Languages - Scope Models (Goal Model and Business Objective Model, Ecosystem Map, Context Diagram, Feature Model and Use Case Diagram)
36 Description and Purpose of Models Description The model refers to a visual representation of information, both abstract and specific, that operates under a set of guidelines in order to efficiently arrange and convey a lot of information in a concise manner. In its simplest form, a business analysis model is a structured representation of information. Purpose Business analysis models are helpful to find gaps in information and to identify extraneous information. Models provide context to better understand and more clearly convey information. Requirements are modeled and refined to achieve further clarity, correctness, and to elicit additional information to define the details necessary for the product to be built.
37 Categories of Models Model and refine requirements Models are visual representations of abstract & specific information which help refine requirements Scope models (e.g. Ecosystem maps) Process models (e.g. Process flow) Rule models (e.g. Decision tree and tables) Data models (e.g. Entity relationship diagram) Interface models (e.g. User interface flow)
38 REQUIREMENTS ELICITATION AND ANALYSIS Eliciting requirements and analysis involves: Model and refine requirements - Process Models (Process Flow, Use Case and User Story) - Rule Models (Business Rules Catalogue, Decision Tree and Decision Table) - Data Models (Entity Relationship Diagram, Data Flow Diagrams, Data Dictionary, State Table and State Diagram) - Interface Models (Report Table, System Interface Table, User Interface Flow, Wireframes and Display- Action-Response
39 Models Organized by Category
40 Modeling Languages and Usage
41 Scope Model
42 Goal Model and Business Objective Model
43 Ecosystem Map
44 Context Diagram
45 Feature Model
46 Use Case Diagram
47 Process Model
48 Process Flow
49 Use Case
50 User Story
51 Rule Model
52 Business Rules Catalog
53 Decision Tree
54 Decision Table
55 Data Model
56 Entity Relationship Diagram Crows Foot and 1 to N notation
57 Data Flow Diagrams
58 Data Dictionary
59 State Table
60 State Diagram
61 Interface Model
62 Report Prototype
63 Top-Level Elements in a Report Table
64 Field Elements in a Report Table
65 System Interface Table
66 User Interface Flow
68 Display-Action Response Model
69 REQUIREMENTS ELICITATION AND ANALYSIS Eliciting requirements and analysis involves: Document the solution requirements - Why Documentation is Important - Business Requirements Document - The Solution Documentation (Requirements and Categorization) - Requirements Specification (Documenting Assumptions and Documenting Constraints) _ Guidelines for Writing Requirements (Functional Requirements)
70 Why Documentation is Important Documented requirements serve a multitude of purposes, such as the following: Baseline to validate the stakeholder needs; Baseline definition of the solution for the business problem or opportunity; Primary input to the design team, the developers, testers, and quality assurance; Basis for user manuals and other documentation whether written or embedded; Supporting detail for contractual agreements, when applicable (e.g., the requirements are a core input to a statement of work (SOW) for a request for proposal (RFP)); Starting point for the evolution of the solution; Foundation for reusability by other project teams who need an understanding of the project details while it is in process or after implementation; and Baseline for an audit of regulated industries and high-risk projects that are required to have documented requirements.
71 Business Requirement and Solution Document Business requirements are the goals, objectives, and higher-level needs of the organization and provide the rationale for a new project. Business requirements recognize what is critical to the business and why it is critical before defining a solution. Solution documentation is the documentation that is comprised of the features, functions, and characteristics of the product or service that will be built to meet the business and stakeholder requirements. It serves as the blueprint for the product that the solution team is being asked to build. The solution documentation may be rendered in any number of forms. Some common forms include: Requirements document, which may be a business requirements document and/or a functional requirements specification and/or a system or software requirements specification, etc.; Deck of user stories written; Set of use cases with accompanying nonfunctional requirements; or List of items on a product backlog.
72 Product and Project Requirement While product requirements describe what is being built or the outcome of the project or solution to the business problem, project requirements describe the constraints and necessities for successful completion of the project. For example, product requirements describe the length and width of the sidewalk to be constructed in front of a building, along with such aspects as color and texture. The project requirements for laying the sidewalk could include the number of laborers required, qualifications of the laborers to handle the equipment, size of the equipment, time frame for usage, and any restrictions on labor hours. Product requirements are the responsibility of the business analyst. Project requirements are the responsibility of the project manager.
73 Categorization Requirement categories are used to help group and structure requirements within the documentation. The process of categorization helps expose vague, misstated, ambiguous, or otherwise poorly written requirements. Categorization filters out the bad or poorly written requirements. Examples of possible filters are: Scope filter. Determine whether a requirement or information is in scope, out of scope, or unknown. Functional filter. Once the functional categories have been determined, any defined functional requirement not fitting into one of the categories can be filtered out, revised, or discarded. Prioritization filter. An arbitrary level of priority (e.g., needs, wants, and desires), is defined and used as a filter to determine which requirements stay or are removed. Testability filter. All requirements need to be testable, and all requirements should be examined to determine if they are testable. Any requirements that are not testable are filtered out and need to be revised.
74 Guidelines for Writing Requirements Information needs to be transcribed into high-quality, well-formatted requirements. Requirements that are well written are of higher value to the solution developer and overall project team, because these will be clear, concise, and reduce conflict and confusion on what needs to be delivered. A well-formatted requirement consists of the following elements: Condition, Subject, Imperative, Active verb, Object, Business rule (optional), and Outcome (optional). Example A well-formed detail level requirement might be as follows: When the new account button is pressed (condition), the system (subject) will (imperative) display (active verb) the new account entry screen (object) allowing the creation of a new account (outcome).
75 Guidelines for Writing Requirements The following characteristics serve as a checklist when reviewing requirements to ensure they are of high quality. 1. Unambiguous 2. Precise
76 Guidelines for Writing Requirements The following characteristics serve as a checklist when reviewing requirements to ensure they are of high quality. 1. Unambiguous 2. Precise 3. Consistent 4. Correct 5. Complete 6. Measurable 7. Feasible 8. Traceable 9. Testable
77 Guidelines for Writing Requirements
78 Guidelines for Writing Requirements
79 REQUIREMENTS ELICITATION AND ANALYSIS Eliciting requirements and analysis involves: Document the solution requirements - Why Documentation is Important - Business Requirements Document - Prioritizing Requirements (Prioritization Schemes) - Technical Requirements Specification - Documenting with Use Cases - Documenting with User Stories - Backlog Items
80 Prioritization Techniques MoSCoW. MoSCow establishes a set of prioritization rules which are: Must haves (fundamental to project success), Should haves (important, but the project success does not rely on them), Could haves (can easily be left out without impacting the project), and Won t haves (not delivered this time around). Multivoting Time-boxing Weighted ranking
81 REQUIREMENTS ELICITATION AND ANALYSIS Eliciting requirements and analysis involves: Validate Requirements - The Concept of Continual Confirmation - Requirements Walkthrough Verify Requirements - Peer Review - Inspection
82 REQUIREMENTS ELICITATION AND ANALYSIS Validate Requirements process ensures all requirements accurately reflect the intent of the stakeholder. It is usually performed via requirements walkthrough or concept of continual confirmation Verify Requirements process reviews the requirements for errors and quality criteria It is usually performed via peer review or inspection.
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
Federal GIS Conference February 9 10, 2015 Washington, DC Best Practices for Collecting User Requirements Gerry Clancy Glenn Berger Requirements Provide direction for program success Why Requirements are
The IDN Variant TLD Program: Updated Program Plan 23 August 2012 Table of Contents Project Background... 2 The IDN Variant TLD Program... 2 Revised Program Plan, Projects and Timeline:... 3 Communication
Requirements Engineering Process Requirement A description of a service that the system is expected to provide and the constraints under which it must operate. 1 Requirement Types Functional Requirement
Tracking System for Job Applicants Sprint Schedule and Overview By Erik Flowers This overview is to determine and develop the Tracking System for Job Applicants (TSJA), to be used by Recruiters/Managers
Copyright 2016 Loft9. All Rights Reserved. 1 Loft9Consulting.com LOFT9 BUSINESS INSIGHTS Requirements Gathering: User Stories Not Just an Agile Tool Copyright 2016 Loft9. All Rights Reserved. 2 Loft9Consulting.com
Quality Software Requirements By J. Chris Gibson The information contained within this document has been gathered from a variety of sources and practices observed by the development team at Protera Software
USER-CENTERED DESIGN WHAT IS USER-CENTERED DESIGN? User-centered design (UCD) is an approach to design that grounds the process in information about the people who will use the product. UCD processes focus
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
Written Date : January 27, 2016 One of the most difficult problem in software development is capturing precisely what you want to build. Inaccurate requirement will end-up with significant delay, rework
ASTQB Advance Test Analyst Sample Exam Answer Key and Rationale Total number points = 120 points Total number points to pass = 78 points Question Answer Explanation / Rationale Learning 1 A A is correct.
Foundation Level Syllabus Usability Tester Sample Exam s Version 2017 Provided by German Testing Board Copyright Notice This document may be copied in its entirety, or extracts made, if the source is acknowledged.
BCS Certificate in Requirements Engineering Syllabus Version 2.3 March 2015 Change History Any changes made to the syllabus shall be clearly documented with a change history log. This shall include the
Software Engineering: A Practitioner s Approach, 6/e Chapter 7 Requirements Engineering copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student
analysis of stakeholders, field studies ANALYZE Problem scenarios claims about current practice metaphors, information technology, HCI theory, guidelines DESIGN Activity scenarios Information scenarios
BPS Suite and the OCEG Capability Model Mapping the OCEG Capability Model to the BPS Suite s product capability. BPS Contents Introduction... 2 GRC activities... 2 BPS and the Capability Model for GRC...
Course Syllabus for 3 days Expert led Enterprise Architect hands-on training "An Architect, in the subtlest application of the word, describes one able to engage and arrange all elements of an environment
12 SDD Task 1: RAD Programming Group Task Due Date: 1/12/2017 Date Distributed: 31/10/2017 Task Weighting: 15% Outcomes H4.2 applies appropriate development methods to solve software problems H5.1 applies
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
Making IT good for society BCS Level 3 Certificate in Programming Syllabus QAN 603/1192/7 Version 3.2 February 2018 This is a United Kingdom government regulated qualification which is administered and
3 Prototyping and Iterative Evaluations Viktoria Pammer-Schindler March 15, 2016 Prototyping and Iterative Evaluations 1 Days and Topics March 1 March 8 March 15 April 12 April 19/21 April 26 (10-13) April
BCS Certificate in Requirements Engineering Extended Syllabus Version 2.5 May 2017 This professional certification is not regulated by the following United Kingdom Regulators - Ofqual, Qualification in
General Assembly Course Curriculum USER EXPERIENCE DESIGN User Experience Design Table of Contents 3 Overview 4 Students 5 Curriculum Projects & Units 11 Frequently Asked Questions 12 Contact Information
ADD 3.0: Rethinking Drivers and Decisions in the Design Process Rick Kazman Humberto Cervantes SATURN 2015 Outline Presentation Architectural design and types of drivers The Attribute Driven Design Method
Foundation Level Syllabus Usability Tester Sample Exam Version 2017 Provided by German Testing Board Copyright Notice This document may be copied in its entirety, or extracts made, if the source is acknowledged.
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,
Chapter 12 Systems Design McGraw-Hill/Irwin Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Objectives Describe the design phase in terms of your information building blocks. Identify
Understanding and Implementing Stakeholder Needs: the Integration of Rational ClearQuest and Rational RequisitePro Rational Software White Paper Table of Contents Introduction... 1 Background... 1 From
Software Development Methodologies Lecturer: Raman Ramsin Lecture 8 Agile Methodologies: XP 1 extreme Programming (XP) Developed by Beck in 1996. The first authentic XP book appeared in 1999, with a revised
DSDM Trainer-Coach Candidate Guidelines Version Jan-16 I help others to do it right 1 INTRODUCTION... 3 2 CERTIFICATION OF DSDM TRAINER-COACHES I HELP OTHERS TO DO IT RIGHT... 4 2.1 GENERAL... 4 2.2 DSDM
July 21, 2016 What is UX? BA & UX roles Design Thinking User Research MVP Personas Customer Experience Maps BA + UX Collaboration Tools Resources UX + BA User Experience & Business Analysis Jeanne Petty
BCS Foundation Certificate in Systems Development Syllabus Version 2.6 March 2017 This qualification is not regulated by the following United Kingdom Regulators - Ofqual, Qualification in Wales, CCEA or
Agile Software Development Agile UX Work Kati Kuusinen Researcher @ TUT / Pervasive / IHTE firstname.lastname@example.org Contents 1. Introduction / Motivation 2. Agile software development 3. User experience work
EVALUATION AND APPROVAL OF AUDITORS Deliverable 4.4.3: Design of a governmental Social Responsibility and Quality Certification System 1 TABLE OF CONTENTS 1. Scope and field of Application 3 2. Normative
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
Prototyping Unit 4 Learning outcomes Understand the uses of different types of prototypes for different kinds/stages of design and be able to choose appropriately Know the basic techniques for low-fidelity
The LUCID Design Framework (Logical User Centered Interaction Design) developed by Cognetics Corporation LUCID Logical User Centered Interaction Design began as a way of describing the approach to interface
CASA External Peer Review Program Guidelines Table of Contents Introduction... I-1 Eligibility/Point System... I-1 How to Request a Peer Review... I-1 Peer Reviewer Qualifications... I-2 CASA Peer Review
Human-Computer Interaction CA357 Lecture 7 More on Prototyping Overview By the end of the session, you should be aware of: Design Importance of prototyping Low fidelity vs High fidelity prototyping Why
INTERNATIONAL STANDARD ISO/IEC/ IEEE 26515 First edition 2011-12-01 Corrected version 2012-03-15 Systems and software engineering Developing user documentation in an agile environment Ingénierie du logiciel
Scenarios, Storyboards, Wireframes, Critique Jon Kolko Professor, Austin Center for Design Scenarios Creating a written story that explains how a person will use a product, service, or system to achieve
Extended version of I-USED 2009 workshop paper Criteria for selecting methods in user-centred design Nigel Bevan Professional Usability Services 12 King Edwards Gardens, London W3 9RG, UK email@example.com
RefineM s January 2014 Lunch & Learn Webinar Writing Agile User Stories NK Shrivastava, PMP, RMP, ACP CEO/Consultant - RefineM Agenda 1. What is Virtual Lunch & Learn 2. Your expectations from this webinar
Introducing Interactive Systems Design and Evaluation: Usability and Users First Ahmed Seffah Human-Centered Software Engineering Group Department of Computer Science and Software Engineering Concordia
Course Summary Description In this course, you will perform evaluations of organizational policies, procedures, and processes to ensure that an organization's information systems align with overall business
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
Morgan Landis Morgan@ContentedDesign.com 614.636.0544 1 Design Thinker. Information Architect. Experience Designer. My specialty is asking the right questions. I work collaboratively to help understand
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
Concepts of Usability Usability Testing What is usability? How to measure it? Fang Chen ISO/IS 9241 Usability concept The extent to which a product can be used by specified users to achieve specified goals
Elements of Requirements Style Sponsored by: Karl Wiegers Principal Consultant, Process Impact www.processimpact.com Sponsor: Seilevel Published in 2012: Visual Models for Software Requirements Karl and
May 2010 PPG Color Launch Process Accelerates Timelines for Development and Deployment of Coatings for Consumer Products. Inspire Market Feedback/Sales Design Color Develop Designer Mass Production Marketing
Unit 3 Building a basic client website Timing: 15 23 hours Unit overview In this unit, student teams work on a project to build a website for a client. All student teams build the same site. The instructor
SEG3201 Basics of the Requirements Process Based on material from: I Bray: An introduction to Requirements Engineering Gerald Kotonya and Ian Sommerville: Requirements Engineering Processes and Techniques,
HCI Research Methods Ben Shneiderman firstname.lastname@example.org Founding Director (1983-2000), Human-Computer Interaction Lab Professor, Department of Computer Science Member, Institute for Advanced Computer Studies
Ready for Scrum? Steve Hutchison DISA T&E Presentation Tasks Backlog In Progress Done Scrum Overview Role of Testing in Scrum Agile Testing Summary 2 Scrum Overview Software development framework focused
Hippo Software BPMN and UML Training Icon Key: www.hippo-software.co.uk Teaches theory concepts and notation Teaches practical use of Enterprise Architect Covers BPMN, UML, SysML, ArchiMate Includes paper
SEG3101 (Fall 2010) Purpose and Structure of Requirements Specifications (following IEEE 830 Standard) Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides by Gunter Mussbacher (2009) with
chapter 6 HCI in the software process HCI in the software process Software engineering and the process for interactive systems Usability engineering Iterative and prototyping Design rationale the software
HCI in the software process chapter 6 HCI in the software process Software engineering and the process for interactive systems Usability engineering Iterative and prototyping Design rationale the software
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
#MPD6 #PMTheMusical Project Management: The Musical! Hello! Let s begin with a classic. Contracting Scope You must spell out the scope. Cost Define the payment terms Dates You re unavailable. Clear Deliverables
DSDM Agile Professional Candidate Guidelines October 2016 I do it right 1 INTRODUCTION 3 2 DSDM AGILE PROFESSIONAL CERTIFICATION I do it right 3 2.1 General 3 2.2 DSDM Version and Examinable Topics 3 2.3
SEG3101 (Fall 2010) Basics : the Requirements Engineering Process Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides prepared by Gunter Mussbacher with material from: Sommerville & Kotonya
When Recognition Matters EXAM PREPARATION GUIDE PECB Certified ISO 37001 Lead Auditor www.pecb.com The objective of the Certified ISO 37001 Lead Auditor examination is to ensure that the candidate possesses
Indra Tobing What is IS Information architecture is the term used to describe the structure of a system, i.e the way information is grouped, the navigation methods and terminology used within the system.
Chapter 12: Introduction: TOTAL QUALITY MANAGEMENT - II Quality Management System (QMS) Dr. Shyamal Gomes American National Standard Institute (ANSI) and American Society for Quality Control (ASQC) define
Advanced Security Tester Course Outline General Description This course provides test engineers with advanced skills in security test analysis, design, and execution. In a hands-on, interactive fashion,
EE/CpE322 Lecture 3 Bruce McNair Based on Engineering Design: A Project-Based Introduction (the 3 rd ed.), by C.L. Dym and P. Little A Model of the Design Process Stage 1: Problem Definition Input: Client
Columbia University Libraries / Information Services Digital Library Collections (Beta) Cognitive Walkthrough Evaluation by Michael Benowitz Pratt Institute, School of Library and Information Science Executive
Amazon AWS for AI Model Management, Training, and Testing ROLE: Lead UX Designer DELIVERABLES: System Sitemap Wireframes Mockups VISION TEAM To make AI more accessible to the masses by creating a platform
Skill Category 6 - Summary Walkthroughs, Checkpoint Reviews and Inspections The following topics will be discussed in this Skill Category: Purpose of Reviews Review Types Prerequisites to Reviews Conducting
Design, Ideation, and Prototyping Why User Centered Design is important How Prototyping helps User Centered Design System Centered Design System Centered Design What can be built easily on this platform?
User-centered design in technical communication Information designer & information architect Sharing knowledge is better than having it. Tekom - TC Europe November 19-20, 2003 Nov. 19-20, 2003 User-centered
Chapter 5 Systems Analysis McGraw-Hill/Irwin Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Objectives Define systems analysis and relate it to the scope definition, problem analysis,
EXAM PREPARATION GUIDE PECB Certified ISO/IEC 17025 Lead Auditor The objective of the PECB Certified ISO/IEC 17025 Lead Auditor examination is to ensure that the candidate possesses the needed expertise
Name of Certifying Body Address of Certifying Body Case number Date of assessment With several locations Yes No Assessed locations: (Name)/Address: (Name)/Address: (Name)/Address: Assessed area (technical
When Recognition Matters EXAM PREPARATION GUIDE PECB Certified ISO/IEC 20000 Lead Auditor www.pecb.com The objective of the Certified ISO/IEC 20000 Lead Auditor examination is to ensure that the candidate
Chapter 2 Web Development Overview Presented by Thomas Powell Slides adopted from HTML & XHTML: The Complete Reference, 4th Edition 2003 Thomas A. Powell Five Pillars of Sites Web sites have five aspects
Cognitive Disability and Technology: Universal Design Considerations Clayton Lewis Coleman Institute for Cognitive Disabilities RERC-ACT email@example.com Prepared for AUCD Training Symposium,