Requirements in the product life cycle Chapter 7

Project inception Goals Scope Vision Cost/benefit Stakeholders

Contracts In house development Product development COTS purchase Tender –Pre qualification –Contract Contract development

Comparing proposals You want to make sure somebody sends a proposal! Normal requirements Weakest requirements Total points Understand the customers problems –They will try to trick you at times !

Comparing proposals Track record Solidity Manipulation of weights Kickbacks Base price plus options Choosing the winner is part art and part science

Rating the requirements Many analysts claim that requirements are mandatory, at the least the functional ones, but this is not quite true in practice Assign priorities (not all high!) Options Open metrics and open targets

Writing a proposal Essential that you convince your customer that you understand the problem and business need Hiring an expensive proposal writer is not out of the question Do not flood the customer with pictures and documentation –Don’t do it on the project either ;-)

Writing a proposal Open metrics and open targets Use assumptions as necessary Feature based requirements High risk requirements –Different suppliers treat these in different ways A high price is not always bad if you can convince your customer of the value –Other suppliers do not understand problem

Design and programming How to ensure that requirements are met –Direct implementation –Verification –Embedded trace information

Types of requirements to verify Data requirements Design level requirements Feature style Task support Usability requirement Performance requirements Goal level requirements

Acceptance testing and delivery Installation test System test Deployment test Acceptance test Operational test

Requirements management Requirements are always changing Must start managing change during the beginning of the project Continues long after delivery This can be managed (CCB) –Reporting –Analysis –Decision –Reply –Carry out decision

Release planning Most often projects are delivered in phases, not all at once –Surprise –Risky project –Iterative development –Product development Commercial product releases –What features should be in the next release?

Tracing and tool support Validation Consistency checks Verification Tools support –Requirements are treated as objects with attributes

Elicitation Chapter 8

Introduction The process of finding and formulating requirements First elicit overall goals of the system Then information about present work and present problems Then detailed issues about what the system shall deal with Then possible solutions

Elicitation barriers Cannot express what they need Difficulty explaining tasks Specify a solution instead of a demand Difficult to imagine new ways of doing things Conflicting views General resistance to change Gold plating Demands change over time

Work products Description of the present work in the environment Present problems in the domain List of goals and critical issues Ideas for the large scale structure of future systems Realistic possibilities Consequences and risks Commitment from stakeholders Conflict resolution from stakeholders Final requirements Priorities of requirements Checks for completeness, etc Interaction diagrams, class models, etc

User involvement Members of design teams or workshops Knowledge sources of things are currently done Brainstorm participants Test users UI reviewers Member of the steering committees

Elicitation techniques Stakeholder analysis Interviewing Observation Task demonstration Document studies Questionnaires Brainstorming Focus groups Domain workshops Design workshops Prototyping Pilot experiments Study similar companies Ask suppliers Cost/benefit analysis