1. Requirements / Specifications

2. 01/18/10CS-499G2 Requirements Determine what the customer needs (wants) the software to do  What are requirements?  An abstract statement of a needed service or system constraint  Requirements serve multiple functions  the contract for services  the basis for design  the basis for verification of the final product

3. 01/18/10CS-499G3 Requirements Properties  REQUIREMENTS MUST BE:  Clearly defined in sufficient detail  Flexible in form and content  { functionally organized, cross referenced, indexed, with a table of contents }  Feasible  Correct  Consistent  Testable  testing must be traceable to requirements  Precise  Understandable  { by all who have to read them )  Organized  Complete  SO THAT:  NOT OPEN TO INTERPRETATION

4. 01/18/10CS-499G4 Complex Problems  Many large software systems address complex problems  Problems which are so complex that they can never be fully understood  Therefore, requirements are normally less than ideal  Reasons for inconsistency  Large software systems must improve the current situation. It is hard to anticipate the effects that the new system will have on the organization  Different users have different requirements and priorities. There is a constantly shifting compromise in the requirements  System end-users and organizations who pay for the system have different requirements  Prototyping is often required to clarify requirements

5. 01/18/10CS-499G5 The requirements document  The requirements document is the official statement of what is required of the system developers  Should include both a definition and a specification of requirements  It is NOT a design document.  It should state WHAT the system should do not HOW it should do it  Attributes  Specify external system behavior  Specify implementation constraints  Easy to change  Serve as reference tool for maintenance  Record forethought about the life cycle of the system i.e. predict changes  Characterize responses to unexpected events

6. 01/18/10CS-499G6 Key points  It is very difficult to formulate a complete and consistent requirements specification  Requirements may change as the project develops, but ALWAYS GET APPROVAL FROM YOUR CUSTOMER FOR CHANGES IN THE REQUIREMENTS  The requirements document is a description for both customers and developers  Requirements errors are usually very expensive to correct after system delivery  Reviews involving the customer, management, and developers are used to validate the requirements

7. 01/18/10CS-499G7 Requirements Analysis  Understanding the customer’s requirements for a software system

8. 01/18/10CS-499G8 Problems of requirements analysis  Stakeholders don’t know what they really want  Stakeholders express requirements in their own terms  Different stakeholders may have conflicting requirements  Organizational and political factors may influence the system requirements  The requirements change during the analysis process. New stakeholders may emerge

9. 01/18/10CS-499G9 Problems Seen with Requirements  Terms/tools that customer or ordinary reader may be unfamiliar with (provide definitions or links if necessary)  Vague/imprecise statements (“fast”, “easy to use”)  Promising more than can be delivered in a semester (prioritize functions, agree on essential functions to be delivered)  Make clear what platforms/environments will be supported (prioritize if needed)  Make sure customer understands and agrees to requirements