Writing Customer Specification Managing the Software Requirements Specifications

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

Writing a Software Requirements Specification • “Partner” with the customer in developing the software requirements – Don’t 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!

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.

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.

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?

How do we gather data to determine a Project’s Requirements? • Observation Watch • Interview Listen • Research Learn

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).

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

Analysis/Definition Phase Accuracy and completeness are the primary characteristics of good analysis. This is the plan!

Project Plan Must Be Complete! • Missing information represents errors by omission! • Checklists help • Select clear cut, rational, measurable goals for the product and process

Software Requirements Specification Distinguishes between Customer "needs" AND Customer's "wants"

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

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?

The Interview Process How many persons should attend an interview?

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

Managing the Customer Expect the following: • We don’t like your design. We would prefer you do it this way… (perhaps because this is how it has always been done…. ) • We don’t 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 doesn’t work? You’re the expert, why didn’t you talk us out of it?

Managing the Customer Expect the following: • We’re 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 don’t want you to finish the project, we only needed you for design. We’ll pay you for what you did, but you won’t be needing all that staff you hired

Managing the Customer Expect the following: • We need some technology. How much will it cost? • Is your software “information superhighway” compatible? • Is your software Y 2 K compliant? (this was last month)

Managing the Customer Expect the following: • Requirements spec? We don’t actually like to write anything down. We’re afraid of industrial espionage. • Give us a quote for $24 K just to get the purchase order signed, and you can add more later.

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.

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.

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.

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.

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.

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

The Sensitive Issue of Money • A Salary of $60 K /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

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

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”

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.

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!

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.

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.

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