1 / 17

BTS330: Business Requirements Analysis using OO

Introduction to Software Requirements. BTS330: Business Requirements Analysis using OO. What are requirements? . It depends who you ask… Requirements try to describe the whole system you are creating.

rufin
Télécharger la présentation

BTS330: Business Requirements Analysis using OO

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. Introduction to Software Requirements BTS330: Business Requirements Analysis using OO

  2. What are requirements? • It depends who you ask… • Requirements try to describe the whole system you are creating. • You need to decide on a definition with all project stakeholders…your requirements document will be based on that definition.

  3. What are requirements? • Intersection of interests of stakeholders: • Customers (acquire the software) • Users • Analysts, developers, testers • Legal staff • And so on…

  4. Why requirements? • Foundation for the software system • Define them well terrific product, happy customers/stakeholders • Define them poorly  disaster

  5. Levels of Requirements • Business Organizationvision/scope • User use cases • Functional software specs

  6. Levels of Requirements • Nonfunctional • Business rules • Quality attributes • External interfaces • Constraints • And so on…

  7. Why requirements? • Foundation for the software system • Define them well terrific product, happy customers/stakeholders • Define them poorly  disaster

  8. Levels of Requirements • Business Organizationvision/scope • User use cases • Functional software specs

  9. Documenting Requirements in BTS330 • We will produce a Requirements Document as per a given template (posted to the bts330 site)

  10. Development and Management • Develop Requirements • Elicitation • Analysis • Specification • Validation

  11. Development and Management • Manage Requirements • Define baseline—SCOPE • Manage changes (**NOT EASY) • Manage project activity • Manage project plan

  12. Why are there problems? • Detailed requirements are difficult!!! • “…no other part of the work so cripples the resulting system if they’re wrong. No other part is more difficult to rectify later.” • (text, p. 15)

  13. 120 100 80 60 40 20 Requirements Design Code Test Operation Cost of Correcting Requirements Relative Cost Source: Text, p. 17

  14. Common Problems • Insufficient user involvement • Scope creep • Ambiguous requirements • Gold plating • “Paper Napkin” syndrome • Overlooked users • Inaccurate planning (bad promises)

  15. The Pain Curve Poor Requirements Good Requirements Pain Time

  16. Collaborating with Customers/Stakeholders • Take responsibility for ensuring understanding • Be respectful • Give honest/correct information • See text pg 32, “bill of rights”

  17. The Sign-off Myth • Signing off requirements • is NOT a weapon but a milestone • establishes a baseline • provides the basis for change management

More Related