80 likes | 84 Vues
Requirements / Specifications. 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
E N D
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 01/18/10 CS-499G 2
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 01/18/10 CS-499G 3
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 01/18/10 CS-499G 4
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 01/18/10 CS-499G 5
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 01/18/10 CS-499G 6
Requirements Analysis • Understanding the customer’s requirements for a software system 01/18/10 CS-499G 7
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 01/18/10 CS-499G 8