Requirements Validation Requirements Management p. 1 R. Kuehl/ J. - - PowerPoint PPT Presentation

▶
requirements validation
SMART_READER_LITE
LIVE PREVIEW

Requirements Validation Requirements Management p. 1 R. Kuehl/ J. - - PowerPoint PPT Presentation

Jan 29, 2024 316 likes •603 views

Requirements Validation Requirements Management p. 1 R. Kuehl/ J. Scott Hawker R I T Software Engineering Two Views of Quality Assessment Validation Do requirements correctly capture stakeholder goals, needs, and constraints?

slide-1
SLIDE 1
  • R. Kuehl/ J. Scott Hawker
  • p. 1

R I T

Software Engineering

Requirements Validation Requirements Management

slide-2
SLIDE 2
  • R. Kuehl/ J. Scott Hawker
  • p. 2

R I T

Software Engineering

Two Views of Quality Assessment

 Validation  Do requirements correctly capture stakeholder goals, needs, and constraints?  Do stakeholders have a common understanding of the requirements?

  • Consensus on trade-offs for conflicting needs?

 Requirement attributes sufficiently understood?  Complete, unambiguous, testable, consistent, modifiable, etc.?

 “Are we building the right product?”  Verification  Does deployed system actually satisfy requirements?

  • Ensure correctness from activity to activity in the

software development process

 “Did we build the product right?”

slide-3
SLIDE 3
  • R. Kuehl/ J. Scott Hawker
  • p. 3

R I T

Software Engineering

Requirements Validation Challenges

 What is truth and what is knowable?

 Requirements are an expression of the real world problem  Validation is observation the problem is expressed correctly  Cannot prove only refute correctness through

  • bservation

 Stakeholder disagreement

slide-4
SLIDE 4
  • R. Kuehl/ J. Scott Hawker
  • p. 4

R I T

Software Engineering

Requirements Specification Validation

 Is this subset of requirements ready for design and implementation?  If valid, baseline this subset and manage change

slide-5
SLIDE 5
  • R. Kuehl/ J. Scott Hawker
  • p. 5

R I T

Software Engineering

Negotiation Principles

 Use a four step solution process  Separate the people from the problem  Focus on interests, not positions  Invent options for mutual gain  Insist on using objective criteria

Fisher & Ury, Getting to Yes, 1981.

slide-6
SLIDE 6
  • R. Kuehl/ J. Scott Hawker
  • p. 6

R I T

Software Engineering

Negotiation

 There are various theories and techniques for negotiation – good knowledge to have in your toolset  Here is an example based on a process called Theory W Win-Win for requirements negotiation between stakeholders and software engineers

Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach; Barry Boehm, et al

Win Conditions (Objectives or Goals) Conflicts

  • 1. Identify Win

Conditions

  • 2. Identify Conflicts

(Risks and Uncertainties)

  • 3. Identify Points
  • f Agreement

(Win Conditions are Satisfied)

  • 4. Negotiate conflicts
  • 5. Alternative win conditions

that resolve conflicts

slide-7
SLIDE 7
  • R. Kuehl/ J. Scott Hawker
  • p. 7

R I T

Software Engineering

Requirements Validation Techniques

 Reviews  Interface prototyping  Analysis modeling  Architecture - incremental design (quality attributes)  Acceptance tests  Observation of operational system

  • Real users, systems, and world environment
  • Alpha, beta versions

Project Cycle

slide-8
SLIDE 8
  • R. Kuehl/ J. Scott Hawker
  • p. 8

R I T

Software Engineering

Review Techniques

 Personal review  Informal peer review  Informal walkthrough  Formal inspection 1 10 100

Defects found in requirements would cost …  10 times more to remove if not discovered until implementation  100 times more to remove if not discovered until deployment

slide-9
SLIDE 9
  • R. Kuehl/ J. Scott Hawker
  • p. 9

R I T

Software Engineering

Inspection Guidelines

 Plan and prepare for the inspection

 Review the inspection process  Prepare a task list and schedule  Assign inspection roles

  • Author, moderator, reader, recorder

 Assemble inspection materials  Prepare inspector checklists  Review ahead of the meeting

 Set an agenda for the inspection meeting and stick to it

See the Defect Checklist in Wiegers Fig. 17-4

The inspection pattern

slide-10
SLIDE 10
  • R. Kuehl/ J. Scott Hawker
  • p. 10

R I T

Software Engineering

Inspection Guidelines (cont)

 The product should be inspected in small “chunks”  Meetings should be at least one hour, but no more than two hours  Inspect the work product, not the author  Limit debate and rebuttal in the inspection meeting  Identify problems, do not attempt to solve them  Take written notes of the meeting; collect effort and defect data  Limit the number of participants and insist upon advanced preparation

slide-11
SLIDE 11
  • R. Kuehl/ J. Scott Hawker
  • p. 11

R I T

Software Engineering

Acceptance Tests

 Designing test cases will reveal problems with requirements (even if you don’t execute the tests)

 Functional requirements and quality attributes (fit criteria)  Vague or ambiguous requirements inhibit test case definition

 Develop requirements and tests together  Have customers write acceptance criteria

 Avoids tester pattern bias – results can be surprising!

 Write test cases for normal flow, alternative flows, and exceptions – i.e., achieve test coverage

slide-12
SLIDE 12
  • R. Kuehl/ J. Scott Hawker
  • p. 12

R I T

Software Engineering

Requirements Define Tests for Verification (Tests are a statement of requirements!)

Black Box Software Tests Business and User Needs Product/ System Reqts. Functional Reqts. Software Impl. Software /System Test Plan System Tests Acceptance Tests Software Design Unit and Integration Tests

System verification: Confirm that the system design and implementation satisfies the (validated) requirements

slide-13
SLIDE 13
  • R. Kuehl/ J. Scott Hawker
  • p. 13

R I T

Software Engineering

Requirements Management

slide-14
SLIDE 14
  • R. Kuehl/ J. Scott Hawker
  • p. 14

R I T

Software Engineering

Requirements Management Activities

 Requirements change control  Trace requirements element relationships through the life cycle  Version control  Track requirements attributes (priority, volatility, cost, benefit, etc.) Someone on the team should “own” the requirements management activities

slide-15
SLIDE 15
  • R. Kuehl/ J. Scott Hawker
  • p. 15

R I T

Software Engineering

Establish Requirements Baseline

 Set of requirements committed to implementation in a specific increment or release  Agreement between the stakeholders and the developers

slide-16
SLIDE 16
  • R. Kuehl/ J. Scott Hawker
  • p. 16

R I T

Software Engineering

Managing Change

 Software requirements will change – additions, deletions, modifications  Uncontrolled change is a common source of project chaos, schedule slips, and quality problems.  Every proposed change is carefully considered and approved  Approved changes are communicated  The change process is as simple as possible (but no simpler)

Change always has a price!

slide-17
SLIDE 17
  • R. Kuehl/ J. Scott Hawker
  • p. 17

R I T

Software Engineering

Requirements Change Activities

 Propose changes  Analyze the impact of the proposed change

 Software artifacts  Cost/benefit/risk trade-offs  Business impact

 Make decisions about the proposal  Update plans  Implement the change

 Update ALL software artifacts  Test changed functionality and regression test unchanged functionality

Don’t agree to backdoor change requests!

slide-18
SLIDE 18
  • R. Kuehl/ J. Scott Hawker
  • p. 18

R I T

Software Engineering

The Change Control Board

Change Control Board

Business and Development Stakeholders

Change Request Change Decision: Approved, Rejected, Deferred

Impact Analysis

Baseline Requirements Update

slide-19
SLIDE 19
  • R. Kuehl/ J. Scott Hawker
  • p. 19

R I T

Software Engineering

Requirements Tracing

 Documents the dependencies between requirements and other system elements, such as:

 Use cases  Business rules  Architecture and design components  Code modules  Test cases

 Claim: the benefits of tracing requirements, and the risks of not doing so, are greater than the cost

slide-20
SLIDE 20
  • R. Kuehl/ J. Scott Hawker
  • p. 20

R I T

Software Engineering

Why Trace Requirements?

 Help assess change impact  Displays test coverage  Facilitates reuse, refactoring, maintenance  Helps project management:

 Planning and scheduling, resource allocation  Estimating and tracking feature costs  Tracking project status

  • e.g., requirements count as a project metric
slide-21
SLIDE 21
  • R. Kuehl/ J. Scott Hawker
  • p. 21

R I T

Software Engineering

Traceability Matrix

 A requirements traceability matrix is used to maintain and trace links between software requirements and related project elements

User Requirement Functional Requirement Package Class Method TestCase UC-28 ChangeGrade UserFeatures Student ChangeGrade() Student1

slide-22
SLIDE 22
  • R. Kuehl/ J. Scott Hawker
  • p. 22

R I T

Software Engineering

Version Control

 Requirements are allocated to development iterations  Requirements change  Just like code, requirements need some form

  • f version control

 Alternatives:

 Label requirements and SRS revisions  Version control tool  Use a requirements management tool

slide-23
SLIDE 23
  • R. Kuehl/ J. Scott Hawker
  • p. 23

R I T

Software Engineering

Track Requirements Attributes

 A requirements attribute matrix is used to maintain the state or status of requirement attributes being tracked

Requirement ID Requirement Name Priority Status Due Date Release UC-28 ChangeGrade High In Test 4/26/10 R1

slide-24
SLIDE 24
  • R. Kuehl/ J. Scott Hawker
  • p. 24

R I T

Software Engineering

Requirements Management: The Essential Activity

 Make informed decisions in response to new or changed requirements

 Defer lower-priority requirements  Increase staff  Increase staff time (overtime)  Slip the schedule  Let the quality suffer  Just say No! (and explain why)

TANSTAAFL: “Their Ain’t No Such Thing as a Free Lunch

… anything free costs twice as much in [the] long run or turns out worthless.”

  • - Manuel, in Robert A. Heinlein’s The Moon is a Harsh Mistress
slide-25
SLIDE 25
  • R. Kuehl/ J. Scott Hawker
  • p. 25

R I T

Software Engineering

Validation and Management Discussion

If you were the project leader at your last job, how would you improve the practices of requirements validation and management?

slide-26
SLIDE 26
  • R. Kuehl/ J. Scott Hawker
  • p. 26

R I T

Software Engineering

Requirements Management Tools

 Manage requirements content, attributes, and change  Typical features:

 Manage requirements versions and changes  Access control  Store and sort on requirements attributes  Manage and display requirements tracing  Track requirement status

slide-27
SLIDE 27
  • R. Kuehl/ J. Scott Hawker
  • p. 27

R I T

Software Engineering

Some Tools

Tool Vendor Database-Centric or Document-Centric Caliber Analyst Borland Software http://www.borland.com/ Database C.A.R.E. (Computer- Aided Requirements Engineering) SOPHIST Group

http://www.sophist.de/sopgroupeng.nsf/( ynDK_framesets)/Main

Database DOORS IBM Rational DOORS

http://www- 01.ibm.com/software/awdtools/doors/produ ctline/

Database RequisitePro IBM Rational Software

http://www- 306.ibm.com/software/awdtools/reqpro/

Document RMTrak RBC, Inc. http://www.rmtrak.com/ Document Dimensions RM Serena Software http://www.serena.com/products/dime nsions/dimensions-requirements.html Database Open Source Requirements Management Tool Source Forge http://sourceforge.net/projects/osrmt/ Database

Updated version of Wieger’s Table 21-1