Requirements Validation in Software Engineering: A Comprehensive Guide, Lecture notes of Software Engineering

how to get software requirement

Typology: Lecture notes

2018/2019

Uploaded on 12/09/2019

shahzad-ali-raja
shahzad-ali-raja 🇵🇰

2 documents

1 / 28

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
Requirements Validation – I
Lectures # 17
Instructor: Sajid khattak
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c

Partial preview of the text

Download Requirements Validation in Software Engineering: A Comprehensive Guide and more Lecture notes Software Engineering in PDF only on Docsity!

Requirements Validation – I

Lectures # 17 Instructor: Sajid khattak

Today’s Topics

  • (^) Requirements validation
  • (^) Validation techniques

Validation Objectives

  • (^) Certifies that the requirements document is an acceptable description of the system to be implemented
  • (^) Checks a requirements document for
    • (^) Completeness and consistency
    • (^) Conformance to standards
    • (^) Requirements conflicts
    • (^) Technical errors
    • (^) Ambiguous requirements

Analysis and Validation

  • (^) Analysis works with raw requirements as elicited from the system stakeholders - (^) “Have we got the right requirements” is the key question to be answered at this stage
  • (^) Validation works with a final draft of the requirements document i.e., with negotiated and agreed requirements - (^) “Have we got the requirements right” is the key question to be answered at this stage

Requirements Document

  • (^) Should be a complete version of the document, not an unfinished draft. Formatted and organized according to organizational standards

Organizational Knowledge

  • (^) Knowledge, often implicit, of the organization which may be used to judge the realism of the requirements

List of Problems

  • (^) List of discovered problems in the requirements document

Agreed Actions

  • (^) List of agreed actions in response to requirements problems. Some problems may have several corrective actions; some problems may have no associated actions

Requirements Review Process

Plan review Distribute documents Prepare for review Hold review meeting Follow-up actions Revise documents

Review Activities - 1

  • (^) Plan review
    • (^) The review team is selected and a time and place for the review meeting is chosen
  • (^) Distribute documents
    • (^) The requirements document is distributed to the review team members

Review Activities - 3

  • (^) Follow-up actions
    • (^) The chair of the review checks that the agreed actions have been carried out
  • (^) Revise document
    • (^) The requirements document is revised to reflect the agreed actions. At this stage, it may be accepted or it may be re-reviewed

Problem Actions

  • (^) Requirements clarification
  • (^) Missing information
  • (^) Requirements conflict
  • (^) Unrealistic requirement

Missing Information

  • (^) Some information is missing from the requirements document. It is the responsibility of the requirements engineers who are revising the document to discover this information from system stakeholders

Requirements Conflict

  • (^) There is a significant conflict between requirements. The stakeholders involved must negotiate to resolve the conflict