Plancher til Anskaffelse og kravspecifikation, Forår 2007 Lauesen: Software requirements - Styles and techniques 9. Checking and validation De fleste af.

Slides:



Advertisements
Similar presentations
System Integration Verification and Validation
Advertisements

Anskaffelse og kravspecifikation SR9_Checking. SR9: Checking and validation Kilder SR: Soren Lauesen: Software requirements - Styles and techniques. Addison-Wesley,
1 Information Systems Development (ISD) Systems Development Life Cycle Overview of Analysis Phase Overview of Design Phase CP2236: Information Systems.
1 R&D SDM 1 Software Project Management Requirements Analysis 2010 Theo Schouten.
1 Software Requirement Analysis Deployment Package for the Basic Profile Version 0.1, January 11th 2008.
Plancher til Anskaffelse og kravspecifikation, Forår 2007 Lauesen: Software requirements - Styles and techniques 4. Functional details Plancherne stammer.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Anskaffelse og kravspecifikation SR4_FuncDetail. Russisk MIG.
Anskaffelse og kravspecifikation SR3_Functions - undtagen tasks.
Function Definition  From Investigation to Specification  Defining Functions  The Universal Function Model  Identifying and Documenting Functions.
SE 555 Software Requirements & Specification Requirements Validation.
Slides for: Software requirements - Styles and techniques Soren Lauesen 3. Functional requirement styles January 2007 Slides covered by the compendium.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
Chapter 11: Testing The dynamic verification of the behavior of a program on a finite set of test cases, suitable selected from the usually infinite execution.
S R S S ystem R equirements S pecification Specifying the Specifications.
The Software Development Life Cycle: An Overview
Web Development Process Description
S/W Project Management
RUP Requirements RUP Artifacts and Deliverables
Pre-Project Activities Text Chapters 5 and 6. Pre-Project Activities 1.Contract Review 2.Development Plan 3.Quality Plan.
Typical Software Documents with an emphasis on writing proposals.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
Slides for Software requirements Styles and techniques Soren Lauesen 9. Checking and validation August 2006 © 2002, Pearson Education retains the copyright.
SoITSSpecifications of IT systems? 1 Specifications of IT systems checking and validating Jens Bennedsen and Peter Gorm Larsen
Copyright © Jerzy R. Nawrocki Requirements Review Requirements Engineering & Project.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Topics Covered: Software requirement specification(SRS) Software requirement specification(SRS) Authors of SRS Authors of SRS Need of SRS Need of SRS.
ITEC224 Database Programming
Requirements Engineering How do we keep straight what we are supposed to be building?
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
Standard SRS Copyright, 2001 © Jerzy R. Nawrocki Requirements Engineering Lecture.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
Testing Requirements What are the requirements for a ripe apple?
Slides for User interface design A software engineering perspective Soren Lauesen 9. Reflections on user interface design August 2006 © 2005, Pearson Education.
Lecture 7: Requirements Engineering
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
Requirements Engineering Southern Methodist University CSE 7316 – Chapter 3.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Chapter 4 Software Requirements
(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.
Checking and validation Chapter 9. Checking and validation.
Page 1 JUSTIFY define and validate REQUIRE- MENTS define initial management DOCUMENTS define INFRA- STRUCTURE allocated maintenance changes management.
1 Quality Attributes of Requirements Documents Lecture # 25.
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
System Requirements Specification
Requirement Engineering
Software Requirements Specification Document (SRS)
IS550: Software requirements engineering Dr. Azeddine Chikh 5. Special interfaces - combined styles.
Slides for User interface design A software engineering perspective Soren Lauesen 13. More on usability testing August 2006 © 2005, Pearson Education retains.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements (utvalgte foiler fra Kap 6 og 7 i Sommerville)
A software engineering perspective
An Overview of Requirements Engineering Tools and Methodologies*
Anskaffelse og kravspecifikation
Scope Planning.
Requirements Validation – II
Software acquisition and requirements SR3_Functions - except tasks
SYSTEM ANALYSIS AND DESIGN
System Requirements Specification
How does a Requirements Package Vary from Project to Project?
Software Requirements analysis & specifications
UNIT II.
Test Planning Mike O’Dell (some edits by Vassilis Athitsos)
A software engineering perspective
Requirements Document
Requirement Analysis.
Information Systems Development (ISD) Systems Development Life Cycle
Requirements Engineering Lecture 6
Presentation transcript:

Plancher til Anskaffelse og kravspecifikation, Forår 2007 Lauesen: Software requirements - Styles and techniques 9. Checking and validation De fleste af plancherne stammer fra lærebogen. Står planchens nummer i parentes, er planchen en tilføjelse til lærebogen.

Fig 9. Checking and validation Guest Event list Goals Tasks E/R Check that all parts match & everything is included Validate that stakeholders are happy (customer, user, developer) Where are the major risks? Quality product = meeting the spec? From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

Fig 9.1 Quality criteria for a specification IEEE 830: A good requirement spec is: Correct Each requirement reflects a need. Complete All necessary requirements included. Unambiguous All parties agree on meaning. Consistent All parts match, e.g. E/R and event list. Ranked for importance and stability Priority and expected changes per requirement. Modifiable Easy to change, maintaining consistency. Verifiable Possible to see whether requirement is met. Traceable To goals/purposes, to design/code. Additional: Traceable from goals to requirements. Understandable by customer and developer. From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

Fig 9.2A Contents check Does the spec contain: Customer, sponsor, background Business goals + evidence of tracing Data requirements (database, i/o formats, comm.state, initialize) System boundaries & interfaces Domain-level reqs (events & tasks) Product-level reqs (events & features) Design-level reqs (prototype or comm. protocol) Specification of non-trivial functions Stress cases & special events & task failures Quality reqs (performance, usability, security...) Other deliverables (documentation, training...) Glossary (definition of domain terms...) From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

Fig 9.2B Structure check Does the spec contain: Number or Id for each requirement Verifiable requirements Purpose of each requirement Examples of ways to meet requirement Plain-text explanation of diagrams, etc. Importance and stability for each requirement Cross refs rather than duplicate information Index An electronic version From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

Fig 9.2C Consistency checks Guest Event list Tasks E/R model Function list CRUD Event check Event check Support? Data exists? Data exists? Virtual windows From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

BookC E OC O E O CheckinBooked RE E O O E O CheckinNonbkdC E OC O E O Checkout E E O R E ChangeRoom R R O E O RecordService OC R PriceChangeC EDOC EDO Missing? D DC?ED? ED Fig 9.2D CREDO matrix Create, Read, Edit, Delete, Overview Guest Stay Room RoomState Service ServiceType Entity Task From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 Classic name: CRUD

Fig 9.3 Checks against surroundings Reviews Review: Developers and customer review all parts. Goal-means analysis: Goals and critical issues covered? Requirements justified? Risk assessment: Customer assesses his risk. Developers assess their risk. High-risk areas improved. Tests Simulation and walk-through Follow task descriptions. Correct? Supported? Prototype test (experiment with prototypes): Requirements meaningful and realistic? Prototype used as requirement? Pilot test (install and operate parts of system): Cost/benefit? Requirements meaningful and realistic? Just before signing? From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

Fig 9.4(A) Check list at work From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002