Testing Requirements What are the requirements for a ripe apple?

Slides:



Advertisements
Similar presentations
Standard Work Making the “new way” become the standard way
Advertisements

What colour is the house on the hill? Waterloo – Wellington IIBA Chapter presentation April 11, 2007 David Milne.
1 Presented By: Sonya Hawkins.  Discuss Scope  Discuss Requirements 2.
Tree Diagrams 1. Learning Objectives Upon completing this module, you will be able to:  Understand the purpose and use of a Tree Diagram (TD)  Construct,
Evaluating Requirements. Outline Brief Review Stakeholder Review Requirements Analysis Summary Activity 1.
CS 411W - Notes Product Development Documentation.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
Plancher til Anskaffelse og kravspecifikation, Forår 2007 Lauesen: Software requirements - Styles and techniques 9. Checking and validation De fleste af.
Requirements (recap)‏
Evaluating Requirements
Business research methods: data sources
This work is licensed under a Creative Commons Attribution 3.0 Unported LicenseCreative Commons Attribution 3.0 Unported License (CC-BY). Project Management.
Project Documentation and its use in Testing JTALKS.
socio-organizational issues and stakeholder requirements
Chapter 4 Capturing the Requirements 4th Edition Shari L. Pfleeger
Problem solving in project management
CMSC 345 The Requirements Specification. Why do we need requirements Without the correct requirements, you cannot design or build the correct product,
Requirements/Systems analyst
Parliamentary Committees in Democracies: Unit 4 Research Services for Parliamentary Committees.
Slides for Software requirements Styles and techniques Soren Lauesen 9. Checking and validation August 2006 © 2002, Pearson Education retains the copyright.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
A GENERIC PROCESS FOR REQUIREMENTS ENGINEERING Chapter 2 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia.
Introduction to the Requirements Document
Testing Requirements Make the Requirement Measurable Quantifiable and non-Quantifiable –Requirements test 1 Keeping track Coherence and Consistency –Requirements.
Copyright 2010, The World Bank Group. All Rights Reserved. Development of Training and Procedural Manuals Section A 1.
Lecture 7: Requirements Engineering
Systems Life Cycle. Know why it is necessary to evaluate a new system Understand the need to evaluate in terms of ease-of- use, appropriateness and efficiency.
Requirements Reference: Chapters 5, 6, & 8. CMSC 345, Fall Objectives To introduce the concepts of user and system requirements To explain functional.
Requirements Engineering Requirements Elicitation Process Lecture-6.
Requirement Handling
Understanding Task Analysis
12/10/15.  It is a Cross Life Cycle Activity (CLCA) that may be performed at any stage ◦ In fact, some part of it (e.g. risk analysis and management)
Capturing the requirements  Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the.
(SRS) SOFTWARE REQUIREMENT SPECIFICATION(SRS) 1. Topics to be discussed.. What is an SRS? Purpose of an SRS Who reads the SRS? Who writes the SRS? Characteristics.
By Germaine Cheung Hong Kong Computer Institute
Project management Topic 1 Project management principles.
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Quick Write Reflection How will you implement the Engineering Design Process with your students in your classes?
Lecture 13.  Failure mode: when team understands requirements but is unable to meet them.  To ensure that you are building the right system Continually.
Unit Syllabus Definition Importance Types of Feasibility study Technical Operational Resource Legal/Ethical Economical.
Winter 2007SEG2101 Chapter 31 Chapter 3 Requirements Specifications.
Identifying Needs and Establishing Requirements Presenters: Veronica Gasca Jennifer Rhough.
Evaluating Requirements
Requirement Engineering
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
Requirements in the product life cycle Chapter 7.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
 System Requirement Specification and System Planning.
In this generation, it is very common to have maids at home to offer a helping hand in the work. With the trend of maid service and other.
The Quality Gateway Chapter 11. The Quality Gateway.
Writing the Requirements
Stages of Research and Development

Scope Planning.
SYSTEM ANALYSIS AND DESIGN
Introduction to Requirements
Software Requirements analysis & specifications
Functional Specification
10 Stages Of the Engineering Design Process
Specify requirements In your Design Notebook, title the page “Green Design: Specify Requirements” Specify 4 design requirements (or features) that state.
AIMS Acute Inventory Management System
Requirements Factoring Themes
Planning longer answers:
What other questions do I need to ask about this picture?
The new IT Roadmap planning tool
WRITING A PARAGRAPH WRITING WORKSHOP #2.
Presentation transcript:

Testing Requirements What are the requirements for a ripe apple?

Testing Requirements Make them measurable Make them quantifiable How to quantify non-quantifiable ones Ones not possible to quantify

Quality Measure Each requirement must have a quality measure that can be tested to see if the solution meets the requirement

How to Do This - Keep Track Define all criteria for measuring the goodness of the solution Description of requirement – one sentence Purpose of requirement – why it is important? Owner(s) – who wants this requirement? Quality Measure – unambiguous test for measuring whether the solution meets the requirement Value – Customer value 1 (bells) to 10 (essential) Type – Functional or non-functional? Unique Identifier – tag for tracking the requirement Dependency – existence/change dependencies on the requirements

Consistency - Coherency Requirements must be understood by anyone who reads them Measurement of the requirements must be easily understood

Specification Clarity Does the specification contain a definition of the meaning of every essential term? If I specify “user” what does that mean? I need to specify all the details that describe “user” as part of the definition.

Completeness Does the context of the system cover everything that you need to understand for the system? Problems that the new system creates? Solves? Is there a requirement that we don’t know about because we don’t know it’s possible?

Stakeholders’ Options Have they been asked about the completeness of the requirements? Compare requirements of new system to that of the old system.

Relevance Many requirements that are suggested may not be relevant to the new system – the goal of the system. Personal bias for wants may enter into the picture. Check the stated requirements against the goal to determine relevancy.

Failure vs. Success Bad system performance = aggravation Good system performance = happiness Not meeting requirements = failure Use a Likert scale to judge performance (1 to 5) If necessary but missing = 5 point penalty or 5 point reward if there If nice to have but not critical = 3 point reward And so forth.. Sum up the numbers = design priorities This knowledge determines the priorities in the design of the system and where trade-offs should be made

Traceability Need to identify each requirement and follow its progress through the system creation Should be able to map the requirement to the solution in the end for testing

Connections After considering each requirement as unique, you must examine the connections between each requirement Event/Use cases are a good way of doing this

Requirements Specification The requirements specification should contain all requirements that are to be solved by the system As soon as we have one requirement we can begin our requirements testing. This method eliminates most of the cost of reworking a project

When you have met success with the requirements testing then you are ready to eat the sweet apples When you have met success with the requirements testing then you are ready to eat the sweet apples