Transcript Requirements in the product life cycle Chapter 7

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