Writing Customer Specification

1
Writing Customer Specification

• Managing the Software Requirements Specifications
  (SRS)
• And the Customer
• Kershner/Buckley

2
Writing a Software Requirements Specification

• Partner with the customer in developing the
  software requirements
• Dont use computerese customers do not speak
  your language
• problem domain the customer knows this far
  better than you do
• You should have no loyalty to a particular
  solution. You are problem solving!

3
Writing a software requirements specification
(SRS)

• The SRS is your contract with the customer. It is
  also an additional source of information. If the
  customer is unhappy, you will hear about it. The
  reverse is also true!
• SRS This is how we see that software can solve
  your problem.
• This in an opportunity to do away with, or state,
  your assumptions in English.

4
Software Requirements Specification

• NOT a design document
• Should set out what the system should do without
  specifying how it should be done.
• One-to-one mapping from software requirements
  document onto the final system design.

5
Software Requirements Specification

• Identifying need is the starting point in the
  evolution of a computer based system.
• Analyst assists the customer in defining the
  goals of the system (product)
• What information will be produced?
• What information is to be provided?
• What functions and performances are required?

6
How do we gather data to determine a Projects
Requirements?

• Observation - Watch
• Interview - Listen
• Research - Learn

7
Characteristics of good requirements.

• 1. They are precise, with no room for
  misinterpretation by customers, users or
  implementers.
• 2. They specify just what the system must do, NOT
  how to do it.
• 3. They show conceptual integrity (a set of
  facilities that interact well with each other).

8
Constraints or Nonfunctional Requirements

• A constraint is a limitation on possible
  implementations of the system.
• A constraint does not contribute to the
  functionality of the system.
• For example
• - particular language required by customer
• - particular algorithm for one part of the system
• - particular format for temporary data storage

9
Analysis/Definition Phase

• Accuracy and completeness are the primary
  characteristics of good analysis.
• This is the plan!

10
Project Plan Must Be Complete!

• Missing information represents errors by
  omission!
• Checklists help
• Select clear-cut, rational, measurable goals for
  the product and process

11
Software Requirements Specification

• Distinguishes between Customer "needs" --
• AND
• Customer's "wants" --

12
The Interview Process

• not everything spoken is the truth
• sometimes people lie or forget facts
• most often they speak from their own ignorance or
  point of view
• interview many people to balanced information
• evaluate what you are hearing
• watch body language

13
The Interview Process

• Provide feedback
• What is it I heard?
• What do I understand?
• Rephrase critical information
• Ask the same question in a slightly different
  way, do you get the same response?

14
The Interview Process

• How many persons should attend an interview?

15
What happens after the interview?

• Immediately write down interview results.
• Research show that even in a life-and-death
  situations
• 50 of what took place is forgotten within 30
  minutes.
• Follow-up Memo

16
Managing the Customer Expect the following

• We dont like your design. We would prefer you do
  it this way (perhaps because this is how it has
  always been done.)
• We dont like the steps you took in your source
  code. We would prefer you do it this way
• And, when you follow their direction
• What do you mean it doesnt work? Youre the
  expert, why didnt you talk us out of it?

17
Managing the Customer Expect the following

• Were adopted a corporate policy where we only
  pay 85 of our invoices. Sue us.
• Since you changed our network, our copier keeps
  getting out of toner errors.
• We dont want you to finish the project, we only
  needed you for design. Well pay you for what you
  did, but you wont be needing all that staff you
  hired

18
Managing the Customer Expect the following

• We need some technology. How much will it cost?
• Is your software information superhighway
  compatible?
• Is your software Y2K compliant? (this was last
  month)

19
Managing the Customer Expect the following

• Requirements spec? We dont actually like to
  write anything down. Were afraid of industrial
  espionage.
• Give us a quote for 24K just to get the purchase
  order signed, and you can add more later.

20
Managing the Customer

• Never lie - about schedule, budget, capabilities
  to win the job, keep the job, or enhance your
  standing.
• Keep the customer appraised relentlessly - every
  week, every change, every problem, every success.

21
Managing the Customer

• Decide - as an expert - where flexibility is
  needed and design it in. Do not design
  flexibility or generality where it is not needed.
  Remember, flexibility is expensive. Better to
  implement incrementally and absorb changes
  slowly.

22
Managing the Customer

• Educate your customer - about software
  development and turning his problem space into
  your solution space.
• Learn from your customer - about his problem
  space.
• Sympathize with your customer. Understand your
  customer.

23
Managing the Customer

• Never say no, just tell how much it will cost.
• Recognize these signs of customer manipulation
• Refusal to develop the requirements combined with
  a refusal to budge from a fixed price.
• Refusal to budge from a fixed price in the face
  of a changing spec.

24
Managing the Customer

• Take extra care with the user and user interface.
  That is the only viewport into your system.
  Customers rarely view source code.

25
Requirements creep

• After the requirements have been agreed to, after
  design has occurred, during coding
• The customer calls and has
• Additions that MUST be made
• Suggested changes to existing requirements
• New information that somehow that was left out of
  earlier discussions

26
The Sensitive Issue of Money

• A Salary of 60K /year
• 30 / hr. salary
• 15 / hr. overhead (burden)
• 5 profit add 2.25 / hr
• 47.25 / hr.
• x 2000 hrs/year 94,500 per year just to keep
  you

27
The Sensitive Issue of Money

• Labor is the most expensive product component
• Companies go out of business when unprofitable
• Keep issues of money open and out front
• Your customer is trying to enhance his profit at
  your expense

28
The Sensitive Issue of Money

• Track and present costs as importantly as
  schedule.
• Work out a schedule of progress payments based on
  identifiable milestones.
• Stop work if payments stop.
• Time Materials is always better than Firm
  Fixed Price

29
Prioritization

• users are likely to ask for the moon if there
  are no limits.
• beauty should not outweigh functionality.
• help customer be realistic about expectations.
• useful to identify enhancements for future work
  once basic product is developed.

30
Requirements Validation

• Talk to the system's users?
• Talk to the customer?
• Talk is NOT cheap!
• Conversations with the customer and users is
  essential to ANY effective and efficient design!

31
Requirements evolution

• The time required to analyze requirements and to
  develop a large system may be several years.
• Over that time....
• The system's environment and the business
  objectives will almost certainly change.

32
Requirements evolution

• Constraints will be affected by changes in
  hardware technology.
• Hardware will improve.
• Anticipate hardware improvements while the
  software is being developed. .
• Changes during the projects LIFETIME should be
  assumed.
• Constraints will have to be modified while the
  software is in use.

33
Requirements evolution

• The Software requirements document should be easy
  to change Otherwise
• changes made not recorded
• system and specification are inconsistent
• maintenance problems