1 / 8

Requirements / Specifications

Learn about the importance of clear, flexible, and precise requirements in software development. Explore the properties of requirements, complexities in handling large projects, and tips for effective requirements analysis.

collinsjoyce
Download Presentation

Requirements / Specifications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements / Specifications

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

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

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

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

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

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

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

More Related