Ambiguous TermImprovement acceptable, adequateDefine what constitutes acceptability and how the system can judge this. as much as practicableDon’t leave.

Slides:



Advertisements
Similar presentations
Better Specifications. What is a Specification? A Statement of the Customers Needs In the Form of Required Characteristics of a Product A Component of.
Advertisements

October DMV Team members: Lin Fry, Heather Goulet, Nancy Trefzger.
Hypothesis testing Another judgment method of sampling data.
Properties of Good Requirements Chapter 8. Understandable by end users  End-users are not often software engineers.  Terminology used must agree with.
CS 411W - Notes Product Development Documentation.
Alternate Software Development Methodologies
1 Methods of Experimental Particle Physics Alexei Safonov Lecture #21.
Computer science is a field of study that deals with solving a variety of problems by using computers. To solve a given problem by using computers, you.
Snejina Lazarova Senior QA Engineer, Team Lead CRMTeam Dimo Mitev Senior QA Engineer, Team Lead SystemIntegrationTeam Telerik QA Academy Telerik QA Academy.
Short Summary from second Meeting of the Ecodesign CF Subgroup on Large Power Transformers Brussels Distribution Transformers (medium PT) Power.
Requirements and Design
Observation Tools Overview and User Guide. Does the need to determine the impact a student's ADHD is having in the classroom or quantitatively describe.
API Design CPSC 315 – Programming Studio Fall 2008 Follows Kernighan and Pike, The Practice of Programming and Joshua Bloch’s Library-Centric Software.
Unit 211 Requirements Phase The objective of this section is to introduce software system requirements and to explain different ways of expressing these.
SE 555 Software Requirements & Specification Requirements Validation.
Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica System implementation and deployment Updated: November.
BA 427 – Assurance and Attestation Services
Non-functional requirements
Capability Maturity Model
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 24 Slide 1 Critical Systems Validation 1.
Process Capability and SPC
12.
By the end of this chapter, you should:  Understand the properties of an engineering requirement and know how to develop well-formed requirements that.
1 Shawlands Academy Higher Computing Software Development Unit.
N By: Md Rezaul Huda Reza n
Chapter 8: Systems analysis and design
Guidelines for the Development and Maintenance of RTF- Approved Measure Savings Estimates December 7, 2010 Regional Technical Forum Presented by: Michael.
Output and User Interface Design
Chapter 1 Introduction to VBA Development in Excel.
FCS - AAO - DM COMPE/SE/ISE 492 Senior Project 2 System/Software Test Documentation (STD) System/Software Test Documentation (STD)
CHAPTER 6, INDEXES, SCALES, AND TYPOLOGIES
A GENERIC PROCESS FOR REQUIREMENTS ENGINEERING Chapter 2 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia.
Feasibility Analysis What is feasibility and when should feasibility checkpoints occur? What are the four types of feasibility and what is the description.
1 The Software Development Process  Systems analysis  Systems design  Implementation  Testing  Documentation  Evaluation  Maintenance.
A Level ICT Unit Implementing CBIS’s. Support Installing a new system is disruptive and the support program will need to be planned well in advance.
The Need Specification. References  Adapted from:  Design for Electrical and Computer Engineers, first edition, by Ralph M. Ford and Chris S. Coulston.
SE: CHAPTER 7 Writing The Program
The Need Specification. References  Adapted from:  Design for Electrical and Computer Engineers, first edition, by Ralph M. Ford and Chris S. Coulston.
Systems Life Cycle. Know the elements of the system that are created Understand the need for thorough testing Be able to describe the different tests.
(1) Unit Testing and Test Planning CS2110: SW Development Methods These slides design for use in lab. They supplement more complete slides used in lecture.
LESSON 3. Properties of Well-Engineered Software The attributes or properties of a software product are characteristics displayed by the product once.
The Software Development Process
Fitness Cases Are input-output pairs describing the output a program should produce given the particular input value. The fitness of an individual is usually.
Chapter 13: Software Quality Project Management Afnan Albahli.
The Practice of Social Research Chapter 6 – Indexes, Scales, and Typologies.
Written by Changhyun, SON Chapter 5. Introduction to Design Optimization - 1 PART II Design Optimization.
SOFTWARE ENGINEERING MCS-2 LECTURE # 2. ATTRIBUTES OF GOOD S/W  Maintainability;  S/w should be written in such a way that it may evolve to meet the.
Human-Computer Interaction Design process Task and User Characteristics Guidelines Evaluation ISE
Sampling technique  It is a procedure where we select a group of subjects (a sample) for study from a larger group (a population)
Dynamic Testing.
1 The Software Development Process ► Systems analysis ► Systems design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance.
CS628 - Object Oriented Analysis And Design. The Four Pillars of Successful Software Development -Avoid Classic Mistakes -Apply Development Fundamentals.
The Testing Process I1 Testing Programs Even a non-programmer can test a program. In fact each of us evaluates a program when we run it for a first time.
Dynamic Black-Box Testing Part 1 What is dynamic black-box testing? How to reduce the number of test cases using: Equivalence partitioning Boundary value.
 System Requirement Specification and System Planning.
Maitrayee Mukerji. INPUT MEMORY PROCESS OUTPUT DATA INFO.
IS Development Methodology
MANAGERIAL ECONOMICS 12th Edition
Classifications of Software Requirements
Strategic Capacity Management
System Design Ashima Wadhwa.
Input Space Partition Testing CS 4501 / 6501 Software Testing
Requirements Management
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Part B – Structured Exception Handling
Capability Maturity Model
SDLC Phases Systems Design.
Capability Maturity Model
Overview Activities from additional UP disciplines are needed to bring a system into being Implementation Testing Deployment Configuration and change management.
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Presentation transcript:

Ambiguous TermImprovement acceptable, adequateDefine what constitutes acceptability and how the system can judge this. as much as practicableDon’t leave it up to the developers to determine what’s practicable. Make it a TBD and set a date to find out. at least, at minimum, not more than, not to exceed Specify the minimum and maximum acceptable values. betweenDefine whether the end points are included in the range. depends onDescribe the nature of dependency. Does another system input to this system, must other software be installed before your software can run, or does your system rely on another to perform some calculations or services?

Ambiguous TermImprovement efficientDefine how efficiently the system uses resources, how quickly it performs specific operations, or how easy it is for people to use. flexibleDescribe the ways in which the system must change in response to changing conditions or business needs. improved, better, faster, superior Quantify how much better or faster constitutes adequate improvement in a specific functional area. including, including but not limited to, and so on, such as The list of items should include all possibilities. Otherwise, it can’t be used for design or testing. maximize, minimize, optimizeState the maximum and minimum acceptable values of some parameter.

Ambiguous TermImprovement normally, ideallyAlso describe the system’s behavior under abnormal or non-ideal conditions. optionallyClarify whether this means a system, user or developer choice. reasonable, when necessary, where appropriate Explain how to make this judgement. robustDefine how the system is to handle exceptions and respond to unexpected operating conditions. seamless, transparent, graceful Translate the user’s expectations into specific observable product characteristics. severalState how many or provide the minimum and maximum bounds of a range.

Ambiguous TermImprovement shouldn’tTry to state requirements as positives, describing what the system will do. state-of-the-artDefine what this means. sufficientSpecify how much of something constitutes sufficiency. support, enableDefine exactly what functions the system will perform that constitute supporting some capability. user-friendly, simple, easyDescribe system characteristics that will achieve the customer’s usage needs and usability expectations.